EIP-6123 - Smart Derivative Contract - frictionless processing of financial derivatives

Smart Derivative Contract

We propose a deterministic decentralized post-trade process protocol for financial derivative contracts - known as Smart Derivative Contract. Counterparty credit risk is removed by construction. This protocol can make use of ERC20 token standard to guarantee frictionless and deterministic post-trade processing. Interface specification and reference implementation please see gitrepo below, for documentation see EIP-markdown-file.


The Smart Derivative Contract is a deterministic protocol to trade and process
financial derivative contracts frictionless and scalable in a complete automated way. Counterparty credit risk ís removed. Known operational risks and complexities in post-trade processing are removed by construction as all process states are fully specified and are known to the counterparties.


Rethinking Financial Derivatives

By their very nature so-called “over-the-counter (OTC)” financial contracts are bilateral contractual agreements on the exchange of long-dated cash flow schedules. Since these contracts change their intrinsic market value due to changing market environments they are subject to counterparty credit risk when one counterparty is subject to default.The initial white paper describes the concept of a Smart Derivative Contract with the central aim to detach bilateral financial transactions from counterparty credit risk and to remove complexities in bilateral post-trade processing by a complete redesign.

Concept of a Smart Derivative Contract

A Smart Derivative Contract is a deterministic settlement protocol which has the same economical behaviour as a collateralized OTC Derivative. Every process state is specified and therefore the entire post-trade process is known in advance. A Smart Derivative Contract (SDC) settles outstanding net present value of the underlying financial contract on a frequent basis. With each settlement cycle net present value of the underlying contract is exchanged and the value of the contract is reset to zero. Pre-Agreed margin buffers are locked at the beginning of each settlement cycle such that settlement will be guaranteed up to a certain amount.
In case a counterparty fails to obey contract rules, e.g. not provide sufficient prefunding, SDC will terminate automatically with the guaranteed transfer of a termination fee by the causing party.
These features enable two counterparties to process their financial contract fully decentralized without relying on a third central intermediary agent.
Process logic of SDC can be implemented as a finite state machine on solidity. ERC20 token standard can be used for frictionless decentralized settlement - see reference implementation.
Combined with an appropriate external market data and valuation oracle which calculates net present values, each known OTC derivative contract is able to be processed using this standard protocol.


The interface design and reference implementation is based on following considerations:

  • A SDC protocol is supposed to be used by two counterparties and enables them to initiate and process a derivative transaction in a bilateral and digital manner.
  • Therefore contract interface specification is supposed to completely reflect the trade livecycle.
  • The interface specification is generic enough to handle the case that two counterparties process one or even multiple transactions (on a netted base)
  • Usually the valuation of an OTC trade will require complex valuation methodology. Therefore the concept will in most cases rely on external market data and valuation algorithms
  • A pull-based valuation based oracle pattern is specified by a simple callback pattern (methods: initiateSettlement, performSettlement)
  • The reference implementation SDC.sol is based on a state-machine pattern where the states also serve as guards (via modifiers) to check which method is allowed to be called at a particular given process and trade state

EIP markdown file

Further information

For further information on the concept please visit:

1 Like

I believe the PR looks fine now. Is there anything that needs to be done on our side?