ERC-6123

  • Name: ERC-6123 (Smart Derivative Contract)
  • URL: https://eips.ethereum.org/EIPS/eip-6123
  • Category: deterministic OTC-contract lifecycle standard / bilateral derivative-processing protocol / oracle-callback settlement interface
  • Summary: ERC-6123 is worth cataloging not as just another RWA or derivative token draft, but as a protocol for the life cycle of a bilateral financial contract itself. Its core move is to model an over-the-counter derivative or bond as a deterministic state machine with explicit trade inception, confirmation, cancellation, settlement initiation, oracle-driven valuation callback, transfer completion callback, and termination flows. That makes ERC-6123 analytically useful because it shifts attention away from tokenized-asset representation and toward process automation: who may incept a trade, how counterparties confirm matching terms, when valuation is requested, what oracle computes settlement, how pre-funding and async transfers are checked, and how failure routes into automatic termination.
  • What it does:
    • Separates the contract lifecycle into interfaces for trade handling (ISDCTrade), settlement handling (ISDCSettlement), and asynchronous transfer completion (IAsyncTransferCallback)
    • Standardizes bilateral trade inception, confirmation, cancellation, and mutual-termination request/confirm/cancel flows around explicit tradeId, tradeData, payment, and settlement-data payloads
    • Standardizes settlement triggering through initiateSettlement, oracle-style callback settlement through performSettlement, and post-settlement verification / next-phase transition through afterSettlement
    • Supports asynchronous settlement-token callbacks through afterTransfer, letting external payment rails or async token movements finalize the settlement state machine
    • Treats valuation as potentially external, with oracle- or service-provided settlement amounts and settlement data fed back into the contract
    • Includes a reference single-trade implementation (SDCSingleTrade.sol) that exposes explicit states such as Inactive, Incepted, Confirmed, Valuation, InTransfer, Settled, InTermination, and Terminated
    • Explicitly frames the same lifecycle machinery as reusable for settle-to-market OTC derivatives, collateralized derivatives, defaultable derivatives, and smart bond contracts
  • Key claims:
    • The most important insight is that ERC-6123 is not primarily a token interface. It is a deterministic process interface for bilateral financial contracts, with token transfers acting as one settlement mechanism inside a broader trade-state machine.
    • Relative to ERC-7092, ERC-3475, or ERC-3525, ERC-6123 is much less about how an instrument is represented in holders’ balances and much more about how trade agreement, valuation, settlement, and termination are orchestrated over time.
    • The EIP’s rationale makes oracle dependence a first-class control surface. Settlement values may come from hosted valuation logic and external market data, so practical authority sits not only in the contract but in the pre-agreed valuation model and the callback pathway that supplies settlement amounts.
    • The reference SDCSingleTrade.sol matters because it shows the proposal’s real center of gravity: guards are tied to explicit trade states, pending request hashes bind counterparties to matching trade data, and settlement / termination are treated as managed protocol phases rather than ad hoc admin calls.
    • Another durable insight is the async-settlement pattern. ERC-6123 anticipates payment systems where transfer success may complete later through a callback, making external cash rails or asynchronous settlement tokens part of the standardized lifecycle instead of an implementation detail.
    • The bond application section is useful precisely because it is secondary. ERC-6123 suggests that some fixed-income instruments may be better modeled as deterministic contract processes with issuer-triggered coupon/redemption settlement than as simple balance tokens.
    • ERC-6123 belongs in the corpus because it makes a different lower layer visible: deterministic financial-contract processing, where the key design questions are counterparty admission, valuation-oracle trust, margin or pre-funding checks, settlement-token design, and failure-to-pay termination rules.
  • Whitepaper: The EIP cites earlier Smart Derivative Contract papers, but no standalone whitepaper was directly reviewed in this pass beyond the canonical EIP text and reference-implementation assets collected in ../../whitepapers/erc-6123-primary-sources-2026-05-13.md.
  • Sources:
  • Last reviewed: 2026-05-13 UTC