# `wallet-boost`
Imagine if end-users could benefit from MEV - instead of being harmed by it. Wallet-Boost is an open-soruce protocol built by Blocknative to faciliate MEV Value Recirculation to various parties, including validators, searchers, protocols, and wallets.

This document seeks to explore the protocol to give wallets, and inevitably their users, more access to the burgeoning MEV market. We welcome contributions.

### Background

MEV stands for Maximal Extractable Value and it is the value that is solely accesible by actors who can control the ordering of transaction within blocks that land on-chain. In practice the highest surface area of MEV are pieces of on-chain state where many users are interested in sending transactions to interact with. A very common example is highly liquid Uniswap Pool. MEV inspires religion like cults in how to handle this value created from contentious state, but most agree that it is an inevitable part of distributed systems. It must be mentioned that there is also an [existing body of research](https://eprint.iacr.org/2021/1465) devoted to the opposite opinion, but this document does not progress this line of thinking. However, it's concepts may prove useful in future architectures.


Up until now, validators have been the main recipients of MEV augmented rewards, through a network of builders and relays all facilitated by the mev-boost protocol.

## Wallet-boost

### Design Goals

Wallets are the entry way into web3, and will be for the forseeable future. Here we define various properties that should be aimed to achieve in the final state of `wallet-boost`.

1. ***Censorship Resistant*** - Censorship resistance is a spectrum. While the protocol should aim for some minimum expected assurance that their transaction will be included on-chain, it should be each wallet-node operators choice on where in this spectrum they sit to support a geographic diversity of nodes. There should also be a mechnaism for the community to monitor censorship.
2. ***User Value Maximizing*** - When chosing between different bids the protocol should choose that which delivers the maximum value to the user.
3. ***Execution Speed/Reliability*** - The time required to put a transaction on chain, assuming appropriate transaction fee settings, should be minimized. Note that this goal may sometimes conflict with User Value Maximizing.

### Objectives

## Prior Art

- [bloxroute backrun.me](https://backrunme.com/)
- [Rook finance](https://www.rook.fi/)
- [Kolibrio by Peanut Trading](https://www.kolibr.io/)
- [Propeller Heads](https://www.propellerheads.xyz/)
- [Wallchain](https://www.wallchain.xyz/)

### Overview of Orderflow Auctions

There currently exist multiple order flow auctions "in prod". Related literature [1](https://collective.flashbots.net/t/order-flow-auctions-and-centralisation-i-a-warning/258) and [2](https://collective.flashbots.net/t/order-flow-auctions-and-centralisation-ii-order-flow-auctions/284) classify concerns and benefits of these approaches. The general break down of approaches fall into two main categories; those with a trusted auctioneer, and those without. In the following diagram "Request-for-Quote" and "Request-for-Solution" approaches fall into the trusted auctioneer category as they exist in Prod.

- Orderflow auction writing

### Malicious Searchers

## Components
- Preview submission standard
- Preview auction marketplace
- Transaction submission RPC

## Architecture

### Sequence Diagram

- bundle creation with wallet boost

## Challenges

- **Transaction Settlement Assurance** - If a searcher fails to deliver a users transaction in a bundle to a builder then this will create poor UX for the user. The protocol can have a fall back mechanism to release the transaction if not seen on-chain in `X blocks`, but even this doesnt feel like an optimal approach so there is room for improvement.
- **Trusted Searcher List** - The early versions of this protocol will require a trusted searcher list to properly extract bundle flow. How to construct this list is an open question.

## Future Work

[ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) ushers in a new paradigm for user wallet interaction. This new architecture also opens up the aperture of the MEV rebate design space.

## Open Collaboration

It's important to engage with other stakeholders to ensure that this receives ecosystem-wide support. Effort and funding must be managed in order to support.
- Create an open working group that requires members to contribute to a shared multi-sig and funds researchers for effort.

## Open Issues

1. You technically don't need to send a simulated preview payload to the searcher at all since they will do their own simulation. Is there another need or requirement for sending the simulated payload? Should we consider not having it be a simulated payload saving valuable time not having to make that request.
- The simulation happens upstream of the signature, so you gain time rather than lose it
- tying simulation or other resources to request (could be staking, tx fee mechanism etc) alleviates a potential spam problem
- If end user's expectations rely on searcher's word there is an integrity problem that arises (eg. searcher says $50 rebate and wins auction, user accepts, but tx executes at $5 rebate) (eg2. searcher says $50 rebate and wins auction, user accepts and receives $50 rebate, but rebate opp was $100)
- For an end user to fully evaluate the value of a potential rebate they should understand the rest of the transaction's dynamics. This can be provided through the searcher response however, and does not necessitate a simulation before sending to searcher
- Given simulation takes about 30ms it's unclear whether the time saved by skipping is impactful, an approach that skips network hops by simulating in the wallet-boost node can also be considered if sim is deemed needed, although this increases the infra burden.
2. MEV scoring - this is a VERY hard problem. 99.9% of opportunities come from a swap causing slippage in 1 liquidity pool. From this one swap there are a number of strategies to capitalize on the swap:
- Atomic Arb: Check other DEXes for the same liquidity pool. But this is not a simple task and has many many permutations. One bot might be doing two pool ARBs only on Uniswap V2 clones, one bot might be doing 2+ pool arbs, another might include Uniswap V3, another Curve and Bancor. You get the idea...
- Sandwich: if you can sandwich a transaction it is almost always more profitable than arbitrage. Easy to eliminate sandwiching from this whole thing, so this is probably not a problem
- CEX-DEX: bots looking at centralized exchanges have a myriad of reasons for bidding what they want to bid. Some are doing market making, some are doing arbtitrage. They typically are able to beat atomic arb bots for the same opportunity.
- All this said, creating a generalized MEV scorer is HARD and if you can do it, you might as well be a searcher. Do we need to have MEV scoring at all? Shouldn't we just rely on the searcher auction to score it.
3. Someone needs to send the bundle - either the searcher or the user or the wallet, but then at some point, either the searcher or the wallet has the others signed transaction and MUST trust the other party not to dump it unbundled in the mempool. Do we create a mechanism like slashing in V0 or do we acknowledge this is a trust issue in V0 and punt it to V1?
4. WalletBoost needs to know when a transaction is confirmed so it can eject it from its queue or mempool or whatever to stop receiving bids on it. How does WalletBoost know about state changes on chain

## WalletBoost as MEVBoost
In WalletBoost, WALLETS are VALIDATORS and SEARCHERS are BUILDERS.

Flow:
- User composes and SIGNS transaction
- The wallet, running WalletBoost, takes the SIGNED transaction, strips out the signature part (V R S) and submits the UNSIGNED tx to the auction where Searchers are watching for new events.
- Just like builders in MEVBoost, searchers are making bids as fast as they want based on the new event. The bid is some SPEC (payload) that we need to specify.
- The SIGNED transaction is also sent PRIVATELY as a bundle of 1 to builders
- So at this point, the transaction is going to be included in the next block because all of the builders have the transaction. In the background, there is the WalletBoost auction happening
- Note the timing of this send can mean the tx gets on-chain before the auction can take place (ie. send needs to be at the earlier seconds of a slot or defer to next block+1, which may have UX impact)
- This can also mean a builder can do MEV theft / steal the auction, so auction will require a high degree of trust or an honesty mechanism will be needed
- Just like VALIDATORS in MEVBoost, they have to at some point call getHeader to get the full block. So each wallet can operate how they choose to operate on behalf of their users. The wallet through WalletBoost calls getBestBid at some point before the next block (their choice and risk here which requires the wallet to have some skin in the game and compete against other wallets on infra just like validators). getBestBid chooses the highest bid from the auction and pings the searcher that they WON and it is now their responsibility to pony up and send the SIGNED tx. This is just like MEVBoost and builders. The builder is selected and now they gotta respond with the block payload. An additional interesting wrinkle here is you can make it exactly like MEVBoost in that WALLETS CHOOSE the Searchers they are connected to just like Validators choose the relays they are connected to. It is still completely open but it gives WALLETS the power to choose the Searchers they are comfortable with. AND if a searcher keeps missing the getBestBid response (like missing a slot) then they take them off their list.
- Now the wallet has the searcher signed transaction, they call eth_sendBundle REPLACING the bundle of 1 with the bundle of 2.
Why I love this approach? Its EXACTLY the same as MEVBoost - why reinvent the wheel? It forces WALLETS to invest in quality infrastructure to compete. It forces SEARCHERS to invest in quality infrastructure to meet the latency requirements or risk getting CUT by WALLETS. And finally it meets the needs of the USER. The REBATE is nice to have not must have. The USER cares about getting the swap price they are looking at on screen and the rebate is the bonus. If WalletBoost falls apart along the way (like a missed 'slot'), then it doesn't mean the users transaction doesn't happen, they just don't get a rebate.