dexX7
commented
6 years ago I think it's better to keep track of the specification or feature proposals in the spec repository:
https://github.com/OmniLayer/spec
Please feel free to open a new issue over there.
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.
Core text:
Bitcoin Core 0.12 merge
Publish Futures Contract tx
Creates a set of new smart properties, at least 2, N blocks between their expiration. Signed integer balance, indivisible units.
Reserves some smart property # as its collateral, N units per contract. Has notional value that can be greater than reserves.
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.
Publish Data Address that is the settlement feed for a given contract, should be multi-sig, pubkeys correspond to setting up sidechain, sidechain regulates cheating on the part of the reporters.
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.
Settlement logic
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:
1) Has there been some futures contract expiration this block?
2) If yes, index all trades involving this contract.
3) Create transactions based on the difference for each set of addresses (optional, apply netting logic and save on the # of inputs required for the settlement).
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.