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

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

Wallet-Boost

Currently 92+% of validators are running MEV-Boost where the top 5 builders make up ~85% of blocks on-chain.

Wallet-Boost design is largely derived from the MEV-Boost design where you can think of Wallets as Validators and Searchers as Builders. There are, of course, some major and minor differences as outlined below.

Design
User constructs a swap transaction, signs the transaction and submits it through their wallet the same way they do now. The eth_sendRawTransaction gets sent to the user’s wallet.
The wallet, running Wallet-Boost, takes the eth_sendRawTransaction and submits it to Wallet-Boost, which calls boost_startAuction with the signed transaction payload.
Wallet-Boost builds a bundle with the User’s transaction and calls eth_sendBundle to every builder that is connected to Wallet-Boost
Wallet-Boost calls boost_publishAuction, which strips the signed transaction down to an unsigned transaction and broadcasts the unsigned transaction Wallet-Boost’s unsigned transaction mempool
Searchers can subscribe to events over websockets on Wallet-Boost’s unsigned transaction mempool.
Searchers evaluate unsigned transaction events and call boost_sendBid on any profitable MEV opportunities
Wallet-Boost receives bids and calls boost_handleBid, which evaluates the bid relative to other bids for the same unsigned transaction, and acknowledges receipt to the searcher
Each block, Wallet-Boost ends the auction and calls boost_handleAuctionWinner for each live auction, which sends a message to the winning searcher to respond with their signed transaction
Searcher responds with boost_sendWinningBid which is the searcher’s signed transaction
Wallet-Boost calls boost_handleWinningBundle on each live auction, which constructs a new bundle including the searcher’s transaction and calls eth_sendBundle to replace the bundle of 1 with the new MEV rebate bundle
Connected builder’s attempt to include it in the next block

Outcomes
At this point there are three main outcomes:
Everything was successful and the winning bundle was included by one of the builders on chain, meaning the User gets their rebate directly in their wallet
The winning bundle was too late for next block inclusion, but the bundle of 1 was included. The user gets no rebate, but their swap transaction was included privately by a builder
Neither the bundle of 1 or the winning bundle made it on chain. In this case, there are a number of options:
Automatically repeat the auction
Do nothing and a builder will include the transaction eventually. This can potential get complicated, because builders may have the bundle of 1 OR the MEV rebate bundle.
Signal to the user that they might want to take an action

Considerations
Users
This is all happening behind the scenes so to the user nothing should be different, but they should be aware they are sending privately and are eligible for MEV rebates.
Might be an extra interaction that the User needs to take in the worst case scenario where their transaction isn’t included for some number of blocks.
Wallets
Configure builder RPC URLs
Configure node provider (they need to run a full node to get new confirmed transactions)
Configure auction end-time (they need to end the block’s auction to ensure there is enough of a timeout to actually receive the searcher signed transaction and send the replacement bundle to the builders.
Wallet-Boost maintains a ‘mempool’ of eligible unsigned transactions
Wallet-Boost would also need to maintain additional state (transaction hashes, bundle hashes, bids, etc)
Wallets have the ability to choose which builders they want to work with
Wallets have the ability to block searchers
Searchers
Subscribe to unsigned transaction events. They would have to do subscribe to each wallet’s Wallet-Boost WSS.
Searchers make bids, which are a direct transfer payment to the User’s address. Searchers may need to adapt their smart contract to incorporate this extra payment.
Searchers need to have low-latency high performance architecture to respond quickly in order to compete.
If their bid is chosen, they need to respond with the actual signed transaction that is only eligible for next block inclusion. Again performance here is key just like builders responding to validators with the full block payload.

Known Issues
The top 5 builders make up 85%+ of blocks that go on-chain, but different builders have different characteristics and each Wallet-Boost operator may not want to work with certain builder’s for certain reasons. How does this impact the User’s transaction execution speed?
Current implementation does not require any change from the user. They need to construct a swap with a marketable gas price, sign it and submit it. In the backend, it is being submitted through the Wallet-Boost private auction vs. the public mempool. What is the best way to let the user know that they MAY BE eligible for a rebate, but it is TBD? As the auction is happening, you could show the User in real-time their expected rebate.
What is the best option In the case where neither the bundle of 1 nor the MEV Rebate bundle is included in the next block?
Repeat the auction after the next block
Do nothing and let one of the builders eventually include it in a block (similar to low gas price in the mempool, eventually it will get included)
Signal a message to the user and give them options to do a speedup, send publicly, repeat auction etc.
Who sends MEV rebate bundle, the searcher or Wallet-Boost? Our current thinking is to have the Searcher trust Wallet-Boost with their signed transaction. Searcher’s are more incentivized to game the system maliciously for profit than a wallet. Wallet’s build their reputation over years with all parties and this would now include searcher’s. There is no direct economic gain for a Wallet to ‘attack’ a searcher by mishandling their signed transaction. In the future it may be possible to explore schemes which bond searchers to incentivize fair play.
Searcher sends the bundle,
Pros: Lower latency (there are less steps), so more time to ensure successful auction
Cons: Must trust the searcher with the User’s signed transaction
Wallet-Boost sends the bundle
Pros: Don’t have to trust searchers with User’s signed transaction
Cons: Requires one extra step, which might not leave enough time for a successful auction. The searcher has to trust Wallet-Boost with their signed transaction.
If Wallet-Boost sends the MEV rebate bundle, the searcher would not be credited for the bundle under the current Flashbots’ reputation system.
This may require pushing builder’s to update their reputation system to accommodate this scenario where Wallet-Boost is sending ‘on-behalf’ of a searcher
Optimistically sending the User’s signed transaction as a private bundle of 1 benefits the User from an execution speed standpoint, but gives builders the opportunity to exploit the User’s signed transaction themselves outside of the Wallet-Boost auction. They could theoretically sandwich or backrun the transaction and ignore any attempts from Wallet-Boost to replace the bundle of 1 with the MEV Rebate bundle.
You could only work with builders who support private transactions like Flashbots Protect where they guarantee you are safe from front-running + rely on builder reputation to honor Wallet-Boosts attempts to replace bundle of 1 with MEV rebate bundle.

Future Work
Reduce the trust that searchers must place on wallets running Wallet-Boost
Work with Builder’s to give ‘credit’ for Wallet-Boost bundles to the searcher under the builder reputation system instead of the wallet
ERC-4337 ushers in a new paradigm for user wallet interaction. This new architecture also opens up the aperture of the MEV rebate design space.

Sequence Diagram
Link

Mock Wallet-Boost API
WalletBoostNode:

Takes in user’s signed transaction
Calls boost_publishAuction
Calls eth_sendBundle to all builders
(w *WalletBoostNode) boost_publishAuction(utx *unsignedTransaction) error
Adds unsignedTransaction to UnsignedMempool
Broadcasts unsignedTransaction to anyone subscribed to WSS
(w *WalletBoostNode) boost_handleBid(bid *Bid) error
Takes in a bid payload
Adds it to appropriate auction
Respond to searcher with confirmation
Return error or nil
(w *WalletBoostNode) boost_handleAuctionWinner() error
For each auction in Auctions
Sends winner payload to Searcher
Expects 200 and Signed Transaction response
Returns error or nil
(w *WalletBoostNode) boost_handleWinningBundle(bid *Bid) error
Takes in a bid
Checks bid.signedTransaction is not nil
Builds bundle with user’s transaction and searcher’s transaction
Sends a replaceBundle to builders
Other:
(w *WalletBoostNode) boost_run()
Starts WSS
(w *WalletBoostNode) SubscribeHeaders() error
Subscribes to ‘NewHeads’ via w3Provider
Calls filterConfirmedTransactions
Calls broadcastUnsignedTransactions //Only if we are attempting to repeat auction
Returns error or nil
(w *WalletBoostNode) FilterConfirmedTransactions(b*block) error
Takes new block and current unsignedQueue and filters out the Confirmed Transactions in the new block from the unsigned Queue
Returns an error or nil
(w *WalletBoostNode) RegisterBuilder(url string) bool
Registers a new builder
Return true if successful, false otherwise
(w *WalletBoostNode) BlockSearcher (address string) bool
Blocks a searcher address if malicious behavior
Returns true if successful, false otherwise
Types:
Bid struct {
bribe *Big.Int
userTxHash string
tx *UnsignedTransaction
Searcher *Searcher
stx *SignedTransaction
}
Auction struct {
highestBid *Big.Int
highestBidder *Bid
}
Searcher struct {
eoaAddress string
smartContractAddress string
Blocked bool
//future reputation metrics
}
Builder struct {
RpcUrl string
}
Bundle struct {} //see Flashbots doc
SignedTransaction struct {
utx *UnsignedTransaction
V *Big.Int
R *Big.Int
S *Big.Int
}
UnsignedTransaction struct {
chainId, nonce, value, gas, etc
txHash string
}
UnsignedMempool struct {
utxs []*unsignedTransaction
}
WalletBoostNode struct {
web3Provider string
u *unsignedMempool
builders map[*Builder]bool
searchers map[*Searcher]bool //clients
register chan *Searcher
unregister chan *Searcher
userSignedTransactions chan *SignedTransactions
bidsChan chan *bid
winnerSignedTransactions chan *bid
Server *http.Server
Auctions map[txnHash string]Auction
}