I think this is a cool idea!
Rationale
From the builder’s perspective, allowing searchers to backrun the block increases its value, so if they don’t do it, someone else will win the PBS auction (given that the extracted value is great enough). This comes with a concern that to do this; they have to share information about the block being built with the searchers. The least revealing solution I can think of is sharing the state changes of the built block. I am not sure how bad revealing slot changes actually is in practice, especially if the builder is transparent about it and users can take this into account, but I hear it is still a concern.
The SUAVE builder doesn’t have to reveal any information about the built block in order for searchers to backrun. In this case the searchers would be contracts called by the builder and the strategy can even remain anonymous if SUAVE can ensure no information can be leaked through the searching process.
SUAVE Block Backrunner POC with YakSwap
Almost three years ago, I built YakSwap, an aggregator that lives fully in the EVM. It is live today at Yield Yak | Earn More Yield and you can learn more about its usage at Yield Yak Analytics. Code can be found here. It supports most dexes including tick based ones (UniV3, TraderJoeV2…).
YakSwap and arbitrage
While YakSwap was designed to find the best path for their trades some users used it to find and executed atomic arbitrage opportunities that more advanced bots missed.
- Here is an example of YakSwap arb tx with ~$4000 profit.
- $250k was extracted via YakSwap in May 2022
- For more historical arbs or other info check out this Colab notebook.
YakSwap SUAVE block backrunning
Although, YakSwap cannot compete with optimized arbitrage setups the record shows it can nevertheless extract significant profits. Since its pathfinding logic lives fully onchain it is uniquely positioned to be a useful tool to extract atomic arbitrage at the end of the block on SUAVE.
YakSwap router and its adapters would need to be deployed on the settlement chain and then any SUAVE contract can call it to find arb.
In order to find opportunities at the end of a built block either state changes would need to be extracted from the built block and then passed into eth_call via state-override-set or SUAVE execution client would need to provide a way to access block building session after block is built.
Practical considerations
- Finding the best path for given amountIn, tokenIn and tokenOut with YakSwap can be quite slow depending on the computational intensity of dex logic and the amount of hop tokens and adapters. Restricting these parameters could cause missed opportunities.
- Multiple calls are required to find optimal amountIn which further increases the latency.
- I do believe there is a lot of potential optimizations to shave off latency, but it makes me wonder if it can be enough to compete with another block builder that will auction this off-chain by revealing storage slots or smth similar.
Would def love to discuss this further!