@NOTICE
The Author has some holdings in ArcherDAO/Eden Network.
The author has a position in LIDO, which has recently seen an investment by Paradigm.
The Author holds YFI, (W)ETH, DAI, USDC, USDT, LIDO, OHM, FOLD, CRV, and (x)SUSHI. This does not include airdropped tokens nor NFT’s.
Summary
Sushi Relay: OpenMEV Solution (f.k.a. YCabal)
-
Sushi Relay is the only MEV Solution that does not force end users to change their metamask settings.
-
This is an exclusive feature for Sushi Relay vs. other MEV enabled protection services. No need to change your RPC settings in metamask.
-
S E A M L E S S
-
HTTPS RPC Endpoint https://api.sushirelay.com/v1
-
WebSocket RPC Endpoint wss://api.sushirelay.com/v1
-
$250,000 worth of Incentives to be distributed for the first month that it is enabled. This is to be distributed in the form of $FOLD tokens (Manifold Finance Token). This is to be distributed at the discretion for specific trading pairs as decided by the Sushiswap team. E.g. pairs trading on the Bar would be eligible or only the top 10 pairs. This is a secondary vote to be decided by the Sushiswap community if this proposal is accepted.
Abstract
Sushi Relay aggregates all transactions and batch processes them to private mining pools (e.g. flashbots, ethermine, etc).
OpenMEV provides a private searcher mempool in which searchers submit arbitrage bundles against the transaction flow. In exchange for exclusive access, the profits from these arbitrage trades are refunded back to end-users.
Sushi Relay operates in the following modes:
0: All trades submitted are privately routed to mining pools. No arbitrage is committed against them. The benefit is only against front running/arbitrage trades. I.e. all trades are submitted privately to miners as opposed to the public mempool.
1: All trades submitted are routed through the private OpenMEV auction space for searchers. End-users receive benefits of mode 0 + gas rebates.
Motivation
enter the motivation behind your proposal here
Specification
Technical Specification
Engine
OpenMEV Engine uses a batch auction-based matching engine to execute orders. Batch auctions were chosen to reduce the impact of frontrunning on the exchange.
- All orders for the given market are collected.
- Orders beyond their time-in-force are canceled.
- Orders are placed into separate lists by the market side, and aggregate supply and demand curves are calculated.
- The matching engine discovers the price at which the aggregate supply and demand curves cross, which yields the clearing price. If there is a horizontal cross - i.e., two prices for which aggregate supply and demand are equal - then the clearing price is the midpoint between the two prices.
- If both sides of the market have equal volume, then all orders are completely filled. If one side has more volume than the other, then the side with higher volume is rationed pro-rata based on how much its volume exceeds the other side. For example, if aggregate demand is 100 and aggregate supply is 90, then every order on the demand side of the market will be matched by 90%.
Orders are sorted based on their price, and order ID. Order IDs are generated at post time and is the only part of the matching engine that is time-dependent. However, the oldest order IDs are matched first so there is no incentive to post an order ahead of someone else’s.
Gas Rebating
Gas rebates are determined by function calls to the sushiswap exchange contracts, see the table here
Example: Your trade calls the function swapExactTokensForTokens. You are eligible for up to 100% of the cost of this function call.
Your trade calls the function addLiquidity. You are eligible for up to 50% of the cost of this function call.
Rebating Transaction Costs
Rebating a transaction is determined by:
- Is the function that is called in the transaction eligible?
- By tracking contract function calls we are better able to provide observability in the rebating process, we can also coordinate with teams wishing to provide more incentives for specific actions and behaviors
- If yes, what is the percentage that can be rebated?
- This percentage value is a protocol value that can be adjusted
- What is the transaction cost for the eligible transaction?
- Thi s the value that the end user utilized in submitting their transaction.
- Calculate the Gas Reporting Index value
- This uses the gas pricing information from api.txprice.com to calculate the gas pricing information to be used in calculating the rebate amount for your transaction
- Calculate the rebate amount from the bundle profit surplus
- We take how much profit the arbitrage made and split it among all eligible trades within that bundle
Rebate Mechanism
- Eligible transactions are rebated based on the 80th confidence interval for gas estimation pricing.
- This is proportionally distributed based on transactional weight. Note: a naive formula would consider pairings, then slippage tolerance, and finally transactional amount
- The amount of compensation is the remainderless fees to miners and network operational transactional costs.
- Compensation payouts occur no later than a half-hour
What happens in case of RPC Failure?
See https://github.com/sambacha/web3-rpc-failover for a portable design of our internal logic.
A stall timeout of 60 seconds is provided before the transaction is automatically sent to the public mempool.
UI / UX
Connection Button Information
Overall Interface changes
For
Yes, bring forth reduced gas fees and front running protection in a seamless manner for end-users
Against
No, I like sushiswap accounting for 30% of overall MEV profits. Keep the original YCabal proposal
Poll
Sushi Relay Proposal
- Yes, For Proposal
- No, Against Proposal
0 voters
