n!


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

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.

  1. Attempt to build the highest value block.
  2. Decide what to bid and determine profit.
    block_value - block_bid =  block_profit
  3. For each bundle in the block, determine its contribution to the block_value.
    bundle_contrib_ratio = bundle_value / block_value
    This leads to the rebate value.
    bundle_rebate = bundle_contrib_ratio * block_profit
  4. 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.

  1. Private transactions are also eligible for rebates.
  2. By sending the same bid to other builders, you are effectively bidding against yourself.
  3. 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

cancellations

Cancellations are best-effort. We cannot gurantee that your bundle/transaction will not be included in the next block, but we will remove it from all built blocks following the cancellation request.

priority

The X-Flashbots-Signature (source: flashbots) header is recommended, but is not necessary. At the time of writing, there is no searcher priority. However, priority bundle processing will be added in the future. We plan to have 3 levels of priority.

  1. low
  2. high (function of bundle inclusion rate)
  3. fast (function of bundle inclusion volume)

high priority bundles will have preference over low priority bundles during periods of high volume. fast priority bundles will be delivered to the builder via pubsub, minimizing time-to-inclusion.

block building algorithm

We use a form of symbolic execution to build our blocks. We will attempt to find the best place in the block for you bundle. So, even if your bundle reverts top-of-block (e.g. attempting to backrun another bundle), it will still be included in the block building process.

for users

rpc endpoints

We offer two rpc endpoints for users. Both endpoints protect against reverting transactions. If we cannot land a block that includes your transaction within 15 blocks, we will send it privately to other builders.

revenue

Our builder aims to profit through extracting "pure" MEV (i.e. re-ordering public transactions). We do not take any direct profit from searchers/users, hence our rebate mechanism. Our goal is to redistribute block profit to the entities that helped contribute to the block's value.

privacy & censorship

We do not store any information outside of bundle/transaction content and we are OFAC compliant.

relays

Blocks are sent to the following relays.