> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fx.meme/llms.txt
> Use this file to discover all available pages before exploring further.

# $FX and protocol revenue

> How eligible revenue becomes reserved USDC, market purchases, and dead-address delivery.

FX's revenue mechanism connects launchpad activity to the official \$FX token.

**90% of eligible realized USDC is reserved for market purchases of the registered \$FX token. The remaining 10% goes to operations.**

Every token acquired with the reserved allocation must be delivered to the configured dead address.

## Follow the revenue

```mermaid theme={null}
flowchart TB
    L["Launch fees · USDC"] --> V["Protocol revenue vault"]
    T["Protocol trading fees<br/>and opening surcharges"] --> C["Revenue collector"]
    C -->|"USDC: forward directly"| V
    C -->|"Other currencies"| X["Approved conversion pool"]
    X -->|"Actual USDC received"| V
    F["Official FX creator fees"] --> V
    V -->|"90%"| B["Reserved buyback budget"]
    V -->|"10%"| O["Operations"]
    B --> P["Canonical FX / USDC market"]
    P --> D["Acquired FX → dead address"]
```

A 10-USDC launch fee reserves 9 USDC and pays 1 USDC to operations in the same launch transaction.

Foreign fees remain buffered in their original assets until conversion. Conversion fees and execution losses reduce the USDC actually received. Only that receipt enters the split.

## What counts as eligible revenue

Eligible sources include launch fees, FX protocol trading fees, opening surcharges, and the official \$FX market's dedicated creator allocation.

Ordinary creator fees, holder rewards, LP earnings, and locked LP principal have their own owners and accounting. They are excluded from the buyback budget.

Direct contributions are tracked separately from organic protocol use. Fees generated by the vault's own \$FX purchases are also labeled as recycled revenue.

## Buy and burn, precisely

The product calls this mechanism **buy and burn**. Its onchain implementation is a market purchase followed by a transfer to:

```text theme={null}
0x000000000000000000000000000000000000dEaD
```

It is not an ERC-20 supply-reducing burn. The official token's `totalSupply` stays fixed, and the executor verifies exact delivery of the acquired tokens.

Fully diluted valuation can still change with the market price. Dead-address delivery does not establish a price floor or guarantee appreciation.

## One official token

A dedicated factory path creates and registers official \$FX in one atomic transaction. Successful registration permanently binds the token and canonical market.

A name or symbol cannot confer official status. Use the factory's registered `protocolToken()` address. At the latest [mainnet check](/reference/release-status), it was the zero address: official FX had not yet been launched.

The dedicated market has a 0.10% protocol fee, a 0.50% creator allocation permanently payable to the revenue vault, and a 0.20% native LP fee. It has no holder rewards or builder allocation.

## When a purchase can execute

Execution is permissionless, subject to the installed policy. The deployed R6 policy requires a **minimum gross purchase of 100 USDC** and has no fixed per-purchase maximum.

The actual amount is still bounded by reserved funds, remaining rolling spend allowances, canonical liquidity, and the execution impact limit. The absence of a fixed per-purchase maximum does not mean unlimited spending.

Liquidity observations, checkpoint freshness, cooldown, full settlement, and the caller's execution bounds also matter. A reserved balance does not guarantee an immediately executable purchase.

<Note>
  The deployed policy sets a **1,500-USDC rolling hourly cap**, **6,000-USDC rolling daily cap**, **60-second cooldown**, **one-hour liquidity window**, **60-second maximum checkpoint age**, and **3.5% execution impact limit**. These are execution constraints, not a purchase schedule. See the [verified production settings](/reference/release-status#deployed-execution-policy).
</Note>

## Before \$FX exists

A fresh deployment can collect revenue, realize USDC, and apply the 90/10 split before the official token is registered. The 90% allocation remains reserved.

After registration, the token identity and purchase venue cannot be substituted. Reserved buyback funds cannot be withdrawn to another recipient.

## Market exposure

Execution controls constrain spending and settlement. They do not establish an independent fair value for \$FX. Other traders can position around expected purchases, and a manipulated starting price can still produce adverse execution.

The revenue commitment describes where funds and acquired tokens go. It does not promise a fixed purchase schedule or investment return.