n!
, a new block builder on Ethereum.
features
- For searchers: Bundle rebates
- For users: Backrun MEV rebates via a managed mempool
motivation and goals
bundle rebates
We are searchers. As searchers ourselves, we started privately building blocks because we could get better "prices" for our bundles over submitting to existing builders. This is due to the fact that some relays provide block submission value data for the pending slot. This results in a large advantage for searcher-builders, since they are able to dynamically adjust their block bids.
We found that for large MEV opportunities (i.e. make up a significant portion of the block value) where the "going rate" was relatively low (i.e. < 70%), we could consistently beat our competition and extract near maximum value by building the blocks ourselves. Searcher-builders are able to dynamically adjust their block bids to give them a better chance of winning the block and also limit "overpaying" for an opportunity.
As a result, we wanted to create a builder that would enable searchers to take advantage of the visibility into the block building auction without having to build blocks themselves.
You can read more about our exact mechanisms here, but in short, we aim to give searchers the lowest price for their bundles by competing in the block building auction and returning excess value to searchers.
MEV rebates for users
A portion of MEV captured should be returned to the users who create it. While there are many other projects aiming to tackle this same problem, we feel as though they are lacking in UX -- from both the prespective of the searcher and user.
disadvantages of other MEV solutions
- Focus on "trading" MEV. While this may be a significant majority of MEV, it does not cover all extractable value that users create.
- Integrations for users and searchers are not frictionless. For example, searchers need to modify existing bots to accomodate different order types and payment mechanisms. For users, they need to interact with specialized dapps.
- Only a handful of competing searchers/keepers/solvers/market makers on each protocol. While these existing searchers are likely optimal, increasing searcher competition can only help users.
our goals
- Allow for users to capture any type of MEV they create. In theory, users should be protected against listing an NFT below floor, accidentally sending funds to a pair contract, adding imbalanced liquidity to a dex pool, etc.
- Increased searcher competition will lead to bigger rebates for users.
- Better experience for users and searchers.
- For users
- "Set and forget" rpc endpoint. Continue using the same dapps you are familiar with. No need to approve more contracts.
- No need for specialized wallets.
- Rebates paid in ETH instantly.
- For searchers
- Familiar rpc endpoint structure should integrate well with existing searchers (
eth_sendBackrunBundle
,txpool_backrunContent
) - No need to change payment structures. Searchers bid for opportunies via normal priority gas fees and/or coinbase transfers.
- Rebates paid in ETH instantly.
- Familiar rpc endpoint structure should integrate well with existing searchers (
- For users
our solution
Users submit transactions to our backrun rpc. These transactions are stored in our private mempool. Searchers can query the state of this mempool (via txpool_backrunContent
) for the unsigned transaction bodies and the respective transaction hashes. Searchers submit bids to backrun these transactions (via eth_sendBackrunBundle
). That is, searchers bid for the right to capture the MEV created by transactions in the pool. Winning bids are choosen through a first-price sealed-bid auction. A minimum 75% of the winning bid is returned to the user, while the remaining 25% is variable and depends on the demand for blockspace.
what other solutions do better
- Pre-trade privacy. Since we expose unsigned transaction bodies, users are not protected against front-running. That is, anyone will be able to see the content of your transaction, but will not be able to "execute" your transaction (e.g. include it in a sandwich bundle). Users that need front-running protection are encouraged to use our private rpc endpoint or other MEV-resistant applications.
- Potentially quicker block inclusion time.
- Rebate accounting may be done off-chain, which helps lower fees.