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:

---

​

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

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.