Using Ethereum for financial smart contracts

Vishakh
6 min readMay 10, 2016

See our deep dive for technical details.

It’s still too early to tell how relevant blockchains are for finance. To get some insight, we modeled a financial derivative contract on the Ethereum blockchain to see what a decentralized, peer-to-peer financial instrument would actually look like. While the implementation revealed a bunch of challenges, some echo of this work might show up in a decentralized financial system of the future.

We started our work during a

hackathon last year and took it from there with some input from our ConsenSys friends. We modeled the life cycle of a call spread with trading accounts, counterparty confirmation, margin calculation and cash settlement, all implemented using smart contracts in Solidity. The front end consists of a collection of web interfaces for creating and interacting with the contracts. These pages can be distributed on IPFS to provide a secure decentralized interface to the system. Although our work was done on a public blockchain, most of our findings also apply to private blockchains as well.

Challenges

One of the delights of working with new technology is getting to understand its constraints and opportunities. Working on this project end to end gave us an insights into some of the less obvious issues which might affect blockchain finance.

Smart contracts potentially allow us to simply put a contract on a blockchain and forget about it, secure in the knowledge that it would execute autonomously. However, for the logic of a financial contract to fully reside on a blockchain, it must be able to “wake” itself up reliably in the future in order to generate the correct cash flows and perform other life cycle events on schedule. Unfortunately, there is no easy way to schedule contract execution on a platform like Ethereum’s. There is no intrinsic capability to guarantee scheduled actions in the future therefore smart contracts rely on external input to initiate any work. Systems like the Ethereum Alarm Clock, while workable for a variety of other contracts, do not offer the scheduling precision and guarantees required for high-notional financial contracts. For example, cashflows might not actually be generated on time or a contract not settled automatically upon maturity. There are people putting thought into the economics of blockchain scheduling and a solution may be possible. Until then, a reliance on third parties is necessary so we created an off-blockchain program that wakes up registered contracts at regular intervals.

Finance heavily relies on mathematics, to say the least. Every financial smart contract must have a sense of its own worth for margin calculation, payouts and general processing. At the moment, Ethereum intrinsically only supports integer math which means, for example, a smart option cannot run Black-Scholes to price itself. It is theoretically possible to create smart contracts which implement complex mathematical formulas by either computing them in an elaborate manner using integer operations or providing lookup tables of outputs for all conceivable inputs. Both approaches are expensive and unwieldy until there is widespread collaboration on a practical standard library of smart utility contracts. Adding native support for a floating point standard like IEEE 754 on a distributed system might be a difficult problem due to differing client implementations and will nevertheless require costly computation. We compromised on this front by simplifying our margin calculation formula to be value-agnostic in lieu of realistic margin calculation.

The financial system also relies on trusted publishers like Bloomberg and Markit to provide market and reference data. Not only does no such facility exist yet on a blockchain but any oracle which steps in becomes a point of centralization and risk. This isn’t an issue for smart contracts involving on-blockchain entities like tokens and accounts. However, a large space of contracts could involve inputs such as NASDAQ quotes or US treasury yields which must somehow be injected on to blockchains by oracles. Each oracle brings in a corresponding amount of infrastructure risk and centralization, especially because smart contracts are static and irrevocable. Some approaches for mitigating this risk involve using committees of oracles, setting up smart contracts such that oracles can be swapped out and using prediction markets instead of conventional market data publishers. On private blockchains, market data could simply be provided as a utility. We worked around the market data issue by using synthetic, randomized market data to run our demos.

Aside from the usual Ethereum and Bitcoin scaling issues, there are some other challenges relevant to blockchain finance. This includes working with execution constraints such as gas limits and the usual user experience issues with new domains. We will likely address these in an upcoming post.

The Good Stuff

The good news is that we were able to get our smart contracts working from end to end. For all the caution we have conveyed so far, it’s pretty cool that we’re able to take the economics and behavior of a trade and encode it on a trustless public ledger. We made a range of simplifying assumptions but we think our work shows that, with sufficient time and effort, it should be possible to construct live deployments of highly bespoke financial smart contracts. Even now, where constraints in the conventional financial system make a contract sufficiently expensive or impossible, one could trade on a blockchain in a peer-to-peer, decentralized manner if needed. There is definitely an overhead in terms of usability and precision, but this might still be worthwhile in situations where conventional approaches are not possible.

Decentralization and applications

So how decentralized and automated can we get? As things stand, far less than ideal. In a perfect world, all business logic would lie on the blockchain and execute itself autonomously. Due to the scheduling issue and reliance on external market data via oracles, quite a bit of processing must still remain off-blockchain. In many cases, enough processing must stay off such that the blockchain doesn’t add much value beyond being a ledger of transactions. The decentralization we do get comes with significant overhead and makes sense only where border restrictions and the international regulatory regime make a transaction impracticable or prohibitively expensive.

In principle, an Ethiopian coffee farmer should be able to sell forwards directly to a coffee roaster in New York or a successful Argentine bakery should crowdfund using international backers to scale itself. There are numerous practical reasons why this isn’t the case but peer-to-peer blockchain finance along with a reputation system could be some part of the eventual solution. Our original vision was to create a library of common financial contracts which could be used by regular people for funding, hedging and geographical arbitrage. If the user experience issues are solved, financial smart contracts could be useful to regular people even with all the other challenges we mentioned. If these contracts follow common standards, it should be possible to build composite contracts on top of simple contracts to take large scale positions on specific sectors or regions.

On the flip side, there is an opportunity for financial institutions to reduce complexity and costs using blockchains. It seems pretty clear that settlements can benefit a lot from the use of immutable public ledgers. There is, however, still no consensus on whether we can go any further. Besides security and privacy issues, the challenges mentioned above make trading on public blockchains difficult at the moment. A lot of these concerns could be ameliorated on a private blockchain or ledger as long as it is backed by some cryptographic guarantee even if some form of mining isn’t employed. An example of such a system is Juno, which employs a consensus mechanism very different from Ethereum’s. Smart contracts could potentially be practicable even if they are not running on a distributed virtual machine. In such scenarios, large chunks of many behemoth financial IT systems could be retired and replaced with smart contracts running on shared platforms.

Conclusion

Overall, we are pleased to report that financial instruments can indeed be encoded on the Ethereum blockchain. There are areas of concern which are not widely discussed but should find some resolution with time. We encourage you once again to read our deep dive to get a better sense of our work and its nuances. We hope that some version of the kinds of contracts we implemented could be part of a fully peer-to-peer decentralized global financial system of the future.

Kapil and Vishakh

Many thanks to Tyler Clark for his help in conceptualizing the project and getting it off the ground.

--

--