One of the benefits of being the oldest “Bitcoin 2.0” project is that we get to use our foundation of highly secure atomic transactions to then place some of the amazing work in smart contracts and distributed IT on that foundation. Eris Industries recently released their ErisDB and I really like it. It plugs into Tendermint’s blockchain consensus protocol to roll an insta-chain based on what could be described as proof-of-stake taken to logical maturity with a bonding requirement for transaction noding, what I call proof-of-bond. Tendermint allows any amount of chains with a minimum of 4 bonded verification parties to achieve Byzantine Fault Tolerance. ErisDB utilizes Docker to distribute application-logic code that is able to define the permissions of writing to your Tendermint blockchain du jour. Then it allows you to plug in a smart contract based in Solidity (Ethereum’s baby, since adopted by Counterparty, and then Eris, and now us). So now you can hardcode these logics based on blockchain events to give permissions to write to your Tendermint blockchain. 

Why am I shilling so hard for “competing” projects? Because this isn’t a Highschool Football team, this is technology, sometimes tech can be complementary. I have been looking at using Omnicore RPCs in conjunction with Node.js apps hosted on a VPS, not too complex. Problem is, that’s no dApp, that’s just an app, but now a bunch of projects are making it possible to easily do p2p blockchain-ified meta-web of things and glaiven.

No ETH or XCP required to execute computer programs in a decentralized way.

Consider the possibilities for combining ErisDB and Omnicore. You’ve got your Bitcoin blockchain with the Omnilayer Dex for monetary settlement and hedging. You’ve got your ErisDB writing to a Tendermint Chain as sort of the console-event-log of your dApp as a blockchain. Got that? Then the two chains can reference each other.

Tendermint requires some kind of bonded collateral as the basis for qualifying a node to stake changes. Therefore if you want your app to support multi-party transactions, there’s a couple ways to get that collateral on your local chain. The first way is to reference a balance on the Bitcoin blockchain, ideally that balance is locked by assurance contract in bitcoind, or as we have built, a move to “Reserve” status in Omnicore, a title reserved for balance used in limit orders, pending confirmation transactions, and futures contract margin. It should be possible for a Tendermint chain to write an issuance of $1000 for instance, by referencing an Omni balance that has 300 OMNI hedged at around $3.33 each. The ErisDB logic for writing Tendermint transactions can be tied to the known parameters of the lock used in Omnilayer. For the sake of fairness, you can do locks directly in bitcoind and MirrorX is working on that.

Now that you’ve got your bonding stake, you can participate in verifying the Tendermint transactions executed in accordance with the ErisDB logic to read/write, and smart contracts that codify such logic in a functionally guaranteed way. However, ideally logics should be factored out as much as possible to the overall flow model of your multi-blockchain application. Don’t worry that this seems complex, it’s just the plumbing that makes a trustless autonomous application possible to spawn and operate in perpetuity independent of its publisher.

Let’s consider how you could do the converse, have something written in the Tendermint chain parsed by an Omnicore node with the right script settings switched on, and then summarily have a pre-signed transaction template executed when the pre-defined conditions are heard from the Tendermint chain. The contents of the Tmint chain could also parameterize the contingent transaction signature. That transaction could:

– Issue something new with parameters.

– Issue more of something existent.

– Redeem something.

– Buy or sell something.

– Pay a dividend.

– Use a reserved balance that is thusly earmarked in an Omnicore transaction to make a payment to somewhere or a set of somewheres.

– To the extent that ErisDB is recording an ID registry with associated Bitcoin addresses, pay specific someones.

This would be all the smart contract layer Omnicore needs to do everything anyone else can do. But you’re doing it with Omnilayer, so it will be fast to plug-in for you and rock solid money movement for your users. Think of it like a wrapper framework.  

Now, I like to ask myself often, “how could this awesome thing I want to build but everyone better at software engineering than me is busy not building, be built by me?”   

Which brings me to the prototype of the decentralized banking system and futures contract that I am building for the Citi Mobile Challenge using these technologies.

I’ve got a busy month ahead as we launch the Omni Dex. Maybe I will not get to the futures contract and lean on OkCoin instead. Maybe I will not get to the more full decentralization of the app-layer logic and lean on simple Node.js running on my own server. Maybe the prototype has a private key dangerously rubber-stamping in the bowels of an Omnicore node running on such a server, lacking the implementation of the wrapper proposed above. We’ll see, but here’s how I’d build the world’s first production decentralized futures contract:

1. Create pairs of smart properties as flexible issue, one is the short-side counterpart to the other. So for example I do two tx 54s that give me long and short OMNI/BTC contracts.
2. I create two templates of an issuance and redemption transaction and set up the robo-signage in Omnicore.
3. I use either a Omnicore-outside-blockchain wrapper (scaleable solution) or just Node logic running my side to parse for a Tendermint blockchain of a given signature.
4. Fire up a Docker instance running ErisDB with a few smart contracts for writing what transactions to broadcast for Omnicore in the Tendermint whose defining handle I have passed to my node.
5. The smart contract logic has to do with writing into the Tendermint chain every time there is a transaction for one or both of the two “contract” smart property tokens representing long and short positions. This records an index of trades in quantity at price P, time T*, with the nature of the trade (Both contracts opened, long opened/short closed, short opened/long closed, both contracts closed).
6. The Omnicore uses the nature of the trade to write “grant” or “revoke” N contracts to the balances in question, based on a netting logic. The only thing that must be added to Omnicore then is, at a minimum, an integer parameter for a smart property that is 0 OMNI by default and asks how much OMNI does this smart property lock in Reserve balance per unit of the smart property. An optional parameter to specify another collateral type is viable, e.g. “USDT” for Tether-dollar collateralized contracts.
7. The confirmed changes in balance record another index entry on Tendermint chain indicating the trade was not spoofed.
8. Come a certain block height on the Bitcoin chain, a settlement algorithm works at the ErisDB logic level, parsing the Tendermint Index and triggering settlement events when it does. The ultimate settlement event goes through the chain, does the formula against the prices, nets everything, and posts the settlement roster on the Tmint chain.
9. Omnicore has a batch simple-send filled in per the parse of the other chain’s settlement block.

That wasn’t even 10 steps.

*(Tendermint goes down to very short timescales, so a contract with enough leverage for reserving Omnilayer balances can potentially be high-frequency traded, just not ultra because the Omni collateral needs some confirmations to settle. This is the role I originally envisioned for Factom.)  
I won’t bore you with enumerating the rest of the dbanking function built off of the futures contracts, but it seems likely to be workable in this architecture.