Cleaning up Contracts within Properties

[patrickdugan]

We are going to save time on refactoring everything into multiple property ids, the raw integer index works fine as a reference for the way the protocol is written now. Presumably we are not going to end up with >64,000 tokens and contracts. However, if we have new futures contracts grabbing numbers indefinitely things can get out of hand. Additionally it will be RPC intensive to loop through a list of properties, which includes contracts, and then pass everything through a RPC to get contract info. We do have RPC calls to return lists of different native and oracle contracts.

The logic for futures should follow:

Create contractA with blocks_until_expiry N, creates immediately the successor contractB expiring in 2N blocks, this is already in place. When contract A expires, contract C enters into existence that block, and all references to the given property id of contract A on that block until the expiration of contract C will refer to contract C. When contract B expires, its property id becomes reference to contract D. Thus to get historical data on any contract, you just have to isolate the pair of property ids relating to the contract (e.g. BTC/USD Weekly Future Front, BTC/USD Weekly Future Back) and then in .js or some other layered code, the expiration time and the dates linked to those blocks can be used to put labels on that data, slice it up for TradingView retrospectives, etc.

This will keep our propertyids relatively tidy. I believe currently the logic is to grab a new property id for contract C when contract A expires, but any other contracts or new tokens issued meanwhile would create erratic and unpredictable gaps between these ids, hard to look up as this scales.

To layer in more expirations and duration on futures, just list a pair of weeklies along with a pair of monthlies and quartrlies, now there are six contracts. Maybe a pair of annual contracts, why not, you'd have to wait until Christmas to line up the dates. All the expiries you could want, and they could even be 8 property id's neatly packed in a cluster. But the problem here, there will come a time once a month where the weekly contract and monthly contract have the same expiry but different ids for the same oracle index. Or, once per year, you'll get 4 contracts all expiring on the same block. Oy!

The elegant solution there is for the logic to check that contracts with the same oracle address, whose expiration blocks are evenly divisible, will sit one out from time to time. For example I create a pair of futures with 4032 blocks and 8064 blocks (1 week, 2 week) to expiration, and same-block, publish a tx to create a pair of futures with 16128 blocks (28 day monthly cycle) and 32256 blocks. Let's call them contracts A-D. When contract A expires its property id becomes contract E, expiring the 3rd week of the month, when contract B expires it would expire on the same block as contract C, so it doesn't become anything it becomes a null entity (all trades invalid etc.) - which is what we originally planned for expired futures, a graveyard of property ids that do nothing. When contract E expires on that 3rd week, it becomes contract F, expiring on the 5th week since this began. When contract C expires, it becomes contract M expiring in 2 months, and Contract B becomes Contract G, expiring the second week of this second month. But it's very logically annoying to wait for the contingent event, better to have one rule.

The rule would be:

If contract with the same oracle address has the same expiration block as this contract that is supposed to be created to replace a just-expired contract, then don't create the new contract, instead, activate this contract's property id for the period after its twin contract, the next time that twin contract is updated.

In other words, when the 2nd week contract expires, instead of becoming the 4th week contract (e.g the monthly contract that already exists) it waits until the 3rd week contract expires, and becomes the 5th week contract, and at that moment, becomes the 6th week contract. No need to wait until the monthly expires. Might as well give these contracts more life.

Why not have the 2nd week contract become the 6th week contract when it expires? It seems logically easier to relate to the twin instead of tracking every single overlapping contract. Like, when the 2nd week expires, why not jump to the 5th week? Well that should belong to the 3rd week contract when it expires. So what, the 3rd week ends up becoming the 6th week, and the 7th week is (if you're keeping track) originally the second property id in the set, and then, the first property id gets its turn the 2nd month to swap places. They'd do this gyration pattern repeatedly and parsing historical data would become so complex in practice. So these pairs offer a consistent math constraint that is easy to look up.

Of course, months are never 4 weeks. You know why? Because Augustus and Julius Ceaser were huge cheeze heads. We could have had a 10 month calendar with 35 days each and 15 days of merry at the end of the year, but even that wouldn't be evenly divisible. An automatic futures calendar, even launched on a Friday, will deviate from the expiry times of centrally operated futures where they try to follow a last Friday of the month rule. Oh well.

[patrickdugan]

This is actually pretty important to keeping things indexable and predictable for the long-term so I'd say this is the 3rd decent-sized ticket prior to shipping Oracle.

[santos177]

done