# wallet-boost v0.2

:::success
:bulb: Thank you to all the wallets, searchers, and pirates for their feedback and conversation around OFAs! We've incorporated those learnings and presented some discussion questions below into `v0.1`!
:::


## Wallet-Boost v0.1

We loved spending time (IRL!) with our various partners, users and frens at ETHDenver, especially as it relates to our latest endeavor, Wallet-Boost (original spec [here](https://github.com/blocknative/discourse/discussions/1)). We are taking the lessons learned from ETHDenver and the Flashbots OFA workshop to bring you Wallet-Boost v0.1. Wallet-Boost v0.1 builds on the design goals of the original spec, but introduces some new ideas and directions for Wallet-Boost, namely, Wallet-Agency, Programmable Privacy and sharpened design objectives.

#### Proposer-agency meet wallet-agency

With the shift to MEV-Boost, the validator ecosystem has shown a varying degree of preferences as it relates to block construction. We believe, proposer agency is an important attribute to maintain because of the diverse nature of entities that operate validators and further, we believe wallets via Wallet-Boost will embark on a similar journey. Currently, Wallets do not have any influence in the MEV supply-chain, despite being key components. Wallet-Boost gives wallets the tools to influence and choose MEV outcomes for their users in the MEV supply chain. Wallet-Boost starts with the notion that wallets are a diverse set of actors with different needs and therefore should have the wallet-agency to control their own destiny. Because wallets care about every pixel that their users experience, Wallet-Boost is designed to fit in with the wallet experience instead of trying to have wallets fit into the OFA experience.

#### A path to programmable privacy

Programmable privacy (H/T to Flashbots and [MEV-Share](https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264)), gives users the ability to express their preferences (and protect themselves) by providing only the information they want to in order to participate in the MEV extraction process. Not surprisingly, searcher’s want as much information as possible to make the most efficient and optimal trade possible. With auctions that have built-in privacy, some MEV strategies either become impossible or shrink substantially like atomic strategies due to their small margins. These atomic strategies are hyper competitive and significantly focused on gas efficiency vs. latency. Comparing these atomic strategies to the statistical strategies that are more popular today (higher margins), does shrinking or eliminating atomic strategies lead to more centralizing outcomes where the trade-off is user privacy and searcher efficiency? Or does it matter and the statistical strategies will ‘crowd out’ the atomic strategies regardless of the OFA’s user privacy choices? Further, just because the searcher is not able to efficiently extract the MEV within the same block, then that MEV extraction will just move to the regular auction process we see today in the subsequent block where searcher’s will compete to builders to take the top slot. This means that MEV will end up with the builders and/or validators instead of the users. Given these dynamics, our current view is to maintain the same or similar level of information for searcher’s, while also providing a pathway to integrate user privacy in future iterations as we conduct more research on the trade-offs.

#### Sharpening our design objectives

As we continue our conversations with wallets, searchers, builders and users, we have a clearer vision on the short-term design objectives for Wallet-Boost. Specifically, we are narrowing our design objectives to the following:

1. **Wallet Agency** - Wallet’s want to extend their current experience to include MEV-rebates, but not necessarily overhaul it. Wallet-agency means giving wallets the tools to control the UI/UX experience within the current context of their wallet. A key component of that is to introduce MEV awareness to their users. This is a net new consideration for wallets and as such, each wallet should be able to choose how or if they want to show rebates to their users at all. Wallet-Boost is configurable, so that wallets or users can receive the rebate (or both!) and this decision has implications on the UI/UX of the wallet.

2. **Common Interface** - With other entities building similar MEV-rebate OFAs, the feedback from potential participants is that OFAs should create a modular interface that is plug-and-play for wallets, searchers and builders. None of these entities will want to accommodate different standards across different OFAs, so Wallet-Boost will optimize for a modular design around a common interface. Specifically that means incorporating the following 3 concepts:
* The searcher will no longer include the MEV-rebate in their bundle, but instead Wallet-Boost will send bundles that include the MEV-Share style options for eth_sendBundle (refundPercent and refundRecipient), so builders will be trusted to make the transfer payments
* Instead of collecting unsigned bids from searchers, every bid will be a signed bid where Wallet-Boost operators will attempt to include the highest bid once the user signs their transaction. If the bundle fails simulation, Wallet-Boost will repeat on the next highest bid until a bundle is successfully simulated, otherwise Wallet-Boost will send the transaction as a bundle of 1.
* Wallet-Boost will default to show searchers the full unsigned payload, but there will be an option to include privacy conditions in a future iteration as outlined by MEV-Share.

3. **Open** - While the initial proof of concept will be through a select group of wallets and searchers, the goal is to open up Wallet-Boost for any wallet or searcher to participate after a successful PoC.

4. **User Agency** - Our original design did not incorporate the idea that user’s have varying degree of privacy preferences and instead assumed a maximal information system all of the time. Wallet-Boost will initially start out its PoC by sharing the full transaction details with searchers, but we will leave the door open to adding programmable privacy in the future.

#### Updated Example Flow

Many wallets today simulate their user’s transactions before they sign and submit it to the network. The user will construct their desired transaction and the wallet will simulate the transaction against current block state, relaying the exact outcome (ie. net balance changes) of the desired transaction back to the user. The time between constructing the transaction and receiving the simulated result is known as the ‘intent layer’. Wallet-Boost intends to start the auction flow at the intent layer. The primary flow will consider four main events:
1. Triggering a new auction (boost_startAuction)
2. Broadcasting the new auction (boost_publishAuction)
3. Add incoming bids to set of auction bids (boost_handleAuctionBid)
4. Choose winning bid and send bundle to builders (boost_handleAuctionWinningBid)

The goal of our mock auction is to optimize for multiple variables, mainly:
- Execution speed
- Maximal MEV rebate to transaction originator
- Minimal trust in participating actors

Mock Flow:
1. User constructs a swap transaction and receives the simulated result back. Once the simulation is received by the user, Wallet-Boost will call boost_startAuction creating a new auction for Wallet-Boost to track.
2. When a new auction is added to Wallet-Boost, Wallet-Boost takes the unsigned transaction and calls boost_publishAuction which adds it to Wallet-Boost’s unsigned transaction mempool.
3. Searchers can subscribe to events on Wallet-Boost’s unsigned transaction mempool and receive real-time notifications on new auctions.
4. Searchers evaluate unsigned transaction events and bid with signed transactions on any profitable MEV opportunities.
5. Wallet-Boost receives bids and calls boost_handleAuctionBid, which adds the bid to the list of auction bids, and acknowledges receipt to the searcher.
6. When the user signs and submits the transaction through their wallet, Wallet-Boost calls boost_handleAuctionWinner, which stops the auction, chooses the highest bid, simulates it, if successful sends it as a bundle, if unsuccessful, repeats on the next highest bid until either a bundle has been sent or the user’s transaction is sent as a bundle of 1 if there are no successful matches.
7. The bundle will use the refundRecipient and refundPercent as outlined in MEV-Share and now seen in builder0x69’s documentation.
8. The builder will include the bundle based on this validity condition and send a transfer payment to the recipient as the MEV-rebate

Sequence Diagram


Key Considerations and Known Issues

**Trust** - Trust considerations have shifted in v0.1 in order to converge on a common interface. All searcher bids are now signed transactions and therefore must trust the Wallet-Boost operator. Searcher’s no longer are making the MEV-rebate payment in the their bundle, but instead Wallet-Boost intends to use the MEV-Share mechanism of having builders add in refundPercent and refundRecipient as optional parameters for eth_sendBundle and pushing the trust on builders to correctly make transfer payments for MEV-rebates.

**Latency** - The latency requirements have decreased since the searcher is always sending signed transactions as bids instead of unsigned transactions. Therefore, Wallet-Boost has eliminated the step where it goes back to the winning searcher to ask for the signed transaction. While this increases the overall trust of the system, it does decrease the communication and therefore latency requirements by the Wallet-Boost operator and participating searchers.

**Wallet Considerations** - Wallet’s operating Wallet-Boost need to consider the following configurations:
- MEV-rebate recipient (the user or the wallet).
- Whether or not to outsource the infrastructure requirements to run Wallet-Boost to a trusted 3rd party (and the potential risks associated with this choice) or operate it themselves
- UI/UX of showing the user’s rebate if the rebate goes to the user

**User Considerations** - If the wallet chooses to send the MEV-rebate directly to the user, then user’s will potentially need to consider a refundPercent parameter or the wallet will need to have a default setting explicitly or implicitly behind the scenes. In the future, Wallet-Boost will allow users to reveal some or all of the transaction details to the searcher’s to give user’s greater programmable privacy options

**Builder Considerations** - Builders will need to allow for refundPercent and refundRecipient as outlined in builder0x69’s documentation. Builders are now trusted actors that must send the MEV-rebate payment to the recipient address

**Searcher Considerations** - Wallet-Boost will provide searchers with the full transaction information, so there are minimal considerations for searchers to participate in Wallet-Boost auctions. The time between a user composing their transaction and signing the transaction may be very short, so user’s will want to operate low-latency infrastructure in order to have their potential bids considered by Wallet-Boost

#### Wallet-Boost API v0.1 (DO WE NEED THIS - Can be added if needed)