In order to get my hands dirty with smart contracts, I decided to try my hand at smart bonds. They are an interesting asset class in as much as they have a long tail – once you have sold a bond, you then have to pay coupon payments for a long time. Automating those payments could in principle achieve operational costs savings. Frankly, could have chosen any other instrument, but you have to start somewhere.
I roped in Ian Cusden to do the actual coding and a few other guys to give us pointers on how bond business logic works. We chose Ethereum as the smart contract platform to have a go with first. It’s our intent to do the same exercise in the future on other platforms likes Eris Industries, Ripple’s Codius etc.
After a couple of week’s worth of on/off work we have something that kinda works – very exciting. We created smart contracts to represent a virtual currency, a smart bond and a Libor smart oracle. We knocked up a simple web UI to issue new currency and bonds, and buy/sell bonds in exchange for virtual currency. We implemented a simple state transition for bonds to simulate issue, allocate etc. transitions.
no mechanism for a smart contract to issue coupon payments in the future
And then we hit a problem. We have found no mechanism for a smart contract to issue coupon payments in the future. It appears that both Ethereum and Eris (have not checked others) do not have a scheduler mechanism – a smart contract must always be pinged by either an external call or by another smart contract.
There is of course a work around, you can have an external scheduler pinging smart contracts like a clock, but that’s not very elegant. I would much prefer if a smart contract could be programmed to wake up in the future and do something, or at least issue a transaction to itself for a future date i.e. a forward transaction, and processing nodes would only process those transactions when the time is right.
what should be part of a smart contract and what is out of scope
Apart from the scheduler issue, we also ended up thinking a lot about what should be part of a smart contract and what is out of scope and to be implemented by something out-of-band.
Thinking is very raw at this point, but if I was pushed for an opinion, I would suggest that one should focus on business logic of trust to be implemented as a smart contract and other parts can be out-of-band.
Let’s use an example. When a bond is issued and people allocate money to it, I need to trust that I will get some or all of my money back if the bond is over allocated. So the process of sending money to the smart bond and issuing refunds in case of over allocation must be implemented as a smart contract on a distributed ledger, to ensure trust of execution.
On the other hand, as a bond or currency holder, you will want to know how much money and what bonds you hold. As bond issuer you will want to know how many you have issued and possibly bond holders. So, all of that user centric data pivots and UI to issue new bonds, state transition them etc. are suited for implementation in a desktop or web wallet.
If you were to create a secondary market for these smart bonds, then you would want a way to discover bonds for sale and provide a capability to offer bonds for sale, request purchase of a bond, and then actually buy and sell bonds. At the very least then you would some sort of a search and analytics engine to enable that.
Ethereum for instance does not have an in-built register of smart contracts, but it does have a name registration contract that could act as a directory. Even so, ability to easily search and find a smart contract and its instances is limited, and would be better implemented as as a search engine with a visualisation layer, to visualise both bond contracts and understand transaction flows.
There are parallels to this in Bitcoin – businesses like blockchain.info have sprung up to partly help view and analyse transactions. It helps to only track a single asset – Bitcoin. It gets more complicated to do the same when you have many different assets as you can with Ethereum and others, so more sophisticated tools will need to emerge. Currently we are thinking of using ElasticSearch and Kibana to help visualise our flows.
Crypto 2.0 