What's actually behind the summary: every capability, how it works, and where it stands today.

The contract's state and every party's authority to change it are enforced by the ledger, not by application code. Each lifecycle state is its own contract template with its own signatories and controllers, so an unauthorized transition is rejected by the network before it can ever reach the application layer.

• —Six-state machine (Draft → Funds committed → Active → Disputed ⇄ Settlement offered → Settled), each state a distinct signed contract, not a status field
• —Tripartite signatory authority (Depositor, Beneficiary, Custodian) on every material transition, with Mediator escalation on dispute and a binding-arbitration path once mediation is exhausted
• —Complex topologies: weighted multi-beneficiary payout, recurring and access-gated escrow, and parent/child contract aggregation (all-children-settled or any-child-settled rules) for related shipments or tranches
• —Two clearing modes selected at signing and fixed for the life of the contract: progressive (each milestone releases independently) or all-or-none (nothing releases until every milestone clears)
• —Zero-fee off-chain negotiation layer for terms and milestones before anything is committed to the ledger, with bilateral ratification required for on-chain promotion
• —Four-eyes separation between the party who drafts terms and the party authorized to commit funds: a preparer role can never unilaterally fund a contract
• —Structured disputes: a dispute is filed with a reason, a narrative and supporting evidence from the start, and a missed performance deadline routes to mediation, never to a unilateral refund
• —The mediator's fee is agreed in the contract at signing, not chosen once a dispute arises; settlements are allocated by percentage, so every unit of the escrowed amount is accounted for
• —Cancellation needs every depositor and beneficiary to approve, then any one of them can carry it out: no single party can cancel alone
• —A printable progress and completion report for each escrow, for the parties' own records

Assets are held as real token interfaces, never as a numeric balance the platform tracks itself, and settlement rail is a choice per leg, not a fixed medium for the whole contract.

• —Native support for the CIP-0056 token standard for interoperability with institutional stablecoin issuers: holdings are referenced directly, never wrapped or bridged into a synthetic asset
• —Threshold custody: fund release can require an n-of-m signature threshold from independent custody approvers, enforced by the ledger's native multi-party signatory model, with no separate multisig infrastructure to operate or trust
• —Reserve attestation, human-countersigned: a reserve snapshot is only valid once an independent Auditor party co-signs it on-ledger, not merely claimed by the custodian
• —Hybrid settlement rail routing: one contract can settle on-chain (stablecoin) or off-chain (ACH, RTP, FedNow, wire, via a swappable fiat-payments-orchestration integration) per disbursement leg, without the ledger needing to know rail-specific mechanics like batch windows or cutoffs
• —Multi-currency custodian resolution: the custodian and stablecoin rail for a given leg are resolved per currency, not fixed for the whole contract, so a single multi-currency deal clears each leg through the custodian actually licensed for that currency
• —Settlement-triggering signatures are proofed through hardware-backed key management (KMS/HSM-class), never software-only keys
• —Custodian per escrow: each contract names its custodian (no single platform-wide custodian), and a custodian quorum governs releases and sweeps to registered destinations
• —Funding backers on record: a bank, underwriter or insurer standing behind the depositor's funds is recorded with its backing type and risk tier, so a letter of credit and on-chain collateral are never treated as equivalent
• —Guaranteed fiat settlement: a named underwriter (the custodian or a correspondent bank) attests a guarantee, modeled on standby letter-of-credit practice (ISP98); once the custodian and the underwriter both approve, the beneficiary is paid over the fiat rail. Verified for custodian-held holdings; real-money use is gated on compliance and legal sign-off
• —Who bears the network fee is a contract term (depositor, beneficiary or shared), mirroring the OUR/BEN/SHA charge options of international wire payments
• —Integration with institutional digital-asset custody providers for real disbursements to external wallets, alongside ledger-native holdings
• —Funding choice per depositor: a verified custodian deposit today (a real per-tenant custody wallet, checked and reserved before anything is minted), with a depositor-owned-holding lock-in-place path specified as the roadmap alternative — see Promise & Lock below

The mechanism that turns a real-world event into a ledger-verifiable fact, without a person deciding by hand whether to believe it.

• —Registered-signer model: every event source (a vessel-tracking feed, a licensed customs broker, a notarization service) is pre-registered against its public key before any signal from it is trusted
• —Verify-then-journal: an incoming signal is cryptographically verified before it is ever durably recorded, and durably recorded before the ledger is touched. A process restart or network blip can't silently drop evidence, and the same signal can't clear a milestone twice
• —Geospatial and customs event coverage today: territorial-boundary crossings, customs filing, and customs clearance for maritime shipments; air, rail, truck and parcel-carrier events are on the roadmap below
• —Scoped auto-approval: a registered trusted signer can be granted a narrow, per-event-type fast path to clear a milestone automatically. Every other case still requires an explicit verifier action, and every auto-cleared milestone remains independently disputable after the fact
• —Every verification attempt, success or failure, stays on the record: auditable and replayable, never a black box

Every piece of evidence behind a milestone is a structured, independently attested object, never a free-text field, never a document sitting on the ledger itself.

• —Evidence types: an uploaded document, a logged record/event stream, or a self-attested oracle signal, each submitted as its own hash-locked, multi-party-signed contract, distinct from the milestone it supports
• —Unilateral submission, gated attestation: a party can submit evidence on their own authority; the verifier's countersignature is what advances it to a status a milestone can actually rely on, the same authorization model that governs fund release, applied to evidence
• —Documents live in a private, encrypted vault: hardware-key (KMS) encryption at rest, never a shared file store or public bucket, and the ledger stores only a content hash and a storage reference, never the document itself
• —Access is exclusively through backend-issued, time-limited, presigned links, granted only to parties the ledger already confirms are signatories on that contract
• —Read-through lazy mirroring: a party's own copy is cached to their vault on first access, not synchronously replicated everywhere in advance, consistent with each participant's private, sovereign infrastructure

Every counterparty is a real, federated institutional identity, never a shared platform login, bridged down to a cryptographic network identity only the ledger uses.

• —Each institution federates through its own enterprise identity provider (SAML or OIDC-based single sign-on): no shared platform password store
• —Every action is authorized by a scoped grant tied to that action (a modern token-based authorization model), never an all-or-nothing session login
• —A three-tier identity bridge: a verified external identity, a namespaced ledger-user identity, and the actual on-chain cryptographic party identity. The first two are never exposed to the ledger, and the network identity is never exposed in the user experience
• —Just-in-time provisioning: a counterparty who has never touched the platform can still be named and invited into a draft contract by email, auto-linked to their real identity the moment they first authenticate
• —Delegated organizational management: a designated manager can act on behalf of the counterparties they're responsible for (drafts, identity reconciliation), bounded strictly to the set they actually manage, mirroring how a bank's own operations team works internally
• —Wallet sign-in and signing: a party can sign in with a Canton wallet and approve transactions with their own key (CIP-0103), so the platform never holds that key
• —Directory-administration privilege (who can reconcile or manage cross-tier identity records) is granted through identity-provider group membership, not an in-application admin toggle: privilege escalation always has an out-of-band paper trail

Funds don't move until the payment has been screened, and a person with the authority to decide reviews anything flagged.

• —Every disbursement is screened (sanctions and transaction monitoring) before funds move, through a swappable screening-provider integration; the production provider is being selected
• —A flagged payment is held for the Money Laundering Officer, whose decision (clear, freeze, or suspicious-activity report filed) is recorded with notes and supporting evidence; a clearance is anchored on the ledger and retries the exact payment it held
• —Every red-flag reason code is documented with its meaning and the closest applicable regulation, in a printable reference
• —Export-control attestation: on import/export escrows, the depositor and the beneficiary each certify against a versioned attestation document before they can accept

Operational assurance built for a financial-grade audit standard, not retrofitted after the fact.

• —Tiered infrastructure governance: network foundation, application workload, and identity infrastructure are separately managed and separately controlled, so a compromise or change in one tier can't silently cascade into another
• —Each institutional participant runs its own network node with its own data sovereignty: no party depends on another's infrastructure to see or act on their own contracts
• —Continuous, layered health diagnostics across the database, ledger, and event-servicing layers, not a single top-level uptime check
• —Distributed request tracing end to end, so a stalled milestone or slow settlement can be diagnosed precisely, not just noticed
• —Built toward a SOC 2-aligned control set: least-privilege service credentials, four-eyes separation on sensitive operations, and hardware-backed key custody throughout
• —Interface in English and French, built so further languages (including Japanese, Chinese and Korean) are translation work, not a rebuild