> ## Documentation Index
> Fetch the complete documentation index at: https://docs.primev.xyz/llms.txt
> Use this file to discover all available pages before exploring further.
# Fast Protocol Economics & Mev Distribution Model
This document explains how **FAST RPC**, **mev-commit**, and the **Fast Protocol** collectively capture, route, and redistribute mev. It aims to give engineers, integrators, and validators a clear understanding of the value flows, incentive design, and equilibrium properties of the system.
***
# Summary
Fast Protocol transforms mev into a transparent, shared, incentive-aligned mechanism:
* **Users** receive top-of-market mev refunds (≥90%, even >100%)
* **Validators** earn strictly more when opting in, and materially more than in other OFA systems
* **Builders** maintain sustainable margins while delivering transactions
* **The protocol** becomes more valuable as usage increases, creating a positive feedback loop
No competing OFA can sustainably provide higher user mev refunds than Fast Protocol. The design is mathematically constrained, incentive-compatible, and self-stabilizing under normal market conditions.
## Overview of Fast Protocol
FAST RPC adds an **order flow auction (OFA)** on top of **mev-commit**. When users send transactions through FAST RPC:
* The RPC auctions and simulates backruns
* Mev is realized through backrun bundles
* Builders commit via mev-commit
* A portion of the mev goes to validators, depending on opt-in status
* The rest flows into the **mev distribution contracts**, forming the basis of tokenized mev rewards
The system ensures:
* Users receive **≥90%** of the mev their transactions generate when feasible
* Opted-in validators earn **significantly more** mev than non-opted-in validators
* The protocol achieves a **unique equilibrium** where no competing OFA can sustainably pay users more
***
# MEV Flow & Core Definitions
## MEV Components
For each mev-commit bundle:
$$
M_{bundle} = M_{bid} + M_{priority} + M_{direct}
$$
Where:
* $M_{bid}$ — the builder's decayed commitment
* $M_{priority}$ — sum of transaction priority fees
* $M_{direct}$ — any explicit builder payment
We also define:
* $M_{rpc}$ — total mev generated by FAST RPC transactions
* $M_{block}$ — total mev in the block
* $\rho = \dfrac{M_{rpc}}{M_{block}}$ — share of block mev attributable to FAST RPC
* $\rho' = \dfrac{M_{bundle}}{M_{rpc}}$ — fraction of RPC mev appearing in bundles
***
## Fee Parameters
FAST Protocol uses two fees:
* **Mev fee on bundles:**
$$
\text{mev\_fee} = f_{mev} \cdot M_{bundle}
$$
* **Validator fee (opted-in only):**
$$
\text{val\_fee} = f_{val} \cdot M_{block}
$$
Typical values:
| Parameter | Value | Meaning |
| --------------- | ------ | --------------------------- |
| $f_{mev}$ | 0.05 | 5% mev fee on bundles |
| $f_{val}$ | 0.05 | 5% validator fee |
| $\mu_{builder}$ | \~0.10 | Builder’s margin on RPC mev |
***
# FAST RPC MEV Generation
## Per-Transaction MEV Estimation
For each transaction $tx$:
$$
m(tx) = \text{estimated backrun profit}
$$
Total mev driven by FAST RPC in a given slot:
$$
M_{rpc} = \sum_{tx} m(tx)
$$
***
# MEV Redistribution Model
Redistributed mev accumulates into a pool $T$ composed of:
* Builder mev fees ($f_{mev} M_{bundle}$)
* Validator fees ($f_{val} M_{block}$)
* Backrun-captured mev from non-opt-in slots
***
## User Distribution
Each user $u$ has a weight:
$$
w_u = \frac{M_{rpc}^{(u)}}{M_{rpc}}
$$
Their payout is:
$$
P_u = T \cdot \tau_{rpc} \cdot w_u
$$
Payout may be delivered in points or tokens depending on availability.
***
# User Refund Ratio (γ)
Define:
$$
\gamma = \frac{T \cdot \tau_{rpc}}{M_{rpc}}
$$
Interpretation:
* $\gamma = 0.9$ → 90% mev refund
* $\gamma > 1$ → users receive **more than 100%** of their generated mev
System objectives:
* Maintain $\gamma \ge 0.9$ under normal conditions
* Allow $\gamma > 1$ in mev-rich phases (treasury surplus)
***
# Adaptive Parameter Logic
The protocol continuously adjusts how much mev goes to users versus the protocol treasury based on how abundant mev is in a given period. Let:
$$
r = \frac{M_{rpc}}{T}
$$
The protocol adapts how value is split between users and treasury based on mev abundance, summarized by the parameter $r$.
***
## Case 1 — Scarce MEV
When mev relative to the redistribution pool is scarce (high $r$), the system caps what it can give back while preserving protocol sustainability.
We can express the scarce regime as:
$$
r > r_{\text{crit}}
$$
for some critical $r_{\text{crit}}$ corresponding numerically to:
* approximately $\dfrac{0.95}{0.9}$ in the original parameterization.
In this regime:
$$
\tau_{rpc} = \tau_{\text{max}}
$$
$$
\tau_{fast} = 1 - \tau_{\text{max}}
$$
with $\tau_{\text{max}}$ set so that users get as much as the system can afford (slightly under 90% refunds in the most constrained conditions).
***
## Case 2 — MEV Rich
When mev is abundant relative to the pool, i.e.
$$
r \le r_{\text{crit}},
$$
the protocol:
* Preserves at least a 90% user refund on average
* Allocates the surplus between users based on the share of mev they generate
* Keeps a minimum fraction of value for the protocol
We can express $\tau_{rpc}$ generically as:
$$
\tau_{rpc} = a \cdot r + b \cdot (1 - r)
$$
for suitable constants $a$ and $b$ chosen so that:
* Users always receive at least 90% of their generated mev on average
* The protocol receives at least 5% in total
Then:
$$
\tau_{fast} = 1 - \tau_{rpc}
$$
In practice, parameter choices are tuned so that:
* For typical orderflow conditions, $\gamma$ is around or above $0.9$
* In mev-rich conditions, $\gamma$ can exceed $1$, sharing surplus with users while still realizing value for protocol treasury
This ensures:
* Users always receive ≥90%
* Protocol always receives ≥5%
* Treasury surpluses enhance both sides proportionally
***
## Greater than 100% Refunds ("Casino Effect")
Because the total value returned to RPC users ($T$) can include both:
* **Immediate mev** generated in the current epoch
* **Historical value** previously accumulated in the treasury and redistributed in later epochs
it is possible for the effective refund rate ($\gamma$) to exceed 1.
### Interpretation
* $M_{\text{rpc}}$ — total mev generated by a user's transactions in the epoch
* $\tau_{\text{rpc}}$ — fraction of the distribution flow allocated to users
* $T$ — total ETH distributed from the treasury to all users in the epoch
When $\gamma > 1$, users receive **more than 100%** of the mev their transactions generated—an effect referred to as the **casino effect**.
This arises naturally when prior epochs accumulated surplus mev in the treasury, allowing later epochs to over-refund users.
***
# Validator Incentive Model
FAST Protocol is designed so that **opting in is rational and strictly profitable** for validators.
Opted-in validators gain:
* All backrun-captured mev from FAST RPC bundles
* Their share of traditional builder → validator mev
* Competitive advantage in attracting order flow
Non-opted-in validators receive only the small residual share left after RPC backruns and mev fees.
***
## Opt-in Profit Condition
Incremental profit from opting in:
$$
\Delta_{opt} = M_{rpc} \cdot (1 - \mu_{builder}) - f_{val} \cdot M_{block}
$$
Opt-in is profitable if:
$$
\rho > \frac{f_{val}}{1 - \mu_{builder}}
$$
With typical values ($f_{val} = 0.05$, $\mu_{builder} = 0.10$):
$$
\rho > 0.0555
$$
Meaning:
**If Fast Protocol generates more than \~5.6% of block mev, opting in and even paying a 5% fee is profitable.**
In practice, Fast Protocol exceeds this threshold comfortably.
***
## What Validators Earn
| Validator Type | Approx. RPC mev Capture | Reason |
| ---------------- | ----------------------- | ---------------------- |
| **Opted-In** | \~95% | Backrun mev + residual |
| **Not Opted-In** | \~5% | Similar to Mev Blocker |
Opted-in validators therefore enjoy **\~20× higher mev capture** on FAST RPC flows.
***
# Why FAST RPC Is the Best-Paying OFA
The equilibrium analysis shows:
* If FAST RPC offered **less** than 90% user refunds, users would defect to other options
* If an OFA tried offering **more**, its builders or validators would become unprofitable
* FAST RPC optimally balances incentives so validators, builders, the protocol, and users all remain profitable
Thus, no competing OFA can sustainably provide higher user mev refunds than Fast Protocol.
***
# Fast Swaps
Fast Swaps is a swap interface built on top of Fast Protocol that lets users trade tokens on Ethereum mainnet while earning mev rewards. Swaps are backed by mev-commit preconfirmations, routed through the [FAST RPC](/v1.2.x/get-started/fastrpc), and settled via the **FastSettlement** smart contracts on L1.
Start swapping and earning miles.
Technical deep-dive: architecture, contracts, and EIP-712 signing.
***
### How It Works
The swap flow follows a familiar DEX experience — select an input token, an output token, and an amount. Execution depends on the input token:
| Input Token | Execution |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
| **ERC-20** (e.g. USDC, DAI) | The user signs an off-chain EIP-712 intent. FAST RPC executes the swap via the FastSettlement contract — **no gas required from the user**. |
| **ETH** | The user submits the transaction directly from their wallet via `executeWithETH`. |
#### Permit2
ERC-20 swaps require a one-time [Permit2](https://docs.uniswap.org/contracts/permit2/overview) approval per input token. Once a token is approved, subsequent swaps with that token only require a signature. If Permit2 has already been approved for a given token on another application (such as Uniswap), no additional approval is needed.
For a full explanation of the swap architecture, smart contracts, pricing mechanism, and security model, see the dedicated [Fast Swaps](/v1.2.x/concepts/fast-swaps) page.
***
### Fast Miles
Users earn Fast Miles proportional to the mev their swaps generate through Fast Protocol. Miles are planned to be tokenized in the near future. Early users can also earn bonus miles through one-time tasks and referrals available in the app.
***
## Knowledge Base
Simplified FAQ overview of Fast Protocol for newcomers.