-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add docs for gas fee refunds #555
Merged
Merged
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
d71a1a7
Add docs for gas fee refunds
sketsdever 70e5e70
Add multiplexing and bundle stats instructions
sketsdever 115fefe
Explain smart bundles
sketsdever 8ca1a47
Correct prefix from eth to flashbots
sketsdever 2fdcb7a
Add refund rule
sketsdever b594532
Specify API users and update description of refund API
sketsdever 2e34d00
Fix build errors caused by link issues
odysseus0 File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,104 @@ | ||
--- | ||
title: Gas Fee Refunds | ||
--- | ||
|
||
## Introduction | ||
|
||
Searchers and private transaction API users are automatically eligible to receive gas fee refunds. If Flashbots can include a bundle on chain for a lower price, you are eligible to receive a refund. | ||
|
||
Gas fee refunds do not change how bundles are executed and searchers do not need to make any changes to be eligible for them. | ||
|
||
## Where do refunds come from | ||
|
||
Gas fee refunds include both priority fees and coinbase transfers. | ||
|
||
In an optimal case, searchers are refunded the difference between their bid and the bid of the next-best bundle or transaction targeting the same state. Ie. the refund effectively results in the searcher paying the second price. In practice, searchers will receive some fraction of this amount depending on how much profit the Flashbots builder makes. | ||
|
||
## Which bundles receive refunds | ||
|
||
Flashbots provides refunds for bundles in blocks landed by the Flashbots block builder. Whether a bundle receives a refund depends on a few factors that vary from block to block: | ||
* How much network congestion and competition there was | ||
* Whether the Flashbots builder made a profit and how much | ||
* How much the specific bundle contributed to the value of the block | ||
* If the bundle was sent directly to Flashbots, or shared with other block builders by the searcher | ||
|
||
## How to maximize both refunds and speed | ||
|
||
Transactions which are sent directly to the Flashbots Builder via the Bundle Relay, and not multiplexed _by the searcher_ to other block builders, are likely to receive higher refunds. This is because they increase the profit of the Flashbots builder which is used to provide refunds. | ||
|
||
The Flashbots block builder does not land 100% of blocks. In order to land bundles in all blocks, searchers can ask Flashbots to share their bundles with other block builders in cases where the Flashbots builder does not win a block. Flashbots will automatically share with all specified builders on the searcher's behalf. | ||
|
||
### Smart multiplexing | ||
|
||
To share bundles with other builders, add the `builders` field to your `eth_sendBundle` request. The `builders` field accepts a list of strings which correspond to the "name" tags of [registered builders](https://github.com/flashbots/dowg/blob/main/builder-registrations.json). | ||
|
||
All `eth_sendBundle` requests are shared with the Flashbots builder. They are multiplexed to other block builders at the end of the slot if the Flashbots builder determines it will not win that block. | ||
|
||
For example: | ||
|
||
``` | ||
{ | ||
"jsonrpc": "2.0", | ||
"id": 1, | ||
"method": "eth_sendBundle", | ||
"params": [ | ||
{ | ||
"txs": ["0x123abc...", "0x456def..."], | ||
"blockNumber": "0xb63dcd", | ||
"minTimestamp": 0, | ||
"maxTimestamp": 1615920932 | ||
"builders": ["builder0x69", "beaverbuild.org"] | ||
} | ||
] | ||
} | ||
``` | ||
|
||
Searchers can also use `mev_sendBundle` to multiplex bundles if they prefer. Though this method is more complex and not necessary for gas fee refunds. | ||
|
||
_Note: Smart multiplexing has a 1% rate of false positives, meaning that in 1% of MEV-Boost blocks there is a risk that searcher bundles will not be landed._ | ||
|
||
### Bundle stats for multiplexed bundles | ||
|
||
To view bundle stats on multiplexed `eth_sendBundle` requests, use the `flashbots_getSbundleStats` API. You will see a new "smart" field in the response to multiplexed `eth_sendBundle` which indicates that the sbundle stats endpoint should be used. | ||
|
||
## How are refunds calculated | ||
|
||
The Flashbots builder uses a refund rule to retroactively calculate refunds for all bundles landed in its blocks. | ||
|
||
The refund rule aims to have bundles make the minimum net payment so that bidding optimally is as straight forward as possible. We do this by measuring the contribution of bundles above the other bundles the builder has received, and refunding as much of that as possible. | ||
|
||
Bundles sent by the same signer will be treated as non-competitive. | ||
|
||
### The Flat Tax Rule | ||
|
||
<div className="med caption-img"> | ||
|
||
![Flat tax rule](/img/flat-tax-rule.png) | ||
|
||
Definition of the flat tax rule | ||
|
||
</div> | ||
|
||
Notice that if the block generates enough value after paying the proposer, everyone should be refunded their contribution, meaning everyone pays the minimum they need to pay to beat competition. | ||
|
||
### Identity constraint | ||
|
||
To avoid the rule being gamed by submitting bundles from multiple identities, we impose an additional constraint that no set of identities can receive in total more refunds than they contribute to the block. | ||
|
||
<div className="med caption-img"> | ||
|
||
![Identity constraint](/img/identity-constraint.png) | ||
|
||
Definition of the identity constraint | ||
|
||
</div> | ||
|
||
## Who receives refunds | ||
|
||
The refund recipient is the signer used on the `eth_sendBundle`, `mev_sendBundle`, or `eth_sendPrivateTransaction` request. | ||
|
||
## How to track refunds | ||
|
||
Refunds are tracked from a start date of July 8, 2024. Via an upcoming API, users will be able to: | ||
* View unclaimed refund amounts | ||
* Delegate refunds to an Ethereum account other than their signing key address. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,47 @@ | ||
--- | ||
title: Gas Fee Refunds | ||
--- | ||
|
||
## Introduction | ||
|
||
Flashbots Protect users are automatically eligible to receive gas fee refunds. If Flashbots can include your transaction on chain for a lower price, you are eligible to receive a refund. This applies to both the RPC and the private transaction API. | ||
|
||
Gas fee refunds do not change how transactions are executed and users do not need to make any changes to be eligible for them. | ||
|
||
Gas fee refunds are calculated separately, and applied in addition to, refunds from [MEV-Share](/flashbots-protect/mev-share). | ||
|
||
## Where do refunds come from | ||
|
||
Users and orderflow providers (like wallets) often pay high priority fees to land transactions on chain. Many of these transactions could be executed just as quickly for a fraction of the gas cost. | ||
|
||
It can be difficult to estimate gas correctly when sending a transaction. The Flashbots block builder calculates this on behalf of users and automatically refunds transactions that overpay. | ||
|
||
Gas fee refunds include both priority fees (more common in user transactions) and coinbase transfers (less common). | ||
|
||
## Which transactions receive refunds | ||
|
||
Flashbots provides refunds for transactions in blocks landed by the Flashbots block builder. Whether a transaction receives a refund depends on a few factors that vary from block to block: | ||
* How much network congestion and competition there was | ||
* Whether the Flashbots builder made a profit and how much | ||
* How much the specific transaction contributed to the value of the block | ||
* If the transaction was sent directly to Flashbots, or shared with other RPCs and block builders | ||
|
||
## How to maximize both refunds and speed | ||
|
||
Transactions which are sent directly to the Flashbots RPC or API, and not multiplexed _by the user_ to other RPCs or block builders, are likely to receive higher refunds. This is because they increase the profit of the Flashbots builder which is used to provide refunds. | ||
|
||
The Flashbots block builder does not land 100% of blocks. In order to improve inclusion speed, users can ask Flashbots to share their transactions with other block builders in cases where the Flashbots builder does not win a block. Flashbots will automatically share with all specified builders on the user's behalf. | ||
|
||
There are two ways to share with other builders: | ||
* Use [fast mode](/flashbots-protect/quick-start#faster-transactions) to share with all registered builders | ||
* Choose [specific builders](/flashbots-protect/mev-share#builders) to share transactions with | ||
|
||
## Who receives refunds | ||
|
||
For the RPC: The refund recipient is the address specified in the first [refund parameter](/flashbots-protect/mev-share#refunds) on an RPC request, if one is provided. Otherwise, refunds are sent to the transaction originator (`tx.origin`) by default. | ||
|
||
For the private transaction API: The refund recipient is the signer used on the `eth_sendPrivateTransaction` request. | ||
|
||
## How to track refunds | ||
|
||
Refunds are tracked from a start date of July 8, 2024. Users wil be able to view unclaimed refund amounts via an upcoming API. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought we were defaulting to msg.sender unless there was an override?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true for protect (tx.origin not msg.sender to be precise). For anything sent directly to the bundle relay it's the signer because signer is always provided and this allows for separating eg. bot address from refund recipient which affords more privacy.