Sushi Relay: YCabal 2.0 - Reducing Gas Prices for SushiSwap Traders

@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

  • docs.openmev.org

  • $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.

  1. All orders for the given market are collected.
  2. Orders beyond their time-in-force are canceled.
  3. Orders are placed into separate lists by the market side, and aggregate supply and demand curves are calculated.
  4. 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.
  5. 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

  1. Eligible transactions are rebated based on the 80th confidence interval for gas estimation pricing.
  2. This is proportionally distributed based on transactional weight. Note: a naive formula would consider pairings, then slippage tolerance, and finally transactional amount
  3. The amount of compensation is the remainderless fees to miners and network operational transactional costs.
  4. 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

connector_button

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

2 Likes

I’ve been a SUSHI holder for quite some time and recently came across Manifold ($FOLD). I believe that Sam’s implementation is elegant and delivers value specifically to Sushi users instead of sending it to the wallets of MEV searchers. It also doesn’t suffer from any of the UI/UX issues

I support this proposal. It will continue to differentiate SUSHI from other DEXs and the txn fee rebate will help to enable traders with smaller portfolios to trade on ETH at Sushi.

Just to reiterate a few things:

Additionally SushiSwap Exchange API

e.g.
https://7ob2ikxqn7.execute-api.us-east-1.amazonaws.com/dev/swap/summary

Additionally, we have observed that changing pool routing constants may additionally produce a source of positive slippage that can be returned to end-users.

This isn’t entirely reliant upon arbitrage-producing bundles FYI.

Hey @sambacha, really interesting concept thanks for sharing.

First off - this quote below is a great feature:

Rewarding users in xSUSHI benefits them with yield and benefits SushiSwap governance with more eligible voters. In the SushiSwap ecosystem we must identify more ways to encourage xSUSHI adoption.

Does the integration work on less expensive networks (i.e. Polygon) and Layer 2s? I am assuming no as rewards are distributed as an ERC20 token.

For the future of ETH - would Sushi Relay become obsolete as more ZK rollups are adopted?

1 Like

Update: Gas Refunding uses baseFee of the transaction or the 80% confidence interval estimate from the gas pricing API located on api.txprice.com

This fixes the possibility of transactions gaming the system. see the variance in baseFee here

Great proposal, Sam! A few questions for clarification:

You propose incentives would be paid to certain traders? And you propose to pay the $FOLD tokens from the Sushi treasury?

You would implement the Sushi Relay, while the Sushi team implements the UI? And you don’t propose to receive funds yourself for your implementation?

sushiswap accounting for 30% of overall MEV profits

Is there a chart for this?