It's always been possible to submit transactions to Flashbots for frontrunning protection. But it hasn't always been easy to do so.
The Flashbots Auction is powerful but submitting transactions has required new tools and new ways of thinking about those transactions.
For example the Flashbots Auction uses "bundles" and not transactions as the relevant object
As you can see in this image, bundles include transactions, but have other fields too
That means you can't natively send transactions to Flashbots, you need to wrap them in bundles
Another example: in the image you might have noticed Flashbots allows you to target a specific block number for inclusion!
That's a powerful feature for users, but it requires that users to send a bundle for every block, and thus you need new tooling to deal with that
Flashbots Protect API abstracts away this complexity for devs: simply pass us a signed transaction and we'll bundle it, repeatedly submit it, and update you on its status
There are two ways to integrate - a websocket or posting a JSON RPC message (eth_sendRawTransaction)
The first product to use the Flashbots Protect API is the Flashbots Protect RPC 🙂
The Flashbots Protect RPC is an RPC endpoint that users can add to their MetaMask which sends all of their transactions to Flashbots
On the backend the RPC endpoint will smartly manage the submission of transactions.
If it's clear a tx doesn't need frontrunning protection (eg: simple ETH transfers) we'll pass it to the mempool.
Otherwise all txs are sent to the Protect API, which submits them to Flashbots!
🥪 bots watch the mempool for users buying on DEXes and 🥪 them:
1.🥪bot buys an asset to push the price up 2. victim buys at an inflated price, pushes price up more 3. 🥪 bot dumps at a profit at the victim's expense
Today Flashbots is releasing v0.4 and introducing mega bundles to the Flashbots Network
Mega bundles will let us innovate faster, support more bundles and will lead to new searcher strategies and more miner revenue
A thread on mega bundles 🧵👇🏻
Flashbots is an open MEV marketplace. On 1 side of the market users submit "bundles" of txs. On the other miners run an auction & place the highest gas price bundles at the top of blocks.
This allows miners of any size to extract MEV, which is important for economic security.
In the early days of Flashbots only 1 bundle could be included in a block. That greatly limited our impact.
Our v0.2 release introduced multiple bundles per block through a merging process & gave miners control the number bundles they wanted to include
Contrary to Multicoin's claims, minimizing MEV is core to Flashbots' mission & products.
That shows from our funding of fairness and ethics research, work on MEV aware dApps, & 100s of users that have used Flashbots to skip the mempool & protect themselves from frontrunning.
More importantly, Multicoin is lying about Eden: it is not permissionless OR transparent.
Eden is a permissioned system with a multisig that has exclusive control over MEV payouts to miners. The Eden team alone decides whether miners are mining "Eden blocks" and should be paid.
Dropping what is probably the most alpha packed thing I've written so far: an in-depth writeup of my strategy for a highly competitive MEV opportunity, the Synthetix Ether Collateral Liquidations, along with code
Blog post contains:
- My process from start the finish
- Explanation of why I made the design decisions I did
- How I sped up data collection
- A few gas optimizations
- Explanation of my economic strategy
- My novel bundle submission strategy
- Code snippets
- Many links
Repo contains:
- The only (I think?) open source example of how to backrun transactions
- Monitoring tools I made
- Contracts used for execution, including dydx flashloan
- Contract for data collection
- my somewhat embarrassing messy Hardhat testing env