Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Refer to "Problem" definition via Synthetixio/synthetix#298 for details on the front-running situation in Synthetix.
The Exchanging Queuing Proposal suggests solving front-running with the use of queue, to be processed at some future stage after prices have been received. The concern with this approach is that it turns a synchronous process -
Instead of using a queue, and instead of using the current max gwei limitation introduced in SIP-12, we allow all exchanges to be processed at whatever gas price the user wishes. Immediately thereafter, there is a small waiting period (of M minutes, say) within which exchanging or transfering any of that synth will fail for the user.
After the waiting period, if a price was received by the oracle during that window that would have led to more profit than the exchange fee, then this profit is marked as reclaimable. The next exchange of that synth after the waiting period will always send any reclaimable amount to the fee pool before processing the exchange. For transfers, in order to not break
1. Legitimate users have to pay front-running fees
While this post-trade fee reclamation is designed to prevent intentional front-running, it is possible that legitimate users get caught out unintentionally front-running. That is, someone is trading unawares of market volatility, and they happen to place a trade right before an oracle update yields them additional profit. However, this proposal only penalizes them for these immediate profits made. Future oracle updates after this waiting period of M minutes have no impact.
2. Friction to exchange & transfer synths
Under this proposal, two points of friction are introduced:
3. Limitations to composability
The final concern with this approach is that any atomic (i.e. within the same transaction) exchanges or transfers that proceed an exchange will fail - causing the entire transaction to fail. As more an more DeFi projects are composed together in smart contracts, we have legitimate concerns that this friction could impede future compositions which have yet to be created.
We have some ideas around how to prevent this - such as a additional exchange function that circumvents this logic but always pays higher fees. Alternatively, we can take into account on-chain volatility of the
We welcome any constructive input you may have around this issue.
Given the following preconditions:
@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).
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
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
@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
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
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...
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.
I'm not sure I follow you? If you mean
Perfect, on the first point.... Thanks