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 → Funded → Active → Disputed ⇄ Proposed → 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

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
• —Proof-of-reserve: reserve backing is attested on-chain and countersigned by an independent auditor party, 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

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, with multi-modal transit (air, rail, truck) as an active area of extension beyond the initial maritime model
• —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
• —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

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