canton-network · 8bitpal · Jun 29, 2026 · Jun 29, 2026 · Jun 29, 2026 · Jul 2, 2026
diff --git a/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx b/docs-main/appdev/deep-dives/smart-contract-upgrade.mdx
@@ -74,8 +74,8 @@ The Java and TypeScript codegen allow the use of package name and package ID (if
 
 PQS supports using package-name (specified in `daml.yaml`) instead of package-id. When specifying a template/interface/choice name, simply substitute any package-id with the package-name (eg. now `register:DA.Register:Token`) instead of the old `deadbeefpackageidhex:DA.Register:Token` format. This applies to template filters and SQL queries (eg. via the `active()` function). These functions will always return all versions of a given identifier. Qualified name can be:
 
-- fully qualified, e.g. `&lt;package-name&gt;:&lt;module-path&gt;:&lt;template-name&gt;`
-- partially qualified, e.g. `&lt;module-path&gt;:&lt;template-name&gt;`
+- fully qualified, e.g. `<package-name>:<module-path>:<template-name>`
+- partially qualified, e.g. `<module-path>:<template-name>`
 
 Qualified names cannot be ambiguous.
 
@@ -1366,9 +1366,9 @@ You can find the in-depth upgrading model, which can be used as a reference for
 
 ## Package Selection in the Ledger API
 
-Until the introduction of SCU, template IDs in requests to the Ledger API were all of the form `&lt;package-id&gt;:&lt;module-name&gt;:&lt;template-name&gt;`. 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 `<package-id>:<module-name>:<template-name>`. 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 `#&lt;package-name&gt;:&lt;module-name&gt;:&lt;template-name&gt;` (**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 `&lt;module-name&gt;:&lt;template-name&gt;` 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 `#<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.
 
 `By-package-name template ID` addressing is supported for all packages and is possible on both the write path (command submission) and read path (Ledger API queries).
 
@@ -1876,7 +1876,7 @@ Package ID selection preference: preferences apply to JSON Ledger API where you
 
 ### PQS
 
-To match the package-name changes to the Ledger API, PQS has changed how packages are selected for queries. All queries that take a Daml identity in the form `&lt;package-id&gt;:&lt;module-name&gt;:&lt;template-name&gt;` 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 `<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.
 
 <Note>
 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
@@ -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 `&lt;place-holders&gt;` as appropriate.
+Add the following to your `daml.yaml`, replacing the `<place-holders>` as appropriate.
 
 ```yaml
 sdk-version: <such as 3.4.9>
-name: &lt;your-package-name&gt;
+name: <your-package-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 `&lt;package-directory&gt;/.daml/dist/&lt;package-name&gt;-&lt;package-version&gt;.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 `<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:
 
 ```yaml
 build-options:

diff --git 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 &lt;DAR-file&gt; -o &lt;output-dir&gt;
+dpm codegen-java <DAR-file> -o <output-dir>
 ```
 
 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
@@ -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 &lt;path_to_json_tests_project&gt;/.daml/dist/json-tests-0.0.1.dar
+dpm sandbox --json-api-port 7575 --dar <path_to_json_tests_project>/.daml/dist/json-tests-0.0.1.dar
 ```
 
 <Note>
@@ -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 &lt;canton_installation&gt;/examples/09-json-ledger-api
+cd <canton_installation>/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 &lt;canton_installation&gt;/examples/09-json-ledger-api/typescript
+cd <canton_installation>/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
@@ -240,7 +240,7 @@ The desired value may vary between SDK versions. You can identify the main packa
 The format follows:
 
 ``` text
-&lt;project-name&gt;-<version>-&lt;package-id&gt;
+<project-name>-<version>-<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
@@ -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-&lt;mypkg-package-id&gt;/dep-1.0.0-&lt;dep-package-id&gt;.dalf
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.daml
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.hi
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.hie
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/mypkg-1.0.0-&lt;mypkg-package-id&gt;.dalf
+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
 ```
 
 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-&lt;mypkg-package-id&gt;.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-<mypkg-package-id>.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-&lt;dep-package-id&gt;.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-<dep-package-id>.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-&lt;mypkg-package-id&gt;/dep-1.0.0-&lt;dep-package-id&gt;.dalf
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/mypkg-1.0.0-&lt;mypkg-package-id&gt;.dalf
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/MyPkg.daml
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/MyPkg.hi
-mypkg-1.0.0-&lt;mypkg-package-id&gt;/MyPkg.hie
+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
 META-INF/MANIFEST.MF
 
 DAR archive contains the following packages:
 
 ...
-dep-1.0.0-&lt;dep-package-id&gt; "&lt;dep-package-id&gt;"
-mypkg-1.0.0-&lt;mypkg-package-id&gt; "&lt;mypkg-package-id&gt;"
+dep-1.0.0-<dep-package-id> "<dep-package-id>"
+mypkg-1.0.0-<mypkg-package-id> "<mypkg-package-id>"
 ```
 
 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-&lt;mypkg-package-id&gt;/dep-1.0.0-&lt;dep-package-id&gt;.dalf",
-        "mypkg-1.0.0-&lt;mypkg-package-id&gt;/mypkg-1.0.0-&lt;mypkg-package-id&gt;.dalf",
-        "mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.daml",
-        "mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.hi",
-        "mypkg-1.0.0-&lt;mypkg-package-id&gt;/Main.hie",
+        "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",
         "META-INF/MANIFEST.MF"
     ],
-    "main_package_id": "&lt;mypkg-package-id&gt;",
+    "main_package_id": "<mypkg-package-id>",
     "packages": {
-        "&lt;mypkg-package-id&gt;": {
+        "<mypkg-package-id>": {
             "name": "mypkg",
             "path":
-              "mypkg-1.0.0-&lt;mypkg-package-id&gt;/mypkg-1.0.0-&lt;mypkg-package-id&gt;.dalf",
+              "mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf",
             "version": "1.0.0"
         },
-        "&lt;dep-package-id&gt;": {
+        "<dep-package-id>": {
             "name": "dep",
-            "path": "mypkg-1.0.0-&lt;mypkg-package-id&gt;/dep-1.0.0-&lt;dep-package-id&gt;.dalf",
+            "path": "mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.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 &lt;path-to-dar-file&gt;` 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 <path-to-dar-file>` 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 &lt;mypkg-package-id&gt;
+package <mypkg-package-id>
 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 &lt;path-to-dalf-file&gt;` on a DALF file prints all of the code in that 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.
 
 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-&lt;mypkg-package-id&gt;/dep-1.0.0-&lt;dep-package-id&gt;.dalf
-package &lt;dep-package-id&gt;
+> dpm damlc inspect mypkg-1.0.0-<mypkg-package-id>/dep-1.0.0-<dep-package-id>.dalf
+package <dep-package-id>
 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-&lt;mypkg-package-id&gt;/mypkg-1.0.0-&lt;mypkg-package-id&gt;.dalf
-package &lt;mypkg-package-id&gt;
+> dpm damlc inspect mypkg-1.0.0-<mypkg-package-id>/mypkg-1.0.0-<mypkg-package-id>.dalf
+package <mypkg-package-id>
 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("&lt;path-to-dalf&gt;"))` to parse out the `ArchivePayload` of a dalf file.
+  Run `ArchiveReader.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` to parse out the `ArchivePayload` of a dalf file.
 
 - `val ArchiveDecoder: GenReader[(PackageId, Ast.Package)]`
 
-  Run `ArchiveDecoder.readArchiveFromFile(new java.io.File("&lt;path-to-dalf&gt;"))` to parse out the `(Ref.PackageId, Ast.Package)` of a dalf file.
+  Run `ArchiveDecoder.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` to parse out the `(Ref.PackageId, Ast.Package)` of a dalf file.
 
 - `val ArchiveParser: GenReader[DamlLf.Archive]`
 
-  Run `ArchiveParser.readArchiveFromFile(new java.io.File("&lt;path-to-dalf&gt;"))` to parse out the `DamlLf.Archive` of a dalf file.
+  Run `ArchiveParser.readArchiveFromFile(new java.io.File("<path-to-dalf>"))` 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("&lt;path-to-dar&gt;"))` to parse out the `Dar[ArchivePayload]` of a dar file.
+  Run `DarReader.readArchiveFromFile(new java.io.File("<path-to-dar>"))` to parse out the `Dar[ArchivePayload]` of a dar file.
 
 - `val DarDecoder: GenDarReader[(PackageId, Ast.Package)]`
 
-  Run `DarDecoder.readArchiveFromFile(new java.io.File("&lt;path-to-dar&gt;"))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file.
+  Run `DarDecoder.readArchiveFromFile(new java.io.File("<path-to-dar>"))` 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("&lt;path-to-dar&gt;"))` to parse out the `Dar[DamlLf.Archive]` of a dar file.
+  Run `DarParser.readArchiveFromFile(new java.io.File("<path-to-dar>"))` 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("&lt;path-to-dar-or-dalf&gt;"))` to parse out the `Dar[ArchivePayload]` of a dar file.
+  Run `UniversalArchiveReader.readFile(new java.io.File("<path-to-dar-or-dalf>"))` to parse out the `Dar[ArchivePayload]` of a dar file.
 
 - `val UniversalArchiveDecoder: GenUniversalArchiveReader[(PackageId, Ast.Package)]`
 
-  Run `UniversalArchiveDecoder.readFile(new java.io.File("&lt;path-to-dar-or-dalf&gt;"))` to parse out the `Dar[(Ref.PackageId, Ast.Package)]` of a dar file.
+  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.
 
 ### Example
 

diff --git 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."
 
   <div class="x2mdx-ref-meta-item">
     <dt>Version filter</dt>
-    <dd>stable Canton release bundles &gt;= 3.2.0</dd>
+    <dd>stable Canton release bundles >= 3.2.0</dd>
   </div>
 
   <div class="x2mdx-ref-meta-item">

diff --git 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 &lt;some-canton-script&gt; -c config/remote-participant1.conf
+./bin/canton run <some-canton-script> -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.&lt;remote-participant-name&gt;.token="&lt;encoded-and-signed-access-token-as-string&gt;" \
-   --bootstrap &lt;some-script&gt;
+   -C canton.remote-participants.<remote-participant-name>.token="<encoded-and-signed-access-token-as-string>" \
+   --bootstrap <some-script>
 ```
 
 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: