[TASK] Next price confirmation

[liamzebedee]

• [x] Feasibility
• [x] Implementation

Context

• Removal PR: https://github.com/Synthetixio/synthetix/pull/1477/files

[artdgn]

Issues with previous version of mechanism:

• Free optionality: there are scenarios in which the order is not executed, and those cases partially depend on the trader's choices. The result is that in some cases the trader can act on new information which makes these scenarios behave like regular spot (atomic) orders - but with much lower fee. Which opens avenues for profitable frontrunning of much lower price spreads than with regular fee.
• Hanged state: if second transaction keeps reverting (e.g. for the rest of future) there needs to be a way to remove it (that doesn't open additional "free optionality").

Proposed mechanism

 submitNextPriceOrder(...)
    - if previous order exists reverts
    - stores the order data + funding index
    - deducts holding-fee from margin

- cancelNextPriceOrder():
    - sends holding-fee to fee-pool
    - removes order

- executeStoredOrder(address account)
    - can be triggered by anyone, at any time after next price(reverts if too soon)
    - in revertless low level call to itself (internal external low level call) executes modifyPosition, remember if call was success
    - remove stored order
    - pay holding fee: 
        - if account is sender: 
            - if call was success - returns fee to margin
            - if call was failure - pay to fee-pool
        - otherwise transfer holding fee to msg.sender (keeper)

[artdgn]

A simpler mechanism after a discussion:

    - submitNextPriceOrder(...)
        - if previous order exists reverts
        - stores the order data + funding index
        - check order is possible with current price (to prevent submitting known bad orders)
        - deduct holding-fee and keeper-fee from margin

    - executeStoredOrder(address account)
        - can be triggered by anyone, at any time after next price(reverts if too soon)
        - in revertless low level call to itself (internal external low level call) executes modifyPosition, remember if call was success
        - remove stored order
        - pay fees (holding-fee and keeper-fee): 
            - call was success - holding-fee back to margin, otherwise to fee-pool
            - sender is original account - keeper-fee back to margin, otherwise to msg.sender

    parameters: 
        holdingFee - can be zero initially if no exploit scenarios are found for free cancellation
        keeperFee - can be equal to minLiquidationFee (20 sUSD)
        nextPriceFee - 5 bp instead of regular spot fee (30 bps)

Main points of discussion:

• It's unclear if free optionality (without holding fee) has profitable exploits. It is clear that it has bad UX (large fee for a possibly failing order). The way forward is to implement the fee, but set to zero initially unless (until?) exploits are found.
• Non zero keeper fee must be introduced to prevent relying on protocol maintained keeper if this mechanism is heavily used. Can be constant (as it's not clear that there is any difference in risk due to different order sizes in this case).
• Explicit cancellation is unnecessary, and if the order fails, second tx is enough to cancel.

Next steps

• [x] implement the above mechanism.
• [x] look for profitable zero holding-fee scenarios. update: seems to have been found
• [x] rename minliquidationfee -> minKeeperFee, use that to pay the second tx sender.

[artdgn]

Mechanism was updated again (following another exploit scenario).

• Confirmation will be possible only during first few rounds (e.g. 2), after which it will always fail.
• Cancellation will be added back. Will be callable by anyone (keeper) after confirmation window is closed, and callable by account owner at any time. Cancellation won't refund the commitFee.

Follow ups for another PR / task:

• Introducing price bounds for orders ("slippage bounds").
• Removing "closureFee" parameter and logic.

[artdgn]

PR: https://github.com/Synthetixio/synthetix/pull/1609