Pricing Network Outages for Sushi Relay - Improved Gas Price API

Pricing Network Outages for Sushi Relay

Abstract How do we price the cost of service interruption for end users for Sushi Relay?

Sushi Relay is a service that accepts user transactions for purposes of private inclusion and rebating this transaction flow by reimbursing end users / protocols with a percentage of profits obtained by arbitrage/MEV transactions. It operates as a private and permissioned mempool. Since users are paid for their submissions of transactions the question evidently rises on how to price transaction inclusion delays.

Note: Read documentation and access the API
Docs: https://docs.openmev.org
HTTPS: https://api.sushirelay.com/v1
Websocket wss://api.sushirelay.com/v1

How do price a network outage for our transaction services? The current existing Gas Pricing API can be used for this purposes by applying the principle of Little’s Law [1].

L=λWL=λW

We can take the value for Littles Law (we apply this to a new field called ‘networkCongestion’) and apply it to the time of networkOutage , which is the time that zero transactions are able to be included in the network . A period of networkOutage can be defined as a value that is three standard deviations above networkCongestion . Think of this as the time it takes to return to a normal value of networkCongestion after the outage is over, i.e. how long it takes to return to normal network congestions (how long it takes to process the transactions that have accumulated during an outage) after networkOutage is over.

Read the entire new gas pricing API and example here:

Feedback, comments, questions are welcomed

4 Likes

Smolbrain frog here, but big recent sushi hodler…is this related to the openMEV toggle on the swap? What happens when I sign the transaction?

1 Like

This is related to how we will be distributing rebates to end users.

Here is a diagram of how the current system is to operate

gas-rebate-diagram.drawio

The reason for having a seperate gas price api rather than using what user submitted gas price for the transaction is this could lead to users picking artificially high gas prices, thus abusing the system. This ensures that both the price is reasonable and ensures fast transaction inclusion based on current network traffic

1 Like

Please let me know if you have more questions, so that we can better explain and provide better docs for users!

Thank you!