A smart collateralized non-recourse futures contract on Ethereum: first impression
Today is yet another exciting day, because I just built the first "smart" Ethereum contract that performs a futures trade between two parties. The contract allows two entities with Ethereum accounts to enter into an ether-settled, margined futures agreement on any market (or non-market!) variable - be that the closing price of SP 500, the air temperature at Noon in downtown Manhattan, or a hurricane event in the Caribbean.
Why are smart distributed financial contracts important? The world creates a huge notional volume of "exchange-traded" and "over-the-counter" derivative transactions. At this time, these transactions go through investment banks and through exchanges, adding a layer of fees for buy-side institutions and individual investors. If the decentralization trend continues, we will see this marketplace evolve from fees based on volume ("spread") to fees based on access, or consulting fees, making trading cheaper. Smart contracts and Ethereum could be an underlying platform for this new marketplace.
The futures contract works in several steps. First, a blank contract must be created. Then, the long side (or the short side) can offer a trade by initializing their side of the contract, and posting the collateral. Then the other party can pick up the contact and take the role the short side. One important part of the contract is a data provider, a very simple messenger contact that relays the current level of a market variable (such as the closing price of SP 500). Another important part is a service that actually calls the daily settlements in our futures contact - Ethereum virtual machine at this time does not support any concept of time. So we need a system of reliable "timer" nodes to actually call contract settlements.
After a contract is "signed" by both long and short sides, the data provider contract will periodically be updated with the most recent closing price, and the timer will call the contract's update method. The contract parties must monitor the current contract balance and port additional collateral if required. If the balance of either the long or the short side falls below the termination trigger level, the contract terminates itself and distributes all money to the long and the short side. The contract can also be terminated by either the long or the short party.
Why are smart distributed financial contracts important? The world creates a huge notional volume of "exchange-traded" and "over-the-counter" derivative transactions. At this time, these transactions go through investment banks and through exchanges, adding a layer of fees for buy-side institutions and individual investors. If the decentralization trend continues, we will see this marketplace evolve from fees based on volume ("spread") to fees based on access, or consulting fees, making trading cheaper. Smart contracts and Ethereum could be an underlying platform for this new marketplace.
The futures contract works in several steps. First, a blank contract must be created. Then, the long side (or the short side) can offer a trade by initializing their side of the contract, and posting the collateral. Then the other party can pick up the contact and take the role the short side. One important part of the contract is a data provider, a very simple messenger contact that relays the current level of a market variable (such as the closing price of SP 500). Another important part is a service that actually calls the daily settlements in our futures contact - Ethereum virtual machine at this time does not support any concept of time. So we need a system of reliable "timer" nodes to actually call contract settlements.
After a contract is "signed" by both long and short sides, the data provider contract will periodically be updated with the most recent closing price, and the timer will call the contract's update method. The contract parties must monitor the current contract balance and port additional collateral if required. If the balance of either the long or the short side falls below the termination trigger level, the contract terminates itself and distributes all money to the long and the short side. The contract can also be terminated by either the long or the short party.
The most important element of this contract is the data provider. In the blockchain world, this is called an "oracle". This is the entity that can provide Ethereum contracts with the external data, such as market index quotes or downtown Manhattan temperature measurements. If an oracle intentionally produces a wrong input, in collusion with one of the parties to the contract, we can have a fraud situation.
There are two ways that the Ethereum network can provide reliable market data. One is through de-centralizing the data provision. A number of outdoor temperature sensors, running on different hardware and located in different spots, can provide a better measurement than a single sensor. Several data feeds from different exchanges can also be used to develop a 'consensus' value of a market quote.
The second (more important) way of entering accurate information into the chain is by incentivising data providers. Each time an 'oracle' contract is called, it can receive a small fee. Different providers will compete for fees - the most accurate provider will be winning more business.
I am planning to deploy a test market data feed on my cloud computer - but this is the topic for the following posting.
This is the contract, deployed (and closed) on the production Ethereum chain.
There are two ways that the Ethereum network can provide reliable market data. One is through de-centralizing the data provision. A number of outdoor temperature sensors, running on different hardware and located in different spots, can provide a better measurement than a single sensor. Several data feeds from different exchanges can also be used to develop a 'consensus' value of a market quote.
The second (more important) way of entering accurate information into the chain is by incentivising data providers. Each time an 'oracle' contract is called, it can receive a small fee. Different providers will compete for fees - the most accurate provider will be winning more business.
I am planning to deploy a test market data feed on my cloud computer - but this is the topic for the following posting.
This is the contract, deployed (and closed) on the production Ethereum chain.
Comments
Nice to see you play around with Ethereum! Are you doing it as part of your job or is it independent self-education?
Also, would it be possible to take a look at the source code of this contract? I am particularly interested in it as a case study of someone not involved in Ethereum development writing a contract of non-trivial complexity. One of the problems with Ethereum that I see but you did not mention in your next post is that the tools provided for developers are insufficient for helping developers write airtight, correct code. It is very easy to make mistakes similar to those in the ill-fated "The DAO" contract and quite difficult to catch them, especially for beginners. Would you mind sharing the source code including any annotation that you might have added?
The most striking point about Ethereum is the highly asynchronous way the network runs. This is not intuitive for anybody. For example, after sending a transaction to the network, the contract state does not change until the contract is mined. That can throw off any code written by a traditional programmer.
I believe a good practice is to write compact contracts, have them relatively short-lived and not to put all assets in one contract. In this way, a bug in the contract code will not impact a large asset base, and will be corrected next time parties enter into a futures contract. So there would be one or several stable boilerplate contracts that people use.
DAO, on the other hand, was quite centralized despite the name, because the same piece of code was used for the whole 140MM.
https://github.com/ethereum/go-ethereum/blob/swarm/swarm/services/chequebook/contract/chequebook.sol