Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
0.0.12 - Futures #366
It seems like the best strategy may be to just use this next dev cycle to do what we've wanted to do for a long time, natively, rather than try to open up interoperability with other tech just yet.
This issue supersedes the Subscribe tx and Reserve Property issues. Full write up here.
Bitcoin Core 0.12 merge
Publish Futures Contract tx
Creates a set of new smart properties, at least 2, N blocks between their expiration.
Reserves some smart property # as its collateral, N units per contract.
Settles based on an oracle address or based on the volume-weighted average price of a Dex spot trading pair over the past N blocks. (parameters either an address or two smart property id’s, order matters).
Trade Futures Contract
Needs a different tx type than standard Dex trades.
Trade is not invalid if sell amount is greater than current supply.
Trade price is encoded in the op_return when trades are executed rather than being implied in the ratio of smart properties swapped.
Fee logic - if an oracle based contract, .01% of notional value, in the form of the underlying collateral (e.g. some OMNI, some USDT) goes to the oracle address, .01% goes to OMNI. If a blockchain price-based settlement, .01% goes to the maker (person providing the order that was matched) and .01% goes to OMNI. Contract using OMNI as collateral have .01% fee that goes to either the blockchain address or maker.
Possibly the short-cut to representing Omnilayer value as collateral for the regulating Credits/Tendermint app is to have that balance on the multi-sig address, or possibly on a separate, 4-of-4 address formed by the same pub-keys, while publication is on the 3-of-4.
Transaction payload itself is pretty straight-forward, most of the concern here is outside the protocol.
Transactions between addresses to settle contracts as their balances all zero out on the pre-appointed settlement block, using reserved balance.
Logic for taking all recorded trade prices and coming up with the settlement transaction values implemented in the protocol’s parsing rules:
Atomic Transactions (Optional)
Allow transactions to be formed where the balance is associated with some satoshis, apply multisig logic so this collateral can be swapped to other addresses as needed.
Untag satoshis to return to address format when the need for a hard swap or collateral (i.e. money pending swap) is finished so users don’t have to hassle with the custodial risk of their liquid capital hinging on mis-placed Satoshis.
SPV wallet for faster trading of futures based on Atomic collateral.