# Tokenomics and fees

Each Rearctor launch creates a separate ERC-20 token, market and fee vault. The creator chooses the trading fees and the allocation of that launch’s fees when creating it. Those settings cannot be edited after launch.

**Current status — 16 September 2026:** Arc Testnet is connected to the deployed factory and protocol treasury. Mainnet remains in Preview, and the official Rearc token (REARC) is upcoming. Use test USDC on Arc Testnet. Mainnet sample tokens and burn figures are illustrative.

## Supply and initial distribution

| Parameter | Contract rule |
| --- | --- |
| Initial supply | 1,000,000,000 tokens per launch |
| Token decimals | 18 |
| USDC quote decimals | 6 |
| Initial token allocation | The full initial supply enters the launch’s pool |
| Additional minting | No public mint function after initialization |
| Burning | Any holder can burn tokens they own |
| Transfer tax | None on ordinary ERC-20 transfers |
| Seed liquidity | At least the current owner-set minimum (1 USDC initially), strictly below 5,042 USDC |
| Graduation target | 5,042 USDC of accounted net quote reserves |
| Optional creator purchase | At most 200,000,000 tokens, paid for through the curve |
| Minimum token migration | At least 200,000,000 tokens deposited into V4 |

“Fixed supply” means no additional issuance after the initial mint. The current total supply can decrease through project buybacks and voluntary holder burns. The dev-buy and migration limits use the **initial** one-billion-token supply, even if tokens are later burned.

Manual graduation transfers the accounted unpaired token remainder to `0x000000000000000000000000000000000000dEaD`. This is an ERC-20 transfer, not a call to `burn`, so it leaves `totalSupply` unchanged. It uses no project or protocol fee budget and is reported separately from buybacks. Direct donations are excluded; automatic migration leaves its small remainders locked in the pool. FDV uses price multiplied by the full ERC-20 total supply, including tokens at the dead address.

The creator’s seed becomes committed market liquidity. It does not create an LP token or a right to withdraw the seed. The creator receives no free tokens. An optional paid purchase during creation sends its purchased tokens to the launch transaction’s caller; the separate `creatorWallet` receives creator fees.

## Trading fees

Buy and sell rates are chosen independently. Each must be between **1% and 10%, inclusive**, represented as 100–1,000 basis points. One basis point is 0.01 percentage points. A 3% buy rate and 5% sell rate are valid; a zero-fee direction is not.

| Market stage | Buy fee | Sell fee |
| --- | --- | --- |
| Bonding curve | USDC, deducted from the amount actually spent | USDC, deducted from gross sale proceeds |
| Canonical V4 pool | Input USDC | Input project tokens |

Curve fees round upward to the smallest USDC unit. Curve outputs round downward. Very small amounts may produce zero output and cannot execute.

After graduation, the hook enforces the configured directional rate on swaps through the canonical V4 pool, including swaps sent by external routers. An independently enabled **Uniswap protocol fee** is accounted for inside the configured rate: the hook reduces the LP component so the combined rate does not exceed that setting. This Uniswap charge is distinct from Rearctor’s 30% protocol allocation below. Rearctor distributes the LP fees its locked position earns, after any Uniswap protocol fee.

Wallet gas charges are separate from trading fees.

## The 30% / 70% allocation

Every launch’s vault allocates accrued fees in each asset as follows:

1. **30% goes to the protocol treasury.**
2. **70% is divided among creator rewards, project-token buybacks and liquidity.**

The three creator-selected shares must add up to 100% of that remaining 70%. An individual share may be zero. The fee rates, creator wallet and allocation cannot be changed after creation.

For example, a 40% creator / 30% buyback / 30% liquidity selection produces these shares of the total collected fee:

| Destination | Share of collected fees | From a 3 USDC collected fee |
| --- | --- | --- |
| Protocol treasury | 30% | 0.90 USDC |
| Creator wallet | 70% × 40% = 28% | 0.84 USDC |
| Project buyback budget | 70% × 30% = 21% | 0.63 USDC |
| Liquidity budget | 70% × 30% = 21% | 0.63 USDC |

This example corresponds to a 100 USDC curve buy with a 3% fee, assuming it is below the remaining curve capacity. On a capped final buy, the fee applies only to the USDC actually spent.

Allocations use cumulative accounting. For each asset and destination, the entitlement is the floor of total fees accrued multiplied by its fixed weight. The vault credits only the increase since the previous accrual. This avoids making the final split depend on how often fees are collected. A small amount of indivisible rounding dust can remain unallocated.

**These allocations are not dividends to token holders.** Holding a token does not create a claim on trading fees, treasury funds or pool principal. The creator reward belongs to the fixed creator wallet; the other budgets have their specific contract destinations.

## What each budget can do

### Creator rewards

Creator fees become claimable by the fixed creator wallet in USDC and, after graduation, in project tokens. Anyone can pay the gas to claim for that beneficiary; the payment still goes to the beneficiary. A caller cannot redirect it to their own wallet.

The factory rejects the treasury and known system addresses as creator wallets, including the new launch’s token, pool and vault. This restriction does not verify that the creator controls an arbitrary wallet address. Creators must enter an address they can actually use.

### Project-token buybacks

A project’s own buyback allocation remains in its own vault. Anyone can call `processBuyback`, subject to the contract’s conditions:

- USDC buys that project’s tokens through its own pool, and the acquired tokens are burned.
- Already allocated project tokens are burned directly.
- USDC purchases are processed in bounded, price-guarded slices. Unspent USDC stays in the buyback budget.
- The curve-stage project buyback path does not charge another curve trading fee. After graduation, normal V4 hook fees apply.

Permissionless execution does not mean automatic execution. Someone must submit a successful transaction and pay its gas. A buyback allocation promises a restricted destination for funds, not a schedule, a minimum burn rate or price appreciation.

### Liquidity

Liquidity allocations accumulate in the vault before graduation. They cannot be added to the curve or used to force graduation.

After graduation, anyone can add budgeted assets to the same locked V4 position using `processLiquidity`. Both assets and nonzero minimum deposited amounts are required. If the budgets are unbalanced, `rebalanceLiquidity` converts a bounded portion of the excess asset through the canonical pool. The direction and amount are calculated from the vault’s own budgets; the caller cannot select another router or recipient.

Unused assets remain budgeted. Reinvested principal joins the permanently committed position and cannot later be withdrawn.

## Protocol treasury and REARC burns

The protocol’s 30% belongs to the protocol treasury. It is separate from every project’s buyback allocation.

The dedicated treasury recognizes protocol receipts from validated fee vaults. Direct donations and creator rewards are not counted as protocol fee revenue. Anyone can trigger collection, but **the treasury owner chooses** whether accounted funds are used for operations, converted from project tokens, withdrawn as protocol-owned tokens, or spent on a manual REARC buyback.

There is no mandatory percentage or automatic schedule for REARC burns. A manual buyback spends an explicit USDC amount through the permanently bound target pool and burns only the tokens purchased in that transaction. Existing target-token balances are preserved. The owner can withdraw all available protocol funds for operations instead; token holders have no contractual claim to those funds.

## Processing budgets

Authorized admin wallets can submit project-budget operations from **Control Room → Fees & treasury**. The underlying fixed-destination contract operations remain permissionless. Swaps process at most 0.5% of the input reserve, with one price-sensitive budget operation per minute for each pool. Execution uses the block-opening price, minimum output and deadline. Unspent balances remain in their original budgets.

Collected buyback tokens can be burned separately. Ordinary trading and beneficiary claims do not use the budget interval. See [Permissions and liquidity](/docs/security/) for the contract roles.

Continue with [the curve and graduation](/docs/graduation/) or [the contract reference](/docs/smart-contracts/).