Cross-Border Payments
Cross-Border Payments is in development. This page describes the planned architecture and flows. Details may change before launch.
Business Context
Cross-border payments are among the most costly and slow transactions in institutional finance — despite being one of the most frequent. A corporate treasurer moving USD to a European subsidiary, a fund manager repatriating proceeds from a foreign market, or a trade finance desk settling a letter of credit all face the same structural problem: the correspondent banking network.
SWIFT messaging coordinates the instruction, but settlement happens through a chain of correspondent banks, each maintaining nostro/vostro accounts with the next in the chain. A payment from a bank in Singapore to a bank in Brazil may route through two, three, or four intermediaries. Each hop adds time — typically 1-5 business days end-to-end. Each hop adds cost — correspondent fees, FX spread, lifting fees. And each hop adds opacity: once the wire is sent, the payer has limited visibility into where the payment is in the chain until it arrives (or fails to arrive).
FX exposure is a compounding problem. The payment is priced in one currency, converted at one or more points in the chain, and arrives in another currency — with the FX rate locked at different times depending on which correspondent holds the position. Hedge accounting becomes difficult when the settlement timestamp is uncertain.
Regulatory friction is multilateral: the payer's jurisdiction requires AML screening, the payee's jurisdiction requires its own KYC, and the correspondent jurisdictions may each impose their own requirements. A transaction that is compliant end-to-end on paper can fail to settle because a correspondent's screening system flags an intermediate step.
How Cocoon Addresses This
Cocoon replaces the correspondent chain with a direct cross-chain DBC settlement. The payer creates DBC cash on their source chain. The payee receives DBC on the destination chain. The transfer is atomic: neither side settles unless both sides settle. FX is priced by an on-chain oracle at the moment of settlement, eliminating the rate uncertainty that comes from multi-hop processing.
Both sides must hold valid OnchainID claims recognized by the other jurisdiction's compliance policy. There is no correspondent bank in the middle. There is no settlement window. The payment either completes atomically or reverts with no funds in transit.
DBC's RingCT confidentiality means the payment amount is not visible to third parties on either chain — only the payer, the payee, and authorized compliance counterparties can see the value. This preserves commercial confidentiality while the OnchainID layer provides the KYC/AML trail that regulators require.
Payment Flow
Initiation
The payer locks their DBC cash in a payment escrow contract on the source chain, specifying:
The payee's OnchainID address (which may be on a different Cocoon chain or a connected network).
The destination chain identifier.
The currency pair (if cross-currency).
An optional settlement deadline — if the payment does not complete by the deadline, the escrowed DBC is returned.
The source chain verifies the payer's OnchainID claims before accepting the lock. A payer without current KYC/AML claims or whose jurisdiction is not on the destination chain's permitted counterparty list will have the initiation rejected at this stage.
Cross-Chain Relay
The cross-chain bridge picks up the payment intent and relays it to the destination chain. The bridge is a verifiable relay — it does not hold funds. Its role is to deliver a signed message attesting that the source chain escrow is locked and finalized.
The bridge queries the FX oracle to obtain the current rate between the source and destination currencies. The oracle provides a signed rate with a timestamp and a validity window. If the rate expires before settlement completes, the bridge re-queries; if no valid rate is available, the payment reverts and the escrow is returned.
Destination Compliance Check
The destination chain verifies the payee's OnchainID claims against its own compliance policy:
The payee must hold a current KYC/AML claim from an issuer recognized by the destination chain's registry.
The payee's jurisdiction must be on the source chain's permitted outbound list and the destination chain's permitted inbound list.
Any per-transaction limits are checked against the FX-converted amount.
If the payee fails the compliance check, the payment intent is rejected on the destination chain, the bridge relays the rejection back to the source chain, and the escrowed DBC is returned to the payer. The entire process leaves no funds in transit.
Atomic Settlement
When both sides are verified, the bridge triggers atomic settlement:
The destination chain mints DBC cash to the payee at the FX-converted amount.
The source chain burns the escrowed DBC (or transfers it to the protocol's FX liquidity pool, depending on the FX mechanism in use).
The bridge emits a settlement proof anchoring both state transitions.
The atomicity guarantee means: either both steps complete or neither does. There is no state where the source escrow is burned but the destination DBC has not been minted, nor vice versa.
Settlement Deadline and Reversion
Every cross-border payment has a settlement deadline. If the destination chain compliance check, the FX rate, or the bridge relay does not complete within that window:
The bridge marks the payment intent as expired.
The source chain escrow releases the DBC back to the payer.
No funds are lost; no partial settlement occurs.
This eliminates the class of failures in the correspondent banking network where a wire is "lost" or held at an intermediate step with no clear resolution path.
FX Oracle
The FX oracle publishes signed exchange rates on-chain for currency pairs supported by the payments product. Key design properties:
Credentialed publication. Rates are published by authorized FX rate providers — regulated FX brokers or prime brokers — who sign rate updates with their registered keys. The oracle contract verifies signatures before accepting a rate.
Staleness enforcement. Each rate has a validity window. Payments will not execute against a rate older than the configured maximum staleness — typically a few minutes for actively traded pairs.
Slippage protection. The payer can specify a maximum acceptable FX rate deviation from the rate observed at initiation. If the rate at settlement time has moved beyond that tolerance, the payment reverts.
Audit trail. Every rate publication is logged on-chain with the publisher identity, the rate, and the timestamp. This provides a complete audit trail of what rate was used for any given payment.
Dual-Jurisdiction Compliance
Cross-border payments are subject to AML screening in both the originating and receiving jurisdictions. Cocoon's OnchainID architecture handles this natively:
Payer KYC/AML
Source chain at initiation
Confirms payer identity and AML clearance in originating jurisdiction
Payer outbound eligibility
Source chain
Confirms payer is permitted to make outbound transfers to the destination jurisdiction
Payee KYC/AML
Destination chain at relay
Confirms payee identity and AML clearance in receiving jurisdiction
Payee inbound eligibility
Destination chain
Confirms payee is permitted to receive inbound transfers from the source jurisdiction
Transaction screening
Both chains
Amount and counterparty screened against sanctions lists encoded in compliance modules
Claims are issued by authorized issuers in each jurisdiction. The source chain's compliance policy specifies which destination-jurisdiction claim issuers it recognizes as valid (and vice versa), establishing the bilateral trust relationship between jurisdictions at the protocol level rather than through bilateral correspondent agreements.
Confidentiality and Regulatory Visibility
DBC's RingCT confidentiality hides payment amounts from third-party observers on both chains. This is intentional: in institutional payments, the size of a cross-border transfer is commercially sensitive information.
Regulatory visibility is provided through selective disclosure. The payer's and payee's OnchainID contracts can issue view keys to authorized regulators, allowing them to decrypt the DBC amounts associated with specific payments. This mechanism:
Does not require publishing amounts publicly.
Does not require a trusted intermediary to hold the data.
Is auditable — the issuance of a view key is itself an on-chain event.
Is scoped — a view key for one payment does not reveal any other payment.
ZK State Verification
Cross-border payment flows generate QMTree proofs anchored on Ethereum, providing:
A verifiable record of payment completion that can be referenced by trade finance contracts, escrow releases, or downstream settlement systems without replaying the full cross-chain flow.
Regulatory reporting attestations — a regulator can verify that a payment was AML-screened and settled without requiring access to the full transaction graph.
Counterparty confirmation for treasury teams who need proof of receipt for accounting purposes without relying on a counterparty's self-attestation.
Last updated