# wen shield swap info?/deriving mev-share defaults

I swap $50 -> No Shield!
I swap $10mil -> Shield!
I swap $1000 -> ???

Programmable privacy, as introduced by [mev-share](https://collective.flashbots.net/t/mev-share-programmably-private-orderflow-to-share-mev-with-users/1264), allows users to control how much information about their transaction a searcher can see. This awesome capability allows users to share their orderflow without having to worry that their tx info will be used to trade against them. But where exactly is the line for revealing information for a simple swap? Can we create rough guidelines for users to follow? Give recommendations? Make an informed default?

***Note : This document focuses on swaps only.***

## 🚪 user scenarios

Below is a matrix evaluating whether a user would:
`shield info (✅)`
or
`not shield (❌)`
depending on their sophistication, time sensitivity, and price sensitivity.


Notable columns to highlight:

- ***Sophisticated, price sensitive, time insensitive*** - would most likely `not shield (❌)` as they can split their order up into multiple smaller batches and settle over time.
- ***Sophisticated, price sensitive, time sensitive*** - Although this case is marked as `shield info (✅)`, most sophisticated users would split this trade up over time. But if the basefee is high, splitting trades up amongst multiple orders may be inefficient.
- **Unsophisticated, time sensitive, price insensitive** - would most likely `shield info (✅)` as they do not want to be front-run.

## 🪤 searcher responses

Let's assume searchers do have access to the full tx info coming out of `mev-share`.

*Important to note that unshield in this case still means the searcher does not have access to the unsigned txn.*

- **Low Value Swap** ➡️ Nothing
- **High Value Swap, Liquid Pools** ➡️ Take opposite side on DEX
- **High Value Swap, Illiquid Pools** ➡️ Optimistically sandwich*

Thus alongside swap size, we have another dimension to consider, liquidity of underlying pools.

### High Value Swap, Liquid Pools
< need thoughts on how a CEX<>DEX arb'er would treat this scenario >

### High Value Swap, Illiquid Pools ➡️
Optimistically sandwiching is with risk. Let's say the searcher learns of the user's tx `T` half way through `block 100`, then the searcher's expected value is:
`E[trade] = p(included_before_T) * profit_from_arb - (1 - p(included_before_T)) * cost_of_failed_arb`

In this scenario the searcher can almost gurantee that the tx `T`, once fully through the `mev-share` process and included by a builder, will include a backrun tx right after it. Thus the only way to profit from this information is to include a txn purchasing the desired coin beforehand, and selling at some unknown time once `T` has settled.

^^^ The above are just proxy for "price impact", this might be a better way to breakdown the section.

## ⚙️ execution costs

- ***backrun*** - find min gas costs, atleast 1 uniswap trade.
- ***CEX trade*** - ??? cost of being wrong - CEX rebate ???

## ⚗️ putting it all together

***example 1: $1,000 USDC to Eth***
- pool price impact =
- expected profit =
- expected cost =

***example 2: $1,000,000 USDC to Eth***
- pool price impact =
- expected profit =
- expected cost =

***example 3: $1000 Shib to Eth***
- pool price impact =
- expected profit =
- expected cost =