Securities Trading

Atomic DvP (On-Chain)

Simultaneous delivery of security token and payment token in a single atomic transaction.

Vendors

Base · Ethereum · ERC-3643

Compliance Center

Simultaneous delivery and payment at Transport + Authorization

securities dvp atomic erc-3643 settlement

S2 — Atomic DvP settlement · Rails: securities · Protocols: Atomic DvP, ERC-3643, ISDA CDM, FIX, ISO 20022 sese.023 · Origin: United States — Federal
CTR (USD 10,000+)TRAVEL-RULE (USD 3,000+)ENHANCED-DUE-DILIGENCE (USD 50,000+)

L5 APPLICATIONWallet UX, consent, policy engineBank customer channel / issuer app

L4 ACCOUNTBalances, addresses, signing keysCore banking ledger / DDA

Step 1 · Seller Custody — Tokenized Security PositionPolicy-EnforcedBlockchain-Native

The seller's DTC-held position on settlement date minus one — securities are reconciled in the custodian's books, available for delivery against confirmed payment, and the seller's broker is waiting for the street-side match.

The seller's custodial account on Base holds the tokenized security — typically an ERC-3643 permissioned token issued by a transfer agent (Securitize, Figure Markets, Tokeny) that maintains an on-chain identity registry. L4 Account and L5 Application are lit, both above the enforcement line — the seller's identity, the custodian's internal controls, and the transfer agent's record of beneficial ownership are all policy-enforced bank-grade controls, not on-chain code. The position is reconciled to the transfer agent's authoritative book; tokenization does not eliminate the transfer agent's SEC-registered role, it relocates the record from a legacy DTC subledger to a public chain while preserving the transfer agent as the legal owner-of-record. Builder: call `isVerified(walletAddress)` on the ERC-3643 identity registry before displaying the position in the seller's UI — a token held by an address that has fallen off the whitelist (expired attestation, revoked qualification) should not be tradable. Use Fireblocks, Anchorage, or Copper as the institutional-grade custodian pattern; for self-custody by the beneficial owner, layer a qualified-custodian wrapper (Anchorage Trust, Coinbase Custody Trust) to satisfy SEC Rule 17f-1. Compliance officer: the seller's identity posture satisfies C1 (verified institutional investor — QIB, accredited investor, or equivalent), the custodian's license posture satisfies C5 (trust charter, SEC transfer-agent registration under §17A(c)), and recordkeeping obligations under C11 anchor to the custodian's books plus the on-chain position. GENIUS §9 (custody & recordkeeping) applies where the custodian is also a stablecoin custodian on the cash leg. Honesty marker: 'tokenized security' as of April 2026 is narrowly defined — private securities under Reg D/144A and some registered funds have tokenized analogues, but publicly-traded equities on NYSE/NASDAQ remain DTC-settled; this path describes the private-market and alternative-asset end of the atomic DvP story, not the public-equity end.

Active Compliance Checkpoints

C2 OFAC SDN/SSI list screening — OFAC 50 USC § 1702 (United States — Federal) · GENIUS §6

⚠ ENHANCED-DUE-DILIGENCE triggered at USD 50,000 — 31 CFR § 1010.312 — Enhanced Due Diligence (United States — Federal)

Counterparty: Seller's qualified custodian · transfer agent (Securitize class)
Latency: Instant · position confirmed on custodian's book
Finality: N/A — trade not yet matched or committed
Vendors: Coinbase Smart Wallet · ERC-4337 Smart Account · Coinbase Paymaster

L3 EXECUTIONSmart contracts, swap / bridge logicClearing & matching engine

◆ Enforcement Line — code-enforced below, policy-enforced above

Step 2 · Pre-Trade Eligibility — ERC-3643 Registry + Rule 144ACode-EnforcedBlockchain-Native

Reg NMS / MiFID II pre-trade eligibility plus the Rule 144A QIB check — both counterparties must be eligible to hold this security class, and for private placements the 144A QIB qualification is code-enforced before any match is accepted.

Before the DvP can bind, both counterparties must clear the ERC-3643 identity-registry check: QIB status (for 144A offerings), accredited investor status (for Reg D), professional-client status (for EU MiFID II Article 24 private placements), or retail-suitable status for registered funds. The registry is queried per-transfer by the security token's `compliance` module, which layers ISIN-specific rules (transfer windows, lock-up periods, jurisdiction restrictions — e.g., no US persons for Reg S tranches) on top of the identity check. Market-abuse surveillance (C13) runs in parallel: the venue's matching engine checks for wash trades, layering, and spoofing patterns against MiFID II Article 14 and SEC Rule 10b-5 typologies. L3 Execution lit and code-enforced: a failed eligibility check reverts the trade-match instruction. Builder: the ERC-3643 ONCHAINID resolver returns the buyer and seller's claim set; filter trades client-side to only counterparties who pass the registry before submitting to the venue's order book, and expect a second on-chain check at match time to close the front-run window. For FIX-integrated venues, the compliance module exposes a pre-trade `ComplianceCheck` message that mirrors the on-chain logic so that the trading system can decline ineligible orders upstream of the match. Compliance officer: satisfies C1 (identity claim validity), C5 (licensed-intermediary gate — only registered broker-dealers or ATSs can facilitate a match), C13 (market-integrity pre-trade), and C15 (consumer-protection where retail eligibility is involved). SEC Rule 15c2-12 (disclosure on municipal securities) and Rule 15c3-5 (market-access risk controls, commonly 'Reg SCI' environment) apply on the intermediary side. For EU-listed tokens, MiCA Article 88 (market-abuse obligations on CASPs) applies directly to the venue. Honesty marker: ERC-3643 is the industry-consensus permissioned-token standard, but adoption is uneven — many tokenized securities still use ad-hoc allowlist contracts or ERC-1404 variants without a shared identity registry, and cross-issuer interoperability of claims is a known open problem.

Active Compliance Checkpoints

C2 OFAC SDN/SSI list screening — OFAC 50 USC § 1702 (United States — Federal) · GENIUS §6

Counterparty: ERC-3643 identity registry · venue compliance engine · market-abuse surveillance
Latency: <1s · on-chain registry read + FIX-layer compliance check
Finality: Pre-condition gate — blocks match if either leg is ineligible
Vendors: Uniswap v4 · Chainalysis OFAC Oracle

L4 ACCOUNTBalances, addresses, signing keysCore banking ledger / DDA

L3 EXECUTIONSmart contracts, swap / bridge logicClearing & matching engine

◆ Enforcement Line — code-enforced below, policy-enforced above

Step 3 · Trade Match + ISDA CDM RepresentationCode-EnforcedBlockchain-Native

The street-side match on the T+1 morning in traditional cash equities — both sides' tickets are tied out, the trade is affirmed, and the execution message is formatted into a settlement instruction ready for DTCC's CNS or the Fed's Securities Service — except here, the match IS the commitment because settlement binds atomically.

The venue (an ATS, a DLT market, or a bilaterally-agreed RFQ platform) matches the seller's offer with the buyer's bid and produces a signed trade affirmation. The trade is represented in ISDA CDM (Common Domain Model) canonical form — the industry-standard machine-readable representation of the economic terms — and simultaneously encoded in the venue's FIX (Financial Information eXchange) execution report. For settlement instruction the match is serialized into ISO 20022 sese.023 (MT541/MT543 equivalent) and, for on-chain atomic settlement, hashed into the DvP settlement contract's `TradeTicket` struct. L3 Execution and L4 Account are lit — the match-and-commit logic runs at execution layer, and both sides' account contracts confirm the committed balances. The CDM representation is the canonical cross-reference that lets this trade be reported to regulators (SEC CAT, EU ARM) and reconciled by the buy-side's post-trade system (Traiana, Omgeo/CTM, on-chain equivalents) without the usual FpML-vs-FIX reconciliation headaches. Builder: emit the CDM-hashed trade to both the DvP contract and an off-chain CDM validator before firing atomic settlement; this guarantees the same trade exists in exactly one canonical form across the affirmation, the settlement, and the downstream regulatory report. For DLT-native venues (Marketnode, Taurus TXG, R3 Corda-based markets), the CDM representation often lives in the native DLT object model; the on-chain hash is the cryptographic anchor back to the canonical representation. Compliance officer: satisfies C10 (oracle / market-data integrity — the trade's economic terms are reported consistently across every downstream system), C11 (recordkeeping — the CDM-hashed trade is the authoritative record), and C13 (market-integrity reporting — regulators receive a single canonical trade representation). SEC Consolidated Audit Trail (CAT) Rule 613 requires reporting within narrow windows; ISDA CDM is the emerging lingua franca for multi-jurisdiction CAT-equivalent reporting. Honesty marker: CDM adoption in cash-securities workflows is still early as of April 2026 — CDM ships production-stable for derivatives and repo under ISDA, but the equity and structured-product modules are works in progress; expect to encounter FIX/FpML/CDM reconciliation during the transition.

Active Compliance Checkpoints

C2 OFAC SDN/SSI list screening — OFAC 50 USC § 1702 (United States — Federal) · GENIUS §6

Counterparty: DLT venue · CDM validator · settlement-instruction builder
Latency: <1s · match to settlement-instruction hash
Finality: Pre-settlement commit — trade is binding but not yet atomically bound
Vendors: Uniswap v4 · Chainalysis OFAC Oracle · ERC-4337 Smart Account

L4 ACCOUNTBalances, addresses, signing keysCore banking ledger / DDA

L3 EXECUTIONSmart contracts, swap / bridge logicClearing & matching engine

L2 CONSENSUSValidator ordering, block productionRTGS settlement engine

◆ Enforcement Line — code-enforced below, policy-enforced above

Step 4 · Atomic Bind — Security Leg ↔ USDC Cash LegCode-EnforcedBlockchain-Native

DTCC's Continuous Net Settlement coupled with the Fed's Wholesale Payment Rail — except the security and the cash leg bind in a single atomic block transition, eliminating the settlement-risk window (Herstatt risk in FX, CNS-to-Fedwire timing gap in US equities) that has defined post-trade operations for fifty years.

The DvP contract executes the atomic bind: security token transfers from seller's custody to buyer's custody and USDC transfers from buyer to seller in the same Base block. Either both transfers succeed or neither does — the legs are bound by the EVM's atomicity guarantee, not by the good intentions of a CSD's timing window. Settlement risk is eliminated by code: the buyer can never be left holding cash with no security, and the seller can never be left holding a security with no cash. L4 Account (balance updates on both sides), L3 Execution (atomic swap logic), and L2 Consensus (block-level atomic ordering) are all lit — every layer at or below the enforcement line participates. Finality on Base is strong at one block (~2s) for institutional amounts under SEC Rule 15c6-1 T+1 thresholds; for sub-second finality needs, pair with Circle's Fast Finality Service or settle on a high-frequency venue (Lit Protocol, Lighter). Builder: the DvP contract should receive the ISDA CDM-hashed trade ticket from Step 3 and verify that the hash matches the buyer/seller/amount/security triple before executing the atomic bind — this prevents ticket-substitution attacks. Emit a `DvPSettled(cdmHash, securityId, buyer, seller, amount, blockNum)` event; downstream regulatory reporting and post-trade reconciliation pipelines index by cdmHash. Compliance officer: satisfies C6 (reserve-backing on the USDC cash leg — Circle's 1:1 reserves under GENIUS §4(a) apply to the in-transit amount), C7 (Travel Rule on cross-border corridors if the transfer crosses $3,000 and either counterparty is in a non-US jurisdiction; packaged via IVMS101 alongside the CDM trade ticket), C13 (market-integrity recordkeeping of the atomic settlement event), and C16 (programmable-compliance enforcement — the transfer-restriction module re-fires at settlement). GENIUS §6 (AML/BSA) sanctions screening on the buyer's and seller's addresses is a pre-condition for the atomic call — wire Chainalysis OFAC oracle as a revert source. MiCA Article 68 (originator information) and EU T2S settlement-standard compatibility apply for EU-jurisdictional legs. Honesty marker: 'atomic DvP' in production as of April 2026 is real on permissioned rails (Fnality USC, JPMorgan Onyx/Kinexys, Project Meridian at the BIS, Clearstream D7) and on public chains for private securities (Securitize + Base, Figure Markets on Provenance); atomic DvP for US public equities on the DTCC perimeter is still in pilot (Project Ion) and has not replaced the existing CNS/Fedwire settlement window.

⚠ TRAVEL-RULE triggered at USD 3,000 — 31 CFR § 1010.410(f) — Funds Transfer Recordkeeping (United States — Federal)

Counterparty: DvP settlement contract on Base · Chainalysis OFAC oracle
Latency: ~2s · single Base block
Finality: T+0 · atomic and irrevocable, both legs simultaneous
Vendors: Uniswap v4 · Coinbase Sequencer · Chainalysis OFAC Oracle · ERC-4337 Smart Account

L5 APPLICATIONWallet UX, consent, policy engineBank customer channel / issuer app

L4 ACCOUNTBalances, addresses, signing keysCore banking ledger / DDA

Step 5 · Post-Trade Recordkeeping — Beneficial-Ownership UpdatePolicy-EnforcedBlockchain-Native

The post-trade recordkeeping event at DTC and the beneficial-ownership reconciliation at the transfer agent — the buyer's custodian books the long position, the seller's books the short, and the transfer agent's shareholder ledger is updated for the next record date.

Both custodians book the post-trade state: buyer's wallet now holds the tokenized security; seller's wallet holds the USDC proceeds. The transfer agent's on-chain registry updates the beneficial-ownership record — the tokenized security's ownership ledger is the single authoritative record for corporate actions, voting, and tax reporting, replacing the old DTC/Cede & Co. nominee structure with direct named-beneficial-owner representation. L4 Account and L5 Application are lit on both sides, above the enforcement line — the post-trade obligations are policy-enforced by the custodians' internal controls and the transfer agent's registered role under SEC Rule 17Ad. Builder: the transfer agent's registry-update function should be callable only by the DvP contract via a permissioned role; this closes the attack where a compromised wallet tries to fake ownership without passing the atomic DvP. Cache the settled position in your custodian's internal books with the DvP block number as the reconciliation key for the overnight tie-out against the on-chain registry. Compliance officer: C11 (recordkeeping — the DvP tx hash + CDM hash + transfer-agent registry update together form the authoritative trade record with a retention floor of 6 years under SEC Rule 17a-4, 7 years for registered reps, longer for specific jurisdictions) and C12 (audit-grade attestation — the on-chain settlement is independently verifiable by any third party without custodian cooperation). Tax reporting obligations attach: IRS §6045 cost-basis reporting for US persons, EU DAC7/DAC8 reporting for EU-based intermediaries. For private placements under Reg D / 144A, Rule 502(d) restrictions on resale for one year (or the 144 holding period) must re-activate in the registry's transfer-restriction module at this step. Honesty marker: direct-beneficial-ownership representation is the long-term promise of tokenized securities but requires parallel upgrades to corporate-actions infrastructure (DTCC CA Web, proxy voting services) that are not yet fully in place — expect hybrid representation (on-chain beneficial owner + traditional voting agent) through 2026–2028.

Active Compliance Checkpoints

C2 OFAC SDN/SSI list screening — OFAC 50 USC § 1702 (United States — Federal) · GENIUS §6

C7 Notabene IVMS101 or Chainalysis Connect — FATF Rec. 16; 31 CFR 1010.410(f) (United States — Federal) · GENIUS §7, §8

⚠ CTR triggered at USD 10,000 — 31 CFR § 1010.311 — Currency Transaction Report (United States — Federal)

Counterparty: Seller + buyer custodians · transfer agent registry
Latency: Instant on DvP settlement confirmation
Finality: Final · beneficial ownership recorded
Vendors: Coinbase Smart Wallet · ERC-4337 Smart Account · Coinbase Paymaster

L5 APPLICATIONWallet UX, consent, policy engineBank customer channel / issuer app

Step 6 · Reconciliation & Regulatory ReportingPolicy-EnforcedBlockchain-Native

End-of-day reconciliation at a sell-side broker-dealer — the trade blotter is tied out to the street-side confirms, regulatory reports are generated (CAT for SEC, EMIR for ESMA, CPMI-IOSCO PFMI reporting for the CSD), and the audit trail is archived for the regulator's next exam.

The broker-dealer and both custodians reconcile the settled trade against their internal books, the CDM-hashed trade ticket from Step 3, and the on-chain DvP event from Step 4. Regulatory reporting fires: SEC CAT Rule 613 (within narrow windows for the execution-report event), FINRA TRACE / ORF for the post-trade public tape (for registered securities), EU ESMA ARM reporting under MiFIR Article 26 for EU-jurisdictional legs. For tokenized securities traded on a DLT market, CPMI-IOSCO Principles for Financial Market Infrastructures §§17–19 (recordkeeping, operational-risk, CSD-specific obligations) apply to the operator. The audit bundle — DvP tx hash + CDM hash + FIX execution report + ISO 20022 sese.023 + transfer-agent registry update — is archived to durable WORM-compliant storage with retention of 6 years (SEC 17a-4), 7 years (FINRA), 10 years (EU MiFID II). L5 Application is lit — finality lives entirely in the policy layer because the regulatory record of settlement is the broker-dealer's books plus the on-chain evidence, with the broker-dealer's SEC/FINRA registration as the accountable party. Builder: for the CAT report, use the CDM hash from Step 3 as the stable cross-reference key; for EMIR/ARM reports on OTC derivatives legs (where S2 overlaps with derivatives settlement), the ISDA CDM representation is reportable directly under ESMA's Technical Standards RTS 22. Store the full audit bundle in R2 or S3-Glacier under a retention policy that outlives the record-date of the underlying security. Compliance officer: C11 (recordkeeping with multi-jurisdictional retention floors), C12 (audit/attestation — the DvP event is independently verifiable by a third party without custodian cooperation, which strengthens the audit posture vs. traditional trade confirmations), and C13 (market-integrity regulatory reporting via CAT, TRACE, ARM, and equivalent). SEC Rule 17Ad-22 (Covered Clearing Agency standards) applies to any DLT-native CSD operating this path. Honesty marker: regulator tolerance for DLT-native recordkeeping as the primary audit source is still jurisdiction-dependent as of April 2026 — the SEC has accepted DLT records for specific pilots (Prometheum ATS, INX, Figure's ATS) but has not issued a general determination that an on-chain record satisfies Rule 17a-4 standalone; most broker-dealers still maintain parallel traditional records, so C11 compliance is effectively belt-and-suspenders.

Active Compliance Checkpoints

C11 SAR/CTR filing via BSA E-Filing — 31 CFR § 1010.320 (United States — Federal) · GENIUS §9

Counterparty: Broker-dealer back office · CSD operator · regulator reporting endpoints
Latency: T+0 for CAT/ARM reports; EOD batch for FINRA/ESMA
Finality: Final · full audit bundle archived
Vendors: ERC-4337 Smart Account · Coinbase Smart Wallet · Coinbase Paymaster

Resolved 6 steps across 1 chain(s). 3 threshold(s) triggered. Frameworks: Bank Secrecy Act, GENIUS Act, OFAC Sanctions Program, FATF Recommendation 16 (Travel Rule), Common Reporting Standard / FATCA.

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

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

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)

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
    });
  },
};