Deploying institutional tokenization on Canton

In December 2025, DTCC announced its Canton-based tokenization service for DTC-custodied U.S. Treasury securities — initial limited production trades expected in July 2026, with a broader launch planned for October 2026 — against DTC's USD 114 trillion assets-under-custody footprint and with a 50-plus firm industry working group spanning BlackRock, Goldman Sachs, J.P. Morgan, Morgan Stanley, Citi, BNP Paribas, HSBC, UBS, State Street, Nasdaq, NYSE Group, Tradeweb, Franklin Templeton, Circle, Ripple, Anchorage Digital, and Digital Asset. The Eurosystem published its Pontes blueprint and exploratory window for DLT-versus-central-bank-money settlement in the same quarter. Goldman Sachs and BNY Mellon launched tokenized money-market funds on Canton in July 2025. Société Générale issued a USD-denominated digital bond on Canton in June 2025.

2026 turned the demonstrations into operating fact. In the first quarter, DTCC and a group of major banks executed the first cross-border intraday repo on Canton — tokenized UK gilts against tokenized non-sterling deposits — and the Canton Industry Working Group demonstrated 24/7 global collateral mobility against a collateral pool the industry sizes in the hundreds of trillions. BitGo extended qualified custody to CIP-0056 assets in March 2026, giving the token standard a regulated custody ecosystem. Canton-based infrastructure processed roughly $7.5 trillion in U.S. Treasury repo in June 2026 alone. Market-wide, tokenized Treasury funds passed $15 billion in the first half of 2026 and tokenized real-world assets excluding stablecoins sit near $25 billion — small against the underlying markets, compounding fast, and concentrated in exactly the fund, credit, and collateral instruments the Tradeable pattern models.

Canton itself — the Global Synchronizer, the privacy-preserving ledger, the Canton Network Token Standard (CIP-0056) and its settlement primitives — is by 2026 the shared institutional rail. Token Standard V2 (CIP-0112, approved June 2026) is backward-compatible, so assets issued against the original interfaces carry forward. The chain itself is not the question. The question is what an institution, an issuer, or an asset owner does on top of it.

A production deployment on Canton, for a regulated asset class, factors into six surfaces. They are the same six whether the asset is a money-market fund, a sovereign bond, a real-estate vehicle, a sukuk, a carbon program, a sovereign register, or a credential schema. The composition is what differs.

The rail. Canton — the Global Synchronizer, the validator participant set, the Canton token standard at CIP-0056 and its settlement primitives. Bought, not built. The institution joins the rail through a validator or a registered Splice application provider.

The asset model. The Daml contract code that represents the instrument on-chain — its issuance, its transfer controls, its lifecycle events, its lockups, its restrictions, its corporate actions, its retirements. This is where every regulated asset class differs, and where most of the Daml engineering work on a deployment lives. Without a pattern library, every deployment writes this from scratch.

The compliance surface. Eligibility rules, transfer restrictions, jurisdictional lockups, sanctions screening, professional-investor gates, holding-period rules. The rail does not specify these. The asset model has to enforce them, on every transfer, on every issuance, on every redemption, on every settlement leg.

The identity surface. The connection between an on-chain party identifier and the off-chain regulated identity — the KYC record, the professional-license attestation, the sovereign credential, the entity register. The rail provides party identifiers; it does not provide identity. The institution either builds the identity layer or composes with one.

The distribution surface. Where Canton settles, but the liquidity is elsewhere — on an EVM chain, on Solana, on a permissioned venue, on an institutional book. Cross-chain projection — the discipline of moving the Canton-settled asset onto another chain via burn-and-mint for trading or distribution — is a design choice that either composes with the asset model or fights it.

The operating surface.The custodian wiring, the back-office integration, the systems of record, the reporting, the audit. This is where the deployment touches the institution's existing stack. The rail does not specify it. The deployment has to.

Boli is the tokenization and interop layer above the rail. The asset model comes as a small library of Daml patterns — Tradeable, Registry-mirror, and Credential — that carries every regulated asset class. Compliance runs as a chain-level pack engine: a named, versioned catalog of rule sets tuned to jurisdictions, instruments, and counterparty relationships, applied at the contract level on every state transition. Identity crosses through the TDIP-to-Canton identity layer, which ties on-chain Canton parties to off-chain regulated identities under decentralized identifiers and verifiable credentials. Distribution runs through cross-chain projection — Canton settles, and the asset projects onto EVM and Solana via burn-and-mint (ERC-7802), with total circulating supply across every chain staying within one attested reserve. Operations run on an agentic runtime — NAV reconciliation, compliance monitoring, MRV verification, and redemption orchestration, executed under AP2 mandates and settled atomically on Canton — composed with the institution's custodian, systems of record, and existing infrastructure. The specifications underneath these surfaces — the patterns, the pack schema, the TDIP identity protocol, the cross-chain projection protocol, the agent-mandate model — are published as the Boli Standards Proposals under CC0, so the standards themselves are inspectable, implementable, and not owned by Boli. The platform implementations remain Boli's.

Funds, bonds, equities, real estate, commodities, carbon, identity, sovereign registers: every regulated asset class Boli has examined reduces to one of three Daml contract shapes — and we have yet to meet a regulated instrument that doesn't fit. One contract surface, three patterns, not a taxonomy rebuilt per instrument.

Tradeable. An on-chain asset that transfers, settles, and clears under the Canton token standard. Money-market funds, tokenized deposits, digital bonds, equities, commodities, carbon credits in their tradeable phase, and any settlement asset (stablecoin, CBDC, commercial-bank money) are Tradeable instances. The pattern wires AllocationV1 for atomic settlement, compliance-pack enforcement on every transfer, and the controls specified at CIP-0056. CBDC is a Pattern A instance, not a separate architecture.

Registry-mirror. An on-chain mirror of an off-chain authoritative register — a real-estate title register, a sovereign land registry, a fund-share register, a corporate register, a carbon-credit retirement register. The on-chain record mirrors the register; authority stays with the off-chain system. Transfers, lifecycle events, and corporate actions propagate from the authority. The pattern handles the attestation surface from the off-chain register to the on-chain mirror and the bidirectional integrity guarantees.

Credential. An on-chain credential record — a KYC attestation, a professional-investor license, a sovereign identity claim, a regulatory authorization, a sanctions-screening result. Credentials do not trade. They are issued, presented, verified, and revoked. The pattern is the on-chain anchor for the off-chain TDIP identity layer. Digital identity is a Pattern C instance, not a separate architecture.

The three patterns are the reason a deployment on Boli is bounded. The asset model is not invented for the engagement; it is configured from the pattern that matches the instrument. The engineering work moves from contract design to compliance- pack tuning, TDIP identity wiring, and operating-surface integration — where it should be.

On Canton, the compliance behavior of an asset is enforced by the asset's Daml contract code. Every transfer, every issuance, every lifecycle event runs through the contract's choices, and the choices either authorize the action or reject it. This is structurally different from a conventional single-chain EVM design, where compliance is bolted on through allow-lists, transfer hooks, or off-chain gating. On Canton the compliance is in the contract.

Boli factors this into a chain-level compliance-pack engine. A pack is a named, versioned, declarative bundle of rules — eligibility, transfer restrictions, jurisdictional lockups, sanctions screening, holding-period rules, attestation gates, professional-investor flags. Each pack is specified once, implemented once, and applied to any asset of the corresponding pattern through configuration rather than rewriting the contract. A deployment picks the packs that match the jurisdiction, the instrument, and the counterparty graph, and tunes parameters; it does not re-implement compliance.

The first packs in the catalog cover Reg-D and Reg-S professional-investor distribution; MiFID II / EU professional- client distribution; UAE FSRA Recognized-Body professional distribution; and Sharia-compliant transfer with on-ledger screening. The catalog extends with each engagement. Pack schemas are specified at the BSP level — the Boli Standards Proposals — and the specifications are published under CC0. An institution that prefers to implement a pack itself, in its own engineering organization, against the published specification can do so. Boli's pack implementations remain Boli's.

The hardest surface in an institutional deployment is the identity surface. The rail provides party identifiers — Canton parties — but it does not provide identity in the regulated sense. The institution's KYC system, its professional- license registry, its sanctions-screening service, its sovereign-credential infrastructure all live off-chain. The asset model has to gate transfers and issuances on the off- chain state, and it has to do this without leaking PII onto the ledger.

Boli runs the identity layer through TDIP — a decentralized-identifier and verifiable-credential protocol — terminated at the Canton party level. A KYC record, a license, or a credential is issued off-chain by an authorized identity issuer. A verifiable-credential presentation is bound to a Canton party identifier. The asset model's compliance pack inspects the credential's presence and validity at the moment of transfer or issuance; the credential itself remains off-chain. The on-chain record carries the gating decision, not the personal data behind it.

The identity layer handles sovereign credentials the same way it handles commercial KYC: a sovereign identity issuer is a TDIP-recognized issuer; a sovereign-credential schema is a Credential-pattern instance; a transfer that is gated on a sovereign credential inspects the verifiable presentation at the point of transfer. This is the surface on which sovereign issuers — central banks, sovereign-bond issuers, registry operators, identity authorities — bring their own credentialing into the Canton stack.

Settlement on Canton does not preclude trading or distribution elsewhere. For some asset classes — institutional money-market funds, sovereign bonds, regulated stablecoins — Canton is the place the asset needs to live. For others — tokenized real-estate fractions, carbon programs, retail-distributed funds, instruments whose liquidity surface is an EVM book or a Solana market — settlement on Canton co-exists with a presence on another chain.

Boli's cross-chain projection is the discipline for this. The Canton contract carries the regulated state, the compliance-pack enforcement, the lifecycle authority. The asset projects onto EVM or Solana via burn-and-mint (ERC-7802) — supply moves between chains rather than being locked and wrapped — so trading, lending, or distribution can occur on the foreign chain. Total circulating supply across every chain stays within one attested reserve, enforced at the mint from live on-chain reads. Projection is a deployment-time choice, not a property of the pattern. Where it is not required, it is not built.

Institutional assets are not only owned; they are operated. A tokenized fund has to be reconciled against custodian balances and trade activity on a continuous basis. A tokenized carbon credit has to carry continuously-updated MRV state. A regulated transfer has to be observed against the licensed party's compliance pack on every state change. A redemption has to coordinate registry updates, settlement-asset movement, and credential revocation atomically. None of this is a one-time issuance event; all of it is a continuous workflow.

The Boli agentic runtime is where that workflow runs. Autonomous workflow execution under AP2 mandates, TEE-attested, settled on Canton. NAV reconciliation, compliance monitoring, MRV verification, and redemption orchestration are first-class workflows; the catalog extends with each engagement.

Every agent action is attributable to an AP2 mandate scoped by TDIP delegation — revocable, auditable, and policy-constrained. Authority graphs and revocation trees — not API tokens — govern what an autonomous system can do. The mandate model is specified in the BSPs; the runtime is Boli's. The institution's compliance team and auditors inspect the same authority graph the agents execute against, in the same form, on the same ledger.

The deployment terminates at the institution's existing stack. The custodian holds the keys. The systems of record hold the accounting line. The reporting infrastructure reports on the on-chain state to the same regulators, auditors, and internal control functions that already see the off-chain state. The on-chain estate has to be legible to the rest of the institution, or the deployment does not survive implementation.

Boli composes with the custodian and systems the institution has already chosen — Anchorage, BitGo, Fireblocks, Taurus, and their peers are integration targets on one adapter pattern, not live connectors today. The institution retains its custody relationship; the deployment adapts to it. The same shape applies to systems of record: the deployment integrates with the institution's book of record (SimCorp, Murex, Calypso, internal), its reporting pipeline, its risk engine, and its general ledger.

Boli does not provide custody. It does not hold keys. It does not run regulated venues. It does not issue settlement assets. It does not carry the institution's licenses. Every regulated function in the deployment sits inside the institution's own license perimeter. This is the line on which the platform is built, and the line on which an institutional engagement is possible at all.

The engagement is one engagement. The institution arrives at it from one of three positions.

Deploying on Canton. An institution standing up tokenized issuance, custody, or settlement infrastructure on Canton — bank, asset manager, custodian, exchange, sovereign issuer, central bank, registry operator. The instrument is one of several the institution will run on the rail. The asset model, the compliance packs, the TDIP identity layer, and the operating-surface integration are configured for the first instrument and extended to the rest.

Issuing on Canton.A licensed issuer bringing a specific instrument or program on-chain — a bond, a fund, a real-estate vehicle, a sukuk, a carbon program, a sovereign register, a credential schema. The instrument is the scope; the platform is composed around it. The license is the issuer's; the engagement maps the license onto the compliance surface.

Issuing through a Boli-onboarded issuer.A party with a real-world asset — a developer, an operator, a corporate, an agency — that does not carry an issuer license. The asset is the party's; the issuance is routed through a licensed issuer already integrated with Boli; the platform stands behind both. This is the surface on which asset owners outside the regulated-issuer class — including issuers in jurisdictions where the license economics for a single instrument do not justify standing up their own license — access Canton.

The platform, the standards, and the scope conversation are the same across the three. The instrument, the jurisdiction, the licensed party, and the counterparty graph are the variables.

A Boli engagement is a bespoke service delivered against the platform. It is not advisory. It is not consultancy. It ends with a production instance on Canton, configured to the instrument, with test vectors and a go-live handover. The scope is bounded by the three patterns, the named compliance packs, the TDIP identity layer, cross-chain projection, the agentic runtime, and the operating-surface adapters Boli already runs. Custom development sits where the platform stops — pack tuning for a novel jurisdiction, integration with a custodian or system of record not yet wired, or an asset-model variant inside one of the three patterns.

Three constants run through every engagement. The deployment settles on Canton, under the Global Synchronizer, composing with the Canton token standard at CIP-0056. The asset patterns, compliance-pack schemas, TDIP identity protocol, cross-chain projection, and agent-mandate model are specified in the Boli Standards Proposals; the engagement implements them rather than inventing them. The output is a running production system, not a slide deck.

Three lines run through every engagement's scope. Custody — the institution chooses its custodian; the engagement integrates with that choice. Settlement assets — stablecoin, tokenized deposit, CBDC, or commercial-bank money are issued by a licensed party; Boli is settlement-asset- agnostic. Regulatory authorization — the institution carries its own license in its own jurisdiction; the engagement does not provide regulatory cover.

The platform sits on a small set of open standards — the Boli Standards Proposals, published at github.com/boli-foundation/bsps under CC0. The BSPs specify the three Daml asset patterns, the compliance-pack engine, the TDIP-to-Canton identity layer, the cross-chain projection protocol, the agent-mandate model, and the marketplace intent-routing protocol. They are inspectable by the institution's engineering organization, by its compliance team, by its auditors, and by its counterparties. The BSPs are the open layer. The platform implementations Boli ships against them are not CC0; they are Boli's.

The standards are governed under a lightweight process — Draft, Final, Replaced; Standard or Informational; named editors; two-editor merge; reference-implementation gate for promotion to Final. The process is documented at the repository. Contribution is open. The platform follows the standards; the standards do not follow the platform.

For the institution deploying on Canton, this means the engineering work that would otherwise be done in-house — three Daml pattern implementations, a compliance engine, a TDIP identity layer, cross-chain projection, an agentic runtime for asset operations, an operating-surface integration kit — is already built, specified, and inspectable. The institution's engineering organization extends the platform rather than reproducing it. The engagement reaches a production instance in a span measured against asset economics, not against rebuilding the infrastructure.

For the licensed issuer, this means the instrument can be brought on-chain without taking a position on the rest of the stack. The license is the issuer's; the compliance pack maps onto it; the TDIP identity layer composes with whatever KYC the issuer already runs; the custodian is the issuer's choice. The engagement is bounded to the instrument and its counterparty graph.

For the asset owner without an issuer license, this means access to Canton through a licensed party already integrated with the platform. The economics that prevent standing up a single-instrument license do not prevent the instrument from reaching the rail. The license stays with the party that holds it; the platform stands behind the issuance; the asset owner brings the asset.

The first conversation is a technical readout, not a sales call. It maps the instrument to a pattern, the jurisdiction to a pack, and the counterparty graph to the integration surface. It identifies, in concrete terms, what the platform already covers and what is custom for the engagement. It ends with a scope and a path to a production instance, or with the reasonable answer that Boli is not the right composition for this asset.

Where the answer is yes, the engagement begins. Where the answer is no, the readout is a contribution to the institution's own evaluation — the standards are CC0 and inspectable, and the work of putting an asset on Canton is, on balance, a smaller undertaking than it looks.

This document is a brief. It is not a contract; it is not an offer or solicitation of securities, tokens, or any financial instrument; it is not a marketing communication for a regulated product; it is not a financial promotion. It describes the Boli platform, the Boli engagement model, and the Canton rail as the platform composes with it.

Forward-looking statements reflect present intent and are subject to change; outcomes may differ materially. References to third-party institutions, products, and milestones are drawn from public sources current at the date of publication and are included to describe the institutional landscape on which the platform composes. Inclusion does not imply endorsement of Boli by the named parties. The document may be updated; the current version is the one published at boli.technology/brief.