An operating platform on the Canton Network for regulated tokenized assets. Three Daml asset patterns, a chain-level compliance-pack engine, multi-VM mirroring, the TDIP identity bridge, and agentic asset operations under DID-bound on-chain mandates.

Hosted by the Boli Foundation as the canonical ecosystem reference. The Boli Platform is built and operated independently by a separate engineering organisation. Licensed CC BY 4.0.

Status of this document

This is a draft for review. It describes the Boli Platform as designed and currently being implemented at v0.9. Sections marked (specification) in Part III are authoritative for implementations; other sections are explanatory. Material changes between v0.9 and v1.0 will be tracked in the change log at the back of this document.

The whitepaper is maintained at github.com/boli-foundation/whitepaper, alongside the Boli Standards Proposals (BSPs) repository at github.com/boli-foundation/bsps. It is licensed under CC BY 4.0.

Abstract

Boli is an operating platform on the Canton Network for regulated tokenized assets. It ships three Daml asset patterns — Tradeable, Registry-mirror, Credential — which together carry every regulated asset class encountered in production: securities, funds, sukuk, real-estate share classes, environmental credits, sovereign registries (land, vehicles, IP), identity attestations, and central-bank instruments. A chain-level compliance-pack engine enforces the licensed party's policy on every transfer; the rule runs on Canton, not in a frontend. Multi-VM mirroring keeps the asset canonical on Canton — where institutions transact under sub-transaction privacy and atomic settlement — and emits distribution mirrors on EVM and Solana for retail and DeFi reach. The TDIP identity bridge, anchored on Tenzro, binds Canton parties to W3C Verifiable Credentials and DIDs. Agentic asset operations under DID-bound, on-chain mandates run the operational lifecycle: NAV reconciliation, MRV verification, compliance monitoring, redemption orchestration.

The whitepaper sets out the architecture, the three asset patterns, the regulatory boundary, and the specifications.

Part I — Strategic

1. Introduction

1.1 What Boli is

Boli is an operating layer on the Canton Network for regulated tokenized assets. The platform is built around three Daml asset patterns; a compliance-pack engine that runs at the chain level; multi-VM mirroring that keeps Canton canonical while emitting distribution surfaces on EVM and Solana; an identity bridge to Tenzro's W3C-Verifiable-Credential foundation; and an agentic runtime that executes operational workflows under on-chain delegated authority.

The chain is Canton. Boli rests on Canton protocol properties: sub-transaction privacy, named-party accountability, atomic delivery-vs-payment, programmable multi-party workflows in Daml, instant finality. Boli turns those primitives into products a licensed party can ship.

Boli does not issue assets. Boli does not custody assets. Boli does not hold keys for any party. Boli does not operate regulated venues. Licensed parties — banks, asset managers, registrars, sovereigns — issue, custody, and operate. Boli ships the standard the licensed party uses to do so on Canton.

1.2 Why now

Three currents converge in 2026.

Institutional tokenization is now the operating model. DTCC and Digital Asset announced in December 2025 the tokenization of DTC-custodied U.S. Treasuries on Canton; on 4 May 2026, DTCC confirmed the production launch timetable for DTC's tokenization service — initial limited production trades in July 2026, full service launch in October 2026 — against DTC's $114 trillion assets-under-custody footprint and with a 50+ 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 HKMA tokenized HK$10 billion in digital green bonds in late 2025. BIS Project Agorá entered its testing phase in January 2026 with seven central banks and forty-one financial institutions. MAS Project Guardian moved from fund tokenization through to government-bills pilots with wholesale CBDC. India's e-Rupee crossed 6 million users in production. Canton's Splice Token Standard V1 stabilised in early 2026. The shift from "experiment" to "production" has happened inside the past eighteen months.

Sovereign DPI is being built right now. SL-UDI on MOSIP, India Stack, the EU Digital Identity Wallet under eIDAS-2, GovStack, MOSIP-derived programmes across more than thirty countries — the identity, payment, and document rails that tokenization depends on are under active construction in jurisdictions that, three years ago, were not on the institutional finance radar. Tokenization on top of these rails is the platform-defining opportunity of the next decade.

The regulatory perimeter is converging on Canton-shaped properties. MiCA in the EU, the FSRA framework in ADGM, the UK's Digital Asset Bill 2025, and the broader migration of regulated tokenization onto permissioned settlement infrastructure all converge on what Canton already provides natively: privacy at the protocol level, named-party operators, atomic settlement. Boli is built for that regulatory direction.

1.3 Reading this document

The whitepaper is organised so that a reader from any of three audiences can stop at a natural boundary.

Strategic readers — central bank policy staff, ministry advisors, multilateral programme managers — should read Parts I and IV end-to-end and skim Part II.
Architectural readers — institutional integration leads, regulators' technical staff, Canton Foundation contributors — should read Parts I and II in full and consult Part III for the specific patterns relevant to their work.
Implementation readers — engineering teams shipping Boli-compatible packages, custodians integrating against Boli's interfaces — should treat Part III as the authoritative reference and use Parts I–II as motivation.

2. The institutional rail: Canton Network

2.1 What Canton is

The Canton Network is a privacy-preserving public blockchain operated as a federation of named institutions. Any participant can join and run a validator; every transaction's privacy domain is bounded to the parties with a need to know. The combination of public access, sub-transaction privacy, and named-party accountability is what makes Canton the rail regulated finance settles on.

The protocol layer is Canton, written in Scala and Daml. The smart-contract layer is Daml, a contract language for multi-party workflows: every Daml template specifies the parties whose authority is required for a state transition, and the Canton runtime enforces that authorisation atomically. If the required signatures are not present, the transition does not occur. Regulated transfers settle on this property.

Settlement is mediated by Splice, a tokenized utility layer on Canton governed under the Linux Foundation through the Global Synchronizer Foundation (GSF). The Splice Token Standard V1 — stabilised in early 2026 — defines the interfaces a Daml asset implements to settle atomically across counterparties under the AllocationV1 model. AllocationV1 is delivery-vs-payment as a Canton primitive: the transfer of the asset and the transfer of the settlement asset are a single atomic action, or neither happens.

2.2 Who is on Canton

Goldman Sachs, BNY Mellon, J.P. Morgan, BNP Paribas, DTCC, HSBC, Standard Chartered, Cboe, Deutsche Börse, Broadridge, Tradeweb, the Hong Kong Financial Markets Infrastructure, Moody's Ratings, Digital Asset, Circle, DRW, Cumberland, and the Global Synchronizer Foundation run on Canton. Validator operators and Super Validators include Deloitte, Paxos, and others under the GSF.

These institutions participate in Canton via the Linux Foundation–hosted GSF. The relevance for a licensed party shipping a regulated asset on Boli is architectural: issuing on Canton puts the asset on the same network where the largest custodians, transfer agents, and tokenization desks transact. The conversation with a regulator, a counterparty, or an investor begins from that fact.

2.3 The Global Synchronizer Foundation

Canton's governance sits with the Global Synchronizer Foundation, hosted by the Linux Foundation. The GSF governs the synchroniser layer that orders transactions across the network's privacy domains, defines the Splice token standards, and oversees protocol evolution. Membership is open to financial institutions, technology providers, and standards bodies under the Linux Foundation's neutral-governance model.

Boli composes with GSF-governed standards. The Splice Token Standard V1, the AllocationV1 settlement model, and the Canton protocol roadmap are inputs to the Boli specification. Where Boli introduces conventions on top — the structure of a compliance pack, the semantics of a registry-mirror transfer — the conventions are documented in the Boli Standards Proposals (BSPs) maintained alongside this whitepaper, and compose with GSF-governed standards.

2.4 Why a privacy-preserving public chain matters for regulated assets

A regulated asset has three properties Canton accommodates natively.

Holder lists are confidential. A bond issuer's investor list, a fund's limited partners, a real-estate development's beneficial owners — these are confidential to the issuer, the regulator, and the holder. On Canton, the holder list is visible only to the parties whose Daml authority is required to read it; the public ledger records that a transfer occurred and that the relevant parties signed it; identities and holding amounts stay inside the privacy domain.

Compliance is per-jurisdiction and per-asset. A real-estate share class issued under Sri Lankan law has different transfer restrictions from one issued under UAE rules; a fund interest issued to a UAE investor has different rules from one issued to a U.S. accredited investor. The compliance rule is encoded in the Daml template and runs as a precondition of every transfer; the chain enforces the rule regardless of which frontend initiated it.

Settlement is atomic and final. A regulated transfer is a delivery against payment, settled in one indivisible action. Canton's AllocationV1 model treats DvP as a primitive: the asset moves, the settlement asset moves, both or neither. Finality is instant.

Confidentiality, jurisdictional compliance, atomic finality. Canton is the rail Boli is built on, and a Boli-issued asset is regulator-ready by construction.

3. The three asset patterns

Every regulated asset class collapses to one of three Daml patterns. A licensed party shipping any of the asset types below selects one of three patterns and configures its parameters; the Daml template is shared, parameterised, and re-used across deployments.

3.1 Pattern A — Tradeable

Motivation. Securities, funds, sukuk, real-estate share classes, environmental credits with secondary markets, structured products. Anything where the asset has a primary issuance, a holder population, and a secondary market in which holders trade with one another under issuer-defined rules.

Shape. A Tradeable asset has:

A fungible holding contract parameterised by the issuer party and the holder party.
A transfer interface that, on every transfer, invokes the issuer's compliance pack as a precondition.
An AllocationV1 settlement interface for atomic delivery-vs-payment against any settlement asset the licensed party permits.
Optional redemption, dividend, and corporate-action interfaces parameterised by the issuer.

The compliance pack carries the rules — investor accreditation, jurisdictional restrictions, holder limits, lock-ups, sanctions screening — and runs at the chain level on every transfer. The rule is the asset's own property, enforced by Canton.

Example assets. A Sri Lankan real-estate development's share class. A UCITS fund interest. A Saudi sovereign sukuk. A tokenized U.S. Treasury Bill (when a licensed issuer ships it). A structured note. A blue-carbon credit with a secondary market.

The full specification is reserved for a forthcoming BSP-0001 (Asset Pattern: Tradeable), summarised in §11 of this whitepaper.

3.2 Pattern B — Registry-mirror

Motivation. Land titles, vehicle titles, IP rights, professional licences — anything for which a sovereign register is the source of truth. The asset on Canton does not replace the sovereign record; it mirrors it, with cryptographic verifiability and atomic transfer semantics that the sovereign record's underlying database does not provide.

Shape. A Registry-mirror asset has:

A mirror contract signed by the registry party (the sovereign authority) and the holder party (the title-holder).
A transfer template in which both parties' Daml authority is required for any state transition. The registry party retains operational control of corrections and revocations; the holder party retains control of voluntary transfers; both are atomic.
A link back to the sovereign record's identifier — a folio number, a chassis number, a registration ID — so the on-chain mirror is auditable against the off-chain authoritative record.
An encumbrance interface that allows liens, mortgages, or restraints to be recorded as additional Daml contracts requiring multi-party authority for release.

Why a mirror, not a replacement. The state remains sovereign over the underlying register. The Canton mirror provides the verifiability properties — uniqueness, atomic transfer, cryptographic audit trail — that the underlying paper or database lacks. The two are kept in sync by an integration adapter operated by the registry authority or its technology partner.

Example assets. Sri Lankan land titles under the Bim Saviya framework. Vehicle registrations under a national DMT. Trademark or patent registrations under a national IP office. Beneficial-ownership filings under a national companies register.

The full specification is reserved for a forthcoming BSP-0002 (Asset Pattern: Registry-mirror), summarised in §12 of this whitepaper.

3.3 Pattern C — Credential

Motivation. eIDAS-2 identity wallets, KYC attestations, professional licences, environmental MRV verifier credentials, accreditation claims, attestations of any form. Anything that is issued by one party to another and verified by a third — without the holder's underlying data being disclosed.

Shape. A Credential is a W3C Verifiable Credential, anchored on Canton with the following Boli additions:

The issuance contract is signed by the issuer party (e.g. a national identity authority, a professional body, an MRV verifier).
The holder party controls disclosure: a credential can be presented selectively, revealing only the predicates required by a verifier (e.g. "is over 18", "holds a valid practising certificate", "is the verified MRV operator for this hectare") without disclosing the underlying birthdate, certificate number, or coordinates.
A revocation contract allows the issuer to revoke a credential atomically; revocation is observable to verifiers without requiring round-trips to the issuer.
The credential is cryptographically anchored to the holder's DID — issued and managed via the TDIP identity bridge — so the credential is portable across identity wallets that comply with the bridge specification.

Why on Canton. Credentials issued by sovereign authorities require the same privacy and named-party properties as regulated financial assets. A national identity attestation is not data that the issuing state wants observable on a public block explorer; nor is the cryptographic revocation status of every citizen's credential. Canton's privacy-by-default model fits the credential pattern natively.

Example credentials. SL-UDI verifiable credentials anchored to MOSIP. EU Digital Identity Wallet credentials under eIDAS-2. Professional licence attestations issued by a national bar council, medical council, or engineering board. Blue-carbon MRV verifier credentials issued by an accredited body. KYC-claim credentials issued by a regulated bank for re-use by other regulated parties.

The full specification is reserved for a forthcoming BSP-0003 (Asset Pattern: Credential), summarised in §13 of this whitepaper.

3.4 Mapping asset classes to patterns

Selecting any regulated asset class and asking which pattern carries it:

A central-bank wholesale CBDC is Pattern A, with the CBSL as the issuer and the compliance pack scoped to permitted counterparties.
A digital green bond is Pattern A, with the green-finance covenant encoded in the compliance pack.
A digital identity wallet credential is Pattern C.
A national land registry mirror is Pattern B.
A blue-carbon credit standard is Pattern A for the credit itself (it trades) plus Pattern C for the underlying MRV attestations (they verify).
A real-estate share class is Pattern A.
A trademark registration is Pattern B.
A KYC-claim re-use programme is Pattern C.
A tokenized fund interest is Pattern A.
A vehicle registry is Pattern B.

The patterns compose. A blue-carbon credit programme uses Pattern A for the credit and Pattern C for the verifier attestations that underpin it. A real-estate development uses Pattern A for the share class and references Pattern B (the underlying land title mirror) as the asset backing.

The three-pattern model is the simplification Boli ships. The pattern is parameterised, audited as a unit, and re-used; a licensed party configures rather than authors a new Daml template for every new asset class.

4. The regulatory line

Boli's design is governed by an explicit boundary between what it ships and what licensed parties carry. This section sets out the boundary; subsequent sections rely on it.

4.1 What Boli ships

Boli ships technology, standards, and ecosystem-design support. Concretely:

Daml packages for the three asset patterns.
A compliance-pack engine that licensed parties configure with their jurisdictional rules.
Multi-VM mirroring infrastructure that keeps Canton canonical while emitting EVM and Solana mirrors.
The TDIP identity bridge specification and its reference implementation.
The Boli Standards Proposals (BSPs) that document the protocol-level conventions on which the platform is built.
An agentic runtime specification for autonomous operations under DID-bound mandates.
A marketplace and intent-routing protocol for discovery across listed partners.

4.2 What Boli does not do

Boli does not:

Issue assets. Issuance is the licensed party's act under the licensed party's authority.
Custody assets or hold keys for any party. Custody is performed by the licensed party or its custody provider.
Operate regulated venues. Order books, RFQ systems, or matching engines for regulated assets are operated by appropriately licensed venues.
Hold settlement assets. Settlement assets are issued and held by the parties that issue and hold them — central banks, regulated stablecoin issuers, tokenized-deposit issuers — not by Boli.
Take regulatory positions on behalf of any party. Boli does not represent that any specific use of the platform satisfies any specific regulator's requirements; that determination is the licensed party's, made with its own counsel and its own regulator.

4.3 The contributing entities

Four distinct constituencies sit behind what is conversationally called "Boli". They are deliberately separate, with different roles, different governance, and different mandates.

The Boli Foundation — the governance entity. The Foundation, once formally established, governs the $BOLI ecosystem token, promotes the ecosystem, and is the publishing entity for this whitepaper and the Boli Standards Proposals (BSPs) the whitepaper references. The Foundation does not ship technology and does not custody assets; its mandate is mission-driven governance and ecosystem alignment. The Foundation's charter, board composition, and treasury policy are documented separately.

The Boli Platform — the technology layer. The Platform is the operating layer on Canton: the Daml packages, the compliance-pack engine, the multi-VM mirroring infrastructure, the TDIP integration, and the agentic runtime. The Platform is built by engineering entities that are contracted or partnered for the work — the engineering organisation is not housed inside the Foundation, and may evolve over time as the platform's scope changes. Specific engineering entities are named in the BSPs they author and in the reference implementations they ship; this whitepaper does not name a single platform-builder because the platform is not built by a single entity.

Tenzro Labs (Singapore) — the infrastructure provider and incubator. Tenzro Labs is a partner in the Canton ecosystem and operates a Canton validator node. Tenzro provides the infrastructure layer integrated with the Canton Network: digital identity (TDIP), secure key handling (MPC custody primitives), and verifiable execution of automated workflows (the agentic runtime). The Boli Platform is deployed on Tenzro's Canton validator node; Boli does not operate its own validator and is not a Super Validator. Tenzro Labs incubated the Boli Platform from 2025 onwards, funds engineering and operational costs through testnet launch, and is a future stakeholder in the Boli treasury (see §15.3 and §16.2). The two are independent entities — Tenzro's mandate is the broader Canton ecosystem, and Boli is governed on its own terms (§15, §16).

The Boli Association (Switzerland) — an independent research partner. The Boli Association is a Swiss non-profit Verein that publishes open research on the infrastructure of regulated digital finance, including tokenization, AI attestation, stablecoins and cross-border settlement, and market structure. The Association is governed by its own members under Swiss non-profit law, funded by donations and research grants, and editorially independent. Its engagement with the Boli Platform is at the research level only. On a transitional basis, the Association anchors the editorial process for the Boli Standards Proposals (BSPs) until the Boli Foundation is established; upon Foundation formation, standards-setting governance for the BSP process passes to the Foundation. The Association is not the publisher of this whitepaper, not a holder or governance participant in $BOLI, not a member of the Boli Foundation, and not a counterparty to platform customers. It issues no tokens, holds no equity, takes no commercial mandates, sells no services, and earns no fees.

The Foundation governs and publishes. The engineering entities build and integrate with licensed parties. Tenzro operates the permissionless infrastructure beneath both. The Association researches and convenes, independently of all three. Each constituency is governed and accountable on its own terms.

4.4 What licensed parties carry

In every Boli deployment, a licensed party carries:

Issuance authority for any asset issued through the platform.
Compliance authority — the policy expressed in the compliance pack is the licensed party's policy, and the licensed party is responsible for its correctness against its regulator.
Custody and key control — keys never leave the licensed party's custody architecture; Boli operates as a software layer the licensed party uses, not as a counterparty.
Venue authority — order books, RFQ systems, and matching engines run on licensed venues, not on Boli infrastructure.
Settlement-asset selection — the licensed party chooses the settlement asset (a tokenized deposit, USDC, EURC, RLUSD, AED-Coin, a Sri Lankan stablecoin, a future LKR wholesale CBDC). Boli does not editorialise on the settlement-asset choice.

This boundary is the basis on which a Boli deployment is regulator-ready in any jurisdiction. The licensed party is regulated; Boli is the standard the licensed party uses.

4.5 Regulatory alignment — overview

The platform is built to compose with — never to replace — the regimes under which licensed parties operate. The compliance-pack engine described in §7 carries one configurable pack per jurisdiction; the asset is regulated by the regime its issuer is licensed under, and the pack encodes that regime's transfer rules at the chain level.

The remainder of §4 sets out, by regime, what Boli ships into a licensed deployment under that regime and what the licensed party carries. The scope covers the regimes most often invoked by Boli's audiences and target deployments as of mid-2026: MiCA (EU), the GENIUS Act and the SEC Staff Statement on tokenized securities (US), the Digital Asset Market CLARITY Act (US, in Senate as of May 2026), MAS Project Guardian and the DTSP framework (Singapore), HKMA Ensemble and the SFC's type-1 framework (Hong Kong), the FSRA framework (ADGM), VARA Categories 1 and 2 (Dubai), the EU DLT Pilot Regime, the Swiss DLT Act, the UK FCA Digital Securities Sandbox, eIDAS-2 (EU identity), and the Travel Rule framework under FATF-aligned implementations. The list is not exhaustive; the same composition pattern extends to other regimes as the relevant packs are authored.

Three principles run through every regime mapping below.

First, Boli is software. The platform's regulatory posture in every regime is that of a technology vendor and standards body — it does not hold licences, does not issue regulated instruments, does not custody assets, does not operate venues, and does not assume regulatory responsibility for any specific deployment. Where a regime contemplates technology providers (e.g. MiCA's third-party reliance arrangements, MAS's outsourcing regime, FSRA's technology-vendor expectations, DORA's ICT third-party regime), Boli is positioned as such; where a regime imposes licensing on the issuer, the custodian, or the venue operator, the licensed party carries that licence.

Second, the compliance pack is the regime-specific surface. A licensed party shipping an MiCA-authorised ART configures a different pack from a licensed party shipping a Reg D 506(c) private placement; both packs are loaded by the same engine, both run on Canton, both enforce per-transfer at the chain level. The pack is the seam between the platform's regime-agnostic primitives and the regime-specific requirements of the licensed party.

Third — and architecturally load-bearing for the other two — the canonical asset record is on Canton. What every regulator supervises, in every regime mapping below, is the Canton-canonical ledger: named parties, sub-transaction privacy, atomic delivery-vs-payment via the Splice Token Standard AllocationV1 interface, instant finality, and governance under the Canton Foundation (Linux-Foundation-hosted, the renamed Global Synchronizer Foundation as of September 2025). EVM and Solana mirrors are downstream representations of the canonical record; they exist to reach retail and DeFi distribution surfaces, not to displace the regulated record. This distinction is not cosmetic. It is the basis on which Boli deployments satisfy MiCA Art. 75 custody-segregation expectations, the Swiss DLT Act's ledger-based-securities requirements under CO Arts. 973d–973i, the HKMA's Ensemble settlement architecture, the EU DLT Pilot Regime's DLT-TSS category, and the GENIUS Act's reserve and redemption expectations against tokenized settlement assets.

The institutional precedent for this architecture is now established. DTCC and Digital Asset announced in December 2025 the tokenization of DTC-custodied U.S. Treasuries on Canton, following an SEC no-action letter to DTC permitting a pilot tokenization service for certain highly liquid assets. On 4 May 2026, DTCC confirmed the production timetable: initial limited production trades through DTC's tokenization service in July 2026, with full service launch in October 2026. Initial asset scope is U.S. Treasury bills, bonds, and notes; the service operates against DTC's $114 trillion assets-under-custody footprint, with subsequent expansion into the broader DTC- and Fed-eligible securities universe. DTCC took a co-chair seat on the Canton Foundation alongside Euroclear, and convened a 50+ firm industry working group spanning BlackRock, Goldman Sachs, J.P. Morgan, Morgan Stanley, Citi, BNP Paribas, HSBC, UBS, State Street, Wells Fargo, Bank of America, Nasdaq, NYSE Group, Tradeweb, Franklin Templeton, Invesco, Charles Schwab — alongside Circle, Ripple, Anchorage Digital, Fireblocks, BitGo, Ondo Finance, Kraken, Robinhood, and Digital Asset. BNY Mellon, Citadel Securities, Moody's, Hong Kong FMI Services, Hex Trust (Super Validator, January 2026), and Visa (Super Validator, March 2026) are also operating on Canton. Boli's regulatory posture across every regime below rests on this: the chain Boli ships onto is the chain on which the United States' central securities depository tokenizes Treasuries against a $114 trillion custody base. Boli does not represent that the DTCC service endorses any particular Boli deployment; the precedent is cited only to establish the regulatory plausibility of Canton-canonical issuance under U.S. securities-market infrastructure.

4.6 EU — Markets in Crypto-Assets Regulation (MiCA)

MiCA's three-titled structure — Title II (crypto-assets other than ARTs and EMTs), Title III (asset-referenced tokens), Title IV (e-money tokens) — together with the parallel Crypto-Asset Service Provider (CASP) regime in Title V is the EU's binding framework as of 2026, with the transitional period closing in mid-2026.

What Boli ships into a MiCA-regulated deployment.

A mica_art pack for ART issuers — enforcing enhanced KYC, EEA-only allowlisting (the 27 Member States plus Iceland, Liechtenstein, Norway), freeze permissions, and Travel Rule integration via Notabene at the €1,000-equivalent threshold. The pack is loaded into the asset's Daml template and runs as a precondition of every transfer.
A mica_emt pack for EMT issuers — equivalent shape with the basic KYC tier MiCA permits for EMTs.
A claim-topic schema that maps MiCA's investor-disclosure and white-paper obligations to TDIP-anchored Verifiable Credentials: mica_eea_resident, kyc_enhanced, and per-transfer claim attestations.
Multi-VM mirroring that keeps the canonical leg on Canton (a privacy-preserving public chain, satisfying MiCA's interoperability expectations for institutional venues) while permitting EVM mirrors where retail distribution is in scope.

What the licensed party carries.

The ART issuer's licence under Title III, including own-funds, reserve-asset composition, and white-paper notification obligations to the home-state National Competent Authority and to the European Banking Authority.
The EMT issuer's licence under Title IV (an EMI or credit institution) and the reserve, redemption-at-par, and complaint-handling obligations attached.
The CASP authorisation under Title V for any party operating a regulated venue, custodian, or advisory service touching the asset.
The white paper itself, ongoing disclosures, and Article 89 supervisory reporting.

Boli does not author MiCA white papers, does not notify the NCA, does not hold ART reserves, and does not represent that any specific deployment satisfies MiCA. Those determinations belong to the licensed party and its counsel.

The Transfer of Funds Regulation (TFR, Regulation 2023/1113) applies the Travel Rule to crypto-asset transfers in the EU. Boli's compliance pack invokes a Travel-Rule integration (Notabene by default, configurable per deployment) at the €1,000-equivalent threshold; the integration runs as a Boli-side check alongside the chain-level pack evaluation.

4.7 EU — eIDAS-2 and the EU Digital Identity Wallet

The eIDAS-2 Regulation establishes the EU Digital Identity Wallet (EUDI Wallet) and the framework for Member States to issue qualified electronic identification attestations at Level of Assurance High. The framework matters for any Boli deployment in the EU that touches a citizen — KYC re-use across regulated institutions, professional-licence attestations, residency attestations, sovereign disbursements.

What Boli ships.

An eidas_2_high pack that requires Full-tier KYC and binds the holder party to an eIDAS-LoA-High credential issued by a qualified trust service provider.
A Pattern C (Credential) Daml template that emits W3C Verifiable Credentials conformant with the EUDI Wallet specifications, anchored to TDIP-bound DIDs.
A TDIP integration with the EUDI Wallet reference implementation, so that a citizen-side EUDI Wallet can present credentials issued via the Boli Pattern C template against verifiers on or off Canton.

What the licensed party carries.

The Qualified Trust Service Provider (QTSP) authorisation under eIDAS-2, where the issuer is a QTSP.
The Member State's national framework around identity-attestation issuance, where the issuer is a public authority.
Any subsequent obligations the verifier carries under sectoral law (e.g. AMLD for KYC re-use).

4.8 United States — SEC Staff Statement on tokenized securities; Reg D / Reg S / Reg A+

The SEC's Joint Staff Statement on tokenized securities of January 2026 sets the operating premise: a tokenized security is a security, the relevant transfer-agent and broker-dealer regimes apply, and the existing securities framework controls. The Statement enables tokenisation under the existing framework; it does not displace it. The DTCC and Digital Asset tokenization of DTC-custodied U.S. Treasuries on Canton (December 2025, pursuant to the SEC's December 11, 2025 no-action letter to DTC) is the concrete institutional precedent: a tokenized security held on Canton, custodied by the United States' central securities depository, supervised under the existing transfer-agent and clearing-agency framework. Boli's Pattern A templates target the same architectural premise.

What Boli ships.

A reg_d_506c pack for general-solicitation private placements — enhanced KYC, accredited-investor gating, US-only allowlisting, 12-month Rule 144 lock-up, MaxHolders capped at 2,000, freeze permissions for transfer-agent intervention, EDGAR Form D reminder with optional auto-file.
A reg_d_506b pack for non-general-solicitation placements with the 35-non-accredited-investor ceiling, explicit-whitelist mode (no general solicitation), and the same 12-month lock-up.
A reg_s pack for offshore distributions — denylist on the United States, 6-month Category-2/3 distribution-compliance period, non-US-person claim attestation, Travel Rule integration.
reg_a_plus_t1 and reg_a_plus_t2 packs for tier-1 and tier-2 Reg A+ offerings, with basic KYC and tier-2's per-investor 10 % cap enforced off-chain.
Tax reporting integration emitting 1099-DIV, 1099-INT, and K-1 forms from the on-chain holder list and distribution events.

What the licensed party carries.

The Reg D, Reg S, or Reg A+ filing and any blue-sky compliance.
Transfer-agent registration where the issuer relies on a transfer agent (SEC Rule 17Ad), or the broker-dealer registration where issuance is via a registered placement agent.
Custody under Rule 15c3-3 where a regulated custodian or qualified custodian holds investor assets.
The SEC Staff Statement explicitly contemplates DLT as a transfer technology; the licensed party's transfer agent (or its TA of record) determines the on-chain operations against the on-chain holder list.

4.9 United States — the GENIUS Act and payment stablecoins

The GENIUS Act (signed 2025) establishes the federal payment-stablecoin regime in the United States. The Act distinguishes payment stablecoins (regulated as such, with reserve-asset, redemption, and operational-resilience requirements) from securities and other tokens.

The GENIUS Act does not regulate Boli. Boli does not issue stablecoins and does not custody settlement assets. The regime governs the licensed party — the bank, the qualified payment-stablecoin issuer, or the credit institution — that issues the settlement asset against which Boli-issued tokenized regulated assets settle.

What Boli ships.

Settlement-asset adapters for US-regulated payment stablecoins (USDC, RLUSD, JPMD, others) on the asset's compliance pack, so that the pack's settlement_asset_in predicate accepts the licensed settlement asset and refuses others.
Reconciliation against the settlement-asset issuer's authoritative records — proof-of-reserve attestations where the issuer publishes them, transaction-level reconciliation otherwise.

What the licensed party carries.

Federal or state payment-stablecoin issuer licensing.
The reserve-asset composition, redemption, and operational-resilience obligations attached.
Any bank-secrecy obligations on the issuer-side custodian.

4.10 United States — the Digital Asset Market CLARITY Act (in Senate as of May 2026)

The Digital Asset Market Clarity Act of 2025 (H.R. 3633) passed the U.S. House of Representatives on July 17, 2025 by a bipartisan vote of 294–134. As of May 12, 2026, the bill is in the Senate Banking Committee, with a markup scheduled for May 14, 2026; a parallel Senate Agriculture Committee track (the Digital Commodity Intermediaries Act) advanced out of committee in January 2026. The legislative outcome is uncertain — bank trade groups formally rejected the Tillis–Alsobrooks stablecoin-yield compromise on May 9, 2026, and the White House target of presidential signature by July 4, 2026 is not guaranteed. This subsection is drafted on the assumption that CLARITY will pass in substantially its House-engrossed form; the licensed party's counsel must verify the enacted text before relying on Boli's pack configuration.

The CLARITY Act, as drafted, partitions the U.S. digital-asset perimeter into three categories: digital commodities (CFTC primary jurisdiction), investment-contract assets (SEC primary jurisdiction), and permitted payment stablecoins (regulated under the GENIUS Act, neither security nor commodity). The "mature blockchain system" certification — a system not controlled by any person or common-control group — triggers reduced disclosure obligations for the related digital commodity. The SEC retains authority over primary-market issuance and registration disclosures regardless of the asset's eventual classification.

What Boli ships, on the assumption CLARITY passes.

A clarity_digital_commodity pack — basic-to-enhanced KYC tier, U.S. allowlisting, freeze permissions limited to the contractual default cases CLARITY contemplates for CFTC-supervised commodities, Travel Rule integration. Suitable for digital commodities whose issuance has progressed beyond the SEC primary-market disclosure window.
A clarity_investment_contract_asset pack — closer to the existing reg_d_506c shape, with enhanced KYC, accredited-investor gating where applicable, and EDGAR/transfer-agent integration during the SEC-supervised primary-market phase.
A clarity_mature_blockchain claim-topic and certification claim attestation, designed to be set on Canton parties whose related instrument has received mature-blockchain certification under the Act's framework.
Continuity with the existing reg_d_506*, reg_s, and reg_a_plus_t* packs: an asset issued under a pre-CLARITY exemption continues to operate under that exemption's pack; CLARITY-era packs are additive, not replacement.

What the licensed party carries.

The CFTC registration or exemption appropriate to the activity (DCM, SEF, FCM, broker, or the Act's new digital-commodity-intermediary categories), where the asset is a digital commodity.
The SEC registration or exemption appropriate to the issuance, where the asset is an investment-contract asset or where the issuance is in its primary-market disclosure window.
The mature-blockchain certification process and the ongoing operational independence the certification depends on.
The interpretive determination — together with counsel — of whether a specific Boli-issued instrument is a digital commodity, an investment-contract asset, or (where the asset references a permitted payment stablecoin) a GENIUS-Act-regulated stablecoin.

Boli takes no position on the CFTC/SEC classification of any specific instrument and does not represent that any Boli deployment is a digital commodity, an investment-contract asset, or a mature blockchain system within the meaning of the Act. The Canton-canonical record on which the licensed party operates is, again, the architectural surface the relevant U.S. regulator supervises; the DTCC US-Treasury tokenization precedent on Canton predates CLARITY and operates under the existing SEC framework regardless of its enactment.

4.11 Singapore — MAS Project Guardian and the DTSP framework

The Monetary Authority of Singapore's Project Guardian provides the operational framework for tokenized funds, and the Digital Token Service Provider (DTSP) Act of 2025 sets the licensing regime for DTSPs operating from Singapore. The VCC framework allows tokenized fund interests to be issued under a familiar single-corporate-vehicle structure.

What Boli ships.

A mas_dtsp pack — enhanced KYC, accredited-investor gating (MAS AI/PI categories), Singapore allowlisting, Travel Rule integration, mas_accredited_investor claim attestation.
Pattern A Daml templates that compose with the VCC and VCC-sub-fund issuer structures licensed parties commonly use for Guardian-aligned deployments.
Canton Network connectivity, which is in active use by Guardian counterparties at the wholesale layer.

What the licensed party carries.

The DTSP licence (or, for the fund manager, the relevant Capital Markets Services licence).
The VCC's constitutional documents, the fund's offering documents, and the manager's MAS supervisory obligations.
The custodian's licence and any administrator obligations under the Securities and Futures Act.

4.12 Hong Kong — HKMA Ensemble and the SFC framework

The HKMA's Project Ensemble provides the wholesale-settlement rail for tokenized real-world assets in Hong Kong, with experimental issuance covering green bonds, treasuries, and tokenized deposits. SFC type-1 (dealing in securities) and type-4 (advising on securities) licences govern the venue and advisory layers.

What Boli ships.

An hkma_sfc_sf pack — enhanced KYC, professional-investor gating (SFC PI), Hong Kong allowlisting, Travel Rule integration.
Pattern A Daml templates that compose with the Hong Kong tokenized-deposit and tokenized-bond programmes via the Ensemble settlement layer, with the asset held canonically on Canton and settled atomically against Ensemble-supplied tokenized deposits using the Splice AllocationV1 interface.
Canton Network connectivity, which is in active use by Ensemble counterparties; HK FMI Services is itself a Canton participant.

What the licensed party carries.

The SFC type-1 / type-4 licence for the venue or advisor, and Securities and Futures Ordinance compliance throughout.
The HKMA-authorised institution licence where the issuer is a bank.
The Ensemble participation agreement at the settlement-rail level.

4.13 Abu Dhabi — FSRA framework (ADGM); and Dubai — VARA

The Financial Services Regulatory Authority of the Abu Dhabi Global Market provides a common-law framework for fund issuance, digital-asset activity, and prudential supervision. The Virtual Assets Regulatory Authority in Dubai supervises virtual-asset activity under categorical licences (Categories 1–7) outside the ADGM perimeter.

What Boli ships.

A vara_cat1 pack — enhanced KYC, VARA Category 1 (Virtual Asset Issuance) parameter set, Travel Rule integration.
A vara_cat2 pack — qualified-investor gating (VARA Qualified Investor), enhanced KYC, Travel Rule integration; suitable for the broker-dealer / advisory configurations VARA Category 2 contemplates.
Pattern A Daml templates that compose with FSRA-licensed fund managers and ADGM-domiciled SPVs (the canonical legal wrapper for many Boli deployments at launch).
Compliance-pack composition with MiCA and Reg-D / Reg-S packs where an ADGM-domiciled SPV distributes into multiple jurisdictions — the pack-composer (§7) merges the multiple regimes' constraints with strict-wins semantics.

What the licensed party carries.

The FSRA financial-services permission appropriate to the activity — fund manager (Category 3C), private-financing-platform operator, custodian (Category 5), broker-dealer (Category 4A), or other.
The VARA Category 1, 2, or higher licence in Dubai for any virtual-asset-issuance, exchange, broker-dealer, custody, or advisory activity in the Emirate.
The ADGM Companies Regulations compliance for the issuer SPV.

4.14 European Union — DLT Pilot Regime; Switzerland — DLT Act

The EU's DLT Pilot Regime (Regulation 2022/858) provides an experimental framework for DLT market infrastructures: DLT multilateral trading facilities, DLT settlement systems, and DLT trading-and-settlement systems, with issuance thresholds tiered at €500 m / €1 bn / €6 bn / €9 bn depending on instrument type and venue role. The Swiss DLT Act (in force since 2021, encoded primarily in Code of Obligations Arts. 973d–973i for ledger-based securities, and in FinMIA for DLT trading facilities) provides a separate, durable framework under FINMA supervision; FINMA Guidance 06/2024 sets out the supervisor's expectations for stablecoin issuance and reserve transparency under the same Act. Both regimes turn on the legal status of the ledger itself — under Swiss CO Art. 973d, a ledger qualifies as a ledger-based-securities register only if it meets specified integrity, public-availability-to-the-creditor, and resistance-to-unauthorised-alteration conditions. Canton's named-party accountability, sub-transaction privacy, and instant finality are the architectural basis on which the licensed party can demonstrate those conditions to FINMA or the relevant Member State NCA.

What Boli ships.

A finma_dlt pack — enhanced KYC, Switzerland-and-Liechtenstein allowlisting, Travel Rule integration; suitable for DLT-based securities issued under the Swiss DLT Act.
Pattern A Daml templates with the AllocationV1 settlement interface, which composes with both Swiss DLT trading facilities and EU DLT Pilot venues where the venue operator is licensed.
Canonical Canton settlement with EVM/SVM mirrors as the licensed venue's distribution model dictates.

What the licensed party carries.

The Swiss DLT trading facility licence under FinMIA / FINMA supervision, or the EU DLT Pilot Regime authorisation issued by the relevant Member State NCA.
The MiFID-equivalent obligations for trading venues, transparency, and reporting.
The settlement-system rules and the custodian arrangements.

4.15 United Kingdom — FCA Digital Securities Sandbox

The Bank of England and the FCA operate the Digital Securities Sandbox (DSS) as a temporary framework permitting DLT-based issuance, trading, and settlement of regulated securities under modified rules. As of Q1 2026, four firms have been selected to test stablecoin issuance under the related stablecoin sandbox.

What Boli ships.

An fca_dss pack — enhanced KYC, UK allowlisting, Travel Rule integration.
Pattern A Daml templates with mirror routing to UK-distributed surfaces.

What the licensed party carries.

DSS authorisation under the modified FCA/BoE rules.
The FSMA-permission structure underneath the sandbox modifications.
The Bank of England supervisory engagement at the settlement-rail level.

4.16 The Travel Rule and AML obligations

The Financial Action Task Force Recommendation 16, implemented as the Travel Rule in EU TFR 2023/1113, US FinCEN guidance, MAS Notice PSN02, and equivalent national rules, requires originator-and-beneficiary information accompanying virtual-asset transfers above defined thresholds.

What Boli ships.

A Travel-Rule integration (default Notabene, configurable per deployment) invoked by the compliance pack at the threshold the pack specifies — €1,000 / US$1,000 for the default packs.
A TDIP-bound DID architecture that maps every Canton party to identity attestations sufficient for Travel-Rule compliance, removing the originator-information-gap that complicates non-custodial transfers.
An AML signal pipeline (/api/boli/ai/aml) that produces freshness-bounded AML scores against subjects, with an AML gate (§10.5) that refuses to mint or settle when severity is block. The gate is consulted as a precondition of issuance; the AI runs out-of-band.

What the licensed party carries.

Its sectoral AML programme — the Bank Secrecy Act regime in the US, the Money Laundering Regulations in the UK, AMLD6 in the EU, MAS-supervised AML for Singapore, FSRA-supervised AML for ADGM, VARA-supervised AML for Dubai.
Sanctions screening obligations under OFAC, EU consolidated lists, UK OFSI, UN Security Council, and equivalent national regimes.
Suspicious-activity reporting (SAR / STR / CTR) into the relevant national FIU.

4.17 Cross-regime composition

Many Boli deployments span multiple regimes — an ADGM-domiciled SPV distributing into the EU, the US, and Singapore; a Hong Kong-issued bond mirrored to EVM for DeFi composability; a Swiss DLT-Act-issued instrument made available to MiCA-regulated EU professional investors. The pack composer (§7) merges multiple regime packs into a single resolved compliance configuration with strict-wins semantics:

KYC tier — max of all min settings (Full > Enhanced > Basic > Unverified).
Accredited-investor / professional-investor — OR of required flags.
Country restriction — intersection on allowlists; union on denylists.
Holding period — max of months.
Maximum holders — min of caps.
Whitelist mode — explicit dominates open-to-KYC.

The composer's output is hashed and anchored to the asset on Canton, so an audit can prove which packs and which versions were applied at issuance. The licensed party reviews the composed configuration before deploy; the licensed party's counsel signs off on the regime stack; the chain enforces the configuration on every transfer thereafter.

5. The eight audiences

The platform serves eight audiences. The three patterns carry all of them.

Asset and fund managers — issuers of tokenized fund interests, structured products, real-estate share classes, and bespoke private placements. Pattern A. The licensed party's compliance pack carries investor accreditation, lock-ups, holder limits, and jurisdictional rules.

Banks — issuers of tokenized deposits, fixed-income instruments, and structured notes; integrators of tokenized assets into their custody and treasury workflows. Primarily Pattern A; Pattern C for KYC-claim re-use across institutions.

Sovereigns — ministries of justice (land), home affairs (vehicle and personal registries), digital economy (national identity), finance (tokenized treasury issuance, governance bond reporting). Pattern B for registries; Pattern A for treasury issuance; Pattern C for identity attestations.

Citizens — holders of identity credentials, professional licences, real-estate titles, and tokenized fund interests. Citizens interact with the platform through their existing wallets — the SL-UDI eLocker, the EU Digital Identity Wallet, a bank's mobile app — not through a Boli-branded interface.

Environmental markets — issuers of carbon credits, biodiversity credits, water-quality credits, and the verifier attestations that underpin them. Pattern A for the credits, Pattern C for the MRV attestations. Continuous MRV under agentic mandates is a primary use case.

Corporates — issuers of trade-finance instruments, supply-chain documents, working-capital facilities, and treasury instruments. Pattern A for tradeable instruments; Pattern C for supply-chain attestations.

Identity issuers — national identity authorities (MOSIP-derived programmes, EU eIDAS-2 issuers, sectoral identity schemes), KYC providers, professional bodies, and accreditation organisations. Pattern C, with the issuer party held by the appropriate authority.

Central banks — issuers of wholesale CBDC instruments and operators of settlement infrastructure for tokenized assets. Pattern A for the CBDC instrument itself; the broader rail interaction is at the Canton protocol level via the Splice settlement-asset interface.

For each audience, the integration shape is the same: the licensed party selects a pattern, configures the compliance pack, integrates with its custody and identity architecture, and ships. The work is parameterised and re-used across audiences.

Part II — Architecture

6. System overview

6.1 The three layers

The Boli architecture is a three-layer model. Each layer has a defined interface to the layer above and below; each layer is independently auditable; no layer assumes responsibilities that belong to another.

┌──────────────────────────────────────────────────────────────┐
│ LICENSED PARTY                                               │
│ (issuer, custodian, registrar, identity authority, venue)    │
└──────────────────────────────────────────────────────────────┘
                              │
                       integration
                              │
┌──────────────────────────────────────────────────────────────┐
│ BOLI PLATFORM                                  Operating     │
│                                                 layer        │
│ ┌──────────────────────────────────────────────────────┐     │
│ │ Daml asset patterns (A — Tradeable;                  │     │
│ │ B — Registry-mirror; C — Credential)                 │     │
│ └──────────────────────────────────────────────────────┘     │
│ ┌──────────────────────────────────────────────────────┐     │
│ │ Compliance-pack engine                               │     │
│ └──────────────────────────────────────────────────────┘     │
│ ┌──────────────────────────────────────────────────────┐     │
│ │ Multi-VM mirroring (Canton canonical;                │     │
│ │ EVM and Solana mirrors for distribution)             │     │
│ └──────────────────────────────────────────────────────┘     │
│ ┌──────────────────────────────────────────────────────┐     │
│ │ Marketplace and intent routing                       │     │
│ └──────────────────────────────────────────────────────┘     │
└──────────────────────────────────────────────────────────────┘
                              │
                  identity / keys / mandates
                              │
┌──────────────────────────────────────────────────────────────┐
│ TENZRO INFRASTRUCTURE                          Infrastructure│
│                                                 layer        │
│ ┌────────────────────┐ ┌────────────────────┐                │
│ │ TDIP — DIDs and    │ │ MPC custody        │                │
│ │ Verifiable         │ │ primitives         │                │
│ │ Credentials        │ │                    │                │
│ └────────────────────┘ └────────────────────┘                │
│ ┌────────────────────┐ ┌────────────────────┐                │
│ │ Agentic runtime —  │ │ Canton validator   │                │
│ │ TEE-verified       │ │ (Tenzro-operated)  │                │
│ │ execution          │ │                    │                │
│ └────────────────────┘ └────────────────────┘                │
└──────────────────────────────────────────────────────────────┘
                              │
                       Canton primitives
                              │
┌──────────────────────────────────────────────────────────────┐
│ CANTON NETWORK                                 Settlement    │
│                                                 layer        │
│ Daml runtime · Splice Token Standard V1 · AllocationV1 ·     │
│ Synchroniser (under Global Synchronizer Foundation)          │
└──────────────────────────────────────────────────────────────┘

The settlement layer is Canton, governed under the Linux Foundation through the Global Synchronizer Foundation — the public institutional rail on which the architecture settles.

The infrastructure layer is Tenzro. Tenzro provides the identity primitives (TDIP, DIDs, Verifiable Credentials), the secure key-handling primitives (MPC custody), the agentic runtime (TEE-verified execution under DID-bound mandates), and operates a Canton validator node. The Boli Platform is deployed on Tenzro's Canton validator node; Boli does not operate its own validator and is not a Super Validator. Tenzro Labs incubated the Boli Platform and is a future stakeholder in the Boli treasury (see §4.3, §15.3, §16.2); the two are independent entities, governed and accountable on their own terms.

The operating layer is the Boli Platform: the Daml asset patterns, the compliance-pack engine, the multi-VM mirroring infrastructure, the marketplace. This is where a licensed party's policy meets Canton primitives.

The licensed party — issuer, custodian, registrar, identity authority — sits at the top. The integration is with the operating layer.

6.2 Why this layering

Each layer has a different audience, a different lifecycle, and a different governance constituency.

The settlement layer evolves under multilateral governance. The Splice Token Standard, the AllocationV1 model, and the Canton protocol roadmap are owned by the GSF and its institutional members. Boli composes with these standards. When Splice V2 ships, Boli adopts it.

The infrastructure layer evolves under Tenzro's ecosystem mandate. Tenzro's TDIP, MPC custody, and agentic runtime serve the broader Canton developer ecosystem. The interfaces Boli uses — DID resolution, credential anchoring, mandate registration, validator operation — are stable, documented, and used by other Canton-native projects. Boli consumes the infrastructure; the roadmap is Tenzro's.

The operating layer evolves under Boli's own governance. The three asset patterns, the compliance-pack engine, the multi-VM mirroring choices, and the marketplace protocol are Boli's specifications, governed through the BSP process described in §16.

The separation lets each layer be audited on its own terms. A regulator examining a Boli deployment asks three separate questions — Is the settlement rail credible? Is the identity infrastructure credible? Is the operating layer correctly configured for our jurisdiction? — and gets three separate answers, from three separate constituencies, against three separate bodies of evidence.

6.3 Interfaces between layers

The interfaces between layers are explicit and documented. Implementations on either side of an interface are independently replaceable.

Boli ↔ Canton. Boli's Daml packages compose with Splice Token Standard V1 and the AllocationV1 settlement interface. The interface is fully specified in the Splice repository and in the BSPs maintained at github.com/boli-foundation/bsps.

Boli ↔ Tenzro. Boli's identity bridge consumes TDIP-issued DIDs and Verifiable Credentials. The interface is reserved for a forthcoming BSP-0005 (TDIP integration), with the TDIP specification as the underlying reference. Boli can, in principle, run against any TDIP-compliant identity infrastructure; Tenzro's implementation is the reference, not the only permissible one.

Licensed party ↔ Boli. The licensed party integrates against the operating layer through (a) Daml package configuration — instantiating the asset pattern with the licensed party's parameters; (b) compliance-pack authoring — encoding the licensed party's policy into the chain-level engine; (c) the licensed party's existing custody and key-handling infrastructure, via TDIP-anchored DIDs.

7. The compliance-pack engine

7.1 What a compliance pack is

A compliance pack is the chain-level encoding of a licensed party's transfer policy. It runs as a precondition of every transfer the asset performs, and a transfer that fails the pack does not occur. Policy enforcement is a property of the asset on Canton.

A pack contains:

Eligibility predicates over the parties to a transfer (e.g. transferee is a credentialled accredited investor; transferee is not in a sanctions list; transferee is in a permitted jurisdiction).
Quantity constraints (e.g. holder limit of 5%; minimum holding lot; maximum aggregate position).
Temporal constraints (e.g. primary-issuance lock-up of 365 days; coupon-period transfer freeze).
Settlement-asset constraints (e.g. only specific tokenized deposits, USDC, and EURC are permitted as settlement assets for this share class).
Disclosure obligations (e.g. transfers above threshold X must be observable to a designated regulator party).

Each predicate is a Daml expression over party attributes, asset state, and transfer parameters. The pack is itself a Daml contract, with the licensed party as the policy authority — the only party that can amend it — and an explicit audit trail of every amendment.

7.2 How a pack is authored

Compliance packs are authored using a structured policy DSL that compiles to Daml. The DSL is intentionally constrained: it expresses predicates and constraints, not arbitrary computation. A pack is a finite set of rules, each of which is auditable in isolation.

The licensed party authors the pack against a specification published by Boli for each asset pattern. The specification enumerates the predicates that pattern accepts, their parameters, and the semantics of each. A pack that does not match the specification is rejected by the platform — the engine refuses to load a pack with unknown predicates.

Once authored, a pack is signed by the policy authority and published as a Daml contract on Canton. The asset's transfer template references the pack contract; on every transfer, the runtime evaluates the pack against the transfer parameters, atomically with the transfer itself.

7.3 Properties of chain-level enforcement

The rule is the asset's own property. The pack runs on every transfer regardless of the surface that initiated it.

Frontend uniformity. A frontend deployed by a counterparty, an integrator, or a venue executes against the same on-chain rule set as the issuer's own. The rule is identical across every surface.
Direct invocation. A transfer initiated by direct contract call evaluates the same pack as a transfer initiated through a UI.
Cross-venue consistency. An asset trading on multiple venues behaves identically on all of them, defined by the canonical pack.

7.4 Audit and amendment

Every compliance-pack amendment is a Daml transaction signed by the policy authority. The audit trail is the transaction history of the pack contract — observable to the parties with read access (the issuer, the relevant regulator, the licensed party's auditor) and immutable.

Amendments take effect from a specified effective date. Transfers in flight at the time of amendment are evaluated against the pack version in force at the time of transfer initiation. There is no retroactive policy change.

A licensed party may operate multiple packs for different products under the same legal entity, or different jurisdictional rules under the same product. Pack composition — applying multiple packs to the same asset, with explicit precedence — is supported; the precedence rules are part of the asset's Daml configuration.

8. Multi-VM mirroring

8.1 Canonical and mirror

Canton is the canonical settlement layer for Boli assets. EVM and Solana — the two largest distribution surfaces in the public-chain market — are mirror layers. Institutional settlement happens on Canton under sub-transaction privacy and atomic settlement; retail and DeFi distribution happens on EVM and Solana, where the wallet ecosystems are largest.

A Boli asset's authoritative state is on Canton. A mirror on EVM or Solana is a downstream reflection of that state, with documented divergence semantics. The mirror is, by construction, downstream of the canonical leg.

8.2 Why mirror at all

Three reasons.

Distribution reach. A retail investor with a MetaMask or Phantom wallet does not have a Canton wallet. Mirroring the asset onto EVM and Solana means the investor's existing infrastructure works.

DeFi composability. Lending, AMM market-making, and structured-product composability happen on EVM today. A Boli-issued asset that is mirrored to EVM is composable with that ecosystem; one that is Canton-only is not.

Cross-jurisdictional listing. Some venues operate on EVM. Some operate on Solana. A licensed party that wants its asset listed on multiple venues without re-issuing it on each chain mirrors once, lists everywhere.

8.3 What "canonical on Canton" means

Three properties define the canonical-leg invariant.

Source of truth. The Canton ledger is the authoritative record of holdings. If a mirror's state disagrees with Canton, the mirror is wrong.

Settlement. Atomic delivery-vs-payment for the asset happens on Canton, against the licensed party's chosen settlement asset, via AllocationV1. A trade settled on a mirror is a trade against a mirror representation; the canonical position has not moved until the canonical leg settles.

Compliance. The compliance pack runs on Canton. A mirror cannot transfer in a way that the canonical pack would have rejected — the mirror's transfer logic enforces the same rule, or the mirror's state diverges and is reconciled against Canton.

The relationship between canonical and mirror is mediated by an anchor contract on each mirror chain, signed by a Boli-operated mirror operator and the asset's issuer. Mirrors are minted against canonical holdings escrowed on Canton; mirrors are burned to release canonical holdings. The mirror operator is operationally responsible for the synchronisation; the asset's authority remains the issuer's, expressed canonically on Canton.

8.4 Divergence and reconciliation

Mirror state can diverge from canonical state in two ways.

Operational lag. A mirror reflects canonical state with bounded latency — typically sub-second, but not zero. During the lag, the mirror's state is a slightly stale view of canonical state. Trades executed on the mirror against this stale view are reconciled at canonical settlement.

Adversarial divergence. Defence is structural: the canonical escrow contract is co-signed by the issuer; mirrors cannot be minted without the escrow being incremented; the escrow's state is observable to the issuer's auditor. A mirror minted without escrow is an instrument the canonical layer will refuse to redeem, and the divergence is visible.

The canonical state is the reference. The mirror operator is auditable. The issuer's authority is preserved.

8.5 Mirror semantics for each pattern

The three asset patterns mirror differently.

Pattern A — Tradeable. Mirrored as ERC-20 (EVM) and SPL (Solana) tokens, with on-chain compliance hooks calling the canonical pack via a cross-chain message. Trading on the mirror is permitted; canonical settlement is required for atomic DvP.

Pattern B — Registry-mirror. Generally not mirrored to EVM or Solana — the registry-mirror pattern is already a mirror, of a sovereign record onto Canton, and a further mirror would compound the indirection. Where required (e.g. a tokenized real-estate share class collateralised by a registry-mirror title), the share class — Pattern A — is mirrored, not the title.

Pattern C — Credential. Credentials are presented, not transferred. The presentation protocol is wallet-side, on the holder's chosen identity wallet, against any verifier on any chain. The credential's revocation status is canonical on Canton; verifiers on other chains query the canonical state via the TDIP bridge.

9. The TDIP identity bridge

9.1 What TDIP is

The Tenzro Decentralized Identity Protocol (TDIP) is the identity foundation Tenzro Labs ships as part of its infrastructure layer. TDIP issues W3C Decentralized Identifiers (DIDs), anchors them to verifiable credentials, manages the cryptographic key material associated with each DID, and bridges DIDs to Canton parties.

For Boli, TDIP solves three problems:

Naming. Every Daml party in a Boli deployment is named by a DID, not a chain-specific identifier. The licensed party's DIDs are portable across implementations; an asset issued under issuer-DID did:tdip:lk:bank-of-ceylon on Canton can be referenced under the same DID on a mirror chain.
Authentication. Authority over a Daml party is exercised by signing with the keys bound to the party's DID. TDIP manages this — the keys are held in MPC custody (Tenzro's primitive), the DID document records the public-key material, and the signing protocol is portable across wallet implementations.
Credential anchoring. Pattern C (Credential) issues W3C Verifiable Credentials anchored to TDIP DIDs. The credential's holder is a DID; the credential's issuer is a DID; the credential's revocation status is a Daml contract on Canton referenced by the DID.

9.2 The bridge

The TDIP-to-Canton bridge is the operational integration that maps between DIDs and Canton party-ids. Concretely:

A DID resolves to a DID document (the standard W3C resolution).
The DID document includes a Canton party-id binding as a verification method, with the public key authorised to act on behalf of the party.
Canton's identity provider (IDP) accepts the DID-bound key as a valid authenticator for the party.
A signing operation on Canton is performed by the key bound to the DID; the signature verifies against the DID document.

The bridge is reserved for a forthcoming BSP-0005 (TDIP integration). The reference implementation lives in Tenzro's identity stack; Boli's web layer integrates against it via a thin client library.

9.3 Wallet portability

End-user wallets are not Boli-specific. A user holding a tokenized real-estate share class issued by a Boli-integrated bank holds the asset in:

Their bank's mobile app (the bank's white-labelled wallet integrates the Boli SDK).
Their existing identity wallet (SL-UDI eLocker, EU Digital Identity Wallet under eIDAS-2, a national-identity wallet).
A standard Web3 wallet (where the asset's mirror is held).

The Daml party — the on-chain entity that owns the holding — is the same across all three. The wallet differences are presentation only; the authority is bound to the DID.

This matters for sovereign-scale deployments, where the citizen-facing surface is a national identity wallet. The citizen's existing wallet, conformant with the bridge specification, is sufficient to participate.

9.4 Key handling

Keys are held in Tenzro's MPC custody primitive. The custody primitive is itself open-source; licensed parties may operate their own MPC custody under the same protocol, or use Tenzro's hosted offering, or use a third-party custodian conformant with the protocol. Boli does not hold keys for any party.

For end-user keys, the standard architecture is custodian-managed MPC: the citizen's bank, identity provider, or wallet provider holds the share material and signs on behalf of the citizen under the citizen's authorisation. This is the model SL-UDI's eLocker uses today, and the model EU eIDAS-2 wallets are converging on.

For licensed-party keys (issuers, registrars, custodians), the standard architecture is institutional MPC under the licensed party's own infrastructure, with TDIP integration via a signing service the licensed party operates.

10. Agentic asset operations

10.1 The operational lifecycle

A regulated asset's operational lifecycle — NAV reconciliation, MRV verification, scheduled disclosures, redemption orchestration, dividend distribution, corporate actions, regulatory reporting — runs continuously between transfers. Agentic asset operations execute this lifecycle autonomously, under verifiable mandates, with the same auditability as the on-chain transactions themselves.

10.2 What an agentic mandate is

An agentic mandate is on-chain delegated authority to perform a defined operation under defined constraints. It is a Daml contract signed by the asset's issuer (the principal) granting a Tenzro-runtime agent (the delegate) the authority to perform specific actions on behalf of the principal, subject to:

Scope — the specific operations the agent is authorised to perform (e.g. recompute NAV daily; submit MRV report monthly; rotate auditor at end of fiscal year).
Constraints — the conditions under which the agent may act (e.g. only between 09:00 and 17:00 SGT; only for amounts below threshold X; only when the upstream data signature verifies).
Verifiability — the agent's execution runs in a Trusted Execution Environment (TEE), with the execution attested cryptographically. The audit trail is the TEE attestation plus the on-chain transaction.
Revocation — the principal can revoke the mandate atomically. Revocation is a Daml transaction signed by the principal.

A mandate is not a private key shared with an agent. It is a Daml authorisation, scoped, time-bounded, and revocable, that the runtime evaluates on every action the agent takes.

10.3 Why TEE-verifiable

The TEE requirement is what makes the agent's autonomy auditable. With TEE attestation, the action is observable as "the agent executed the specific code path on inputs X under attested conditions and produced output Y, then submitted the transaction." The principal, the regulator, and the auditor can verify the attestation independently.

This matters for regulated workflows. A NAV computation that runs in a TEE under a published code commitment, with the input data signed and the output attested, is a reportable artefact.

10.4 What agents do, in practice

Three classes of operation are typical.

Continuous reconciliation. NAV recomputation against custody-side market data; cash position reconciliation between the on-chain settlement record and the off-chain bank account; corporate-action accounting when the underlying issuer pays a dividend.

Continuous verification. MRV report generation for environmental assets, against sensor data; compliance monitoring against transfer streams (e.g. flagging concentrations approaching holder limits); auditor evidence collection on a scheduled basis.

Lifecycle orchestration. Redemption queue processing under bounded SLAs; dividend distribution to the holder list; coupon payment for fixed-income instruments; regulatory disclosure generation on a scheduled basis.

In each case, the agent's actions are bounded by the mandate, attested by TEE execution, and auditable to the principal and the regulator. The operational layer is a verifiable artefact on the same auditability footing as the on-chain layer.

10.5 Boundary between agent and principal

The boundary is explicit. The principal — the licensed party — sets policy, configures the mandate, and bears regulatory responsibility for the agent's actions. The agent — the runtime — executes within the mandate, under attestation, against verifiable inputs. The agent does not exercise judgement outside its mandate; if the inputs to a NAV computation are stale or inconsistent, the agent does not produce a NAV — it raises an exception that the principal handles.

The mandate is the SLA, the TEE attestation is the audit evidence, the chain-level execution is the record. Regulated outsourcing, expressed as cryptographic artefacts.

Part III — Specifications

The chapters in this part are specification-grade. They define the Daml interfaces, parameters, and semantics that a Boli-conformant implementation must provide. Where a chapter summarises material that is fully specified in a BSP, the BSP is normative and this chapter is illustrative.

11. Pattern A: Tradeable (specification)

11.1 Conformance

A Tradeable asset implementation will conform to the forthcoming BSP-0001 (Asset Pattern: Tradeable) once that BSP is published, by implementing the Daml interfaces defined therein. BSP-0001 will reference CIP-56 (the Canton Improvement Proposal for institutional-grade tokens) and Splice Token Standard V1; conformance with BSP-0001 will imply conformance with both.

11.2 Core interfaces

A Tradeable asset implements the following Daml interfaces:

Token — the holding contract. Parameterised by issuer : Party, holder : Party, instrumentId : InstrumentId, amount : Decimal, lockState : LockState. The contract represents the holder's position in the instrument.
Transferable — the transfer interface. Implements an Initiate_Transfer choice taking the proposed transferee, the amount, the proposed settlement asset, and the proposed settlement amount. The choice produces a transfer proposal; the proposal is accepted by the transferee and atomically settled via AllocationV1.
Allocatable — the AllocationV1 settlement interface from Splice. Atomic delivery-vs-payment is performed via this interface against any settlement asset that itself implements Allocatable.
Holding — the holding-list interface, observable by parties with read access (the issuer, the holder, the issuer's auditor, the regulator party if configured).
PolicyGoverned — the compliance-pack interface. Every transfer evaluates the asset's pack as a precondition.

11.3 Compliance-pack predicates for Pattern A

The compliance-pack engine accepts the following predicate categories for Pattern A:

Eligibility — transferee_is_credentialled, transferee_jurisdiction_in, transferee_not_sanctioned, transferee_is_accredited.
Quantity — holder_limit_max, aggregate_holder_count_max, lot_size_min, position_concentration_max.
Temporal — lockup_period, transfer_blackout, coupon_period_freeze.
Settlement — settlement_asset_in, settlement_amount_min, settlement_amount_max.
Disclosure — regulator_observability_threshold, audit_observability_always.

Each predicate's exact semantics are reserved for the forthcoming BSP-0001 §4.

11.4 Primary issuance flow

The issuer instantiates an instance of the Tradeable Daml package, configured with the instrument's parameters and the compliance pack reference.
The issuer creates the initial Token holding contracts assigning the primary-issuance allocation.
Primary investors authenticate via TDIP-bound DIDs; their KYC and accreditation credentials are verified against the issuer's required-credential list.
Primary subscriptions execute as AllocationV1 settlements: the issuer's Token holding is allocated to the investor party against the investor's settlement-asset position, atomically.
The compliance pack is evaluated on every allocation; primary-issuance lock-up rules apply if configured.

11.5 Secondary settlement flow

A holder initiates a transfer via Initiate_Transfer, specifying the transferee, amount, settlement asset, and settlement amount.
The proposal is signed by the holder; the transferee is offered the proposal as a Daml contract.
The transferee accepts; the runtime evaluates the compliance pack against the transfer parameters.
If the pack passes, the runtime executes the AllocationV1 settlement: the holder's holding decrements, the transferee's holding increments, and the settlement asset moves in the opposite direction — all atomically.
The transfer is recorded on Canton; if the asset is mirrored, mirror updates are propagated downstream.

11.6 Corporate actions

Pattern A supports corporate actions via the following interfaces, each of which is implemented optionally:

Dividend — the issuer distributes a dividend to the holder list, atomically against the issuer's payment of the settlement asset.
Redemption — the issuer redeems a holding against payment.
Reorganisation — the issuer reissues holdings under a new instrument identifier (e.g. for a corporate split or merger).
Coupon — for fixed-income instruments, scheduled coupon payments.

Each corporate action is a Daml workflow; each evaluates the compliance pack; each settles atomically.

11.7 Mirror semantics for Pattern A

Mirrors of Pattern A assets implement:

EVM — an ERC-20 contract with a transfer precondition that calls a Boli-operated cross-chain message bus; the message bus relays the proposed transfer to the canonical Canton ledger for compliance evaluation; the transfer either commits on both chains or neither.
Solana — an SPL token with the same precondition pattern via a Solana program calling the message bus.

The mirror operator is identified by an issuer-signed Daml contract on Canton; the mirror's authority does not exceed the issuer's authority. Burn-to-redeem semantics return canonical holdings to the issuer's escrow.

12. Pattern B: Registry-mirror (specification)

12.1 Conformance

A Registry-mirror implementation will conform to the forthcoming BSP-0002 (Asset Pattern: Registry-mirror) once that BSP is published, by implementing the Daml interfaces defined therein.

12.2 Core interfaces

MirrorEntry — the mirror contract. Parameterised by registryParty : Party, holderParty : Party, recordIdentifier : Text, recordHash : Hash, attributes : Map Text Text. The contract represents the on-chain mirror of a single record in a sovereign register.
Transferable — the holder-initiated transfer interface. Requires the joint authority of the registry party and the holder party for any state transition.
Encumberable — the encumbrance interface. A separate Daml contract (lien, mortgage, restraint, caveat) is created against the mirror entry; the entry's transfer is blocked while encumbrances exist; the encumbrance's release requires its beneficiary's authority.
Correctable — the registry-party-initiated correction interface. The registry retains operational control of corrections, audited by the chain-level transaction record.
Synchronisable — the synchronisation hash interface. Each mirror entry carries a hash of the corresponding off-chain record; the synchronisation adapter is responsible for updating the hash when the off-chain record changes.

12.3 The synchronisation adapter

A registry-mirror deployment requires a synchronisation adapter operated by the registry authority or its technology partner. The adapter:

Subscribes to the off-chain register's change feed (or polls, where a change feed is unavailable).
For each change, computes the new record hash and submits a Daml transaction updating the mirror entry's recordHash field.
Verifies that the on-chain mirror's holder party matches the off-chain record's title-holder; flags any divergence.
Surfaces a public divergence dashboard showing any mirror entries whose hash has not been updated within the SLA window.

The adapter is the operational integration between the sovereign register and Canton. Its correctness is the registry authority's responsibility; the chain enforces the authority of the registry party to make changes, but does not enforce that the registry party's changes match the off-chain record. That match is the adapter's job.

12.4 Encumbrance lifecycle

An encumbrance against a Pattern B asset is a separate Daml contract. The lifecycle:

The encumbrance beneficiary (e.g. a mortgagee bank) and the holder party jointly sign an encumbrance contract referencing the mirror entry.
The mirror entry's transfer template observes the encumbrance — if any active encumbrance contracts exist, the transfer template's preconditions fail.
Release of the encumbrance is a Daml transaction signed by the beneficiary, optionally also by the holder if the contract requires it.

Once all encumbrances are released, the mirror entry is again transferable.

12.5 Correction semantics

Corrections — performed by the registry party to fix errors in the on-chain mirror — are a Daml transaction signed by the registry party alone. Corrections are observable to the holder; the contract's transaction history records the correction's reason, the registry-party signatory, and the resulting state.

A correction does not bypass encumbrances. If the mirror entry has active encumbrances, a correction that would change the entry's identifier or the holder party requires the encumbrance beneficiary's joint authority — preventing the registry from extinguishing a third party's interest unilaterally.

12.6 Mirroring Pattern B further

Pattern B assets are generally not mirrored to EVM or Solana, because Pattern B is itself a mirror. Where downstream tokenization is required (e.g. fractionalising a real-estate title for capital formation), the standard pattern is:

The Pattern B mirror entry remains canonical.
A Pattern A share class is issued, with the share class's compliance pack referencing the Pattern B entry's identifier.
The Pattern A share class is mirrored to EVM and Solana per §11.7.

This composition keeps the registry-mirror's authority structure intact while enabling distribution of derived instruments.

13. Pattern C: Credential (specification)

13.1 Conformance

A Credential implementation will conform to the forthcoming BSP-0003 (Asset Pattern: Credential) once that BSP is published, by implementing the Daml interfaces defined therein and emitting credentials conformant with the W3C Verifiable Credentials Data Model 2.0.

13.2 Core interfaces

CredentialRecord — the on-chain anchor for a credential. Parameterised by issuer : Party, holderDid : DID, credentialHash : Hash, issuedAt : Time, expiresAt : Optional Time, revocationStatus : RevocationStatus. The record does not contain the credential's payload — that is held by the holder, off-chain — only the cryptographic anchor.
Issuable — the issuer-initiated issuance interface. The issuer signs a credential payload (off-chain), publishes the corresponding CredentialRecord (on-chain), and delivers the signed payload to the holder via TDIP.
Revocable — the issuer-initiated revocation interface. A revocation is a Daml transaction updating the revocationStatus field; verifiers observe the status atomically.
Presentable — the presentation protocol. The holder presents a credential to a verifier off-chain, optionally with selective disclosure (zero-knowledge proofs over predicates of the credential payload). The verifier checks the presentation against the on-chain CredentialRecord to confirm the credential is current.

13.3 Selective disclosure

Pattern C credentials support selective disclosure over the credential's claims. The holder's wallet computes a presentation that reveals only the predicates a verifier requires, without disclosing the underlying claims.

Examples:

A holder of an SL-UDI verifiable credential proves they are over 18 to a verifier without disclosing their date of birth.
A holder of an MRV-verifier credential proves they are accredited to verify a specific methodology without disclosing their other credentials.
A holder of a KYC-claim credential proves they passed KYC at a regulated bank without disclosing the bank's identity.

The cryptographic primitives are standard W3C VC selective disclosure (BBS+ signatures, in the current implementation).

13.4 Anchoring and resolution

The on-chain CredentialRecord serves as the revocation status registry and the issuance anchor. A verifier resolving a credential:

Receives the holder's presentation (off-chain).
Verifies the issuer's signature against the issuer's DID document.
Resolves the credential's credentialHash to the corresponding CredentialRecord on Canton.
Confirms revocationStatus is Active and the credential has not expired.

The on-chain step (3–4) is the difference between a credential that can be invalidated atomically and one that requires a round-trip to the issuer's CRL. For sovereign and regulated credentials, this matters.

13.5 Privacy

The Canton CredentialRecord is observable only to parties with read access — the issuer, the holder (via the holder's DID-bound party), and any verifier the holder has presented to. The credential payload itself is held off-chain by the holder, encrypted in their wallet. The revocation registry does not leak the credential's existence to the public.

Boli's choice of Canton for Pattern C is the same choice as for Pattern A and B: regulated credentials require privacy at the protocol level.

13.6 Mirror semantics for Pattern C

Credentials are not transferred — they are issued and presented. There is no mirror chain for credentials in the same sense as Pattern A. A holder's identity wallet can be on any chain; the wallet presents to a verifier; the verifier resolves the credential's status against Canton via TDIP.

Where a verifier on a non-Canton chain needs to programmatically check credential status, the TDIP bridge exposes a status oracle that emits revocation-status updates to subscribed mirror chains. The oracle is operated under TEE attestation; the canonical state remains on Canton.

14. Marketplace and intent routing

14.1 What the marketplace is

The Boli Marketplace is aggregated discovery and intent routing across listed partners. It is not a venue. It does not match orders. It does not custody assets. It surfaces what is available across the partners that have onboarded, routes a user's intent to the partner that can fulfil it, and observes the outcome for analytics and audit.

A "listed partner" is a Boli-onboarded entity — a licensed issuer, a licensed venue, a custodian, a registrar, or an identity provider — that has gone through Boli's onboarding process and elected to make some of its assets or services discoverable through the marketplace.

14.2 Permissionless to use; approval to list

Two distinct permissioning regimes:

Use is permissionless. Any user with a TDIP-bound DID and the credentials required by the listed asset can browse, subscribe, transfer, or interact with marketplace listings, subject to the listed asset's compliance pack.
Listing requires approval. A partner that wants to list assets or services on the marketplace goes through Boli's onboarding: legal entity verification, jurisdictional fit, asset-pattern conformance, compliance-pack review. The approval is documented; the listing is reversible.

This split mirrors the architecture of a stock exchange: anyone can buy a listed share (subject to KYC); listing the share requires the issuer to satisfy listing standards.

14.3 Intent routing

A user's interaction with the marketplace is expressed as an intent: "I want to subscribe to X", "I want to transfer Y to Z", "I want to verify the credential C". The marketplace:

Identifies the partner(s) that can fulfil the intent.
Routes the intent to the partner's integration endpoint.
Observes the outcome (settled on Canton, observable via the chain).

The routing is non-custodial. Boli does not take possession of the user's assets, settlement assets, or credentials at any point. The routing is informational; the execution is between the user and the partner, atomically on Canton.

14.4 Onboarding criteria

A partner seeking to list goes through:

Legal verification — the partner's licensing in its jurisdiction, the legal entity's good standing, beneficial-ownership transparency.
Asset-pattern conformance — the partner's assets must conform to one of the three Boli patterns. Bespoke asset structures are not listed; they are addressed by extending the patterns through the BSP process.
Compliance-pack review — Boli reviews the pack for soundness, but does not approve its substance. The substance is the partner's regulatory choice.
Operational readiness — the partner's integration is tested against Boli's reference platform, including failure modes.

The criteria are reserved for the forthcoming BSP-0006 (Marketplace listing criteria).

Part IV — Operating model

15. Boli Foundation, on-chain governance, and the $BOLI utility token

15.1 The interim period — on-chain DAO governance, no legal entity

Boli operates without a legal entity until the Foundation is formally established. There is no Boli operating company, no Boli holding company, no Boli LLC. In the interim, the platform's governance runs on-chain as a DAO — proposals, votes, treasury actions, and $BOLI custody are executed by the DAO's smart contracts. The contributors who build the platform (Tenzro Labs and other engineering entities) participate in governance as contributors, not as a Boli-side legal entity.

Contracts and legal documents in the interim. Any contracts a customer, partner, vendor, or regulator needs to sign — services agreements, IP licences, employment, regulatory correspondence — are executed by a contributing entity under its own legal personality, not by Boli. Tenzro Labs (Singapore) and the other contributing entities sign in their own names. The DAO is not a contractual counterparty during this period because it has no legal personality.

This pattern is recognised institutional practice: Uniswap (2020–2022), Gitcoin (2021–2023), and others operated as on-chain DAOs with separate contributor entities holding contracts until a Foundation was chartered. The contributing-entity-signs-contracts model is described in the public structuring playbooks of a16z and Variant; the post-2025 commentary (following the Samuels v. Lido line of cases) is unanimous that the interim window should be bounded and that the contributor-entity-services arrangement should be documented. Boli's interim period is bounded by the Foundation's charter, which the DAO is expected to vote into existence as the platform reaches institutional scale.

15.2 The Foundation, once established

The Boli Foundation will be chartered by an on-chain DAO vote. Once established, the Foundation becomes the only legal entity associated with Boli. The Foundation's mandate is governance of the $BOLI token and promotion of the ecosystem — it is not an operating company, does not ship technology, does not custody user assets, and does not run regulated venues. Engineering continues to be performed by contracted or partnered entities; the Foundation funds and coordinates their work through grants or service agreements documented under its charter.

The Foundation's jurisdiction (Cayman Foundation Company, Swiss Stiftung, ADGM DLT Foundation, or other) will be selected at charter time based on the platform's deployment posture at that point. The Foundation's board composition, treasury policy, grant-making process, and the on-chain governance procedures that continue to run under its charter will be documented in the Foundation's constituting instrument, separately from this whitepaper.

The Foundation is legally separate from the engineering entities contributed or partnered to build the Boli Platform, and from the licensed parties that operate venues, custodians, and issuance infrastructure on top of it. Those entities continue to carry their own licences, their own contracts, and their own regulatory responsibilities.

15.3 The $BOLI utility token

$BOLI is the platform's utility and governance-participation token. It is non-revenue-bearing — holding $BOLI does not entitle the holder to a share of platform revenue, asset issuance fees, or any other cash flow. It is not equity in any of the Boli legal entities (during the interim there is none; after charter, the Foundation is the only Boli legal entity and $BOLI is not equity in it either).

What $BOLI does:

Governs the platform on-chain. $BOLI weights votes on BSP standards, treasury actions, and — until the Foundation is chartered — every other platform-level decision. After charter, on-chain governance continues to operate under the Foundation's constituting instrument.
Aligns ecosystem contributors. Grants, ecosystem incentives, and standards-process participation are denominated in $BOLI; long-term contributors accumulate $BOLI proportional to their contribution.
Funds the mission treasury. The DAO (and after charter, the Foundation) holds a treasury allocation of $BOLI and uses it to fund the activities described in §15.1 and §15.2.
Provides utility within the platform. Specific platform interactions — onboarding, listing fees, MPC operator service fees, validator-tier benefits — denominate in $BOLI. These uses are payment-for-service, not investment.

Treasury composition. The full $BOLI distribution and vesting schedule is maintained in the tokenomics document separately to this whitepaper; the discipline applied to that document is summarised here for the regulatory line.

Tenzro Labs holds 10% of total supply as the platform's incubator and engineering/operational funder through testnet launch (see §4.3 and §16.2).
Additional development-phase stakeholders are onboarded by the Boli founders on similar incubator/contributor terms, against treasury allocations carved out of the same total supply.
The single-holder concentration ceiling is 20% of total supply for any individual address or beneficial holder, consistent with the threshold the U.S. CLARITY Act §205 uses for its mature-blockchain certification (the bill is in Senate Banking markup as of May 2026).
Insider allocations (founders, contributors, strategic stakeholders, treasury) vest no faster than community allocations: a one-year cliff from token generation event (TGE) followed by three-to-four-year linear vesting, with the Foundation/treasury portion non-transferable for at least five years post-charter. This pattern follows the post-Samuels v. Lido discipline that emerged across 2025 token launches (Consensys-Linea's 85/15 community-to-parent split with five-year non-transferable lock is the closest comparable).
Initial circulating supply at TGE targets 22–33% of total supply, consistent with the 2026 institutional-launch band (Linea 22%, Hyperliquid ~33%).
The Foundation does not market $BOLI as an investment, does not promise yields, does not denominate marketing in expected returns, and does not run primary sales to retail. Token marketing follows the post-Samuels discipline of chartering the Foundation before insider-driven governance push or material primary distribution.

15.4 The regulatory line for $BOLI

The same boundary that governs the platform (§4) governs the token, with token-specific overlays for each regime.

$BOLI is not a security. The token does not entitle the holder to revenue, profit, or an equity claim. The Foundation does not represent it as an investment. Under the U.S. CLARITY Act framework (in Senate Banking markup as of May 2026), the platform's design — mature-blockchain certification path, ≤20% single-holder threshold, no centralised control over consensus — targets the non-security treatment that the Act establishes for digital commodities on certified mature blockchains.
$BOLI is not a payment stablecoin. The token is not pegged, is not redeemable for fiat, and is not marketed as a settlement instrument. It is therefore out of scope of the U.S. GENIUS Act (signed July 2025), which regulates payment stablecoins specifically. Marketing copy avoids fixed-value, redemption, and settlement language to maintain that line.
$BOLI is not a settlement asset. Boli-issued tokenized assets settle against settlement assets the licensed party chooses — tokenized deposits, regulated stablecoins, CBDC, fiat-on-chain. $BOLI is not used as a settlement asset for tokenized regulated assets.
$BOLI is not a governance share over assets. The token does not grant voting rights over assets issued by licensed parties through the platform. Those assets' governance rests with their issuers.
EU — MiCA Article 6. Any offer of $BOLI to the public or admission to trading on an EU trading platform after the end of MiCA's transitional period (1 July 2026) requires a notified white paper under Article 6. The Foundation prepares and notifies that white paper in advance of any EU-targeted distribution; the ESMA/EBA January 2025 Joint Report makes clear that the Recital 22 "fully decentralised" exemption is not practically available, so the white paper route is the operative one. Marketing communications in the EU follow Article 7.
Singapore — MAS DTSP. The Digital Token Service Provider framework (June 2025) carves out utility and governance tokens from the DTSP perimeter; $BOLI's utility/governance design is intended to sit inside that carve-out.
Hong Kong — HKMA Cap. 656 and SFC. The Stablecoins Ordinance (Cap. 656, August 2025) regulates fiat-referenced tokens only; utility tokens are out of scope. The SFC's Type 1/7 perimeter for tokenized securities is the relevant frame if any platform-issued asset (not $BOLI itself) crosses into security territory.
Abu Dhabi — FSRA FRT framework (January 2026). The Fiat-Referenced Token framework regulates pegged tokens; utility/governance tokens are out of scope.
Switzerland — FINMA Guidance 06/2024 and the three-tier classification. FINMA's payment/utility/asset-token taxonomy survives the 2024 guidance update; $BOLI's utility/governance design targets the utility-token tier. Any Swiss-domiciled Foundation issuance would be supported by a legal opinion from Swiss counsel (MME or Lenz & Staehelin remain the canonical 2026 issuers of such opinions).

The narrow scope of $BOLI's utility — non-revenue-bearing, non-pegged, non-settlement, non-asset-governance — is what allows the Foundation to operate it as an ecosystem-alignment instrument across jurisdictions.

16. Governance and contributing entities

16.1 The standards process

This whitepaper and the BSPs that accompany it are maintained under a public process. In the interim period (before Foundation charter), BSPs are authored by contributing entities and ratified by on-chain DAO vote; after charter, the Foundation is the standards body of record and the DAO continues to operate within the Foundation's constituting instrument. The BSP repository lives at github.com/boli-foundation/bsps; the only BSP currently published is BSP-0000, which specifies the standards process itself. BSPs 0001 through 0006 referenced throughout this whitepaper are reserved identifiers for forthcoming proposals.

The high-level lifecycle:

Authoring. A BSP is drafted by a contributing entity or external contributor. The author is named in the BSP.
Draft. The BSP is published in the BSP repository with status Draft. Open public comment.
Review. Once stable for implementation review, the BSP moves to status Review. Implementations may begin; breaking changes are flagged.
Final. When two independent implementations interop against the BSP and no breaking issues remain open, the BSP is moved to Final by on-chain DAO vote (post-charter, ratified under the Foundation's constituting instrument). The BSP is frozen.
Superseded. If a later BSP supersedes an earlier one, the earlier moves to Superseded with explicit reference forward, by the same vote mechanism.

The process itself is specified in BSP-0000.

16.2 Contributing entities

Three classes of contributor.

Tenzro Labs (Singapore) — incubator of the Boli Platform from 2025 onwards, Canton ecosystem partner, operator of a Canton validator. Under the incubation deal, Tenzro Labs funds engineering and operational costs through testnet launch and retains 10% of total $BOLI supply as the originating sponsor (see §15.3). The Boli Platform is deployed on Tenzro's Canton validator node (see §4.3 and §6.1). Tenzro authors and reviews BSPs in the identity, key-handling, agentic-runtime, and validator-operation domains; Tenzro contributes the reference implementation of TDIP and the agentic runtime.

Engineering entities under contributor agreements — engineering organisations contracted or partnered to build the Boli Platform. In the interim period (before Foundation charter) these entities sign customer, IP, and employment contracts under their own legal personalities (§15.1); after charter, the Foundation may grant or contract directly. They author BSPs in the Daml-pattern, compliance-pack, mirroring, and marketplace domains; they contribute reference implementations. Additional engineering contributors are onboarded by the Boli founders against treasury allocations carved from total $BOLI supply.

External contributors — institutional integrators, sovereign technical staff, academic researchers, and other Canton ecosystem participants. External contributors author BSPs as their domain knowledge warrants; the BSP-0000 process is open to non-affiliated contributors with no special permission.

No entity gates contribution. Moving a BSP to Final requires an on-chain DAO vote on the implementation evidence — but a contributor can author and progress a Draft and Review BSP without prior approval.

16.3 Relationship to the Canton ecosystem

Boli's standards process composes with, and does not duplicate, the Canton ecosystem's standards processes. The relationship:

Canton Improvement Proposals (CIPs) — protocol-level standards for Canton itself, governed under the Linux Foundation Decentralized Trust umbrella. Boli relies on CIPs (notably cip-0056 for institutional-grade tokens) and contributes upstream where Boli's deployment experience is relevant.
Splice Token Standards — the token-layer standards governed by the Global Synchronizer Foundation. The forthcoming BSP-0001 (Pattern A) will implement Splice Token Standard V1.
Boli Standards Proposals (BSPs) — operating-layer standards specific to Boli. BSPs do not duplicate or replace CIPs or Splice standards; they extend them with Boli-specific conventions.

A BSP that would conflict with a CIP or a Splice standard is not finalised; either the BSP is revised to compose, or the relevant CIP/Splice change is proposed upstream and Boli waits for the upstream change.

16.4 Decision-making

Decisions on BSP status, on the platform roadmap, and on treasury policy are made by the bodies appropriate to each:

BSP status decisions — by on-chain DAO vote in the interim period; under the Foundation charter once chartered.
Platform roadmap — by the contributing engineering entities, with input from licensed-party deployment experience and from the on-chain DAO (post-charter: from Foundation grant-making).
Treasury — by on-chain DAO vote in the interim; by the Foundation board under the Foundation charter once chartered.

Each body publishes its decisions transparently. The DAO (and, after charter, the Foundation) decides standards and treasury, while the contributing engineering entities decide implementation — the same separation-of-powers logic the Linux Foundation, the GSF, and other major open-source/open-standards bodies operate under.

17. Roadmap and current status

17.1 What ships at v0.9

As of this whitepaper's draft date (May 2026), the platform's v0.9 state is:

Daml asset patterns. Pattern A (Tradeable) and Pattern B (Registry-mirror) base packages are stable and shipped against Daml SDK 3.4.10 with Splice Token Standard V1. Pattern C (Credential) base package is stable for issuance and revocation; selective-disclosure presentation is shipped via the TDIP wallet client.
Compliance-pack engine. v0.9 supports the predicate categories enumerated in §11.3 for Pattern A, with extension points for additional categories for Pattern B and C in subsequent BSPs.
Multi-VM mirroring. EVM mirror is shipped against the canonical message-bus protocol. Solana mirror is in integration testing.
TDIP identity bridge. The DID-to-Canton-party-id binding is shipped; the TDIP wallet client is integrated; the production canonical bridge is wired through Boli's web layer.
Agentic runtime. Tenzro's runtime ships; on-chain mandate registration is integrated; TEE-attested execution is in pilot deployment.
Marketplace. v0.9 supports listing, discovery, and intent routing for Pattern A assets; Pattern B and C marketplace surfaces are forthcoming.
Pack catalog. Four minimal first packs against the asset bases (covering common Pattern A configurations for fund interests, real-estate share classes, environmental credits, and structured products) are available.

17.2 Current network posture

The platform's first launch is on the Tenzro testnet, with Canton mainnet wired from day one for the institutional integrations that require it. The Boli Platform is deployed on Tenzro Labs' Canton validator node; Boli does not operate its own validator. There is no Boli operating company in the interim period (§15.1); contributing entities (Tenzro Labs and others) sign customer, partner, and regulatory contracts under their own legal personalities.

The launch posture is operational, not architectural. The platform's design does not depend on the jurisdictional posture of any contributing entity; the architecture is portable, and the Foundation's jurisdictional anchoring at charter time will be independent of any contributor's incorporation.

17.3 What is contemplated for v1.0

The v1.0 release is contemplated to include:

Pattern C selective-disclosure at the on-chain anchor level, beyond the wallet-client level.
Solana mirror in production.
The marketplace extended to Pattern B and Pattern C.
Additional BSPs finalising the bridge specifications (TDIP, mirroring), the marketplace listing protocol, and the agentic-mandate model.
Sovereign deployments in production — at least one land-registry pilot under Pattern B, at least one environmental-MRV deployment under Pattern C, at least one tokenized real-estate share class under Pattern A.

The exact timing of v1.0 depends on the deployment readiness of the integrating parties, not on the platform's engineering velocity. A v0.95 interim is published once the Solana mirror and Pattern C selective-disclosure on-chain support are stable.

17.4 Open questions

The principal open questions for the platform at v0.9:

Pattern composition for hybrid sovereign-and-financial assets. Some asset classes (governance-linked sovereign bonds, sovereign carbon-backed instruments) cross Pattern A and Pattern B in ways the current pattern boundaries handle by composition, but where direct hybrid patterns may simplify deployment. BSP work on this is at the early-draft stage.
Mirror-chain selection beyond EVM and Solana. Whether and when to support additional mirror chains (Aptos, Sui, Stellar, others) is a tractable engineering question with non-trivial governance implications. The current posture is to add mirrors in response to clear deployment demand, not speculatively.
The wholesale-CBDC interaction model. Boli is settlement-asset-agnostic; the question of how the platform composes with multiple wholesale CBDC initiatives (mBridge, Project Agorá, Project Ensemble) without privileging any particular initiative is a live policy question.
Privacy-preserving regulator observability. The compliance-pack engine supports regulator observability under explicit configuration, but the broader question of how regulators' supervisory needs are served on a privacy-preserving rail — without weakening the privacy properties for the supervised entities — is a live cryptographic and policy question. Active work, with academic partners, is under way.

Back matter

References

The references below are non-exhaustive; the BSPs referenced in Part III contain their own complete reference lists.

Canton and GSF

Canton Network Documentation. canton.network/docs.
Splice Token Standard V1. canton-network/splice repository, GSF.
Global Synchronizer Foundation. canton.foundation.
Linux Foundation Decentralized Trust. lfdecentralizedtrust.org.

Daml

Daml SDK 3.4 Documentation. docs.daml.com.
Digital Asset, Daml — A Smart Contract Language for Distributed Multi-Party Applications.

W3C standards

Decentralized Identifiers (DIDs) v1.0. W3C Recommendation.
Verifiable Credentials Data Model v2.0. W3C Recommendation.

Tenzro

Tenzro Network documentation. tenzro.com/docs.
TDIP specification. (Forthcoming, to be linked at BSP-0005 finalisation.)
Tenzro open-source SDKs and infrastructure. github.com/tenzro/.

Boli

Boli Standards Proposals repository. github.com/boli-foundation/bsps/.
Boli Whitepaper repository. github.com/boli-foundation/whitepaper/.
Boli Platform. boli.technology.

Institutional tokenization precedents

DTCC and Digital Asset, Treasury tokenization on Canton. December 2025.
HKMA, Project Ensemble — wholesale CBDC pilots. November 2025.
HKMA, HK$10 billion digital green bond issuance. Late 2025.
BIS, Project Agorá — testing phase. January 2026.
MAS, Project Guardian. Ongoing.
RBI, e-Rupee — production deployment statistics. 2026.
Project mBridge, cumulative cross-border transactions. 2026.

Glossary

Allocatable — the Daml interface in Splice Token Standard V1 that an asset implements to participate in AllocationV1 atomic settlement.

AllocationV1 — the Splice Token Standard V1 model for atomic delivery-vs-payment on Canton. The transfer of an asset and the corresponding transfer of a settlement asset are a single atomic action.

BSP — Boli Standards Proposal. A versioned specification document maintained in the boli-foundation/bsps repository.

Canton — the privacy-preserving public blockchain that is the settlement layer for the Boli Platform. Operated as a federation of named institutions; governed under the Linux Foundation through the Global Synchronizer Foundation.

Compliance pack — the chain-level encoding of a licensed party's transfer policy. A precondition of every transfer; written in a structured policy DSL that compiles to Daml.

Daml — a smart-contract language for multi-party workflows; the contract language used on Canton.

DID — W3C Decentralized Identifier. The naming primitive for parties on the Boli Platform, anchored via TDIP.

GSF — Global Synchronizer Foundation. The Linux Foundation–hosted body that governs the Canton synchroniser layer and the Splice Token Standards.

MRV — Monitoring, Reporting, Verification. The data lifecycle for environmental credits.

Pattern A / B / C — the three Boli Daml asset patterns: Tradeable, Registry-mirror, Credential.

Splice Token Standard V1 — the Canton ecosystem's institutional token standard, governed by the GSF; to be implemented by the forthcoming BSP-0001 (Pattern A).

TDIP — Tenzro Decentralized Identity Protocol. The identity foundation Tenzro Labs ships; provides DIDs, Verifiable Credentials, and the Canton party-id bridge.

TEE — Trusted Execution Environment. A hardware-attested execution context used by the agentic runtime to produce verifiable execution attestations.

$BOLI — the Foundation's non-revenue-bearing utility token; aligns ecosystem contributors and funds the mission treasury.

Change log

Version	Date	Notes
v0.9	May 2026	First draft for review. Parts I–IV complete; BSP-0000 published, BSPs 0001–0006 referenced as reserved identifiers for forthcoming proposals.
v0.9.1	May 2026	Regulatory-alignment chapter expanded into §§4.5–4.17 (MiCA / eIDAS-2 / SEC Staff Statement / Reg D-S-A+ / GENIUS Act / CLARITY Act / MAS Project Guardian / HKMA Ensemble / FSRA / VARA / EU DLT Pilot / Swiss DLT Act / UK FCA DSS / Travel Rule / cross-regime composition). Canton-canonical anchoring made explicit in every regime mapping; DTCC + Digital Asset tokenization of DTC-custodied U.S. Treasuries on Canton (December 2025) cited as the institutional precedent. Operating-model chapter restructured: §15 split into interim DAO governance / Foundation-once-chartered / $BOLI utility token / regulatory line for $BOLI, with 2026 token-design discipline applied (CLARITY §205 ≤20% single-holder, post-Samuels v. Lido vesting parity, MiCA Article 6, GENIUS carve-out marketing line, FSRA / HKMA / FINMA / MAS carve-outs); §16 rewritten to drop Association as standards body and replace with interim DAO ratification → Foundation-as-standards-body post-charter, with contributing engineering entities authoring BSPs. Tenzro Labs's incubator role and 10% future-supply stake recorded. Whitepaper publisher line and repository paths moved from `boliassociation/` to `boli-foundation/`.

Contributors

The whitepaper is authored by the Boli Platform contributors with contributions from Tenzro Labs and external reviewers. A complete contributor list will be maintained at the v1.0 release; comments on this draft are invited via the boli-foundation/whitepaper repository's issue tracker.

Published by the Boli Foundation (to be established; in the interim the whitepaper is maintained by the Boli Platform contributors under the on-chain DAO). Maintained at github.com/boli-foundation/whitepaper, alongside the BSP repository at github.com/boli-foundation/bsps. Licensed CC BY 4.0.

The Boli Whitepaper

Status of this document

Abstract

Part I — Strategic

1. Introduction

1.1 What Boli is

1.2 Why now

1.3 Reading this document

2. The institutional rail: Canton Network

2.1 What Canton is

2.2 Who is on Canton

2.3 The Global Synchronizer Foundation

2.4 Why a privacy-preserving public chain matters for regulated assets

3. The three asset patterns

3.1 Pattern A — Tradeable

3.2 Pattern B — Registry-mirror

3.3 Pattern C — Credential

3.4 Mapping asset classes to patterns

4. The regulatory line

4.1 What Boli ships

4.2 What Boli does not do

4.3 The contributing entities

4.4 What licensed parties carry

4.5 Regulatory alignment — overview

4.6 EU — Markets in Crypto-Assets Regulation (MiCA)

4.7 EU — eIDAS-2 and the EU Digital Identity Wallet

4.8 United States — SEC Staff Statement on tokenized securities; Reg D / Reg S / Reg A+

4.9 United States — the GENIUS Act and payment stablecoins

4.10 United States — the Digital Asset Market CLARITY Act (in Senate as of May 2026)

4.11 Singapore — MAS Project Guardian and the DTSP framework

4.12 Hong Kong — HKMA Ensemble and the SFC framework

4.13 Abu Dhabi — FSRA framework (ADGM); and Dubai — VARA

4.14 European Union — DLT Pilot Regime; Switzerland — DLT Act

4.15 United Kingdom — FCA Digital Securities Sandbox

4.16 The Travel Rule and AML obligations

4.17 Cross-regime composition

5. The eight audiences

Part II — Architecture

6. System overview

6.1 The three layers

6.2 Why this layering

6.3 Interfaces between layers

7. The compliance-pack engine

7.1 What a compliance pack is

7.2 How a pack is authored

7.3 Properties of chain-level enforcement

7.4 Audit and amendment

8. Multi-VM mirroring

8.1 Canonical and mirror

8.2 Why mirror at all

8.3 What "canonical on Canton" means

8.4 Divergence and reconciliation

8.5 Mirror semantics for each pattern

9. The TDIP identity bridge

9.1 What TDIP is

9.2 The bridge

9.3 Wallet portability

9.4 Key handling

10. Agentic asset operations

10.1 The operational lifecycle

10.2 What an agentic mandate is

10.3 Why TEE-verifiable

10.4 What agents do, in practice

10.5 Boundary between agent and principal

Part III — Specifications

11. Pattern A: Tradeable (specification)

11.1 Conformance

11.2 Core interfaces

11.3 Compliance-pack predicates for Pattern A

11.4 Primary issuance flow

11.5 Secondary settlement flow

11.6 Corporate actions

11.7 Mirror semantics for Pattern A

12. Pattern B: Registry-mirror (specification)

12.1 Conformance

12.2 Core interfaces

12.3 The synchronisation adapter

12.4 Encumbrance lifecycle

12.5 Correction semantics

12.6 Mirroring Pattern B further