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

EIPs
,
1

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.

Abstract

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.

Motivation

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.

Rationale

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:
https://www.finmath.net/finmath-smart-derivative-contract/

2 Likes
2

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

3

@pekola : Given that we have some new use cases that would require some (small?) changes/improvement to this interface, I wonder: can we still modify the current EIP-6123 or should we keep it as is and create a new one?

4

Hi @cfries. The enhanced interface proposal could cover more use cases / implementations. In my opinion a new EIP proposal for such an enhanced SDC would be hard to separate from 6123. Wondering, what is common practice regarding changing the interface of ERC-EIPs which are in Draft Mode?
@Pandapip1 - could you help out on this question. Thanks

1 Like
5

In Draft? Feel free to make whatever changes you want!

6

We made some updates. The interface has been slightly extend and modify to better support different implementation variants and different financial products (smart financial contracts). More examples using EIP-6123 will follow.

The reference implementation has been updated accordingly. As well as the documentation and unit tests.

See Update EIP-6123: Move to Draft by cfries · Pull Request #7857 · ethereum/EIPs · GitHub

7

Note:
The new interface is available via @finmath.net/sdc@0.3.0
The old interface is available via @finmath.net/sdc@0.2.3

See @finmath.net/sdc - npm

(@pekola @kourouta )

8

I have moved the EIP to the new ERC repository. I have added the package.json and hardhat-config files.
The new version is pushed as 0.3.1 to npm:

9

Dear All.

As EIP-6123 may have relevance for the European Central Bank’s “exploratory phase for central bank money settlement of wholesale financial transactions” we would like to make some small changes.
However, there are a few PRs in the pipeline. I saw that PR of EIP-6123 (move to draft) is not on the list for the office hours. Will there be longer delays, e.g., given the ERC/EIP split? @Pandapip1

@Kourouta @pekola