patrickdugan
commented
3 years ago Nice recap almost a year later:
- This has been thoroughly sorted, we'll give it a once-over again towards the end.
- We have everything except the interaction with the "container" of settlement counterparties, where the fund would inject funds iteratively to every counter-party that has a short-fall, or we might do it in a general pro-rate fashion. Finishing this will come after Lihki's done with the refactor.
- Adding some tickets for stops and per-tick % limits to further de-risk the systemic properties of edge case liquidity.
- Lihki's done a lot here, needs more testing.
- We've tested this a lot but we'll put it through 100k tx on testnet next.
- This needs to be dry tested on testnet.
So 1, 2 by half, 4 by 75%, 5 by half.
So a bit under 50%.
The following 6 things must be thoroughly high-confidence tested on testnet:
1) Fee flow (what happens when there is no mDex order for the collateral currency in which the fee is generated? "We'll just market make all day long." - no there needs to be a cache and out-flow when orders appear); do fees flow at the correct rates for on-chain maker/taker vs. InstantTrade? Do fees flow correctly as rebates? Do fees flow correctly into relevant insurance funds? Does the correct amount of fee flow to Oracles?
2) Insurance fund functionality - Oracle contracts fund two insurance funds, the ALL/TOTAL insurance fund and the local contract's insurance fund. Since we're activating Oracles ahead of full Native ecosystem, we have to ask, where does the ALL/TOTAL fee go? It should still go to populating the insurance cache for ALL/LTC and TOTAL/BTC contracts in preparation for the native launch. Do insurance funds pay out when there is a socialization event? Do they pay out correctly? What happens when there is part of the short-fall paid by the insurance fund, depleting it, and a part paid by socialization, are numbers consistently correct there?
3) Liquidation - does the liquidation increment we're going with and our max leverage tend to hold up in volatility shocks of 10%, 20%, 50%, 80%? Let's assume the worst and compile some good stats to talk about. Also, does the margin system handle the bail-in and insurance application correct.
4) Settlement - does the settlement algo generate odd numbers that break consensus ever? Run it a bunch of times including, especially, the times where there is liquidation. I don't think Lihki tested the liquidation aspect. He tested every version of the algo many times in regtest/sim-mode but not with a volatility sim, I think. The algo, mathematically, should add up by routing sub-graphs and balancing out surpluses or making up the surplus from either a bail in or the insurance fund. Is the algo as it is currently implemented sensitive to these contingency inputs to make the sub-graphs net-out to 0 together? Is the injection of resolution-funds from a bail-in or the insurance fund happening after the pairs have been settled? Or before? If it's after, then the algo needs to accept some non-0 discrepancies that then get transformed into the post-bailout or post-insurance injection set of balances. Have creeping feeling there may be a decent-sized ticket here.
5) Trade Channels: do the trade channels all work properly?
6) Oracle management/recovery: do the Oracle failsafe and related functions all work correctly? Maybe do a dress rehearsal of key compromise/recovery.