From 39745b3891bc8936ab4ea8408695632eceda3248 Mon Sep 17 00:00:00 2001 From: 8bitpal Date: Mon, 29 Jun 2026 08:41:43 +0200 Subject: [PATCH 1/3] Fix </> HTML entities rendering as literal strings Replaces < and > with literal < and > in code blocks and backtick-enclosed prose, where Mintlify renders entities as-is rather than decoding them. Leaves entities intact inside raw HTML elements (command-deduplication, performance-optimization, language-reference) where HTML context correctly decodes them. Closes #875 Signed-off-by: 8bitpal --- .../deep-dives/smart-contract-upgrade.mdx | 10 +-- .../appdev/modules/m3-building-packaging.mdx | 6 +- docs-main/appdev/modules/m4-backend-dev.mdx | 2 +- .../appdev/modules/m4-json-api-tutorial.mdx | 6 +- docs-main/appdev/quickstart/json-api.mdx | 2 +- .../appdev/reference/daml-lf-reference.mdx | 78 +++++++++---------- .../reference/protobuf-history/index.mdx | 2 +- .../production-operations/canton-console.mdx | 6 +- .../production-operations/key-management.mdx | 4 +- .../validator-disaster-recovery.mdx | 6 +- .../reference/canton-configuration-guide.mdx | 4 +- .../reference/canton-console-commands.mdx | 6 +- .../reference/metrics-reference.mdx | 4 +- .../release-notes/splice.mdx | 16 ++-- .../troubleshooting-methodology.mdx | 4 +- docs-main/integrations/exchanges/guidance.mdx | 18 ++--- docs-main/reference/typescript.mdx | 48 ++++++------ docs-main/reference/typescript/dapp-sdk.mdx | 72 ++++++++--------- docs-main/reference/typescript/wallet-sdk.mdx | 12 +-- .../splice-scan-bulk-data-api.mdx | 2 +- .../development-tools/daml-compiler.mdx | 2 +- .../language-bindings/javascript.mdx | 2 +- 22 files changed, 156 insertions(+), 156 deletions(-) diff --git a/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx b/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx index 16aaa9bef..f3d4d14a7 100644 --- a/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx +++ b/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx @@ -205,8 +205,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. @@ -1497,9 +1497,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). @@ -2007,7 +2007,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 38aad6d28..7170e7bd6 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 ae1e781c7..9936b291b 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/production-operations/validator-disaster-recovery.mdx b/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx index 3deddf2d3..2bc40ea09 100644 --- a/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx +++ b/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx @@ -178,7 +178,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). @@ -225,7 +225,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). @@ -272,7 +272,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). diff --git a/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx b/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx index f080f979c..dbc45ff72 100644 --- a/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx +++ b/docs-main/global-synchronizer/reference/canton-configuration-guide.mdx @@ -37,7 +37,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 @@ -236,7 +236,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/canton-console-commands.mdx b/docs-main/global-synchronizer/reference/canton-console-commands.mdx index 142636da3..09c4b6c0b 100644 --- a/docs-main/global-synchronizer/reference/canton-console-commands.mdx +++ b/docs-main/global-synchronizer/reference/canton-console-commands.mdx @@ -4990,7 +4990,7 @@ This command imports contracts from an Active Contract Set (ACS) snapshot file i The argument is: - `importFilePath`: The path denoting the file from where the ACS snapshot will be read. Defaults to "canton-acs-export.gz" when undefined. -- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-<random_UUID>" when unspecified. +- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-" when unspecified. - `contractImportMode`: Governs contract authentication processing on import. Options include Validation (default), [Accept, Recomputation]. - `representativePackageIdOverride`: Defines override mappings for assigning representative package IDs to contracts upon ACS import. Defaults to NoOverride when undefined. @@ -5199,7 +5199,7 @@ If the import process succeeds, the mapping from the old contract IDs to the new The arguments are: - `importFilePath`: The path denoting the file from where the ACS snapshot will be read. Defaults to "canton-acs-export.gz" when undefined. -- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-<random_UUID>" when unspecified. +- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-" when unspecified. - `contractImportMode`: Governs contract authentication processing on import. Options include Validation (default), [Accept, Recomputation]. - `representativePackageIdOverride`: Defines override mappings for assigning representative package IDs to contracts upon ACS import. - `excludedStakeholders`: When defined, any contract that has one or more of these parties as a stakeholder will be omitted from the import. @@ -6804,7 +6804,7 @@ proposals: Whether to query proposals instead of authorized transactions. timeQu List multi-hosted party proposals. -Multi-hosted parties require all involved actors to sign the topology transaction. Topology transactions without sufficient signatures are called proposals. They are distributed the same way as fully authorized topology transactions, and signatures are aggregated until the transaction is fully authorized. This method here allows to inspect the pending queue of open hosting proposals. The proposals are returned as seen on the specified synchronizer. They can be approved by the individual participants by invoking node.topology.transactions.authorize(<synchronizer-id>, <tx-hash>). +Multi-hosted parties require all involved actors to sign the topology transaction. Topology transactions without sufficient signatures are called proposals. They are distributed the same way as fully authorized topology transactions, and signatures are aggregated until the transaction is fully authorized. This method here allows to inspect the pending queue of open hosting proposals. The proposals are returned as seen on the specified synchronizer. They can be approved by the individual participants by invoking node.topology.transactions.authorize(, ). **Arguments** 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 450bb643f..a2233f81a 100644 --- a/docs-main/global-synchronizer/release-notes/splice.mdx +++ b/docs-main/global-synchronizer/release-notes/splice.mdx @@ -1349,8 +1349,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 @@ -1593,7 +1593,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 @@ -2489,7 +2489,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. @@ -2643,7 +2643,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 @@ -2682,7 +2682,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. @@ -2705,7 +2705,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). @@ -2962,7 +2962,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 395094926..a09650896 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 8256f51bd..d1f351049 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` | - | - | - | @@ -93,7 +93,7 @@ Interface for objects representing Daml choices. | Member | Type | Description | | --- | --- | --- | | `choiceName` | `string` | The choice name. | -| `template` | `() => TemplateOrInterface` | Returns the template to which this choice belongs. | +| `template` | `() => TemplateOrInterface` | Returns the template to which this choice belongs. | @@ -121,7 +121,7 @@ The origin companion that contained a [[Choice]]. | Member | Type | Description | | --- | --- | --- | -| `template` | `() => O` | Returns the template to which this choice belongs. | +| `template` | `() => O` | Returns the template to which this choice belongs. | @@ -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** @@ -226,15 +226,15 @@ iteration is unspecified; the only guarantee is that the order in ``keys`` and | Member | Type | Description | | --- | --- | --- | -| `delete` | `(k: K) => Map<K, V>` | - | -| `entries` | `() => Iterator<[K, V], undefined, undefined>` | - | -| `entriesArray` | `() => [K, V][]` | - | -| `forEach` | `(f: (value: V, key: K, map: Map<K, V>) => T, u?: U) => void` | - | -| `get` | `(k: K) => undefined \| V` | - | -| `has` | `(k: K) => boolean` | - | -| `keys` | `() => Iterator<K, undefined, undefined>` | - | -| `set` | `(k: K, v: V) => Map<K, V>` | - | -| `values` | `() => Iterator<V, undefined, undefined>` | - | +| `delete` | `(k: K) => Map` | - | +| `entries` | `() => Iterator<[K, V], undefined, undefined>` | - | +| `entriesArray` | `() => [K, V][]` | - | +| `forEach` | `(f: (value: V, key: K, map: Map) => T, u?: U) => void` | - | +| `get` | `(k: K) => undefined \| V` | - | +| `has` | `(k: K) => boolean` | - | +| `keys` | `() => Iterator` | - | +| `set` | `(k: K, v: V) => Map` | - | +| `values` | `() => Iterator` | - | @@ -295,7 +295,7 @@ Interface for objects representing Daml templates. It is similar to the | Member | Type | Description | | --- | --- | --- | -| `Archive` | `Choice<T, {}, {}, K> & ChoiceFrom<Template<T, K, I>>` | - | +| `Archive` | `Choice & ChoiceFrom>` | - | | `templateId` | `I` | - | | `templateIdWithPackageId` | `string` | - | @@ -388,7 +388,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 +610,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** @@ -844,7 +844,7 @@ ContractId(_t: Serializable | TemplateOrInterface \| TemplateOrInterface` | yes | - | Returns: `Serializable>` @@ -903,7 +903,7 @@ List(t: Serializable): Serializable | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `t` | `Serializable<T>` | yes | - | +| `t` | `Serializable` | yes | - | Returns: `Serializable` @@ -936,8 +936,8 @@ Map(kd: Serializable, vd: Seria | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `kd` | `Serializable<K>` | yes | - | -| `vd` | `Serializable<V>` | yes | - | +| `kd` | `Serializable` | yes | - | +| `vd` | `Serializable` | yes | - | Returns: `Serializable>` @@ -997,7 +997,7 @@ Optional(t: Serializable): Serializable> | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `t` | `Serializable<T>` | yes | - | +| `t` | `Serializable` | yes | - | Returns: `Serializable>` @@ -1029,6 +1029,6 @@ TextMap(t: Serializable): Serializable> | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `t` | `Serializable<T>` | yes | - | +| `t` | `Serializable` | yes | - | Returns: `Serializable>` diff --git a/docs-main/reference/typescript/dapp-sdk.mdx b/docs-main/reference/typescript/dapp-sdk.mdx index d991248f7..06bd4a048 100644 --- a/docs-main/reference/typescript/dapp-sdk.mdx +++ b/docs-main/reference/typescript/dapp-sdk.mdx @@ -11,19 +11,19 @@ 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` | - | - | - | +| [`DiscoveryClient`](#class-discoveryclient) | Class | DiscoveryClient manages provider adapters and exposes a unified
Provider 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` | - | - | - | | [`EventEmitter`](#class-eventemitter) | Class | - | `1.1.0` | - | - | - | | [`ExtensionAdapter`](#class-extensionadapter) | Class | ProviderAdapter for any CIP-103 compliant wallet exposed as a browser extension.

provider() returns a DappProvider which communicates via postMessage
and implements the full openrpc-dapp-api.json surface directly. | `1.1.0` | - | - | - | -| [`InjectedAdapter`](#class-injectedadapter) | Class | A ProviderAdapter is a thin factory that knows how to create a
Provider<DappRpcTypes> for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | +| [`InjectedAdapter`](#class-injectedadapter) | Class | A ProviderAdapter is a thin factory that knows how to create a
Provider for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | | [`NotConnectedError`](#class-notconnectederror) | Class | - | `1.1.0` | - | - | - | | [`RemoteAdapter`](#class-remoteadapter) | Class | ProviderAdapter for any CIP-103 compliant wallet reachable over HTTP/SSE.

provider() returns a provider that maps the remote API
(openrpc-dapp-remote-api.json) to the dApp API
(openrpc-dapp-api.json) via dappSDKController. | `1.1.0` | - | - | - | | [`SessionExpiredError`](#class-sessionexpirederror) | Class | - | `1.1.0` | - | - | - | | [`TimeoutError`](#class-timeouterror) | Class | - | `1.1.0` | - | - | - | | [`UserRejectedError`](#class-userrejectederror) | Class | - | `1.1.0` | - | - | - | -| [`WalletConnectAdapter`](#class-walletconnectadapter) | Class | Single-class WalletConnect adapter that implements both ProviderAdapter
(for discovery/wallet-picker) and Provider<DappRpcTypes> (for RPC calls).

Calls signClient.request() directly with ``canton_`` prefixed methods.
Events arriving via session_event are buffered until a listener attaches. | `1.1.0` | - | - | - | +| [`WalletConnectAdapter`](#class-walletconnectadapter) | Class | Single-class WalletConnect adapter that implements both ProviderAdapter
(for discovery/wallet-picker) and Provider (for RPC calls).

Calls signClient.request() directly with ``canton_`` prefixed methods.
Events arriving via session_event are buffered until a listener attaches. | `1.1.0` | - | - | - | | [`WalletNotFoundError`](#class-walletnotfounderror) | Class | - | `1.1.0` | - | - | - | | [`WalletNotInstalledError`](#class-walletnotinstallederror) | Class | - | `1.1.0` | - | - | - | | [`ActiveSession`](#interface-activesession) | Interface | - | `1.1.0` | - | - | - | @@ -32,7 +32,7 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | [`DiscoveryConnectedEvent`](#interface-discoveryconnectedevent) | Interface | - | `1.1.0` | - | - | - | | [`DiscoveryDisconnectedEvent`](#interface-discoverydisconnectedevent) | Interface | - | `1.1.0` | - | - | - | | [`DiscoveryErrorEvent`](#interface-discoveryerrorevent) | Interface | - | `1.1.0` | - | - | - | -| [`ProviderAdapter`](#interface-provideradapter) | Interface | A ProviderAdapter is a thin factory that knows how to create a
Provider<DappRpcTypes> for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | +| [`ProviderAdapter`](#interface-provideradapter) | Interface | A ProviderAdapter is a thin factory that knows how to create a
Provider for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | | [`RemoteAdapterConfig`](#interface-remoteadapterconfig) | Interface | - | `1.1.0` | - | - | - | | [`WalletConnectAdapterConfig`](#interface-walletconnectadapterconfig) | Interface | - | `1.1.0` | - | - | - | | [`WalletInfo`](#interface-walletinfo) | Interface | - | `1.1.0` | - | - | - | @@ -134,31 +134,31 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | `TxChangedSignedPayload` | `void` | Payload for the TxChangedSignedEvent. | | `Wallet` | `void` | Structure representing a wallet | | `AccessToken` | `string` | JWT authentication token. | -| `AccountsChanged` | `() => Promise<AccountsChangedEvent>` | - | +| `AccountsChanged` | `() => Promise` | - | | `AccountsChangedEvent` | `Wallet[]` | Event emitted when the user's accounts change. | | `ActAs` | `Party[]` | Set of parties on whose behalf the command should be executed, if submitted. If not set, the primary wallet's party is used. | | `CommandId` | `string` | The unique identifier of the command associated with the transaction. | | `CompletionOffset` | `number` | - | -| `Connect` | `() => Promise<ConnectResult>` | - | +| `Connect` | `() => Promise` | - | | `ContractId` | `string` | The unique identifier of the disclosed contract. | | `CreatedEventBlob` | `string` | The blob data of the created event for the disclosed contract. | | `Disabled` | `boolean` | Whether the wallet is disabled. Wallets are disabled when no signing provider matches the party's namespace during sync. Disabled wallets use participant as the default signing provider. | | `DisclosedContracts` | `DisclosedContract[]` | List of contract IDs to be disclosed with the command. | -| `Disconnect` | `() => Promise<Null>` | - | +| `Disconnect` | `() => Promise` | - | | `ExternalTxId` | `string` | Unique identifier of the signed transaction given by the Signing Provider. This may not be the same as the internal txId given by the Wallet Gateway. | -| `GetActiveNetwork` | `() => Promise<Network>` | - | -| `GetPrimaryAccount` | `() => Promise<Wallet>` | - | +| `GetActiveNetwork` | `() => Promise` | - | +| `GetPrimaryAccount` | `() => Promise` | - | | `Hint` | `string` | The party hint and name of the wallet. | -| `IsConnected` | `() => Promise<ConnectResult>` | - | +| `IsConnected` | `() => Promise` | - | | `IsConnectedValue` | `boolean` | Whether or not the user is authenticated with the Wallet. | | `IsNetworkConnected` | `boolean` | Whether or not a connection to a network is established. | -| `LedgerApi` | `(params: LedgerApiParams) => Promise<LedgerApiResult>` | - | +| `LedgerApi` | `(params: LedgerApiParams) => Promise` | - | | `LedgerApiUrl` | `string` | The base URL of the ledger API. | -| `ListAccounts` | `() => Promise<ListAccountsResult>` | - | +| `ListAccounts` | `() => Promise` | - | | `ListAccountsResult` | `Wallet[]` | An array of accounts that the user has authorized the dapp to access.. | | `Message` | `string` | The message to sign. | | `MessageId` | `string` | The unique identifier of the message associated with the message to be signed. | -| `MessageSignature` | `() => Promise<MessageSignatureEvent>` | - | +| `MessageSignature` | `() => Promise` | - | | `MessageSignatureEvent` | `MessageSignaturePendingEvent \| MessageSignatureSignedEvent \| MessageSignatureFailedEvent` | Event emitted when a message signature is requested or completed. | | `Namespace` | `string` | The namespace of the party. | | `NetworkId` | `string` | The network ID the wallet corresponds to. | @@ -168,8 +168,8 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | `PackageIdSelectionPreference` | `PackageId[]` | The package-id selection preference of the client for resolving package names and interface instances in command submission and interpretation | | `Party` | `string` | The party that signed the transaction. | | `PartyId` | `string` | The party ID corresponding to the wallet. | -| `PrepareExecute` | `(params: PrepareExecuteParams) => Promise<Null>` | - | -| `PrepareExecuteAndWait` | `(params: PrepareExecuteParams) => Promise<PrepareExecuteAndWaitResult>` | - | +| `PrepareExecute` | `(params: PrepareExecuteParams) => Promise` | - | +| `PrepareExecuteAndWait` | `(params: PrepareExecuteParams) => Promise` | - | | `Primary` | `boolean` | Set as primary wallet for dApp usage. | | `ProviderId` | `string` | The unique identifier of the Provider. | | `ProviderType` | `"browser" \| "desktop" \| "mobile" \| "remote"` | The type of client that implements the Provider. | @@ -178,12 +178,12 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | `Reason` | `string` | Reason for the wallet state, e.g., 'no signing provider matched'. | | `RequestMethod` | `"get" \| "post" \| "patch" \| "put" \| "delete"` | - | | `Resource` | `string` | - | -| `RpcTypes` | `{ accountsChanged: { params: Params<AccountsChanged>; result: Result<AccountsChanged> }; connect: { params: Params<Connect>; result: Result<Connect> }; disconnect: { params: Params<Disconnect>; result: Result<Disconnect> }; getActiveNetwork: { params: Params<GetActiveNetwork>; result: Result<GetActiveNetwork> }; getPrimaryAccount: { params: Params<GetPrimaryAccount>; result: Result<GetPrimaryAccount> }; isConnected: { params: Params<IsConnected>; result: Result<IsConnected> }; ledgerApi: { params: Params<LedgerApi>; result: Result<LedgerApi> }; listAccounts: { params: Params<ListAccounts>; result: Result<ListAccounts> }; messageSignature: { params: Params<MessageSignature>; result: Result<MessageSignature> }; prepareExecute: { params: Params<PrepareExecute>; result: Result<PrepareExecute> }; prepareExecuteAndWait: { params: Params<PrepareExecuteAndWait>; result: Result<PrepareExecuteAndWait> }; signMessage: { params: Params<SignMessage>; result: Result<SignMessage> }; status: { params: Params<Status>; result: Result<Status> }; txChanged: { params: Params<TxChanged>; result: Result<TxChanged> } }` | - | +| `RpcTypes` | `{ accountsChanged: { params: Params; result: Result }; connect: { params: Params; result: Result }; disconnect: { params: Params; result: Result }; getActiveNetwork: { params: Params; result: Result }; getPrimaryAccount: { params: Params; result: Result }; isConnected: { params: Params; result: Result }; ledgerApi: { params: Params; result: Result }; listAccounts: { params: Params; result: Result }; messageSignature: { params: Params; result: Result }; prepareExecute: { params: Params; result: Result }; prepareExecuteAndWait: { params: Params; result: Result }; signMessage: { params: Params; result: Result }; status: { params: Params; result: Result }; txChanged: { params: Params; result: Result } }` | - | | `Signature` | `string` | The signature of the message. | | `SignedBy` | `string` | The identifier of the provider that signed the transaction. | | `SigningProviderId` | `string` | The signing provider ID the wallet corresponds to. | -| `SignMessage` | `(params: SignMessageParams) => Promise<SignMessageResult>` | - | -| `Status` | `() => Promise<StatusEvent>` | Generated! Represents an alias to any of the provided schemas | +| `SignMessage` | `(params: SignMessageParams) => Promise` | - | +| `Status` | `() => Promise` | Generated! Represents an alias to any of the provided schemas | | `StatusExecuted` | `"executed"` | The status of the transaction. | | `StatusFailed` | `"failed"` | The status of the message signature. | | `StatusPending` | `"pending"` | The status of the message signature. | @@ -191,7 +191,7 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | `SynchronizerId` | `string` | If not set, a suitable synchronizer that this node is connected to will be chosen. | | `TemplateId` | `string` | The template identifier of the disclosed contract. | | `TopologyTransactions` | `string` | The topology transactions | -| `TxChanged` | `() => Promise<TxChangedEvent>` | - | +| `TxChanged` | `() => Promise` | - | | `TxChangedEvent` | `TxChangedPendingEvent \| TxChangedSignedEvent \| TxChangedExecutedEvent \| TxChangedFailedEvent` | Event emitted when a transaction changes. | | `UpdateId` | `string` | The update ID corresponding to the transaction. | | `Url` | `string` | The URL of the Wallet Provider. | @@ -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** @@ -307,7 +307,7 @@ Use ``DiscoveryClient`` + the wallet picker, or construct any - Source: `node_modules/@canton-network/core-wallet-discovery/dist/client.d.ts:31` DiscoveryClient manages provider adapters and exposes a unified -Provider<DappRpcTypes> regardless of the underlying wallet type. +Provider regardless of the underlying wallet type. It is UI-framework agnostic — the wallet picker UI is injected via the ``walletPicker`` config option. @@ -412,7 +412,7 @@ and implements the full openrpc-dapp-api.json surface directly. - Source: `dist/adapter/injected-adapter.d.ts:12` A ProviderAdapter is a thin factory that knows how to create a -Provider<DappRpcTypes> for a particular wallet type, detect its +Provider for a particular wallet type, detect its availability, and clean up resources. All RPC methods (connect, disconnect, status, prepareExecute, etc.) @@ -560,7 +560,7 @@ provider() returns a provider that maps the remote API - Source: `dist/adapter/walletconnect-adapter.d.ts:25` Single-class WalletConnect adapter that implements both ProviderAdapter -(for discovery/wallet-picker) and Provider<DappRpcTypes> (for RPC calls). +(for discovery/wallet-picker) and Provider (for RPC calls). Calls signClient.request() directly with ``canton_`` prefixed methods. Events arriving via session_event are buffered until a listener attaches. @@ -650,7 +650,7 @@ interface ActiveSession | Member | Type | Description | | --- | --- | --- | | `adapter` | `ProviderAdapter` | - | -| `provider` | `Provider<RpcTypes>` | - | +| `provider` | `Provider` | - | | `providerId` | `string` | - | @@ -773,7 +773,7 @@ interface ProviderAdapter ``` A ProviderAdapter is a thin factory that knows how to create a -Provider<DappRpcTypes> for a particular wallet type, detect its +Provider for a particular wallet type, detect its availability, and clean up resources. All RPC methods (connect, disconnect, status, prepareExecute, etc.) @@ -837,7 +837,7 @@ interface WalletConnectAdapterConfig | --- | --- | --- | | `chainId` | `string` | - | | `metadata` | `{ description: string; icons: string[]; name: string; url: string }` | - | -| `onUri` | `(uri: string) => void` | Called with the pairing URI so the dApp can display or forward it. | +| `onUri` | `(uri: string) => void` | Called with the pairing URI so the dApp can display or forward it. | | `projectId` | `string` | - | @@ -1283,7 +1283,7 @@ onAccountsChanged(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<AccountsChangedEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1309,7 +1309,7 @@ onConnected(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<StatusEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1335,7 +1335,7 @@ onStatusChanged(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<StatusEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1361,7 +1361,7 @@ onTxChanged(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<TxChangedEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1461,7 +1461,7 @@ removeOnAccountsChanged(listener: EventListener): Promise< | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<AccountsChangedEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1487,7 +1487,7 @@ removeOnConnected(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<StatusEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1513,7 +1513,7 @@ removeOnStatusChanged(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<StatusEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` @@ -1539,7 +1539,7 @@ removeOnTxChanged(listener: EventListener): Promise | Parameter | Type | Required | Description | | --- | --- | --- | --- | -| `listener` | `EventListener<TxChangedEvent>` | yes | - | +| `listener` | `EventListener` | yes | - | Returns: `Promise` diff --git a/docs-main/reference/typescript/wallet-sdk.mdx b/docs-main/reference/typescript/wallet-sdk.mdx index 5b1a27b80..da4cd7028 100644 --- a/docs-main/reference/typescript/wallet-sdk.mdx +++ b/docs-main/reference/typescript/wallet-sdk.mdx @@ -208,7 +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. | +| `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` | - | @@ -226,7 +226,7 @@ Generated from published `@canton-network/wallet-sdk` TypeDoc snapshots. | Member | Type | Description | | --- | --- | --- | | `constructor` | `void` | - | -| `preparedPromise` | `Promise<{ costEstimation?: { confirmationRequestTrafficCostEstimation: number; confirmationResponseTrafficCostEstimation: number; estimationTimestamp: string; totalTrafficCostEstimation: number }; hashingDetails?: string; hashingSchemeVersion: "HASHING_SCHEME_VERSION_UNSPECIFIED" \| "HASHING_SCHEME_VERSION_V2" \| "HASHING_SCHEME_VERSION_V3"; preparedTransaction: string; preparedTransactionHash: string }>` | - | +| `preparedPromise` | `Promise<{ costEstimation?: { confirmationRequestTrafficCostEstimation: number; confirmationResponseTrafficCostEstimation: number; estimationTimestamp: string; totalTrafficCostEstimation: number }; hashingDetails?: string; hashingSchemeVersion: "HASHING_SCHEME_VERSION_UNSPECIFIED" \| "HASHING_SCHEME_VERSION_V2" \| "HASHING_SCHEME_VERSION_V3"; preparedTransaction: string; preparedTransactionHash: string }>` | - | | `decode` | `void` | - | | `sign` | `void` | - | | `toJSON` | `void` | - | @@ -277,7 +277,7 @@ Generated from published `@canton-network/wallet-sdk` TypeDoc snapshots. | Member | Type | Description | | --- | --- | --- | | `constructor` | `void` | - | -| `signedPromise` | `Promise<{ response: { costEstimation?: { confirmationRequestTrafficCostEstimation: number; confirmationResponseTrafficCostEstimation: number; estimationTimestamp: string; totalTrafficCostEstimation: number }; hashingDetails?: string; hashingSchemeVersion: "HASHING_SCHEME_VERSION_UNSPECIFIED" \| "HASHING_SCHEME_VERSION_V2" \| "HASHING_SCHEME_VERSION_V3"; preparedTransaction: string; preparedTransactionHash: string }; signature: string }>` | - | +| `signedPromise` | `Promise<{ response: { costEstimation?: { confirmationRequestTrafficCostEstimation: number; confirmationResponseTrafficCostEstimation: number; estimationTimestamp: string; totalTrafficCostEstimation: number }; hashingDetails?: string; hashingSchemeVersion: "HASHING_SCHEME_VERSION_UNSPECIFIED" \| "HASHING_SCHEME_VERSION_V2" \| "HASHING_SCHEME_VERSION_V3"; preparedTransaction: string; preparedTransactionHash: string }; signature: string }>` | - | | `execute` | `void` | - | | `response` | `void` | - | | `signature` | `void` | - | @@ -321,8 +321,8 @@ interface FeaturedAppService | Member | Type | Description | | --- | --- | --- | -| `grant` | `(options?: GrantFeaturedAppRightsOptions) => Promise<FeaturedAppRight>` | Submits a command to grant feature app rights for validator operator. | -| `rights` | `(options: LookupFeaturedAppRightsOptions) => Promise<FeaturedAppRight>` | Looks up if a party has FeaturedAppRight.
Has an in built retry and delay between attempts | +| `grant` | `(options?: GrantFeaturedAppRightsOptions) => Promise` | Submits a command to grant feature app rights for validator operator. | +| `rights` | `(options: LookupFeaturedAppRightsOptions) => Promise` | Looks up if a party has FeaturedAppRight.
Has an in built retry and delay between attempts | ### Type Aliases @@ -712,7 +712,7 @@ type RegisteredPlugins

SDKPlugin> | Name | Constraint | Default | Description | | --- | --- | --- | --- | -| `P` | `Record<string, (ctx: SDKContext) => SDKPlugin>` | `Record<string, (ctx: SDKContext) => SDKPlugin>` | - | +| `P` | `Record SDKPlugin>` | `Record SDKPlugin>` | - | 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; ``` From d17fcdf2366a23493d5bab2c4e5c540cc5d575b9 Mon Sep 17 00:00:00 2001 From: 8bitpal Date: Mon, 29 Jun 2026 09:20:32 +0200 Subject: [PATCH 2/3] Re-escape bare JSX-conflicting placeholders and regenerate tabs Provider in prose/table cells (not inside backtick spans) and in prose were incorrectly unescaped by the prior entity fix; restore them as <> entities to prevent MDX parse errors. Also regenerate network variable tabs for validator-disaster-recovery.mdx. Signed-off-by: 8bitpal --- .../validator-disaster-recovery.mdx | 6 +++--- .../reference/canton-console-commands.mdx | 4 ++-- docs-main/reference/typescript/dapp-sdk.mdx | 16 ++++++++-------- 3 files changed, 13 insertions(+), 13 deletions(-) diff --git a/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx b/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx index 2bc40ea09..3deddf2d3 100644 --- a/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx +++ b/docs-main/global-synchronizer/production-operations/validator-disaster-recovery.mdx @@ -178,7 +178,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). @@ -225,7 +225,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). @@ -272,7 +272,7 @@ If you still observe issues, in particular you observe `ACS_COMMITMENT_MISMATCH` 6. Start your validator app again. -3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `` depending on your deployment model). +3. If the previous step failed or you chose not to attempt it, you can retry the migration procedure with a fresh participant. If your parties are still on the original node that you took identities backup from, you can use your existing backup. If your parties have been migrated to the new node already, take a new identities dump from the new node. If the new node is in a state where you cannot take a fresh dump, use the old dump but edit the `id` field to the participant ID of the new node. You can obtain the `id` in the correct format by, for example, running `participant.id.toProtoPrimitive` in a Canton console to the participant. You can now take down the node to which you originally tried to restore and try the restore procedure again with your adjusted dump on a fresh node with a different participant ID prefix (i.e., a different `newParticipantIdentifier` / `<new_participant_id>` depending on your deployment model). diff --git a/docs-main/global-synchronizer/reference/canton-console-commands.mdx b/docs-main/global-synchronizer/reference/canton-console-commands.mdx index 09c4b6c0b..910fc6bc5 100644 --- a/docs-main/global-synchronizer/reference/canton-console-commands.mdx +++ b/docs-main/global-synchronizer/reference/canton-console-commands.mdx @@ -4990,7 +4990,7 @@ This command imports contracts from an Active Contract Set (ACS) snapshot file i The argument is: - `importFilePath`: The path denoting the file from where the ACS snapshot will be read. Defaults to "canton-acs-export.gz" when undefined. -- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-" when unspecified. +- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-<random_UUID>" when unspecified. - `contractImportMode`: Governs contract authentication processing on import. Options include Validation (default), [Accept, Recomputation]. - `representativePackageIdOverride`: Defines override mappings for assigning representative package IDs to contracts upon ACS import. Defaults to NoOverride when undefined. @@ -5199,7 +5199,7 @@ If the import process succeeds, the mapping from the old contract IDs to the new The arguments are: - `importFilePath`: The path denoting the file from where the ACS snapshot will be read. Defaults to "canton-acs-export.gz" when undefined. -- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-" when unspecified. +- `workflowIdPrefix`: Sets a custom prefix for the workflow ID to easily identify all transactions generated by this import. Defaults to "import-<random_UUID>" when unspecified. - `contractImportMode`: Governs contract authentication processing on import. Options include Validation (default), [Accept, Recomputation]. - `representativePackageIdOverride`: Defines override mappings for assigning representative package IDs to contracts upon ACS import. - `excludedStakeholders`: When defined, any contract that has one or more of these parties as a stakeholder will be omitted from the import. diff --git a/docs-main/reference/typescript/dapp-sdk.mdx b/docs-main/reference/typescript/dapp-sdk.mdx index 06bd4a048..3834a3f5c 100644 --- a/docs-main/reference/typescript/dapp-sdk.mdx +++ b/docs-main/reference/typescript/dapp-sdk.mdx @@ -13,17 +13,17 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | [`ErrorCode`](#enumeration-errorcode) | Enumeration | - | `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 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` | - | - | - | +| [`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` | - | - | - | | [`EventEmitter`](#class-eventemitter) | Class | - | `1.1.0` | - | - | - | | [`ExtensionAdapter`](#class-extensionadapter) | Class | ProviderAdapter for any CIP-103 compliant wallet exposed as a browser extension.

provider() returns a DappProvider which communicates via postMessage
and implements the full openrpc-dapp-api.json surface directly. | `1.1.0` | - | - | - | -| [`InjectedAdapter`](#class-injectedadapter) | Class | A ProviderAdapter is a thin factory that knows how to create a
Provider for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | +| [`InjectedAdapter`](#class-injectedadapter) | Class | A ProviderAdapter is a thin factory that knows how to create a
Provider<DappRpcTypes> for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | | [`NotConnectedError`](#class-notconnectederror) | Class | - | `1.1.0` | - | - | - | | [`RemoteAdapter`](#class-remoteadapter) | Class | ProviderAdapter for any CIP-103 compliant wallet reachable over HTTP/SSE.

provider() returns a provider that maps the remote API
(openrpc-dapp-remote-api.json) to the dApp API
(openrpc-dapp-api.json) via dappSDKController. | `1.1.0` | - | - | - | | [`SessionExpiredError`](#class-sessionexpirederror) | Class | - | `1.1.0` | - | - | - | | [`TimeoutError`](#class-timeouterror) | Class | - | `1.1.0` | - | - | - | | [`UserRejectedError`](#class-userrejectederror) | Class | - | `1.1.0` | - | - | - | -| [`WalletConnectAdapter`](#class-walletconnectadapter) | Class | Single-class WalletConnect adapter that implements both ProviderAdapter
(for discovery/wallet-picker) and Provider (for RPC calls).

Calls signClient.request() directly with ``canton_`` prefixed methods.
Events arriving via session_event are buffered until a listener attaches. | `1.1.0` | - | - | - | +| [`WalletConnectAdapter`](#class-walletconnectadapter) | Class | Single-class WalletConnect adapter that implements both ProviderAdapter
(for discovery/wallet-picker) and Provider<DappRpcTypes> (for RPC calls).

Calls signClient.request() directly with ``canton_`` prefixed methods.
Events arriving via session_event are buffered until a listener attaches. | `1.1.0` | - | - | - | | [`WalletNotFoundError`](#class-walletnotfounderror) | Class | - | `1.1.0` | - | - | - | | [`WalletNotInstalledError`](#class-walletnotinstallederror) | Class | - | `1.1.0` | - | - | - | | [`ActiveSession`](#interface-activesession) | Interface | - | `1.1.0` | - | - | - | @@ -32,7 +32,7 @@ Generated from published `@canton-network/dapp-sdk` TypeDoc snapshots. | [`DiscoveryConnectedEvent`](#interface-discoveryconnectedevent) | Interface | - | `1.1.0` | - | - | - | | [`DiscoveryDisconnectedEvent`](#interface-discoverydisconnectedevent) | Interface | - | `1.1.0` | - | - | - | | [`DiscoveryErrorEvent`](#interface-discoveryerrorevent) | Interface | - | `1.1.0` | - | - | - | -| [`ProviderAdapter`](#interface-provideradapter) | Interface | A ProviderAdapter is a thin factory that knows how to create a
Provider for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | +| [`ProviderAdapter`](#interface-provideradapter) | Interface | A ProviderAdapter is a thin factory that knows how to create a
Provider<DappRpcTypes> for a particular wallet type, detect its
availability, and clean up resources.

All RPC methods (connect, disconnect, status, prepareExecute, etc.)
are called directly on the provider — the adapter does not duplicate them. | `1.1.0` | - | - | - | | [`RemoteAdapterConfig`](#interface-remoteadapterconfig) | Interface | - | `1.1.0` | - | - | - | | [`WalletConnectAdapterConfig`](#interface-walletconnectadapterconfig) | Interface | - | `1.1.0` | - | - | - | | [`WalletInfo`](#interface-walletinfo) | Interface | - | `1.1.0` | - | - | - | @@ -307,7 +307,7 @@ Use ``DiscoveryClient`` + the wallet picker, or construct any - Source: `node_modules/@canton-network/core-wallet-discovery/dist/client.d.ts:31` DiscoveryClient manages provider adapters and exposes a unified -Provider regardless of the underlying wallet type. +Provider<DappRpcTypes> regardless of the underlying wallet type. It is UI-framework agnostic — the wallet picker UI is injected via the ``walletPicker`` config option. @@ -412,7 +412,7 @@ and implements the full openrpc-dapp-api.json surface directly. - Source: `dist/adapter/injected-adapter.d.ts:12` A ProviderAdapter is a thin factory that knows how to create a -Provider for a particular wallet type, detect its +Provider<DappRpcTypes> for a particular wallet type, detect its availability, and clean up resources. All RPC methods (connect, disconnect, status, prepareExecute, etc.) @@ -560,7 +560,7 @@ provider() returns a provider that maps the remote API - Source: `dist/adapter/walletconnect-adapter.d.ts:25` Single-class WalletConnect adapter that implements both ProviderAdapter -(for discovery/wallet-picker) and Provider (for RPC calls). +(for discovery/wallet-picker) and Provider<DappRpcTypes> (for RPC calls). Calls signClient.request() directly with ``canton_`` prefixed methods. Events arriving via session_event are buffered until a listener attaches. @@ -773,7 +773,7 @@ interface ProviderAdapter ``` A ProviderAdapter is a thin factory that knows how to create a -Provider for a particular wallet type, detect its +Provider<DappRpcTypes> for a particular wallet type, detect its availability, and clean up resources. All RPC methods (connect, disconnect, status, prepareExecute, etc.) From bdc59d4f01daedf04e63ff369cc0368ef9f7b654 Mon Sep 17 00:00:00 2001 From: 8bitpal Date: Thu, 2 Jul 2026 14:38:16 +0200 Subject: [PATCH 3/3] Escape and placeholders in prose Both appear in a prose sentence on line 6807 outside any code block or backtick span, causing an MDX JSX parse error. Signed-off-by: 8bitpal --- .../global-synchronizer/reference/canton-console-commands.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs-main/global-synchronizer/reference/canton-console-commands.mdx b/docs-main/global-synchronizer/reference/canton-console-commands.mdx index 910fc6bc5..142636da3 100644 --- a/docs-main/global-synchronizer/reference/canton-console-commands.mdx +++ b/docs-main/global-synchronizer/reference/canton-console-commands.mdx @@ -6804,7 +6804,7 @@ proposals: Whether to query proposals instead of authorized transactions. timeQu List multi-hosted party proposals. -Multi-hosted parties require all involved actors to sign the topology transaction. Topology transactions without sufficient signatures are called proposals. They are distributed the same way as fully authorized topology transactions, and signatures are aggregated until the transaction is fully authorized. This method here allows to inspect the pending queue of open hosting proposals. The proposals are returned as seen on the specified synchronizer. They can be approved by the individual participants by invoking node.topology.transactions.authorize(, ). +Multi-hosted parties require all involved actors to sign the topology transaction. Topology transactions without sufficient signatures are called proposals. They are distributed the same way as fully authorized topology transactions, and signatures are aggregated until the transaction is fully authorized. This method here allows to inspect the pending queue of open hosting proposals. The proposals are returned as seen on the specified synchronizer. They can be approved by the individual participants by invoking node.topology.transactions.authorize(<synchronizer-id>, <tx-hash>). **Arguments**