Comments (9)
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).
from sips.
@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).
from sips.
@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.
from sips.
@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.
from sips.
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...
from sips.
@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.
from sips.
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
from sips.
This is now being discussed in this PR: #77 - please direct comments over there.
from sips.
Update: this is now SIP-37 - link to discussions in Discord in the SIP
from sips.
Related Issues (20)
- SCCP 18: Decrease Collateralisation Ratio to 700%
- SIP: Add sOMG and iOMG synths
- stake snx HOT 1
- Rethinking frozen iSynths HOT 7
- Solutions To Snapshotters that Works on L1 HOT 1
- Draft SIP: SNX Community Fund Allocation Through Inflation HOT 4
- Unfork from ethereum/EIPs HOT 2
- Time based staking rewards HOT 4
- Alternative arbitrage pool mechanism HOT 2
- Arb Pool Upgrade Proposal HOT 2
- Arb pool: time based rewards and splitting into 2 contracts
- Mitigating price feed manipulation
- SNX Uniswap Pool Staking Incentives HOT 1
- SNX Auction Trial HOT 2
- Synth exchange pausing for spot market closures HOT 1
- Synth exchange suspension for protocol security HOT 1
- eSNX an ERC-20 token redeemable for escrowed SNX HOT 1
- Test Cases for SIP-210
- Synthetix protocolDAO Phase 1 & 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sips.