diff --git a/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx b/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx index 2670ffac4..c489791d3 100644 --- a/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx +++ b/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx @@ -74,8 +74,8 @@ The Java and TypeScript codegen allow the use of package name and package ID (if PQS supports using package-name (specified in `daml.yaml`) instead of package-id. When specifying a template/interface/choice name, simply substitute any package-id with the package-name (eg. now `register:DA.Register:Token`) instead of the old `deadbeefpackageidhex:DA.Register:Token` format. This applies to template filters and SQL queries (eg. via the `active()` function). These functions will always return all versions of a given identifier. Qualified name can be: -- fully qualified, e.g. `<package-name>:<module-path>:<template-name>` -- partially qualified, e.g. `<module-path>:<template-name>` +- fully qualified, e.g. `::` +- partially qualified, e.g. `:` Qualified names cannot be ambiguous. @@ -1366,9 +1366,9 @@ You can find the in-depth upgrading model, which can be used as a reference for ## Package Selection in the Ledger API -Until the introduction of SCU, template IDs in requests to the Ledger API were all of the form `<package-id>:<module-name>:<template-name>`. For disambiguation, going forward, we refer to this format as **by-package-id template IDs**. +Until the introduction of SCU, template IDs in requests to the Ledger API were all of the form `::`. For disambiguation, going forward, we refer to this format as **by-package-id template IDs**. -With SCU, we introduce a more generic template reference of the format `#<package-name>:<module-name>:<template-name>` (**by-package-name template ID**) that scopes templates by package-name, allowing version-agnostic addressing of templates on the Ledger API. It serves as a reference to all template IDs with the qualified name `<module-name>:<template-name>` from all packages with the name `package-name` known to the Ledger API server. +With SCU, we introduce a more generic template reference of the format `#::` (**by-package-name template ID**) that scopes templates by package-name, allowing version-agnostic addressing of templates on the Ledger API. It serves as a reference to all template IDs with the qualified name `:` from all packages with the name `package-name` known to the Ledger API server. `By-package-name template ID` addressing is supported for all packages and is possible on both the write path (command submission) and read path (Ledger API queries). @@ -1876,7 +1876,7 @@ Package ID selection preference: preferences apply to JSON Ledger API where you ### PQS -To match the package-name changes to the Ledger API, PQS has changed how packages are selected for queries. All queries that take a Daml identity in the form `<package-id>:<module-name>:<template-name>` now take a package name in place of package ID. Note that this differs from the Ledger API in that the `\#` prefix is not required for PQS, as PQS has dropped direct package ID queries. Queries for package names return all versions of a given contract, alongside the package version and package ID for each contract. +To match the package-name changes to the Ledger API, PQS has changed how packages are selected for queries. All queries that take a Daml identity in the form `::` now take a package name in place of package ID. Note that this differs from the Ledger API in that the `\#` prefix is not required for PQS, as PQS has dropped direct package ID queries. Queries for package names return all versions of a given contract, alongside the package version and package ID for each contract. If you still need to perform a query with an explicit package ID, you can either use a previous version of PQS or add the following filter predicate to your query: `SELECT \* FROM active('my_package:My.App:MyTemplate') WHERE package_id = 'my_package_id'` diff --git a/docs-main/appdev/modules/m3-building-packaging.mdx b/docs-main/appdev/modules/m3-building-packaging.mdx index 6a5e4bdd2..3aac60e3f 100644 --- a/docs-main/appdev/modules/m3-building-packaging.mdx +++ b/docs-main/appdev/modules/m3-building-packaging.mdx @@ -142,11 +142,11 @@ All Daml packages require a daml.yaml file. Create this file at the root of your - SDK Version: call `dpm version` to determine the installed SDK versions - Package name: lower-skewer-case name that is unique to your package and company. -Add the following to your `daml.yaml`, replacing the `<place-holders>` as appropriate. +Add the following to your `daml.yaml`, replacing the `` as appropriate. ```yaml sdk-version: -name: <your-package-name> +name: version: 1.0.0 source: daml dependencies: @@ -195,7 +195,7 @@ See Environment Variable Interpolation for more information. ## How to build Daml packages -To build a single package, navigate to its root directory and run `dpm build`. To build all packages in a multi-package project, navigate to the directory containing the `multi-package.yaml` and run `dpm build --all`. By default these will create a Daml Archive (.dar) file for each package built in `<package-directory>/.daml/dist/<package-name>-<package-version>.dar`. .dar files are used both for uploading to the Canton Ledger, and for package dependencies. The location where the .dar is created can be overridden using the `--output` flag for dpm build, which can also be provided in the `daml.yaml` file under the `build-options` field: +To build a single package, navigate to its root directory and run `dpm build`. To build all packages in a multi-package project, navigate to the directory containing the `multi-package.yaml` and run `dpm build --all`. By default these will create a Daml Archive (.dar) file for each package built in `/.daml/dist/-.dar`. .dar files are used both for uploading to the Canton Ledger, and for package dependencies. The location where the .dar is created can be overridden using the `--output` flag for dpm build, which can also be provided in the `daml.yaml` file under the `build-options` field: ```yaml build-options: diff --git a/docs-main/appdev/modules/m4-backend-dev.mdx b/docs-main/appdev/modules/m4-backend-dev.mdx index dc34a9d3e..b0f2cf7f3 100644 --- a/docs-main/appdev/modules/m4-backend-dev.mdx +++ b/docs-main/appdev/modules/m4-backend-dev.mdx @@ -273,7 +273,7 @@ Compile the new Daml module and regenerate the Java bindings. If you're working ```bash dpm build -dpm codegen-java <DAR-file> -o <output-dir> +dpm codegen-java -o ``` In cn-quickstart, the Gradle build handles both steps. Run the Daml build task, which compiles the `.daml` files into a DAR and then runs the transcode codegen plugin to produce Java classes: diff --git a/docs-main/appdev/modules/m4-json-api-tutorial.mdx b/docs-main/appdev/modules/m4-json-api-tutorial.mdx index 829fefa7d..36959aec3 100644 --- a/docs-main/appdev/modules/m4-json-api-tutorial.mdx +++ b/docs-main/appdev/modules/m4-json-api-tutorial.mdx @@ -74,7 +74,7 @@ First, ensure you can run the Canton sandbox with the JSON Ledger API enabled. Start the Canton sandbox, providing a path to the created `dar` file: ``` -dpm sandbox --json-api-port 7575 --dar <path_to_json_tests_project>/.daml/dist/json-tests-0.0.1.dar +dpm sandbox --json-api-port 7575 --dar /.daml/dist/json-tests-0.0.1.dar ``` @@ -291,7 +291,7 @@ Before starting, ensure you have the following installed: Open a terminal and navigate to the JSON Ledger API example folder: ``` -cd <canton_installation>/examples/09-json-ledger-api +cd /examples/09-json-ledger-api ``` Start Canton: @@ -303,7 +303,7 @@ Start Canton: Once the Canton console is ready, open a new terminal and navigate to the TypeScript example folder: ``` -cd <canton_installation>/examples/09-json-ledger-api/typescript +cd /examples/09-json-ledger-api/typescript ``` ### Running the Example diff --git a/docs-main/appdev/quickstart/json-api.mdx b/docs-main/appdev/quickstart/json-api.mdx index af5c42c7f..6403bb8f2 100644 --- a/docs-main/appdev/quickstart/json-api.mdx +++ b/docs-main/appdev/quickstart/json-api.mdx @@ -240,7 +240,7 @@ The desired value may vary between SDK versions. You can identify the main packa The format follows: ``` text -<project-name>--<package-id> +-- ``` At the time of publication, the repeating string of `b59ffbf847ac36fee1a4a743864274c5d8ab6f02ea8899f49fb5347e9978543f` is the project ID that we seek. diff --git a/docs-main/appdev/reference/daml-lf-reference.mdx b/docs-main/appdev/reference/daml-lf-reference.mdx index 926f83db8..152c8009a 100644 --- a/docs-main/appdev/reference/daml-lf-reference.mdx +++ b/docs-main/appdev/reference/daml-lf-reference.mdx @@ -501,18 +501,18 @@ A DAR is actually a zip file which contains many different files, all of which w META-INF/MANIFEST.MF ... -mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf -mypkg-1.0.0-<mypkg-package-id>/Main.daml -mypkg-1.0.0-<mypkg-package-id>/Main.hi -mypkg-1.0.0-<mypkg-package-id>/Main.hie -mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf +mypkg-1.0.0-/dep-1.0.0-.dalf +mypkg-1.0.0-/Main.daml +mypkg-1.0.0-/Main.hi +mypkg-1.0.0-/Main.hie +mypkg-1.0.0-/mypkg-1.0.0-.dalf ``` The majority of the files in a given DAR will be DALF files (`.dalf`). Each `.dalf` file contains the entire compiled code for a specific package. -One of the DALF files will be the "main" or "primary" package that the DAR was compiled from - this DALF will contain the definitions of templates, interfaces, datatypes, and functions that were originally described in the Daml code that the DAR was compiled from. In this case, that is the `mypkg-1.0.0-<mypkg-package-id>.dalf` file listed above. +One of the DALF files will be the "main" or "primary" package that the DAR was compiled from - this DALF will contain the definitions of templates, interfaces, datatypes, and functions that were originally described in the Daml code that the DAR was compiled from. In this case, that is the `mypkg-1.0.0-.dalf` file listed above. -All of the other DALF files will be for dependency packages of that "main" package, which are required to run the package. This includes the `dep-1.0.0-<dep-package-id>.dalf` file, as well as many DALF files for the `daml-prim` and `daml-stdlib` libraries. +All of the other DALF files will be for dependency packages of that "main" package, which are required to run the package. This includes the `dep-1.0.0-.dalf` file, as well as many DALF files for the `daml-prim` and `daml-stdlib` libraries. Aside from these files, there will be: @@ -603,18 +603,18 @@ Created .daml/dist/mypkg-1.0.0.dar DAR archive contains the following files: ... -mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf -mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf -mypkg-1.0.0-<mypkg-package-id>/MyPkg.daml -mypkg-1.0.0-<mypkg-package-id>/MyPkg.hi -mypkg-1.0.0-<mypkg-package-id>/MyPkg.hie +mypkg-1.0.0-/dep-1.0.0-.dalf +mypkg-1.0.0-/mypkg-1.0.0-.dalf +mypkg-1.0.0-/MyPkg.daml +mypkg-1.0.0-/MyPkg.hi +mypkg-1.0.0-/MyPkg.hie META-INF/MANIFEST.MF DAR archive contains the following packages: ... -dep-1.0.0-<dep-package-id> "<dep-package-id>" -mypkg-1.0.0-<mypkg-package-id> "<mypkg-package-id>" +dep-1.0.0- "" +mypkg-1.0.0- "" ``` The first section reports all of the files in DAR, and the second section reports the package name and package ID for every DALF in the archive. @@ -629,24 +629,24 @@ In addition to the human-readable output, you can also get the output as JSON. T > dpm damlc inspect-dar --json .daml/dist/mypkg-1.0.0.dar { "files": [ - "mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf", - "mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf", - "mypkg-1.0.0-<mypkg-package-id>/Main.daml", - "mypkg-1.0.0-<mypkg-package-id>/Main.hi", - "mypkg-1.0.0-<mypkg-package-id>/Main.hie", + "mypkg-1.0.0-/dep-1.0.0-.dalf", + "mypkg-1.0.0-/mypkg-1.0.0-.dalf", + "mypkg-1.0.0-/Main.daml", + "mypkg-1.0.0-/Main.hi", + "mypkg-1.0.0-/Main.hie", "META-INF/MANIFEST.MF" ], - "main_package_id": "<mypkg-package-id>", + "main_package_id": "", "packages": { - "<mypkg-package-id>": { + "": { "name": "mypkg", "path": - "mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf", + "mypkg-1.0.0-/mypkg-1.0.0-.dalf", "version": "1.0.0" }, - "<dep-package-id>": { + "": { "name": "dep", - "path": "mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf", + "path": "mypkg-1.0.0-/dep-1.0.0-.dalf", "version": "1.0.0" } } @@ -657,14 +657,14 @@ Note that `name` and `version` will be `null` for packages in Daml-LF \< 1.8. ## Inspecting the main package of a DAR file -If you'd like to inspect the code inside the main package of a DAR, the Daml compiler provides the `inspect` tool; running `dpm damlc inspect <path-to-dar-file>` prints all of the code in the main package of that DAR file in a human-readable format. +If you'd like to inspect the code inside the main package of a DAR, the Daml compiler provides the `inspect` tool; running `dpm damlc inspect ` prints all of the code in the main package of that DAR file in a human-readable format. For example, run the `inspect` tool on the DAR produced in the previous section: ``` sh # Human-readable dump of code in "mypkg" package inside of "mypkg" DAR > dpm damlc inspect .daml/dist/mypkg-1.0.0.dar -package <mypkg-package-id> +package daml-lf 2.1 metadata mypkg-1.0.0 @@ -674,7 +674,7 @@ module Main where ## Inspecting a DALF file -The `inspect` tool also accepts DALF files; running `dpm damlc inspect <path-to-dalf-file>` on a DALF file prints all of the code in that DALF file. +The `inspect` tool also accepts DALF files; running `dpm damlc inspect ` on a DALF file prints all of the code in that DALF file. We can unzip a DAR to access its dalfs and inspect them, for example with the DAR from the previous section: @@ -683,8 +683,8 @@ We can unzip a DAR to access its dalfs and inspect them, for example with the DA > unzip .daml/dist/mypkg-1.0.0.dar # Human-readable dump of code in dep -> dpm damlc inspect mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf -package <dep-package-id> +> dpm damlc inspect mypkg-1.0.0-/dep-1.0.0-.dalf +package daml-lf 2.1 metadata dep-1.0.0 @@ -696,8 +696,8 @@ We can even inspect the main package of a DAR this way, even though running `ins ``` sh # Identical to dump from `dpm damlc inspect .daml/dist/mypkg-1.0.0.dar` -> dpm damlc inspect mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf -package <mypkg-package-id> +> dpm damlc inspect mypkg-1.0.0-/mypkg-1.0.0-.dalf +package daml-lf 2.1 metadata mypkg-1.0.0 @@ -739,39 +739,39 @@ Decoders for reading DALFs are instances of `GenReader[X]`, which provides the m - `val ArchiveReader: GenReader[ArchivePayload]` - Run `ArchiveReader.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` to parse out the `ArchivePayload` of a dalf file. + Run `ArchiveReader.readArchiveFromFile(new java.io.File(""))` to parse out the `ArchivePayload` of a dalf file. - `val ArchiveDecoder: GenReader[(PackageId, Ast.Package)]` - Run `ArchiveDecoder.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` to parse out the `(Ref.PackageId, Ast.Package)` of a dalf file. + Run `ArchiveDecoder.readArchiveFromFile(new java.io.File(""))` to parse out the `(Ref.PackageId, Ast.Package)` of a dalf file. - `val ArchiveParser: GenReader[DamlLf.Archive]` - Run `ArchiveParser.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` to parse out the `DamlLf.Archive` of a dalf file. + Run `ArchiveParser.readArchiveFromFile(new java.io.File(""))` to parse out the `DamlLf.Archive` of a dalf file. Decoders for reading DARs are instances of `GenDarReader`, which provides the method `readArchiveFromFile(file: java.io.File): Either[Error, Dar[X]]`. - `val DarReader: GenDarReader[ArchivePayload]` - Run `DarReader.readArchiveFromFile(new java.io.File("<path-to-dar>"))` to parse out the `Dar[ArchivePayload]` of a dar file. + Run `DarReader.readArchiveFromFile(new java.io.File(""))` to parse out the `Dar[ArchivePayload]` of a dar file. - `val DarDecoder: GenDarReader[(PackageId, Ast.Package)]` - Run `DarDecoder.readArchiveFromFile(new java.io.File("<path-to-dar>"))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file. + Run `DarDecoder.readArchiveFromFile(new java.io.File(""))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file. - `val DarParser: GenDarReader[DamlLf.Archive]` - Run `DarParser.readArchiveFromFile(new java.io.File("<path-to-dar>"))` to parse out the `Dar[DamlLf.Archive]` of a dar file. + Run `DarParser.readArchiveFromFile(new java.io.File(""))` to parse out the `Dar[DamlLf.Archive]` of a dar file. Decoders for reading DARs are instances of `GenUniversalArchiveReader`, which provides the method `readFile(file: java.io.File): Either[Error, Dar[X]]`. - `val UniversalArchiveReader: GenUniversalArchiveReader[ArchivePayload]` - Run `UniversalArchiveReader.readFile(new java.io.File("<path-to-dar-or-dalf>"))` to parse out the `Dar[ArchivePayload]` of a dar file. + Run `UniversalArchiveReader.readFile(new java.io.File(""))` to parse out the `Dar[ArchivePayload]` of a dar file. - `val UniversalArchiveDecoder: GenUniversalArchiveReader[(PackageId, Ast.Package)]` - Run `UniversalArchiveDecoder.readFile(new java.io.File("<path-to-dar-or-dalf>"))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file. + Run `UniversalArchiveDecoder.readFile(new java.io.File(""))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file. ### Example diff --git a/docs-main/appdev/reference/protobuf-history/index.mdx b/docs-main/appdev/reference/protobuf-history/index.mdx index cc64a5e85..470ec5f12 100644 --- a/docs-main/appdev/reference/protobuf-history/index.mdx +++ b/docs-main/appdev/reference/protobuf-history/index.mdx @@ -32,7 +32,7 @@ description: "Descriptor-backed protobuf API history grouped by package."
Version filter
-
stable Canton release bundles >= 3.2.0
+
stable Canton release bundles >= 3.2.0
diff --git a/docs-main/global-synchronizer/production-operations/canton-console.mdx b/docs-main/global-synchronizer/production-operations/canton-console.mdx index 84658d884..93a470aa6 100644 --- a/docs-main/global-synchronizer/production-operations/canton-console.mdx +++ b/docs-main/global-synchronizer/production-operations/canton-console.mdx @@ -68,7 +68,7 @@ Given a remote config file, start a local Canton console configured to execute c Additionally, you can use the remote configuration to run a script: ```bash -./bin/canton run <some-canton-script> -c config/remote-participant1.conf +./bin/canton run -c config/remote-participant1.conf ``` Note that most Canton commands can be executed from a remote console. However, a few commands can only be called from the local console of the node itself. @@ -94,8 +94,8 @@ The remote console can be used in installations that utilize authorization, so l ```bash ./bin/canton daemon \ -c remote-participant1.conf \ - -C canton.remote-participants.<remote-participant-name>.token="<encoded-and-signed-access-token-as-string>" \ - --bootstrap <some-script> + -C canton.remote-participants..token="" \ + --bootstrap ``` The remote console uses the token in its interactions with the Ledger API of the target participant. It also extracts the user ID from the token and uses it to populate the userId field in the command submission and completion subscription requests. This affects the following console commands: diff --git a/docs-main/global-synchronizer/production-operations/key-management.mdx b/docs-main/global-synchronizer/production-operations/key-management.mdx index c5b99b72e..1add31c84 100644 --- a/docs-main/global-synchronizer/production-operations/key-management.mdx +++ b/docs-main/global-synchronizer/production-operations/key-management.mdx @@ -306,7 +306,7 @@ enum SigningKeySpec { The synchronizer the participant node intends to connect to might restrict further the list of supported key specifications. To obtain this information from the synchronizer directly, run the following command on the synchronizer Public API. ``` -grpcurl -d '{}' <sequencer_endpoint> com.digitalasset.canton.sequencer.api.v30.SequencerConnectService/GetSynchronizerParameters +grpcurl -d '{}' com.digitalasset.canton.sequencer.api.v30.SequencerConnectService/GetSynchronizerParameters ``` If a console is not accessible, you can use either a bootstrap script or `grpccurl` against the Admin API to invoke the commands. @@ -384,7 +384,7 @@ And the following command can be used to generate the signature: ``` gcloud kms asymmetric-sign \ --version key-version \ - --key <root-key> \ + --key \ --keyring key-ring \ --location location \ --digest-algorithm digest-algorithm \ diff --git a/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx b/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx index 65abee579..737ac0bf9 100644 --- a/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx +++ b/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx @@ -35,7 +35,7 @@ The Canton configuration file for static properties is based on [PureConfig](htt When understanding the mapping from scaladocs to configuration, please keep in mind that: - CamelCase Scala names are mapped to lowercase-with-dashes names in configuration files, e.g. `synchronizerParameters` in the scaladocs becomes `synchronizer-parameters` in a configuration file (dash, not underscore). -- `Option[<scala-class>]` means that the configuration can be specified but doesn't need to be, e.g. you can specify a JWT token via `token=token` in [RemoteParticipantConfig](/reference/scala/com-digitalasset-canton-participant-config/remoteparticipantconfig), but not specifying `token` is also valid. +- `Option[]` means that the configuration can be specified but doesn't need to be, e.g. you can specify a JWT token via `token=token` in [RemoteParticipantConfig](/reference/scala/com-digitalasset-canton-participant-config/remoteparticipantconfig), but not specifying `token` is also valid. ## Configuration Compatibility @@ -234,7 +234,7 @@ bin/canton sandbox --dar Main.dar ... For testing and scripting purposes, Canton can also start in headless script mode: ```bash -bin/canton run <script-path> --config ... +bin/canton run --config ... ``` In this case, commands are specified in a script rather than executed interactively. Any errors with the script or during command execution should cause the Canton process to exit with a non-zero exit code. When the script completes all components are stopped. diff --git a/docs-main/global-synchronizer/reference/metrics-reference.mdx b/docs-main/global-synchronizer/reference/metrics-reference.mdx index f529fadb9..6742f7e9e 100644 --- a/docs-main/global-synchronizer/reference/metrics-reference.mdx +++ b/docs-main/global-synchronizer/reference/metrics-reference.mdx @@ -14,13 +14,13 @@ You can check your validator's health using the readiness endpoints. All CN appl You can also manually check validator readiness with the following command: ```yaml - kubectl exec <pod-name> -n -- curl -v http://localhost:5003/api/validator/readyz + kubectl exec -n -- curl -v http://localhost:5003/api/validator/readyz ``` - In Docker: run for example this command to check validator liveness inside a container: ```yaml - docker exec <container-name> -- curl -v http://localhost:5003/api/validator/livez + docker exec -- curl -v http://localhost:5003/api/validator/livez ``` You should expect in both case HTTP status code 200 if the validator is ready and live. diff --git a/docs-main/global-synchronizer/release-notes/splice.mdx b/docs-main/global-synchronizer/release-notes/splice.mdx index c998f14e5..f7a9d2b5a 100644 --- a/docs-main/global-synchronizer/release-notes/splice.mdx +++ b/docs-main/global-synchronizer/release-notes/splice.mdx @@ -1420,8 +1420,8 @@ Note: 0.4.6 had a bug and should be skipped in favor of 0.4.7 which fixed a bug - Info (new) - *important* This release contains a new helm chart "splice-info" which is supposed to be installed on all SV nodes and made publicly accessible. The new `info` endpoint provides: - - Static information about network, sv, synchronizers, config digests of ip ranges and identities under `https://info.sv.<YOUR_HOSTNAME>`. - - Regularly updated (every minute) copy of DSO information under `https://info.sv.<YOUR_HOSTNAME>/runtime/dso.json`. + - Static information about network, sv, synchronizers, config digests of ip ranges and identities under `https://info.sv.`. + - Regularly updated (every minute) copy of DSO information under `https://info.sv./runtime/dso.json`. The relevant documentation is updated at `sv-helm`. - Scan @@ -1664,7 +1664,7 @@ Note: 0.4.6 had a bug and should be skipped in favor of 0.4.7 which fixed a bug - It is now possible to force the recovery attempt for a party that was skipped during the fully automated recovery flow. - Improve the error message when trying to use the wallet outside of localhost or https. Thanks to Stephane Loeuillet for contributing this in [https://github.com/canton-network/splice/pull/322](https://github.com/canton-network/splice/pull/322). - Scan - - Scan now implements some Token Standard endpoints that are under the `/registry` path. `https://scan.sv.<YOUR_HOSTNAME>/registry` should be routed to `/registry` at port 5012 in service `scan-app` in the `sv` namespace, the same way that `/api/scan` already is. + - Scan now implements some Token Standard endpoints that are under the `/registry` path. `https://scan.sv./registry` should be routed to `/registry` at port 5012 in service `scan-app` in the `sv` namespace, the same way that `/api/scan` already is. ## 0.3.21 @@ -2560,7 +2560,7 @@ Note: 0.1.5 resulted in the issue mentioned below so both SVs and validators sho - Global Domain (whenever it refers to the more generic concept) -\> Decentralized Synchronizer - Note that for technical reasons the URLs for networks still include the term "svc" for now; e.g., `https://wallet.sv.svc.YOUR_HOSTNAME`. - Added an option to disable the Validator apps' wallet. This can be done by setting `enableWallet` to `false` in the `validator-values.yaml` file. -- Added ANS name resolution (formally known as CNS) for `dso.ans` to the DSO party and `<sv-name>.sv.ans` to all SV members parties. +- Added ANS name resolution (formally known as CNS) for `dso.ans` to the DSO party and `.sv.ans` to all SV members parties. - CometBFT pruning duration has been increased to 30 days. No configuration changes are required. - Sequencer pruning period has been adjusted to 30 days and pruning interval has been reduced to 1 hour. Adjust `sequencerPruningConfig.pruningInterval` and `sequencerPruningConfig.retentionPeriod` in your `sv-values.yaml` to match the example `sv-values.yaml`. - The sequencer URL of the Digital Asset 2 node `https://sequencer.sv-1.svc.CLUSTER.network.canton.global` is no longer exposed. Instead use `https://sequencer-MIGRATION_ID.sv-1.svc.CLUSTER.network.canton.global` where `MIGRATION_ID` is the current migration id of the cluster. @@ -2714,7 +2714,7 @@ Note: 0.1.5 resulted in the issue mentioned below so both SVs and validators sho - Minor SV UI tweaks. Among other things, it is now mandatory to supply a textual proposal summary when submitting a vote request. - Renamed `directory` to `CNS` across the system - - Renamed ingress rule from `https://directory.sv.svc.<YOUR_HOSTNAME>*` to `https://cns.sv.svc.<YOUR_HOSTNAME>*`. Please note that this is now a requirement for this UI to continue working properly. + - Renamed ingress rule from `https://directory.sv.svc.*` to `https://cns.sv.svc.*`. Please note that this is now a requirement for this UI to continue working properly. ## 2023-12-11 @@ -2753,7 +2753,7 @@ Note: 0.1.5 resulted in the issue mentioned below so both SVs and validators sho - Removing the adjustment of SVC governance thresholds for DevNet, aligning it with the one used in TestNet. - Deployment updates: - The URL of the global domain sequencer hosted by the Canton Foundation has changed to `https://sequencer.sv-1.svc.\.network.canton.global`. This change is reflected in the values specified in `participant-values.yaml`, `validator-values.yaml` and `sv-values.yaml`. - - The requirement for URL rewriting in the rules for Scan and SV apps has been removed: `https://scan.sv.svc.<YOUR_HOSTNAME>/api/scan` and `https://sv.sv.svc.<YOUR_HOSTNAME>/api/sv` no longer requires rewriting (and also has been modified from `/api/v0/scan` to `/api/scan` and from `/api/v0/sv` to `/api/sv`). For example, `https://scan.sv.svc.<YOUR_HOSTNAME>/api/scan/foobar` should be forwarded to `http://validator-app:5012/api/scan/foobar`. Note that URL rewriting is now required only in the ingress rule of the JSON API used by the directory frontend. This rule will be completely removed in the future. + - The requirement for URL rewriting in the rules for Scan and SV apps has been removed: `https://scan.sv.svc./api/scan` and `https://sv.sv.svc./api/sv` no longer requires rewriting (and also has been modified from `/api/v0/scan` to `/api/scan` and from `/api/v0/sv` to `/api/sv`). For example, `https://scan.sv.svc./api/scan/foobar` should be forwarded to `http://validator-app:5012/api/scan/foobar`. Note that URL rewriting is now required only in the ingress rule of the JSON API used by the directory frontend. This rule will be completely removed in the future. - Note that the readiness and liveness endpoints of Validator, Scan and SV apps have all been moved to `/api/\/readyz` and `/api/\/livez`, with `\` being `validator`, `scan` or `sv`, respectively. The corresponding Helm charts have been updated to reflect this change. - The URL configuration for the foundation's Scan app in `validator-values.yaml` has been updated to be `https://scan.sv-1.svc.TARGET_CLUSTER.network.canton.global`. Similarly, in the config files in the self-hosted validator section. - The `isDevNet` flag has been removed from the `cn-cometbft` helm chart in order to eliminate its potential for accidental misconfiguration. Instead, the chart now relies on the value of `genesis.chainId` in `cometbft-values.yaml` to determine whether it is a TestNet or DevNet deployment. @@ -2776,7 +2776,7 @@ Note: 0.1.5 resulted in the issue mentioned below so both SVs and validators sho - Add a hidden page to the SV UI (`/leader`) that allows SVs to manually trigger a reelection of the SvcRules leader, as an additional safety mechanism and measure of last resort. - Deployment updates: - Add documentation for Kubernetes-Based Deployment of a Validator node - - The requirement for url rewriting in one of the rules has been removed: `https://wallet.sv.svc.<YOUR_HOSTNAME>/api/validator` no longer requires rewriting (and also has been modified from `/api/v0/validator` to `/api/validator`). For example, `https://wallet.sv.svc.<YOUR_HOSTNAME>/api/validator/foobar` should be forwarded to `http://validator-app:5003/api/validator/foobar`. In the future, the other rewrite requirements will also be removed. + - The requirement for url rewriting in one of the rules has been removed: `https://wallet.sv.svc./api/validator` no longer requires rewriting (and also has been modified from `/api/v0/validator` to `/api/validator`). For example, `https://wallet.sv.svc./api/validator/foobar` should be forwarded to `http://validator-app:5003/api/validator/foobar`. In the future, the other rewrite requirements will also be removed. - Renamed `SV_WALLET_USER_ID` placeholder in `validator-values.yaml` to `OPERATOR_WALLET_USER_ID` to better reflect that this value is the operator's user in the deployment for both SVs and standalone validator nodes - Bugfixes: - Fixed an issue with fees in Scan recent activity and transaction history API where some sender and receiver fees were not reported. If a party transfers to themself, it will now be included in the Transfer receivers property in API responses (this was previously filtered out). @@ -3033,7 +3033,7 @@ Note: 0.1.5 resulted in the issue mentioned below so both SVs and validators sho ## 2023-06-04 - Deployment updates: - - Docker images now use the same versioning scheme as helm charts: `..-snapshot.<commit_date>.<number_of_commits>.0.v<commit_sha_8>` + - Docker images now use the same versioning scheme as helm charts: `..-snapshot...0.v` - Frontend updates: - Reorganized the information tab in SV UI and included rules governing canton coin (e.g. fees) in SV UI. - Added support for displaying details of governance vote requests, casting a vote, and updating a casted vote. diff --git a/docs-main/global-synchronizer/troubleshooting-guide/troubleshooting-methodology.mdx b/docs-main/global-synchronizer/troubleshooting-guide/troubleshooting-methodology.mdx index e42257740..d7f5f8b20 100644 --- a/docs-main/global-synchronizer/troubleshooting-guide/troubleshooting-methodology.mdx +++ b/docs-main/global-synchronizer/troubleshooting-guide/troubleshooting-methodology.mdx @@ -29,8 +29,8 @@ We recommend to use `lnav` to read the logs. A guideline is provided in [this do Logging in kubernetes (note that this only provides logs for a limited timeframe): -- `kubectl describe pod <pod-name>` to get a detailed status of the given pod, -- `kubectl logs <pod-name> -n <namespace-name>` or `kubectl logs -l app=<app-name> -n <namespace-name> --tail=-1` to get logs for a given pod in a given namespace. +- `kubectl describe pod ` to get a detailed status of the given pod, +- `kubectl logs -n ` or `kubectl logs -l app= -n --tail=-1` to get logs for a given pod in a given namespace. ## Debugging issues in Web UIs diff --git a/docs-main/integrations/exchanges/guidance.mdx b/docs-main/integrations/exchanges/guidance.mdx index 2877fba9a..73deb3e0c 100644 --- a/docs-main/integrations/exchanges/guidance.mdx +++ b/docs-main/integrations/exchanges/guidance.mdx @@ -513,13 +513,13 @@ In this case, we query a single transaction. The format is identical to the tran curl -sSL --fail-with-body http://json-api-url/v2/updates/update-by-id \ -H 'Authorization: Bearer ' \ -d '{ - "updateId": "<update-id>", + "updateId": "", "updateFormat": { "includeTransactions": { "transactionShape": "TRANSACTION_SHAPE_LEDGER_EFFECTS", "eventFormat": { "filtersByParty": { - "<treasury-party>": { + "": { "cumulative": [ {"identifierFilter": {"WildcardFilter": {"value": {"includeCreatedEventBlob": false}}}}, {"identifierFilter": {"InterfaceFilter": {"value": {"interfaceId": "#splice-api-token-transfer-instruction-v1:Splice.Api.Token.TransferInstructionV1:TransferFactory", "includeInterfaceView": true, "includeCreatedEventBlob": false}}}}, @@ -547,9 +547,9 @@ You can parse such transactions using the token standard history parser provided 4. Go over all events whose `nodeId` is larger than the `nodeId` of the transfer (4 in the example here) and smaller than the `lastDescendantNodeId` of the transfer (12 in the example here). -5. Find all `CreatedEvents` in that range that create a `Holding` with `"owner": "<treasury-party>"` and sum up the amounts for each `instrumentId`. In this example, we have two events that create holdings, `nodeId` 11 and 12. However, only 12 has `"owner": "<treasury-party>"`. Therefore, we extract that the transfer created `200.0000000000` for the token with instrument id `{"admin": "DSO::12204b8b621ec1dedd51ee2510085f8164cad194953496494d32f541f3f2c170e962", "id": "Amulet"}`. +5. Find all `CreatedEvents` in that range that create a `Holding` with `"owner": ""` and sum up the amounts for each `instrumentId`. In this example, we have two events that create holdings, `nodeId` 11 and 12. However, only 12 has `"owner": ""`. Therefore, we extract that the transfer created `200.0000000000` for the token with instrument id `{"admin": "DSO::12204b8b621ec1dedd51ee2510085f8164cad194953496494d32f541f3f2c170e962", "id": "Amulet"}`. -6. Find all `ExercisedEvents` with `implementedInterfaces` containing the `Holding` interface and `consuming: true`. In the example here, this is the event with `nodeId:: 8`. For each of them get the `contractId` and lookup the contract payload through the event query service as shown below. If you get a 404, it's a holding for a different party so you can ignore it. If you get back an event, check if `"owner": "<treasury-party>"`. If so, sum up all events for which this is the case. In the example here, we get a 404 as it is a holding of the sender not treasury-party. +6. Find all `ExercisedEvents` with `implementedInterfaces` containing the `Holding` interface and `consuming: true`. In the example here, this is the event with `nodeId:: 8`. For each of them get the `contractId` and lookup the contract payload through the event query service as shown below. If you get a 404, it's a holding for a different party so you can ignore it. If you get back an event, check if `"owner": ""`. If so, sum up all events for which this is the case. In the example here, we get a 404 as it is a holding of the sender not treasury-party. ```bash curl -sSL --fail-with-body http://json-api-url/v2/events/events-by-contract-id \ @@ -558,7 +558,7 @@ You can parse such transactions using the token standard history parser provided "contractId": "009b939ae451ef1a0cb81d1606391406690e055b5be301fd2f51efb6be5675577eca1112200f58604ac538224f73bdc57117d73830ed1e3167f956d66f9e3ecdacbf2359a7", "eventFormat": { "filtersByParty": { - "<treasury-party>": { + "": { "cumulative": [ {"identifierFilter": {"InterfaceFilter": {"value": {"interfaceId": "#splice-api-token-holding-v1:Splice.Api.Token.HoldingV1:Holding", "includeInterfaceView": true, "includeCreatedEventBlob": false}}}} ] @@ -589,13 +589,13 @@ In this case, we query a single transaction. The format is identical to the tran curl -sSL --fail-with-body http://json-api-url/v2/updates/update-by-id \ -H 'Authorization: Bearer ' \ -d '{ - "updateId": "<update-id>", + "updateId": "", "updateFormat": { "includeTransactions": { "transactionShape": "TRANSACTION_SHAPE_LEDGER_EFFECTS", "eventFormat": { "filtersByParty": { - "<treasury-party>": { + "": { "cumulative": [ {"identifierFilter": {"WildcardFilter": {"value": {"includeCreatedEventBlob": false}}}}, {"identifierFilter": {"InterfaceFilter": {"value": {"interfaceId": "#splice-api-token-transfer-instruction-v1:Splice.Api.Token.TransferInstructionV1:TransferFactory", "includeInterfaceView": true, "includeCreatedEventBlob": false}}}}, @@ -616,7 +616,7 @@ curl -sSL --fail-with-body http://json-api-url/v2/updates/update-by-id \ You can parse such transactions using the token standard history parser provided in the wallet SDK to extract the deposit amount, account and holding contract ids. If you prefer implementing your own implementation, you can parse this as follows: 1. Go over the list of events ordered by `nodeId` that you see in the transaction. -2. Look for all `CreatedEvents` of the `TransferInstruction` interface with `"receiver": "<treasury-party>"`. Each of these represents a deposit offer that can be accepted or rejected. In the example this is only one event with node id `0`. Extract the `instrument`, the `amount` and the `splice.lfdecentralizedtrust.org/reason` field from the `interfaceView` and the contract id of the `TransferInstruction`. Note that one transaction can contain multiple deposits including mixing 1 and 2-step deposits in the same transaction. +2. Look for all `CreatedEvents` of the `TransferInstruction` interface with `"receiver": ""`. Each of these represents a deposit offer that can be accepted or rejected. In the example this is only one event with node id `0`. Extract the `instrument`, the `amount` and the `splice.lfdecentralizedtrust.org/reason` field from the `interfaceView` and the contract id of the `TransferInstruction`. Note that one transaction can contain multiple deposits including mixing 1 and 2-step deposits in the same transaction. After accepting the deposit offer through your automation, Tx History Ingestion can then observe and process acceptance. An example of such a transaction can be seen below. @@ -635,7 +635,7 @@ To parse this proceed as follows: "contractId": "009b939ae451ef1a0cb81d1606391406690e055b5be301fd2f51efb6be5675577eca1112200f58604ac538224f73bdc57117d73830ed1e3167f956d66f9e3ecdacbf2359a7", "eventFormat": { "filtersByParty": { - "<treasury-party>": { + "": { "cumulative": [ {"identifierFilter": {"InterfaceFilter": {"value": {"interfaceId": "#splice-api-token-transfer-instruction-v1:Splice.Api.Token.TransferInstructionV1:TransferInstruction", "includeInterfaceView": true, "includeCreatedEventBlob": false}}}} ] diff --git a/docs-main/reference/typescript.mdx b/docs-main/reference/typescript.mdx index 9baad2aaf..f4ed5949b 100644 --- a/docs-main/reference/typescript.mdx +++ b/docs-main/reference/typescript.mdx @@ -13,13 +13,13 @@ Generated from published `@daml/types` TypeDoc snapshots. | [`ChoiceFrom`](#interface-choicefrom) | Interface | The origin companion that contained a [[Choice]]. | `3.4.8` | - | - | - | | [`ContractTypeCompanion`](#interface-contracttypecompanion) | Interface | Companion objects for templates and interfaces, containing their choices. | `3.4.8` | `3.4.9`: members added: `templateIdWithPackageId` | - | - | | [`FromTemplate`](#interface-fromtemplate) | Interface | A mixin for [[InterfaceCompanion]]. This supplies the basis
for the methods of [[ToInterface]].

Even interfaces that retroactively implement for no templates implement this,
because forward implementations still require this marker to work. | `3.4.8` | - | - | - | -| [`Map`](#interface-map) | Interface | The counterpart of Daml's ``DA.Map.Map K V`` type.

This is an immutable map which compares keys via deep equality. The order of
iteration is unspecified; the only guarantee is that the order in ``keys`` and
``values`` match, i.e. ``m.get(k)`` is (deep-, value-based) equal to
``[...m.values()][[...m.keys()].findIndex((l) => _.isEqual(k, l))]`` | `3.4.8` | - | - | - | +| [`Map`](#interface-map) | Interface | The counterpart of Daml's ``DA.Map.Map K V`` type.

This is an immutable map which compares keys via deep equality. The order of
iteration is unspecified; the only guarantee is that the order in ``keys`` and
``values`` match, i.e. ``m.get(k)`` is (deep-, value-based) equal to
``[...m.values()][[...m.keys()].findIndex((l) => _.isEqual(k, l))]`` | `3.4.8` | - | - | - | | [`Serializable`](#interface-serializable) | Interface | Interface for companion objects of serializable types. Its main purpose is
to serialize and deserialize values between raw JSON and typed values. | `3.4.8` | - | - | - | | [`Template`](#interface-template) | Interface | Interface for objects representing Daml templates. It is similar to the
``Template`` type class in Daml. | `3.4.8` | `3.4.9`: members added: `templateIdWithPackageId` | - | - | | [`ToInterface`](#interface-tointerface) | Interface | A mixin for [[Template]] that provides the ``toInterface`` and
``unsafeFromInterface`` contract ID conversion functions.

Even templates that directly implement no interfaces implement this, because
this also permits conversion with interfaces that supply retroactive
implementations to this template. | `3.4.8` | - | - | - | | [`Unit`](#interface-unit) | Interface | The counterpart of Daml's ``()`` type. | `3.4.8` | - | - | - | | [`Bool`](#type-alias-bool) | Type Alias | The counterpart of Daml's ``Bool`` type. | `3.4.8` | - | - | - | -| [`ContractId`](#type-alias-contractid) | Type Alias | The counterpart of Daml's ``ContractId T`` type.

We represent ``ContractId``s as strings. Their exact format of these strings depends on the ledger
the Daml application is running on.

The purpose of the intersection with ``{ [ContractIdBrand]: T }`` is to
prevent accidental use of a ``ContractId<T>`` when a ``ContractId<U>`` is
needed (unless ``T`` is a subtype of ``U``). This technique is known as
"branding" in the TypeScript community. | `3.4.8` | - | - | - | +| [`ContractId`](#type-alias-contractid) | Type Alias | The counterpart of Daml's ``ContractId T`` type.

We represent ``ContractId``s as strings. Their exact format of these strings depends on the ledger
the Daml application is running on.

The purpose of the intersection with ``{ [ContractIdBrand]: T }`` is to
prevent accidental use of a ``ContractId`` when a ``ContractId`` is
needed (unless ``T`` is a subtype of ``U``). This technique is known as
"branding" in the TypeScript community. | `3.4.8` | - | - | - | | [`Date`](#type-alias-date) | Type Alias | The counterpart of Daml's ``Date`` type.

We represent ``Date``s as strings with format ``YYYY-MM-DD``. | `3.4.8` | - | - | - | | [`Decimal`](#type-alias-decimal) | Type Alias | The counterpart of Daml's ``Decimal`` type.

In Daml, Decimal's are the same as Numeric with precision 10. | `3.4.8` | - | - | - | | [`DisclosedContract`](#type-alias-disclosedcontract) | Type Alias | A disclosed contract that can be passed on a command submission. | `3.4.8` | - | - | - | @@ -30,7 +30,7 @@ Generated from published `@daml/types` TypeDoc snapshots. | [`Numeric`](#type-alias-numeric) | Type Alias | The counterpart of Daml's ``Numeric`` type.

We represent ``Numeric``s as string in order to avoid a loss of precision. The string must match
the regular expression ``-?(?:0\|[1-9]\d*)(?:\.\d+)?(?:[eE][+-]?\d+)?``. | `3.4.8` | - | - | - | | [`Optional`](#type-alias-optional) | Type Alias | The counterpart of Daml's ``Optional T`` type. | `3.4.8` | - | - | - | | [`Party`](#type-alias-party) | Type Alias | The counterpart of Daml's ``Party`` type.

We represent ``Party``s as strings matching the regular expression ``[A-Za-z0-9:_\- ]+``. | `3.4.8` | - | - | - | -| [`TemplateOrInterface`](#type-alias-templateorinterface) | Type Alias | - | `3.4.8` | `3.4.9`: signature updated; type parameter renamed: `I` -> `Id` | - | - | +| [`TemplateOrInterface`](#type-alias-templateorinterface) | Type Alias | - | `3.4.8` | `3.4.9`: signature updated; type parameter renamed: `I` -> `Id` | - | - | | [`Text`](#type-alias-text) | Type Alias | The counterpart of Daml's ``Text`` type. | `3.4.8` | - | - | - | | [`TextMap`](#type-alias-textmap) | Type Alias | The counterpart of Daml's ``TextMap T`` type.

We represent ``TextMap``s as dictionaries. | `3.4.8` | - | - | - | | [`Time`](#type-alias-time) | Type Alias | The counterpart of Daml's ``Time`` type.

We represent ``Times``s as strings with format ``YYYY-MM-DDThh:mm:ss[.ssssss]Z``. | `3.4.8` | - | - | - | @@ -213,7 +213,7 @@ The counterpart of Daml's ``DA.Map.Map K V`` type. This is an immutable map which compares keys via deep equality. The order of iteration is unspecified; the only guarantee is that the order in ``keys`` and ``values`` match, i.e. ``m.get(k)`` is (deep-, value-based) equal to -``[...m.values()][[...m.keys()].findIndex((l) => _.isEqual(k, l))]`` +``[...m.values()][[...m.keys()].findIndex((l) => _.isEqual(k, l))]`` **Type Parameters** @@ -295,8 +295,7 @@ Interface for objects representing Daml templates. It is similar to the | Member | Type | Description | | --- | --- | --- | -| `Archive` | `Choice & ChoiceFrom>` | - | -| `templateId` | `I` | - | +| `Archive` | `Choice & ChoiceFrom>` | - || `templateId` | `I` | - | | `templateIdWithPackageId` | `string` | - | @@ -388,7 +387,7 @@ We represent ``ContractId``s as strings. Their exact format of these strings dep the Daml application is running on. The purpose of the intersection with ``{ [ContractIdBrand]: T }`` is to -prevent accidental use of a ``ContractId<T>`` when a ``ContractId<U>`` is +prevent accidental use of a ``ContractId`` when a ``ContractId`` is needed (unless ``T`` is a subtype of ``U``). This technique is known as "branding" in the TypeScript community. @@ -610,7 +609,7 @@ We represent ``Party``s as strings matching the regular expression ``[A-Za-z0-9: | Version | Changes | | --- | --- | -| `3.4.9` | signature updated; type parameter renamed: `I` -> `Id` | +| `3.4.9` | signature updated; type parameter renamed: `I` -> `Id` | **Signature** @@ -845,7 +844,6 @@ ContractId(_t: Serializable | TemplateOrInterface \| TemplateOrInterface` | yes | - | - Returns: `Serializable>` diff --git a/docs-main/reference/typescript/dapp-sdk.mdx b/docs-main/reference/typescript/dapp-sdk.mdx index a5b2912df..137c61bb1 100644 --- a/docs-main/reference/typescript/dapp-sdk.mdx +++ b/docs-main/reference/typescript/dapp-sdk.mdx @@ -11,7 +11,7 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | --- | --- | --- | --- | --- | --- | --- | | [`dappAPI`](#namespace-dappapi) | Namespace | - | `1.1.0` | - | - | - | | [`ErrorCode`](#enumeration-errorcode) | Enumeration | - | `1.1.0` | - | - | - | -| [`DappClient`](#class-dappclient) | Class | DappClient is a thin convenience wrapper around a connected
``Provider<DappRpcTypes>``.

It exposes typed RPC helpers, event subscription shortcuts,
``window.canton`` injection, and session-persistence listeners.

How to obtain a provider is **not** this class's concern.
Use ``DiscoveryClient`` + the wallet picker, or construct any
``Provider<DappRpcTypes>`` directly — then pass it here. | `1.1.0` | - | - | - | +| [`DappClient`](#class-dappclient) | Class | DappClient is a thin convenience wrapper around a connected
``Provider``.

It exposes typed RPC helpers, event subscription shortcuts,
``window.canton`` injection, and session-persistence listeners.

How to obtain a provider is **not** this class's concern.
Use ``DiscoveryClient`` + the wallet picker, or construct any
``Provider`` directly — then pass it here. | `1.1.0` | - | - | - | | [`DappSDK`](#class-dappsdk) | Class | - | `1.1.0` | - | - | - | | [`DiscoveryClient`](#class-discoveryclient) | Class | DiscoveryClient manages provider adapters and exposes a unified
Provider<DappRpcTypes> regardless of the underlying wallet type.

It is UI-framework agnostic — the wallet picker UI is injected
via the ``walletPicker`` config option.

Client-level events (``discovery:connected``, ``discovery:disconnected``,
``discovery:error``) track the adapter session lifecycle. Provider-level
CIP-103 events (statusChanged, accountsChanged, txChanged) live on
the Provider — subscribe via ``client.getProvider().on(...)``. | `1.1.0` | - | - | - | | [`DiscoveryError`](#class-discoveryerror) | Class | - | `1.1.0` | - | - | - | @@ -232,14 +232,14 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. - Source: `dist/client.d.ts:22` DappClient is a thin convenience wrapper around a connected -``Provider<DappRpcTypes>``. +``Provider``. It exposes typed RPC helpers, event subscription shortcuts, ``window.canton`` injection, and session-persistence listeners. How to obtain a provider is **not** this class's concern. Use ``DiscoveryClient`` + the wallet picker, or construct any -``Provider<DappRpcTypes>`` directly — then pass it here. +``Provider`` directly — then pass it here. **Members** diff --git a/docs-main/reference/typescript/wallet-sdk.mdx b/docs-main/reference/typescript/wallet-sdk.mdx index d2c587bad..c5079eb18 100644 --- a/docs-main/reference/typescript/wallet-sdk.mdx +++ b/docs-main/reference/typescript/wallet-sdk.mdx @@ -208,8 +208,7 @@ Generated from published `@canton-network/wallet-sdk` TypeDoc snapshots. | Member | Type | Description | | --- | --- | --- | | `constructor` | `void` | - | -| `command` | `{ cancel: (args: { parties: PreapprovalParties }) => Promise<[{ ExerciseCommand: { choice: string; choiceArgument: unknown; contractId: string; templateId: string } & { choice: string; choiceArgument: unknown; contractId: string; templateId: string } }, { contractId?: string; createdEventBlob: string; synchronizerId?: string; templateId?: string } & { contractId?: string; createdEventBlob: string; synchronizerId?: string; templateId?: string }[]] \| readonly [null, readonly []]>; create: (args: { parties: PreapprovalParties }) => Promise<{ CreateCommand: { createArguments: unknown; templateId: string } & { createArguments: unknown; templateId: string } }> }` | Commands for managing transfer preapprovals. The return result can be used as an argument to pass to signing and execution of a transaction.
Transfer preapprovals allow receivers to automatically accept incoming transfers. | -| `fetchQuick` | `void` | - | +| `command` | `{ cancel: (args: { parties: PreapprovalParties }) => Promise<[{ ExerciseCommand: { choice: string; choiceArgument: unknown; contractId: string; templateId: string } & { choice: string; choiceArgument: unknown; contractId: string; templateId: string } }, { contractId?: string; createdEventBlob: string; synchronizerId?: string; templateId?: string } & { contractId?: string; createdEventBlob: string; synchronizerId?: string; templateId?: string }[]] \| readonly [null, readonly []]>; create: (args: { parties: PreapprovalParties }) => Promise<{ CreateCommand: { createArguments: unknown; templateId: string } & { createArguments: unknown; templateId: string } }> }` | Commands for managing transfer preapprovals. The return result can be used as an argument to pass to signing and execution of a transaction.
Transfer preapprovals allow receivers to automatically accept incoming transfers. || `fetchQuick` | `void` | - | | `fetchStatus` | `void` | - | | `renew` | `void` | - | diff --git a/docs-main/sdks-tools/api-reference/splice-scan-bulk-data-api.mdx b/docs-main/sdks-tools/api-reference/splice-scan-bulk-data-api.mdx index 96cea434d..5d62f9e67 100644 --- a/docs-main/sdks-tools/api-reference/splice-scan-bulk-data-api.mdx +++ b/docs-main/sdks-tools/api-reference/splice-scan-bulk-data-api.mdx @@ -155,7 +155,7 @@ The response returns a list of transactions. Every transaction contains the foll - **synchronizer_id**: The instance ID of a Synchronizer (for example the ID of the Global Synchronizer). When contracts get reassigned, they become unavailable for processing via the old instance of the synchronizer and become available via the new instance of the synchronizer. Every contract is assigned to a `synchronizer_id`, which represents the synchronizer that the stakeholders agreed on to use for sequencing future transactions on this contract. - **update_id**: Uniquely identifies an update (globally unique across networks and synchronizers). - **record_time**: The time at which the update was sequenced. Within a given migration and synchronizer, the record time of updates is strictly monotonically increasing (and thus unique). Record times between migrations can overlap; for example, if *rtn* is the latest record time for migration ID *n*, then there may exist updates with migration ID *n+1* but record time preceding *rtn*. The update history is mainly traversed by `migration_id`, `synchronizer_id`, and `record_time`. -- **root_event_ids**: These represent the top level events of the update tree that are directly caused by commands submitted to the ledger. They are the starting points for all actions within the transaction, and need to be read in the order given. To traverse the update tree, start with the `root_event_ids` in order, get event by ID from `events_by_id`, traverse events in preorder, process `child_event_ids` recursively. Note: event ids are stored as a string of the format `<update_id>:<event_index>`. The event index exposed by scan is consistent cross all SVs for the same event. Note that it differs from the event index that the ledger API exposes on an individual participant as those can differ between different participants for the same event. +- **root_event_ids**: These represent the top level events of the update tree that are directly caused by commands submitted to the ledger. They are the starting points for all actions within the transaction, and need to be read in the order given. To traverse the update tree, start with the `root_event_ids` in order, get event by ID from `events_by_id`, traverse events in preorder, process `child_event_ids` recursively. Note: event ids are stored as a string of the format `:`. The event index exposed by scan is consistent cross all SVs for the same event. Note that it differs from the event index that the ledger API exposes on an individual participant as those can differ between different participants for the same event. - **events_by_id**: This object contains all events in the transaction update tree, indexed by their event ID. An example list of transactions response for the beginning of the network is shown below: diff --git a/docs-main/sdks-tools/development-tools/daml-compiler.mdx b/docs-main/sdks-tools/development-tools/daml-compiler.mdx index e2abe7b4d..cd9bfd034 100644 --- a/docs-main/sdks-tools/development-tools/daml-compiler.mdx +++ b/docs-main/sdks-tools/development-tools/daml-compiler.mdx @@ -118,7 +118,7 @@ These flags are available for both `--build` as well as `--test`. - `-o,--output FILE` - Optional output file (defaults to `<PACKAGE-NAME>.dar`). + Optional output file (defaults to `.dar`). - `--incremental ARG` diff --git a/docs-main/sdks-tools/language-bindings/javascript.mdx b/docs-main/sdks-tools/language-bindings/javascript.mdx index 7e473616c..7f8be97de 100644 --- a/docs-main/sdks-tools/language-bindings/javascript.mdx +++ b/docs-main/sdks-tools/language-bindings/javascript.mdx @@ -259,7 +259,7 @@ interface IouInterface { } const Iou: - damlTypes.Template & + damlTypes.Template'> & damlTypes.ToInterface & IouInterface; ```