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
Futures - Publish Contract Atomic Tx #374
A variant on the Managed Smart Property creation, this transaction creates two new smart properties that are to be part of a series, and carry a special categorization as being Futures Contracts
Blocks between Expiration - from the block the new contract series if published, the first contract will expire N blocks later, and the second contract will expire 2N blocks later. At Block N, a new contract comes into existence which expires 3N blocks after this transaction was published, and so on ad infinitum.
Note the smart property IDs for a contract series needs to follow a numeration where 1000s of contracts can come in and out of existence over time without collisions. So futures contract series should occupy a large header number, such as 410000, so that if a contract expires every day, after ten years all the contracts in that series still occupy 41xxxx numeration.
There should be a minimum time between contract expirations, perhaps 50 blocks (~6hr contract) or perhaps 150 (~24hrs).
Collateral Currency - a smart property ID # for the smart property used to both back and settle the contracts. Eg. #1 for OMNI backed contracts that pay some amount of OMNI to winners.
Collateral amount - the # of units of a reserve currency locked up per absolute value number of contracts held long or short. Eg. 10 OMNI per contract means if you have -10 contracts or 10, then your address must have had 100 OMNI to enter the positions. The amount is reserved until settlement for any amounts that are net profits or loss. The amounts can be freed up by reducing the absolute value of one's contract positions, less any losses, which remain reserved until settlement.
Quote Currency - a smart property ID # used to calculate settlement value. Eg. Tether; if the collateral currency were OMNI and the quote currency were Tether on a OMNI/USDT contract, then the OMNI value of a contract would become larger as the price declined, with the USDT value fixed, providing a perfect hedge. Or conversely, imagine an OMNI/BTC contract that is collateralized and quoted in OMNI, it would be a quanto contract that provides convex gains and losses to those who are long/short is respectively, because the losses for the short-side would be fixed in OMNI as the value of OMNI rises. Hence 10% rise means 11% loss.
Notional Value - the value of each contract in the quote currency. Eg. 1 contract is worth 10 OMNI or 1 contract is worth $100 worth of OMNI.
Settlement Reference - either an array containing two smart property IDs or a bitcoin address where a data feed is regularly published by some party. The prior option has settlement logic that looks for the Merkle branches of the two properties, tallies all the spot Dex trades between them in the preceeding N blocks, and uses the ratios to devise a price. The latter option has nodes looking at the Op_return data of transactions broadcast from the data feed address, with some contingency logic for a non-timely publication of a settlement price, that looks at preceeding prices and averages them, and includes a grace period of 2-5 blocks before doing so in case the publisher is a bit late on the update. Perhaps that grace period and the number of preceeding data feed points to average could be parameters in this transaction, perhaps we simply go with 6 and 6 as hardcoded. The benefit of that latter approach is, traders can see if a feed is not being kept up consistently or has been overtly manipulated and know what they are getting into (we can have such statistics included in UI designs for Omniwallet/OmniJ), and it balances with the publisher's profit motive and professional reputation to provide an imperfect but recoverable dynamic.
From what I can gather so far there is quite some complexity to what's being requested, so it's going to be a fairly lengthy development effort I think as all of it requires extra ways of storing and processing data etc in the reference client (it's not a simple A+B consensus rule change) - though we can estimate time required better once we have a workable spec (again @marv-engine is your man here and the sooner we get to a workable spec the sooner we can start prototyping :) ).
Thanks for all you're doing & for the ideas
@patrickdugan I need some help understanding this. Assume that I know virtually nothing about what business transaction you're trying to specify. Can you describe the transaction(s) in layman's terms and/or point me toward an existing description?
When writing a spec, I prefer to start with objective and quantifiable functional requirements. If nothing else, that provides a framework for testing. Design and then implementation come only after all the stakeholders understand and agree on the reqs.
You bet on changes in price using a fraction of the value of the bet. At a fixed time the bet will pay based on a reference price. So I put up 10 OMNI to take a bet on something that is worth 50 OMNI, and you have the same amount, and when the price changes and I trade off my contract to someone else or wait for expiration, if the price went up and I'm long, I pay you, and if the price went down and you were short, you pay me.
If I understand how a contract series will work, we can consider using (or extending) the Property Type and Previous Property ID fields to indicate the sequence of SP id's - effectively, generating a linked list. That would eliminate the need(?) to reserve a block of SP id's.
It's TBD if append or replace or something new is the correct Property Type description of the relationship between the new and old contracts' SP id's.
Update - I realized that a new contract in the series would be generated by Omni Layer itself when the previous one expires, not by subsequently submitted transactions, so the it may be that a linked list is the way to go, but not as the result of a submitted tx.