Deploying institutional tokenization on Canton.

On 4 May 2026, DTCC confirmed the production launch timetable for its Canton-based tokenization service — initial limited production trades in July 2026, full service launch in 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.

Canton itself — the Global Synchronizer, the privacy-preserving ledger, the CIP-0056 institutional-grade token standard, the Splice Token Standard V1 settlement primitive — is by 2026 the shared institutional rail. 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 programme, a sovereign register, or a credential schema. The composition is what differs.

The rail. Canton — the Global Synchronizer, the Splice Token Standard V1 settlement primitive, the validator participant set, the institutional-grade token standard at CIP-0056. 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-licence attestation, the sovereign credential, the entity register. The rail provides party identifiers; it does not provide identity. The institution either builds the bridge 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. The mirror — the discipline of representing the Canton-settled state on another VM 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 an operating layer above the rail. It supplies the asset model as a small library of Daml patterns — Tradeable, Registry- mirror, and Credential — to which every regulated asset class reduces. It supplies the compliance surface as a chain-level compliance-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. It supplies the identity surface as the TDIP-to- Canton bridge — a protocol that ties on-chain Canton parties to off-chain regulated identities under decentralized identifiers and verifiable credentials. It supplies the distribution surface as the multi-VM mirror — Canton settles, EVM and Solana mirror, with the settlement state on Canton remaining canonical. It supplies the operational layer as an agentic runtime — autonomous workflows for NAV reconciliation, compliance monitoring, MRV verification, and redemption orchestration, executed under DID-bound mandates and settled atomically on Canton. It supplies the operating surface as a configurable runtime that composes with the institution's custodian, systems of record, and existing infrastructure. The specifications underneath these surfaces — the patterns, the pack schema, the identity-bridge protocol, the mirror 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.

Most institutional tokenization conversations begin with a taxonomy of instruments — funds, bonds, equities, real estate, commodities, carbon, identity, sovereign registers — and rebuild the contract surface for each one. Boli has taken a different cut: every regulated asset class, examined closely, reduces to one of three Daml contract shapes.

Tradeable. An on-chain asset that transfers, settles, and clears under Splice Token Standard V1. 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 institutional-grade 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 contract is the canonical-on-chain reflection of the off-chain authority. 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 licence, a sovereign identity claim, a regulatory authorisation, 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 bridge. Digital identity is a Pattern C instance, not a separate architecture.

The three-pattern reduction is 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, identity-bridge wiring, and operating-surface integration — where it should be.

On Canton, the compliance behaviour 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 Layer-1 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 organisation, 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- licence 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 bridge through TDIP — a decentralized-identifier and verifiable-credential protocol — terminated at the Canton party level. A KYC record, a licence, 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 bridge 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 only place the asset needs to live. For others — tokenized real-estate fractions, carbon programmes, 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 VM.

The Boli multi-VM mirror is the discipline for this. The Canton contract remains canonical: it carries the regulated state, the compliance-pack enforcement, the lifecycle authority. The EVM or Solana mirror is a reflection — an account-level or token- level representation against which trading, lending, or distribution can occur on the foreign VM. The state on Canton is the source of truth; the foreign VM's state is brought back into line with it on every confirmed Canton transition. The mirror 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 DID-bound mandates, verifiable in TEE, 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 a DID-bound mandate, 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 integrates with the custodian the institution has already chosen — Anchorage, BitGo, Fireblocks, Taurus, Zodia, Komainu, or an internal custody system. The institution retains its custody relationship; the deployment composes with 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 licences. Every regulated function in the deployment sits inside the institution's own licence 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 identity bridge, 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 programme on-chain — a bond, a fund, a real-estate vehicle, a sukuk, a carbon programme, a sovereign register, a credential schema. The instrument is the scope; the platform is composed around it. The licence is the issuer's; the engagement maps the licence 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 licence. 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 licence economics for a single instrument do not justify standing up their own licence — 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 bridge, the multi-VM mirror, 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 and the CIP-0056 institutional-grade token standard, composing with Splice Token Standard V1. The asset patterns, compliance-pack schemas, identity-bridge protocol, multi-VM mirror, 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 authorisation — the institution carries its own licence 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 bridge, the multi-VM mirror, the agent-mandate model, and the marketplace intent-routing protocol. They are inspectable by the institution's engineering organisation, 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, an identity bridge, a multi-VM mirror, an agentic runtime for asset operations, an operating-surface integration kit — is already built, specified, and inspectable. The institution's engineering organisation 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 licence is the issuer's; the compliance pack maps onto it; the identity bridge 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 licence, this means access to Canton through a licensed party already integrated with the platform. The economics that prevent standing up a single-instrument licence do not prevent the instrument from reaching the rail. The licence 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 industry 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.