Official Response + Links to important documentation
The links section includes a post I have created in response to a specific question on the governance/payouts mechanism
Payouts / Staking / DAO Governance
Answers to questions posted above
-
-
- You mentioned $250k in Sushi incentives, what activity are these to incentivize and who are the incentives paid to?
-
- ANSWER: These are to be paid out to trades occurring for markets in the Sushi Bar and top100 pools. The pools are subject to change depending on what the Sushi team thinks is best.
-
- Does the OpenMEV apply to all transactions by default on Sushiswap or is it only certain pairs?
- ANSWER: The “arbitrage”/“gas refund/rebate” mechanism is what I think you are referring to. That applies to any trading pair on sushiswap actually.
-
- Does the default setting only apply OpenMEV protection or does it also apply arb based gas refunding?
- ANSWER: The default setting is controlled by our infrastructure. The default setting is currently configured to only do MEV protection. We will enable the default behavior from trades submitted from the sushiswap fronted to be gas refundable after two weeks. We will be expanding the OpenMEV API to a new endpoint, (api.openmev.net - not currently configured) for non-sushiswap usage.
-
- You mentioned xFold earlier, what is it and how does it work?
-
- Has the team done any estimates on what value the OpenMEV can extract? In other words what range of reward could a $FOLD token holder expect based on a certain Sushiswap volume?
- ANSWER: We do not provide forward guidance without historical precedent. Having said that are things that are of notable relevance:
- we expect MEV opportunities to become more bespoke (e.g. plain arbitrage opportunities will not persist as a sizeable spread on the most liquid pairings, this is natural),
- opportunities will move to different chains (the first 3 chains we plan on supporting are Fathom, Polygon and Avalanche/possibly something else).
- Reducing our ability to produce arbitrage/refunds will be minimal as we onboard new searchers .
To @foldguy
- Do scenarios exist where Sushi traders that elect to utilize OpenMEV receive worse price execution? Receiving gas rebates is awesome, but hope this doesn’t have any negative impact on the price for traders.
- ANSWER: By ‘worse price execution’ do you mean effective price slippage increase? Increase in time to block inclusion for the trade? Not capturing positive price slippage back to the trader (1inch/paraswap recapture this positive slippage benefit for themselves, excluding the originating trader)? In general, we do not produce sandwich trades for realizing arbitrage profits, which does decrease the gross potential of potential profits. This is done specifically so as not to introduce secondary effects that traders need to now account for / cause disturbances to the underlying markets being traded. If you can provide more specific language to your question I can answer it better!
- In terms of arbitrage, we have some data available from https://explore.flashbots.net/. They only count single transaction arbitrage in these figures however. If I understand correctly, OpenMEV will submit in batches so may not be able to compare apples to apples, but how do we expect that OpenMEV will perform relative to the data from explore.flashbots?
- ANSWER: It should be comparable for the mean amount extracted over time. Please let me know what data sets/calculations you would like to see on our portal, the development instance is here: https://mevscan-kvtz9.ondigitalocean.app/ - we are currently providing complete miner information. Deploying a metabase instance will be trivial, so be creative in your requests!
Closing Remarks
We appreciate everyone’s patience with us over the last few months. We know that having delays is not encouraging, however in retrospect, they have helped surface rare edge cases and production issues as it relates to infrastructure. Doing things the correct way yields important benefits down the road, an example being that the SushiSwap integration fronted provides seamless metamask support without the need to configure RPC network information from the end-user, a feature that no one currently is able to offer.
Additionally, we will be providing more information on Carrier Transactions
and how to easily adopt OpenMEV protection (e.g. using our react hook, use-react-wallet
see: Use-react-wallet - Easier onboarding for new protocols and applications)