Proposal: Fee Reclamations

[jjgonecrypto]

Proposal: Fee Reclamations

[brian0641]

I propose extending this proposal to both directions: gains due to luck or soft front-running are reclaimable and losses due to bad luck are rebatable. If only the reclaimable portion were implemented, lucky trades would be penalized while traders that make unlucky trades would bear the full loss. To non-front running traders, it would average out to be an effective fee increase.

Rebatable Implementation: During an exchange or transfer, the rebatable flow is similar to the reclaimable flow, except rebatable amounts are credited to a per-account rebate variable. The user would manually need to call Synthetix.claimRebates() in order to claim their rebate from the fee pool. If the fee pool didn't have enough, the call would fail.

In discussion on discord, one issue mentioned with this implementation of rebatable is that the fee pool may sometimes not have enough funds, which would be a poor user experience. Some possible solutions to this: (1) Instead of fully distributing the fee pool every week to SNX holders, always leave a minimum amount in the fee pool (e.g., 20k sUSD); (2) deduct the outstanding rebates in real-time from the fee pool, so that there will always be enough to cover calls to Synthetix.claimRebates(); (3) when needed, new sUSD can simply be minted and added to the fee pool. As long as the amount minted is offset by corresponding creating of new debt, everything balances.; (4) some combination of (1)-(3).

[jjgonecrypto]

@thebkr7 because that would introduce a delay (of unknown length) while the oracles fetched prices off-chain and before reporting back with the latest price. Like queuing, it breaks composability completely as the execution of the order would no longer happen atomically (i.e. within the same transaction).

[thebkr7]

@justinjmoses What if each trade sends an oracle request to chainlink with an ID specific to that trade.
The oracle then uses the callback function to return the price for the trade thus completing the creation of the trade.

[jjgonecrypto]

@brian0641 I think adding rebates are a reasonable compromise for this proposal, and I've come around to them (as this was discussed a few weeks ago on our Discord in the #sips-wips channel). I think however instead of a separate function, that we include the rebates in settleFeesReclaimed() - naming it settle() - rather than making another function. Creating a separate function makes the logic more convoluted with respect to storage and lookup.

As for the fee pool size - I think with the addition of fee reclamation to the fee pool, there should be a sufficient amount to pay for rebates. This feels like quite an edge case regardless (user has negative front-run - presumably by accident - and the fee pool isn't big enough to cover the losses). If we implement and find it is impacting the user experience, we can revisit this (or if griefing does start to occur - which seems unlikely due to cost to the user).

That being said, I appreciate the possible suggestions. Of them, (1) is a possible addition. (2) is too tough and doesn't work in all cases - it's possible the first exchange in a new period (where fees are currently 0) has a rebate; we can't deduct it from the fee pool until there's a transaction to settle() - which unless we write an oracle to process these settlements, could be never. (3) seems problematic in that it introduces minting into a new scenario - adding more complexity to a complex system, and I don't feel the trade-off is worth it. It makes sense that we use the fee pool as the place where debt is repaid to SNX stakers, and that this same pool be used to rebate them.

Hey Justin,
Just read this fee reclamation proposal, really amazing job with the concept. I am worried though how will the time delay be decided upon? Meaning, let's say we set it now to 1 minutes. Where is the vulnerability is my concern...

Also on the second friction point you raised above, regarding the failure of swap transactions due to unclaimed fees... I don't know about the complexity of the implementation where triggers payment/receipt of unclaimed fees when swapping the synth automatically...

[jjgonecrypto]

@ace0999 thanks 🙏

how will the time delay be decided upon

We will initially decide upon a conservative time frame, based on known oracle updates, and monitor it. We also need to integrate this with the remainder of the chainlink migration - so we will need thread the needle a little. I expect the initial rate to be somewhere in the vicinity of 5 minutes, but that is subject to change.

regarding the failure of swap transactions due to unclaimed fees... I don't know about the complexity of the implementation where triggers payment/receipt of unclaimed fees when swapping the synth automatically...

I'm not sure I follow you? If you mean exchange when you say swap, then these will automatically be deducted or credited following successive exchanges.

Perfect, on the first point.... Thanks
For the second point I meant, if I buy something like sETH, and I want to swap it on uniswap, I'm assuming I'll be blocked due to the reclamation fees?
So if it is the case, will I have an ability to settle these fees on MintR, or maybe automatically on swapping... That's what I meant...
Thanks a lot

[jjgonecrypto]

This is now being discussed in this PR: #77 - please direct comments over there.

[jjgonecrypto]

Update: this is now SIP-37 - link to discussions in Discord in the SIP