Per-tick % Limits

[patrickdugan]

To help confine the limits of structural melt-down/melt-up that might occur in these systems, the protocol should have a logic that the Mark Price cannot increase or decrease more than e.g. 5% from one block to another. If it's outside this, then the mark price used to trigger liquidations would be at the 5% limit. Then, the next block can be another 5% further along.

Bitstamp/Deribit et al. all use something like this, but for them a tick is a much faster interval of time. There's merit in making the % value somewhat bigger. But also considering the max. leverage we have in mind for Native, 5% is pretty good.

The main goal is to liquidate the most leveraged (e.g. 20x) ahead in the queue of the less leveraged (e.g. 10x, then 5x, etc.) to limit the risk to the system.

This makes sense to earmark for Native since an Oracle is going to follow its own rules anyway, and could implement this as a matter of policy, but this is important to the structural integrity of the native VWAP clearing.

[patrickdugan]

This is another good one to put in for the Insurance Fund v2 activation.

[patrickdugan]

I may have accomplished this in the get mark price function where I added a simple logic:

int64_t Register::getPosExitPrice(const uint32_t contractId, bool isOracle) const { if(isOracle) { int64_t oracleTwap = mastercore::getOracleTwap(contractId, 1); int64_t oracleLag = mastercore::getOracleTwap(contractId, 3);

    if(oracleLag*0.965>=oracleTwap){
        oracleTwap = oracleLag*0.965;
    }

    return oracleTwap;
}

// refine this: native contracts mark price
return 0;

}