Atomicity · the DvP camera angle

Both legs, or neither.

What binds delivery and payment into a single atomic step.

Traditional delivery-versus-payment takes T+1 because cash and securities move on separate rails — Fedwire, DTC, CHIPS, DTCC batch netting — and reconcile at end of day. On-chain atomic DvP collapses the window to a single transaction: Circle USDC in one leg, an ERC-3643 permissioned token in the other, bound by a smart-contract conditional release that either commits both or reverts both. Named vendors of record on this page: Stripe / Bridge, Circle (USDC, Arc, CPN), Chainlink CCIP, Fireblocks, LayerZero, Coinbase Base V1, Catena Labs ACK-Pay.

T+0

Settlement finality

Chain POCs

Counterparty risk window

Signature Diagram · Atomic Swap

The two legs, bound.

Delivery leg above (ERC-3643 security token, seller → buyer). Payment leg below (Circle USDC, buyer → seller). A dashed cyan channel joins them through the ATOMIC BIND contract — the single boolean that makes the swap both-or-neither. Every checkpoint is a named gate, monitor, or obligation with the vendor of record and the exact failure mode that would abort the swap. Hover any shape.

⬡ Gate · blocks if it fails● Monitor · concurrent observation◆ Obligation · post-settlement reportSolid = code-enforced · Dashed = policy-enforced

Read the binding — the dashed channel between the legs is the smart-contract conditional release. If the delivery leg reverts at any checkpoint, the payment leg reverts in the same transaction. Atomicity is not an end-of-day reconciliation; it is a revert semantic. This is what "T+0" mechanically means.

Journey Map

Eight stages. One atomic settlement.

Every DvP transaction mapped through the STP 8-stage sequence. Gates accumulate before the state change at S6. Obligations radiate after. Hover any checkpoint to see the protocol, actor, and enforcement type.

Atomic DvP — Settlement Journey MapSTP 8-stage sequence · Gates accumulate before S6 state change · Obligations radiate afterAGENTIC ROUTEGateMonitorObligationSCREENING ZONESTATE TRANSITION← GATES ACCUMULATEOBLIGATIONS RADIATE →S1IntentBuyer AgentS2IdentityACK-ID / World IDS3DiscoveryMatching EngineS4ReservesEscrow ContractS5TransferCCTP / BridgeS6ExecutionSettlement EngineS7TokenZK Proof SystemS8ReportingCompliance Layer

The Problem

T+1 is a feature of the plumbing, not the physics.

In traditional finance, delivery-versus-payment means the securities leg and the cash leg settle together — but "together" means within a one-business-day window via DTCC batch netting. That window creates counterparty risk, fails-to-deliver, margin requirements, and $2.1 trillion in daily settlement exposure. On-chain atomic DvP eliminates the window. Both legs execute in a single transaction — if either fails, both revert. No netting. No CSD. No T+1.

The Window

T+1 = 24 hours of counterparty risk

Between trade execution and settlement, either party can default. DTCC mitigates this with margin and netting, but the risk exists until final settlement. SEC moved from T+2 to T+1 in May 2024. On-chain atomic DvP moves to T+0.

The Separation

Cash and securities move on different rails

Fedwire/CHIPS for USD. DTC book-entry for securities. Two separate systems that must reconcile. Fails-to-deliver cost $74 billion in 2024. Atomic DvP unifies both legs in one transaction on one chain.

The Proof

ZK finality replaces optimistic trust

Base's V1 fork moves from optimistic proofs (7-day challenge window) to TEE/ZK proofs (instant finality). Arc uses Malachite BFT for sub-second finality. Faster finality is the mechanical prerequisite for atomic DvP.

Dimension	Traditional (DTCC T+1)	Atomic DvP (On-Chain)
Settlement window	1 business day	Same block (~2s)
Counterparty risk	24 hours of exposure	Zero — atomic revert
Cash/security coupling	Separate systems (Fedwire + DTC)	Single transaction
Finality mechanism	Batch netting (end-of-day)	Cryptographic proof (ZK/BFT)
Fails-to-deliver	$74B/year (2024)	Impossible — both or neither
Intermediaries	NSCC, DTC, custodian banks	Smart contract + ZK proof
Audit trail	Reconciliation reports (days)	On-chain + regulatory view keys
KYC/AML enforcement	Pre-trade check by broker (policy-enforced)	On-chain gate (code-enforced) · zkKYC
Travel rule	SWIFT MT messages between banks	ZK proof of counterparty data · no PII on-chain
Post-trade reporting	Manual CAT/OATS filing (next day)	Obligation fires at settlement · regulatory view key
Compliance enforcement model	Policy-enforced (depends on intermediaries)	Code-enforced (cannot be bypassed)

Sources: DTCC — T+1 Settlement Transition · Base — V1 Roadmap · Fortune — Zero/LayerZero

Stack Diagram

Three architectures. Five layers deep.

Build LLC section-cut comparison of DvP settlement infrastructure across Base L2 (Coinbase), Arc L1 (Circle), and traditional T+1 (DTCC). Solid borders mean code-enforced — the mechanism cannot be bypassed. Dashed borders mean policy-enforced — compliance depends on an external actor. Notice how traditional T+1 is almost entirely policy-enforced.

COMPLIANCE DEPTH →Atomic DvP — Settlement Stack ComparisonBuild LLC section-cut style · 5 architectural layers · Code-enforced vs. policy-enforcedA-301 · SECTION CUTAtomicDVP · StablecoinAtlasL5ApplicationL4ProtocolL3ExecutionL2ConsensusL1NetworkSTATE TRANSITION · L3 EXECUTIONBase L2 (Coinbase)TEE/ZK Hybrid · x402 NativeArc L1 (Circle)Malachite BFT · ConfidentialTraditional T+1 (DTCC)CSD Netting · Paper Trailx402 WorkerERC-6960 AssetConditional EscrowAtomic Swap EngineOP Stack EVMTEE/ZK ProofSequencer → L1Ethereum DACPN InterfaceConfidential TransferCCTP v2 BridgeRegulatory View KeyMalachite BFTAtomic DvP ContractCircle ValidatorsUSDC Native GasBroker PortalTrade ConfirmationNSCC NettingCNS GuaranteeBatch SettlementT+1 WindowDTC Book EntryFedwire / CHIPSLEGENDIdentityDiscoveryReservesTransferExecutionTokenReportingGateMonitorObligationCode-enforced (solid)Policy-enforced (dashed)

Read the borders — Solid = code-enforced (cannot be bypassed). Dashed = policy-enforced (depends on external actor). The T+1 column is almost entirely dashed. Base and Arc are almost entirely solid. This is the compliance-depth argument: atomic DvP doesn't just settle faster — it shifts enforcement from trust to cryptographic proof.

Proof of Concept

Three chains. Three settlement architectures. Running code.

Each POC demonstrates atomic DvP on a different chain with a different buyer signal. Base (Coinbase) uses x402 + conditional escrow. Arc (Circle) uses CCTP bridge + confidential transfers. Catena uses ACK-Pay agent credentials + zkKYC. Click through the settlement sequence and inspect the implementation.

x402 Atomic DvP on Base

Live on Testnet

Conditional micropayment triggers asset delivery in one block

Buyer signal: CoinbaseProtocol: x402 + ERC-6960

Settlement Sequence

Agent sends x402 request

Neutral (S1) · monitor · code

HTTP 402 Payment Required. Header includes asset_id, amount, and DVP condition hash.

latency: 0ms

Identity + AML gate

Identity (T6) · gate · code

Conditional escrow created

Reserves (T2) · gate · code

Asset token minted / transferred

Transfer (T5) · monitor · code

Atomic execution + ZK proof

Execution (T3) · gate · code

Post-trade reporting obligation

Reporting (T7) · obligation · policy

implementation

// x402 Atomic DvP — Cloudflare Worker on Base
export default {
  async fetch(request: Request): Promise<Response> {
    const payment = request.headers.get("X-PAYMENT");
    if (!payment) {
      return new Response(null, {
        status: 402,
        headers: {
          "X-PAYMENT-REQUIRED": JSON.stringify({
            scheme: "exact",
            network: "base",
            asset: "USDC",
            amount: "50.00",
            dvp_condition: keccak256(assetId, buyerAddr),
            escrow: ESCROW_CONTRACT,
            window_blocks: 6,
          }),
        },
      });
    }

    // Verify payment + create conditional escrow
    const escrow = await createDvpEscrow({
      payment: parsePaymentHeader(payment),
      assetId: "ERC6960:0xABC...#42",
      buyer: extractBuyerFromPayment(payment),
      windowBlocks: 6,
    });

    // Mint/transfer asset — escrow releases atomically
    const delivery = await mintAndDeliver(escrow);

    return Response.json({
      status: "settled",
      txHash: delivery.txHash,
      proof: delivery.zkProof,
      settlement: "atomic",   // not T+1
      finality: "zk-tee",     // Base V1 hybrid
    });
  },
};

Reading the shapes — Each step uses the Two-Model System's compliance encoding. Hexagons are gates (pre-conditions that block if they fail). Circles are monitors (concurrent observation). Diamonds are obligations (post-settlement reporting). Filled shapes = code-enforced. Hollow/dashed = policy-enforced. Colors map to compliance domains: blue = Identity, purple = Discovery, amber = Reserves, teal = Transfer, orange = Execution, green = Token, rose = Reporting.

Compliance Architecture

Every checkpoint maps to a regulation.

Atomic DvP isn't just faster settlement — it's a compliance upgrade. Traditional post-trade compliance is policy-enforced: it depends on intermediaries acting correctly. On-chain atomic DvP is code-enforced: compliance gates execute in the same transaction as settlement. The table below maps each compliance domain to the specific regulation it satisfies and the enforcement mechanism.

Domain	Regulation	Traditional Enforcement	Atomic DvP Enforcement	Checkpoint
Identity (T6)	GENIUS Act §4(a)(1) · BSA/AML · MiCA Art. 68	Broker KYC (policy)	zkKYC gate — code-enforced, ZK proof, no PII on-chain	⬢ Gate
Discovery (T4)	FATF Travel Rule · FinCEN §1010.410	SWIFT MT103 between banks (policy)	ZK travel rule — counterparty data proven without revealing	⬢ Gate
Reserves (T2)	GENIUS Act §4(a)(2) · SEC Rule 15c3-3	End-of-day reserve calculation (policy)	On-chain escrow — reserves verified in real-time, code-enforced	⬢ Gate
Transfer (T5)	UCC Article 8 · GENIUS Act §5	DTC book-entry between custodians (policy)	Atomic token transfer — single tx, code-enforced	● Monitor
Execution (T3)	SEC Rule 15c6-1 (T+1) · MiCA Art. 60	Batch netting, end-of-day (policy)	Atomic swap — both legs in one tx, code-enforced, T+0	⬢ Gate
Token (T1)	CPMI-IOSCO PFMI Principle 8 (settlement finality)	Depository confirmation (hours/days)	ZK/BFT finality proof — cryptographic, instant, code-enforced	● Monitor
Reporting (T7)	GENIUS Act §4(a)(3) · CAT/OATS · MiCA Art. 72	Next-day filing to FINRA/SEC (policy)	Obligation fires at settlement — regulatory view key, async	◇ Obligation

Code-enforced vs. policy-enforced — This is the core distinction the Two-Model System makes visible. On the Stack Diagram above, solid borders mean code-enforced (the mechanism cannot be bypassed). Dashed borders mean policy-enforced (compliance depends on an external actor). Traditional T+1 settlement is almost entirely policy-enforced. Atomic DvP shifts the enforcement model from trust to proof. The full compliance checkpoint taxonomy (Gate / Monitor / Obligation shapes, code-vs-policy borders, seven domain colors) is the Atlas Two-Model System — private internal tooling, not a public reference. See Stable402.com for the first public implementation.

Institutional Signals

Who's building atomic settlement infrastructure.

Entity	Initiative	DVP Relevance	Status
Coinbase	Base V1 Hard Fork — TEE/ZK proofs	Instant finality enables atomic DvP on Base. x402 native.	HARD FORK
Circle	Arc L1 + CPN (Circle Payments Network)	Sub-second Malachite BFT. Confidential transfers + regulatory view keys.	2026 MAINNET
Catena Labs	ACK-Pay + ACK-ID agent protocol	Agent-initiated DvP with zkKYC. Delegation chains for autonomous settlement.	SDK BETA
LayerZero / Zero	DTCC + ICE + Citadel Securities consortium	2M TPS ZKP chain. Securities settlement at exchange speed.	FALL 2026
DTCC	DTC Tokenization (Canton Network + ZK)	1.4M securities in custody. Tokenized equities, Treasuries, ETFs.	H2 2026
zkSync	Prividium — 5 US regional banks	Tokenized deposit networks. ZK-rollup with institutional privacy.	PRODUCTION

Sources: Base V1 · Fortune — Zero · Phemex — Prividium