n!
├── features
│ ├── bundle rebates
│ └── mev-capturing managed mempool
├── for searchers
│ ├── supported mev rpc methods
│ ├── cancellations
│ ├── priority
│ └── block building algorithm
├── for users
│ └── rpc endpoints
├── revenue
├── privacy & censorship
└── relays
features
- bundle rebates
- mev-capturing managed mempool
bundle rebates
Stop overpaying for your bundles.
Our builder will compete to find the lowest price for your bundle. If we can include your bundle and win the block for a profit, a portion (or all!) of the bundle's value will be returned via a rebate transaction. Motivation. Searcher-builders have an advantage since there is some visibility into the block building auction. If you overpay for a bundle, some builders will keep the difference. This is especially true for more long-tail MEV, since there is greater uncertainty in what the winning bid will be.
How it works.
- Attempt to build the highest value block.
- Decide what to bid and determine profit.
block_value - block_bid = block_profit
-
For each bundle in the block, determine its contribution to the
block_value
.
This leads to the rebate value.bundle_contrib_ratio = bundle_value / block_value
bundle_rebate = bundle_contrib_ratio * block_profit
- Rebates are paid to the sender of the last transaction in the bundle and are included at the end of the block. This was done for full compatability with existing Flashbots MEV RPC methods.
For example.
Alice submits a bundle worth 50eth. The builder builds a block worth 100eth with Alice's bundle included and decides to bid 50eth. Since Alice contributed 50% of the blocks value, she will receive a rebate equivalent to 50% of the blocks profit. This this case, the block profit is 50eth. The block is won and Alice receives a 25eth (minus transfer fee) rebate.
Notes.
- Private transactions are also eligible for rebates.
- By sending the same bid to other builders, you are effectively bidding against yourself.
- Bundle payment should be thought of as your max payment.
mev-capturing managed mempool
Entitle users to a share of the MEV created by their transactions.
Users submit transactions to the our backrun rpc (rpc.nfactorial.xyz
). These transactions are stored in our private mempool. Searchers can query the state of this mempool for the unsigned transaction bodies and the respective transaction hashes (via txpool_backrunContent
). Searchers submit bids to backrun these transactions (via eth_sendBackrunBundle
). That is, searchers bid for the right to capture the MEV created by transactions in the pool. Winning bids are choosen through a first-price sealed-bid auction. A minimum 75% of the winning bid is returned to the user, while the remaining 25% is variable and depends on the demand for blockspace. Note that since all transaction bodies are public, this does not protect against front-running.
For example.
Bob submits a transaction to trade two tokens on Uniswap. Unbeknownst to Bob, his transaction will create a 1eth arbitrage opportunity. Alice polls for new transactions to our managed mempool, observes Bob's transaction, and detects the arbitrage. Alice submits a bid of 0.9eth to execute her arbitrage transaction after Bob's transaction to capture the 1eth in MEV created by Bob. Alice wins the auction and the builder wins the block as well. Demand for blockspace is low, so Bob is able to recoup 90% of Alice's winning bid. Alice profits 0.1eth, 0.09eth is contributed toward the block reward for the proposer, and 0.81eth (minus transfer fees) is sent to Bob.
for searchers
supported mev rpc methods
-
eth_sendBundle
(show/hide) -
eth_cancelBundle
(show/hide) -
eth_sendPrivateTransaction
(show/hide) -
eth_cancelPrivateTransaction
(show/hide)