How Zero works

Architecture

In plain terms: one contract creates your token and its trading pool, burns the liquidity so nobody can pull it, and splits every trading fee automatically.

Zero is six contracts on Ethereum mainnet, built directly on Uniswap v4. There is no bonding curve and no graduation step; every token trades in a real v4 pool from its first block. The Factory/Hook pair exists twice: once for ETH-quoted launches and once for launches quoted in a tokenized stock (see Pairs & RWA).

Pairs & RWA

In plain terms: your token can trade against ETH, or against a tokenized stock like $TSLA or $NVDA — and then your fees are paid in that stock.

Every launch picks a quote asset: either native ETH or one of the Ondo tokenized equities on mainnet. The two cases run on separate contracts — Factory + ZeroHook for ETH, ZeroRWAFactory + ZeroRWAHook for ERC-20 quotes — so the ETH path stays exactly as audited while stock pairs get the rules they need. Everything else is identical: burned LP, the same fee split, the same locker, the same solvency invariant.

Why fees arrive in the stock

A pool only ever holds its two assets. When someone buys your $TSLA-paired token, they pay TSLAon, so the swap fee is charged in TSLAon and that is what accrues to you. The dashboard therefore lists earnings per currency, andcollectFees(quote) pays each one out separately.

The ordering rule

A Uniswap v4 pool sorts its two currencies by address. For stock pairs Zero requires the new token to sort above the quote, so the token is always currency1 and the fee path has a single branch — the same one the ETH hook uses. The launch UI mines a CREATE2 salt until the predicted address satisfies that (milliseconds); a salt that fails reverts with TokenBelowQuote.

Supported quotes

$TSLA, $AAPL, $NFLX, $SPCX, $AMZN, $META, $QQQ, $GOOGL, $TSM, $SPY, $NVDA — all 18-decimal Ondo tokens with no transfer restrictions. New quotes are added by the owner; existing pools are never affected.

Launch lifecycle: one transaction

In plain terms: you sign once. When the transaction confirms, your token exists, trading is live, and the liquidity is already burned.

deployCoin(name, symbol, metadata, salt, configId, feeBps, deployer, lock) does everything atomically. If any step fails, the whole launch reverts; there is no half-launched state.

Measured cost on a mainnet fork: deployCoin ≈ 1.36M gas including the pool, the LP mint and bookkeeping.

Fee mechanics

In plain terms: every buy and sell pays the fee the creator chose. There is no cheap side-door: all four ways of swapping cost the same rate.

The hook implements beforeSwap and afterSwap with return-delta permissions. Its deployment address literally encodes 0xCC in the low bits, which Uniswap v4 validates. The fee is always charged on the ETH side, for all four swap shapes, and the exact-out formulas are grossed up so no shape is cheaper than another:

Collection is a single ETH transfer: the hook calls poolManager.take(currency0, factory, fee). The ETH lands on the Factory directly, and the hook then reports the amount with depositFees(token, amount). The hook never holds ETH and has no receive().

Pools created around the Factory can attach this hook but are unusable: _feeBps reverts with TokenNotRegisteredfor any token the Factory didn't register.

The solvency invariant

In plain terms: the Factory only believes money it can actually see. Nobody can invent fee balances: the math makes lying revert.

Because the hook only reports amounts, the Factory refuses to believe it blindly. It keeps one aggregate liability counter and checks it against the real balance on every deposit:

function depositFees(address token, uint256 amount) external {
    if (msg.sender != tokenHook[token]) revert OnlyTokenHook();
    totalAccrued += amount;
    if (address(this).balance < totalAccrued) revert InsufficientETHReceived();
    // ... 90/10 split
}

take() runs before depositFees() in the same transaction, so the ETH is already on the Factory when the check runs. Over-reporting by even 1 wei reverts the whole swap, verified in fork tests. Under-reporting only donates to the platform. Claims (collectFees, claimProtocolFees) decrement totalAccrued, so balance ≥ totalAccrued holds at all times: the Factory can always pay every outstanding claim.

Fee split & creator rights

In plain terms: creators earn 90% of every fee, can redirect it, or give it up forever. The platform's 10% mostly ends up as burned $ZERO.

Locker

In plain terms: locked tokens are provably untouchable, even by us, until the schedule says otherwise.

Anyone can lock any ERC-20 for any beneficiary. The owner role exists for future admin needs only; there is deliberately no path to locked funds and no way to shorten a lock.

Implementation details

Each lock packs into 3 storage slots (token+kind+timestamps / beneficiary+vestEnd / amount+claimed as uint128). Deposits are fee-on-transfer safe: the contract locks what actually arrived, measured by balance difference. Lock lists are not stored on-chain; indexers rebuild them from Locked/Withdrawn events, while totalLocked[token] keeps the live locked balance for badges.

Liquidity math

In plain terms: your two launch choices, supply and starting liquidity, are just a price: how much ETH the pool pretends to hold on day one.

A launch config is a pair: total supply S and virtual ETH V (the opening market cap). The entire supply deposits as single-sided currency1 liquidity, priced as if V ETH were already in the pool:

sqrtPriceX96 = √(S / V) × 2⁹⁶          // pool opens at S/V tokens per ETH
initTick     = log₁.₀₀₀₁(S / V)
tickUpper    = floor(initTick, 200)     // price sits just above the range →
tickLower    = -887200                  // the whole supply deposits one-sided,
                                        // buy-side liquidity never runs out

The tick-floor gap makes the effective opening price at most ~1.6% below nominal. All 20 precomputed configs (1M–1B supply × 0.69–10 ETH) are verified against the 200 tick spacing: divisibility, min/max bounds, and the single-sided condition.

Events & indexing

The contracts store the minimum on-chain and emit everything an indexer needs. Metadata, deploy timestamps and per-token fee totals are intentionally not in storage; they are derived from events:

Security properties

Contract reference

In plain terms: every function you can call, what each input means, and who is allowed to call it.

Factory — ETH pairs

ZeroRWAFactory — tokenized stock pairs

Same functions, with two differences: a quote address selects which stock the pool is priced in, and money moves as ERC-20 transfers instead of msg.value.

setTokenFeeRecipient, renounceCreatorFees, communityTakeover and depositFees have the same signatures and rules as the ETH factory — only the currency differs.

Hooks (ZeroHook / ZeroRWAHook)

The hooks are called by the PoolManager on every swap; you never call them directly. Their only writable surface is administrative.

Locker

Deployments

In plain terms: these are the exact contracts your transactions touch. Verify them on Etherscan before you sign anything.

Zero contracts

Uniswap v4 infrastructure

Zero deploys none of these — they are Uniswap's canonical mainnet contracts, and your funds move through them, not through us.

Burned liquidity goes to 0x000000000000000000000000000000000000dEaD — the standard dead address, which has no known private key.