> ## Documentation Index
> Fetch the complete documentation index at: https://primev-24-aloknerurkar-patch-7.mintlify.site/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.