Proposal: SushiGuard Router Contract

Sushi Guard Router Contract

Sushi Guard is the OpenMEV implementation for Sushiswap. This proposal is for upgrading the existing routing contract. The routing contract aggregates trade liquidity from multiple sources (UniswapV2 and SushiswapV1 currently). It also aims to bring OpenMEV rewards and rebate process on-chain, so that there is no need for manual processing of rebates/etc.

See the GitHub repo for more details/technical related stuff

  • cross-dex backruns for swaps and liquidity changes

  • reduced slippage fallback router

The contract leverages and depends on 2 external protocols:

  1. Aave V2 for flashloan backruns

  2. UniswapV2/Sushiswap V1 (or equivalent on another network) for backrun completion and fallback swaps

Note, Kashi and AAVE usage are being prioritized before audit submission

Delivery of Proposal

We expect 6-8 weeks for Auditing and Frontend integration to take place, no longer than May 25th.

This proposal should not be voted on by snapshot until at least 2 community calls on this proposal have been had and discussed. First community call should occur on April 7th, second, April 21st potentially sooner.

Proposal Cost

Cost of implementation and auditing borne by Manifold Finance, with a conditional reimbursable of auditing costs to be disbursed by Sushiswap Treasury once Routing contract is published on Mainnet Ethereum.

This reimbursable cost should have a defined budget determined by Sushiswap ACD based on their informed expectations

Benefits

  • Profits are immediately distributed to the Sushiswap Protocol. Sushiswap must designate an address to receive these rewards.

  • Rewards can be used to provide:

  • Rebates paid back in $SUSHI

  • Additional sources of paid incentives for Onsen incentives

  • etc, etc

User

For the User it aims to offer:

  1. Better order routing for minimal slippage

  2. At source MEV with instant rewards

  3. Lower gas costs for swaps and liquidity changes

  4. Efficient execution (with Manifold MEV protection relay)

LP

For the Liquidity providers:

  1. Inclusive rewards

  2. Reduced impermanent loss

Protocol

For the Exchange providers:

  1. Inclusive rewards

  2. Increased adoption

General

For the Ethereum environment:

  1. Reduced MEV attacks and fee spikes

  2. Healthy growth in MEV space with inclusive incentives

Suggested usage of Benefits

We highly suggest to the Sushiswap team to utilize existing optimization solutions, such as that currently used by Onsen that is provided by Gauntlet Network, to be included in their parameter optimization updates that are provided weekly to be used as a ‘tunable gauge’ that can provide greater returns and impact dollar for dollar the entire community.

Planned updates

Prioritized are being designed and implemented, whereas considered may not be implemented in the release version of the Router Contract.

  • Kashi Integration see Kashi contract in repo - this is prioritized

  • Gasless transaction support (this is being considered)

  • Trident support (this is being prioritized)

Auditing:

Auditing is scheduled to undergo through yAcademy. We are arranging a time this week to start in earnest.

We are also reaching out to selected auditors that I will provide names once confirmed and paid for (2-3 weeks).

Documentation

Documentation will be provided via this repo: https://github.com/manifoldfinance/sushi-doc-portal

Currently, this repo holds a partial port of the existing sushiswap documentation. You can visit the webpage via https://sushiswap-docs.vercel.app/

EDIT: Updates/Modifications

A few updates based on discussions we have had and feedback/questions we have discussed with people

No updating addresses for profit recipient [Final]

We are removing the ‘ownership’ functionality for updating the split addresses for withdrawing profits. After talking about it with the team it seems unnecessary. If an address needs to be updated, which should be a rare event, we can just deploy a new contract. Since this contract is primarily used by the frontend to begin with, it would not be difficult to ensure that users were updated to the latest version.

Backrunning Only [Final]

We are only implementing backrunning into this routing contract: other forms of arbitrage are to be external of the routing contract. Users should never be left worst-off: we can not guarantee that with other forms of arbitrage, therefore only backrunning is to be implemented.

Trade Execution Solver API (TES)

There should be, in conjunction with the update of the routing contract, an open source server/function for assisting in creating trades with the new routing contract.

Trident support (feedback phase, not final)

Trident support may be implemented in a ‘side car’ routing contract that is to be used by TES for optimizing user submitted trades. Trident router is a little bit more complicated, so better anyways to offload this to a service than have to over-engineer UI safeguards

Subgraph [Final]

There will be a new subgraph specific to this new routing contract.

Analytics page [Final]

The analytics page will be updated to include volume/trades/etc from the new routing contract

Additional Routing Contract Features:

By highest priority we have ranked additional features for V2 of the Sushi Guard Routing contract that should be prioritized in development/feedback/testing

  • Vault position Trading (Bento/Kashi/Yearn/Rari/etc)
  • Gasless Trading (similar to CowSwap)
  • Trident support (1st class)
  • Limit Order Support via TWAP (r&d)

Scenario: Sushi decides to no longer use OpenMEV Router

Sushiswap can always utilize the existing routing contract. Nothing about usage of the new routing contract prohibits the underlying protocol from deciding to use another solution/etc.

Scenario: What is updatable for the routing contract?

The only updatable portion of the contract is determining the receiving address for profits. This is managed by a Two-Step Ownership contract see TwoSteOwnable

This portion of the contract is owned by the governance multi-sig, and may change depending on feedback received from Sushiswap ACD (all core devs).

Scenario: The Router Contract is found to be insecure, what are the procedures?

Coordination with the Sushiswap team to reduce impact to end users will be coordinated through existing channels of communication that we maintain with the team for existing development coordination.

We will maintain a conformance monitoring suite that will monitor submitted transactions both public and private for real time monitoring of potential exploits that are attempted in real time. This system provides defensive monitoring and may include in the future offensive countermeasures including, but not limited to, potential block reorgs should the exploit be acknowledged within a quick enough time.

Legal Notice

THESE MATERIALS ARE PROVIDED “AS IS”.

The owners and contributors expressly disclaim any
warranties (express, implied, or otherwise), including implied
warranties of merchantability, non-infringement, fitness for a
particular purpose, or title, related to the materials. The entire risk
as to implementing or otherwise using the materials is assumed by the
implementer and user. IN NO EVENT WILL THE OWNERS AND CONTRIBUTORS BE
LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT,
SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY
CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS
GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT
(INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER
PARTICIPANT HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."

For

Implement the Router Contract upgrade

Against

Do not implement the router contract upgrade

  • Yes, For
  • No, Against

0 voters

6 Likes

is there any indication how much revenue the upgrade might generate going forward? understand it’s for sushi to decide what to use it for, but what is the business opportunity here in terms of income per month?

1 Like

Thanks for your proposal Sam.

Could you go into detail about what kind of disaster prevention capabilities the OpenMEV router smart contract will provide?
You discuss about monitoring and cooperation with sushi, but are there automated/manual proactive defensive/mitation steps that can be described at this point?

For example, if the smart contract turns out to be vulnerable, can it be paused by a multisig call so that it simply forwards swaps as if it were disabled?

I would not underestimate the cost and time of this undertaking.

A contract upgrade has significant risk and UX implications. While I acknowledge your calls for Audits, how did you choose and narrow the selection to yAcademy?

Seems to be a myriad of options for auditors. Would be curious to better understand the decision-making process here.

Highly Supportive this is producing a new stream of revenues to Sushiswap and elevating Sushi to the same level has mistX or Cowswap (by protecting against frontrunning natively)

12 Likes

Sounds great. This is what you should strive for.

RE: Expected Revenue
Dependent on relative size and frequency of swaps and market state. As an order of magnitude estimate, from our analysis, I would expect ~ 5 - 100 swaps to be back-runable per day with an average of ~ 0.1 Eth profit per backrun. Extrapolating these estimates to an expected monthly revenue of between 15 - 300 Eth p.c.m.

RE: User Front-run Protection
Swaps that are back-run within the router carry no front-run opportunity, so inherently protect from front-runs. OpenMev private transaction RPC relay (separate from this router contract proposal) protects all other swaps from front-runs by relaying directly to miners (i.e. no public mempool transition).

RE: Disaster prevention
A disabled state function could possibly be added where swaps are forwarded to the old router.

1 Like

Updates/Modifications

A few updates based on discussions we have had and feedback/questions we have discussed with people

No updating addresses for profit recipient [Final]

We are removing the ‘ownership’ functionality for updating the split addresses for withdrawing profits. After talking about it with the team it seems unnecessary. If an address needs to be updated, which should be a rare event, we can just deploy a new contract. Since this contract is primarily used by the frontend to begin with, it would not be difficult to ensure that users were updated to the latest version.

Backrunning Only [Final]

We are only implementing backrunning into this routing contract: other forms of arbitrage are to be external of the routing contract. Users should never be left worst-off: we can not guarantee that with other forms of arbitrage, therefore only backrunning is to be implemented.

Trade Execution Solver API (TES)

There should be, in conjunction with the update of the routing contract, an open source server/function for assisting in creating trades with the new routing contract.

Trident support (feedback phase, not final)

Trident support may be implemented in a ‘side car’ routing contract that is to be used by TES for optimizing user submitted trades. Trident router is a little bit more complicated, so better anyways to offload this to a service than have to over-engineer UI safeguards

Subgraph [Final]

There will be a new subgraph specific to this new routing contract.

Analytics page [Final]

The analytics page will be updated to include volume/trades/etc from the new routing contract

Additional Routing Contract Features:

By highest priority we have ranked additional features for V2 of the Sushi Guard Routing contract that should be prioritized in development/feedback/testing

  • Vault position Trading (Bento/Kashi/Yearn/Rari/etc)
  • Gasless Trading (similar to CowSwap)
  • Trident support (1st class)
  • Limit Order Support via TWAP (r&d)
5 Likes

How will the restriction to backrunning only affect protocol revenue?

3 Likes

Here ya go

SushiGuard OpenMEV Router V03

This documents the finalized featureset for the router contract. Auditing and a bug bounty are to start tomorrow and be announced later this week (respectively).

New features

  • Sushi Guard now sources flashloan liquidity from Bentobox’s. This means more trades can be flashloaned, more of the flashloan fee stays within Sushiswap, and we save gas.

  • No worse execution: Trades will be cheaper than existing trades. Arbitraged trade’s are cheaper than existing trades with rebates from flashloaned liquidity.

  • Subgraph now supports user tracking of earned rebates from profits. This is useful for tracking your rebated trades over time.

Walkthrough

Process is as follows. (using example 40 ETH → USDT)

If router has enough `balance` for optimal arb, use `balance`. (gas ~ 180,000, fee = 0.00%)
If router does not have enough balance for optimal arb, use `bento` *if it *has sufficient balance. (gas ~ 230,000, fee = 0.05%)
If router and `bento` do not have enough balance for optimal arb, use `aave`. (gas ~ 380,000, fee = 0.09%)


That’s an example for a user swap from ETH → USDT in current market conditions

Graph shows MEV extracted, without fees (Flashloan fees can take away from the MEV profit)

User gas fees would be fixed at:

~90,000 for swap less than 0.1% reserve
~180,000 for swap where router has sufficient USDT to arb
~230,000 for swap where router does not have sufficient USDT to arb but `BentoBox` does
~390,000 for swap where router does not have sufficient USDT to arb nor `BentoBox` but `Aave` does

Subgraph and User data

MEV event to store the protocol profit, token and user address from the trade

You should be able to verify and calculate user rebates (without fees) from the MEV profit.

emit MEV(user: 0xb4c79dab8f259c7aee6e5b2aa729821864227e84, token: 0x6b175474e89094c44da98b954eedeac495271d0f, value: 744148988356071006123)

We should be able to pick up and aggregate this information easily from the (Sushi Guard) subgraph

References

Graph Table

amountIn (eth) amountOut (usdt) Ca Cb Cf Cg arb amount (usdt) mev (usdt)
0.1 243.2540764 7.29427E+17 7.20543E+17 8.88404E+15 37247288290 118892.23 0.00
1 2432.348157 8.67381E+17 7.20543E+17 1.46838E+17 37248182898 1879747.46 0.20
10 24304.23764 2.24572E+18 7.20543E+17 1.52518E+18 37257128979 14803014.79 21.17
20 48565.78235 3.77465E+18 7.20543E+17 3.05411E+18 37267069069 24918483.10 84.77
30 72784.74653 5.3009E+18 7.20543E+17 4.58036E+18 37277009159 33098644.07 190.70
40 96961.24217 6.82448E+18 7.20542E+17 6.10394E+18 37286949249 40147072.44 338.85
50 121095.3809 8.34538E+18 7.20542E+17 7.62484E+18 37296889339 46428544.82 529.10
60 145187.2739 9.86362E+18 7.20542E+17 9.14308E+18 37306829429 52145481.44 761.35
70 169237.032 1.13792E+19 7.20542E+17 1.06587E+19 37316769519 57424097.36 1035.48
80 193244.7657 1.28921E+19 7.20541E+17 1.21716E+19 37326709609 62349403.21 1351.38
90 217210.5849 1.44024E+19 7.20541E+17 1.36819E+19 37336649699 66981901.70 1708.95
100 241134.5995 1.59101E+19 7.20541E+17 1.51896E+19 37346589789 71366476.13 2108.07

BentoBox Interface

NOTE. it’s FlashLoan not Flasloan

function testFlash(address token, uint256 amount) external {
        bentoBox.flashLoan(
            IFlashBorrower(address(this)),
            address(this),
            IERC20(token),
            amount,
            bytes("0")
        );
    }

    function onFlashLoan(
        address sender,
        IERC20 token,
        uint256 amount,
        uint256 fee,
        bytes calldata data
    ) external {
        uint256 amountToReturn = amount + fee;
        token.transfer(address(bentoBox), amountToReturn);
    }
2 Likes