Coming soon:preview the live demo.
Escrow that clears at the speed of the shipment, not the speed of the bank.
A tripartite escrow platform built on the Canton Network, releasing funds against verified milestones (territorial crossing, customs filing, customs clearance) instead of waiting on correspondent banking chains.
Trust in trade still runs through a single intermediary.
Cross-border trade escrow today means a correspondent-banking chain that takes days to clear, a single custodian who can become a single point of failure, and settlement terms enforced by contract language rather than by the system moving the money.
- —Multi-day settlement across time zones and banking hours
- —No native way to tie release to a physical or regulatory event
- —Dispute resolution bolted on after the fact, not designed in
Money that moves as fast as the data proving the deal.
Stablecoin settlement, milestone-verified release, and a private institutional network converge into something correspondent banking was never built for: escrow that reacts to a shipment crossing a boundary in the time it takes a signed feed to arrive.
- —24/7 settlement, not bound to banking-hour cutoffs
- —Evidence-driven release, a fact triggers a transfer, not a form
- —One counterparty relationship instead of a correspondent chain
A ledger-native escrow, governed by three parties, not one.
Buyer, seller, and a regulated issuer co-sign every state change. A mediator and, where needed, a binding arbitrator sit above the transaction. No party, including the platform, can unilaterally move funds.
- —Tripartite signatory authority on every disbursement
- —Stablecoin or fiat rail, selected per settlement leg
- —Sub-transaction privacy on a shared institutional network
Why stablecoins carry the international leg
Fiat rails stay the right choice for domestic, regulated, or payroll-adjacent disbursement. The moment a payment crosses a border and needs to move outside banking hours, the calculus changes.
| Dimension | Correspondent Banking | Stablecoin Settlement |
|---|---|---|
| Settlement window | 1–5 business days, banking-hour bound | Minutes, 24/7/365 |
| Intermediary chain | 2–5 correspondent banks per leg | Single custodial issuer |
| Release trigger | Manual confirmation, document review | Signed on-chain or oracle event |
| Cost structure | Cumulative correspondent fees | Fixed network + custody fee |
| Regulated payroll / domestic payout | Purpose-built, well understood | Not the right tool |
A contract that knows exactly what state it's in
Every escrow is a formal state machine, not a status field a person edits by hand. Strict transition guards mean funds cannot move until the specific condition for that transition (a signature, a piece of evidence, a bilateral ratification) is actually satisfied. Six states, each with its own authorized signer and its own exit conditions.
Terms agreed by all three parties, asset not yet deposited.
Asset locked on-chain by the depositor, awaiting issuer activation.
Escrow is live; milestones are being monitored against incoming evidence.
Either counterparty can raise a dispute from Active; adjudication begins.
Mediator has proposed a settlement; both parties must ratify or it reverts to Disputed.
Terms are satisfied or a settlement is ratified; awaiting final disbursement by the issuer.
Four things engineered into the ledger, not bolted on after
Each of these is a property of the contract itself, enforced by the state machine and the network it runs on, not by a policy document sitting next to the software.
Finance
Settlement runs on standardized, interoperable token mechanics rather than a custom ledger entry, so it can plug into real institutional stablecoin issuance.
- —Native CIP-0056 support for interoperability with major stablecoin issuers
- —Assets are cryptographically locked while a contract is Active, preventing double-spend
- —Final settlement transfers execute through standardized token choices, not bespoke code
- —Terms and milestones can be negotiated in a zero-fee draft layer before anything touches the ledger
Governance
Authority is distributed by design. No single signer, including Data Cloud, can move a contract through its lifecycle alone.
- —Every material transition requires co-signature from depositor, beneficiary, and issuer
- —Each participant runs its own Canton node, so no party depends on another's infrastructure
- —Mediator escalation on dispute, binding arbitration only once mediation is exhausted
- —Infrastructure itself is tiered, with foundation, workload, and identity separately governed
- —Fund release can require an n-of-m threshold of independent custody approvers, enforced natively by the ledger's own multi-party signatory model, with no external signing infrastructure to operate or trust
Integrity
The state machine's guards are only as trustworthy as the signatures and infrastructure behind them, so both are held to a hardware standard.
- —Settlement-triggering signatures are proofed through hardware-backed KMS keys, not software keys
- —Continuous health diagnostics across database, ledger, and oracle layers, not a single uptime check
- —Distributed tracing on every request, so a stalled milestone can be diagnosed, not just noticed
- —Transition guards are enforced at the contract level; a client bug can't release funds early
- —Reserve backing is attested on-chain and countersigned by an independent auditor party, not just claimed by the issuer
Privacy
Institutions on a shared network still need their deal terms hidden from every other participant on that network, competitors included.
- —Contract terms, counterparty identity, and amounts are visible only to that agreement's signers
- —Each participant's private contract data lives only on their own node, zero-trust isolation by default
- —Evidence documents sit in private storage with no public access; access requires a time-limited signed link
- —All document blobs are encrypted at rest with hardware-backed keys
A shipment crossing the 12 nautical mile territorial waters boundaryreleases an agreed partial percentage the moment a signed vessel-position feed confirms the crossing. Filing entry with customs releases a further tranche. Customs clearance releases the remainder. Each step is verified independently, each disputable independently, with no party waiting on a bank's confirmation queue to find out where the money stands.
Two ways a contract can clear
The custody line is Tripart's release mechanism, the sequence that actually moves funds out of escrow. Every deal picks one mode at signing. It doesn't change mid-contract, so neither side is ever surprised by how release behaves partway through.
Each milestone releases on its own
The default mode. A construction draw, an earnout tranche, or a customs-boundary crossing releases its own portion the moment its evidence clears, independent of every other milestone in the contract, and independently disputable.
Nothing releases until everything clears
Every milestone in the contract must reach verified before any funds move, then the full balance releases in one action. Suited to deals where a partial release would leave either side exposed if the remaining conditions never land.
Payment milestones clear on signed events, not a phone call with human document processing
Every stagegate in the custody line needs evidence that a real-world condition happened, such as a vessel crossed a boundary, a customs authority cleared a shipment. Trusted event servicing is how that evidence reaches the contract: cryptographically, durably, and without a person in the loop deciding whether to believe it.
Each event source (an AIS feed, a licensed customs broker, a notarization service) is pre-registered against its public key before any signal from it is trusted. Nothing is trusted by default.
Every incoming signal is checked against that registered key before it touches durable storage. An unsigned or misattributed signal is rejected outright, never journaled.
A verified signal is durably recorded before the ledger is ever touched, so a network blip or process restart can't silently drop evidence. Replay-protected by design: the same signal can't clear a milestone twice.
The matching milestone verifies against the ledger asynchronously, retried automatically until it lands. Every attempt, success or failure, stays on the record: auditable, replayable, never a black box.
What's next
Coming soonThe next releases layer AI assistance onto contract authoring and evidence review. In every case below, the AI drafts, translates, flags, or recommends; a party still signs.
Draft a contract from a brief
Describe the deal in plain language; get a structured draft (parties, milestones, evidence types) ready for review before anyone signs.
Transfer or extend an existing contract
Reuse a prior deal's structure for a new counterparty, or propose an extension to a live contract, routed through the same ratification every hand-drafted change requires.
Legal translation
Counterparty-facing translations of contract terms, always labeled against the governing original, never a second source of truth.
Change detection
Upload a revised shipping agreement or purchase order; see exactly what changed against the terms on record before proposing an amendment.
Mediation advisor
A dispute-evidence summary and rationale, surfaced to the mediator or arbitrator alongside the underlying documents, never a substitute for their decision.