launchpad-v4-minimal architecture for launch coordination, permanent liquidity, fees, creator rights, announcements, and optional atomic Dev Buy. The chain-specific token step differs: Base creates and validates a native B20 token, while Robinhood, Monad, Arc, BSC and X Layer create a fixed-supply ERC-20 through a dedicated token deployer. Each contract has a narrow responsibility, which makes its authority and custody easier to verify.
Arc uses the same ERC-20 core with an adapter for native and ERC-20 USDC.
Launch path
The creator signs one factory transaction. It creates the token, opens the Uniswap v4 pool, and places the complete fixed supply into the permanent liquidity position.
Trading path
The trader signs a swap through Uniswap. Standard and Tax recipient fees become claimable balances; the $O launch Hook instead burns its wstO fee during the trade. The user receives the resulting trade output.
Staking path
A vault creator funds an independent reward program. Participants approve and deposit wallet-held tokens, then withdraw principal and claim completed-epoch rewards under the vault’s fixed rules.
Standard contract responsibilities
Factory: launch coordination
createLaunch coordinates the complete launch. The selected chain and product determine the factory, and the paired asset determines the market type. For Standard tokens, Base, Robinhood, BSC and X Layer each use one factory for both crypto-paired and stock-paired launches. Base, Robinhood, BSC and X Layer each have a separate Tax factory shared by crypto and stock pairs. Monad and Arc have separate Tax factories for their registered crypto pairs.
The minimal factories also expose createLaunchAndBuy. It creates the token, opens and seeds the pool, then executes one protected buy through the chain’s configured adapter in the same transaction. An ordinary launch continues to use createLaunch. Both methods require creation to be enabled.
The factory owner may update paired assets, supply, opening prices, liquidity ranges, fees, and the platform fee receiver for future launches. The announcement registry is bound once and cannot be replaced. The minimal factories provide bounded paired-asset updates, revision checks, a restricted opening-price updater, and a switch for new creation. That switch covers every new launch through the factory, regardless of paired asset. These changes cannot rewrite a completed token or pool.
Launch-buy adapter
The browser prepares SwapX route data, whileSwapXLaunchBuyAdapter enforces the atomic Dev Buy boundary onchain. The adapter is not a quote engine. It accepts calls only from the configured launch hook, checks that the route starts with the actual funding asset, requires connected non-cyclic hops, and requires the final hop to use the exact newly created launch pool, selected paired asset, launch token, and hook. Routes are bounded to four hops, external pools must match the venues permitted by that deployment, and the creator must receive at least minAmountOut. The transaction also stops if it changes any unexpected route-asset or native-currency balance held by the adapter or SwapX router.
Venue support is deployment-specific without changing the factory or UI flow. The active Base adapter uses its configured v3 and Aerodrome path. The active Robinhood adapter can also validate constrained external v4 pools through its configured PoolManager. For these adapters, the complete launch reverts if the optional buy cannot satisfy the route and output checks; ordinary createLaunch remains independent.
Managed paired-asset controls
Each Standard or Tax factory keeps its chain’s native asset where supported, stablecoins, registered crypto majors and Stock Tokens in one paired-asset registry. The $O launch Factory instead requires reviewed burn-compatible ERC-20 quotes. Every registered asset has its own availability state, decimals, opening-price frame, and revision.
Base Standard supports ETH, USDC, the configured Coinbase crypto assets and Base Stock Tokens. Robinhood supports ETH, USDG and its supported Stock Tokens. A paired asset must be registered on the selected factory, with creation enabled, before it can be used for a new launch. Each Tax factory has its own registrations; see Live configuration for each product’s assets.
LaunchHook: market enforcement
Each pool receives a frozen configuration when it is created. The hook then enforces the launch market throughout its lifetime.
During the opening anti-snipe period,
LaunchHook keeps o1’s input-amount buy and sell flow open while applying the temporary surcharge. It rejects exact-output requests while the surcharge window is active. New Arc Standard launches configure the opening total equal to the normal 1% base fee, so the surcharge is zero and the Hook treats the window as inactive. Existing pools retain their frozen settings; router support is separate.
The detailed callback and function surface is available in Functions and events.
Escrow, staking, and announcements
FeeEscrow tracks claimable balances by recipient and currency. Ordinary recipient fees use the paired asset; Tax burn credits use launched tokens. Anyone can trigger payment to the recorded recipient, while a recipient can also redirect their own claim. Only the launch hook can add new fee credits.
The staking contract is separate from token creation. Anyone can create an immutable reward vault for a compatible B20 or ERC-20 token and fund every epoch in advance. Participants deposit wallet-held tokens in independent lots, withdraw according to the vault’s fixed policy, and manually claim time-weighted rewards after each epoch. The owner may change the global fee for future vault creation but cannot change or cancel existing vaults, withdraw accounted assets, or pause participant actions. See the staking guide.
The announcement contract records each launch token. It resolves authorization through the active factory’s current creator rights, so accepted creator-rights changes also move announcement authority. The current creator can post announcements with a unique ID, description, and URI without receiving any token administration role.
Tax architecture
Base, Robinhood, BSC, Monad, X Layer and Arc each have an additional Tax ERC-20 suite. Each retains direct v4 launches, locked liquidity, creator rights and the same FeeEscrow claim model, with its own immutable bindings. It replaces Standard fee components with inclusive taxes.
See Tax contract integration for exact units, functions, events and trust boundaries. The Standard-specific fee-component and B20 descriptions above do not apply to Tax or $O launches.
$O launch architecture
$O launches on Base and Robinhood use a separate ERC-20/managed-quote suite with immediate quote burns. The suite preserves permanent liquidity, metadata, announcements and creator rights, without FeeEscrow, dividends or Standard/Tax economic allocations.
The same address represents the external wstO vault and ERC-20 shares. That vault holds the $O backing; the settlement reserve accounts for wstO held in PoolManager. Neither is the optional staking reward contract. See $O launch integration for exact accounting and interfaces.
Launchpad of Launchpads architecture
Launchpad of Launchpads uses three parts on Base and on Robinhood. These are an $O launch token, a registry with vaults, and a child Tax suite. The registry creates one vault for each launchpad. The child Tax suite checks launch consent. Each chain has its own set.
A child launch names the vault as its integrator. The hook calls
launchConsent on the vault with a fixed gas budget. The vault answers from the registry pauses and its launch rules. An accept makes the pool a member of the launchpad. A reject reverts the launch. A vault that gives no answer does not stop the launch, and the pool then gets no membership.
Fees reach the vault through the child fee escrow. The vault splits new income with the owner share that registration fixed. The rest goes into the burn fund. The only exit of the burn fund is take, which moves the burn amount of launchpad tokens to the dead address. No pause stops take or the owner withdrawal.
Vaults are clones of an immutable implementation. A new vault version applies only to launchpads that register after the registry selects it.
Trust boundaries
- The factory owner can change economic defaults for launches that have not happened yet. Tax additionally permits Dividend exclusion, receiver and asset-recovery administration for existing clones; those powers cannot seize tokens from holders’ wallets or unlock launch liquidity.
- The factory owner cannot change an existing token supply or remove liquidity. Creator-rights changes affect only current project authority and future creator-fee routing, without granting token or pool custody.
- The hook can credit fees only according to frozen pool configuration.
- The escrow can pay only swap fees already credited to it.
- The staking contract can move only principal and rewards according to each immutable vault and participant action.
- Transaction signing stays in the user’s wallet; o1 services never hold signing keys.
Monad deployment
Monad uses the ERC-20 minimal suite for standard crypto launches with MON, USDC and WETH. The adapter uses Monad’s no-deadline-argument SwapX overload while still enforcing the launch request deadline. It supports configured Uniswap/Pancake V3 and constrained hook-free external ERC-20 V4 pools; no Aerodrome factories are configured. The app searches bounded direct and USDC-bridge candidates. This is not a guarantee of the best route across all pools.Arc deployment
Arc’s native USDC pays gas and the launch fee in 18-decimal units. The USDC pool quote uses the six-decimal ERC-20 interface over the same balance. cirBTC is a separate eight-decimal crypto quote in the application catalog. Pool trading fees and escrow claims use the selected quote currency. There is no separate wrapped-native token. This follows Arc’s USDC integration guidance.ArcSwapXLaunchBuyAdapter accepts native or ERC-20 USDC funding. For native funding it converts the buy amount once by dividing by 1e12, then lets SwapX spend through ERC-20 approval with zero native value forwarded. Native buy amounts must be exactly representable with six decimals; otherwise the transaction reverts. It does not wrap USDC or exchange USDC for itself. With USDC as the registered quote, the route ends directly in the USDC/launch-token pool. For a registered cirBTC quote, the planner first acquires cirBTC through a configured V3 pool, then executes the final cirBTC/launch-token swap. It compares the 0.01%, 0.05%, 0.3% and 1% V3 fee candidates by output. Token-page trading supports direct paired-asset swaps and USDC settlement through the same acquisition planner in either direction. Missing liquidity or an output too small to quote prevents route preparation.
The attached adapter uses the deadline-enabled SwapX overload. It permits configured V3 pools and initialized, liquid, hook-free external V4 pools with static fees up to 5%; PancakeSwap and Aerodrome are not configured. The final launch pool must still use o1’s launch hook. Router pause and configuration checks, minimum output, complete input spending, balance preservation and allowance cleanup remain enforced. Accepted routes do not guarantee liquidity or the best quote.
The 5% value is a ceiling per external pool, not a fee automatically charged or a cap on all fees along a route. A permitted 0.3% pool charges 0.3%; quoting must account for each leg’s actual fees. The launch pool’s own Hook fee is separate. See Direct integration for funding amounts and approval targets.
See Arc configuration for current launch settings.
Arc Tax uses ArcTaxDividend with the same public claim selectors, authorization and fee-accrual storage as the shared Dividend implementation. Its payment override transfers the fixed ERC-20 reward token for either unwrap preference, counting USDC backing once. See Arc Tax currency rules.
BSC deployment
BSC uses the same immutable ERC-20 launch suite for BNB, USDC and registered bStocks. Native BNB is the zero-address quote and WBNB is a separate wrapper. BSC USDC and all configured bStocks use 18 decimals.BscSwapXLaunchBuyAdapter inherits the standard funding, authorization, exact-final-pool, minimum-output, deadline, residual-balance and allowance-cleanup checks. Clients supply the standard eight-field route; this BSC-only adapter encodes the router’s ten-field descriptors, with the reserved poolManager and parameters fields zero. The route limit remains four hops.
Acquisition searches configured Uniswap V3 and PancakeSwap V3 pools, including USDC/USDT bridge candidates, before the exact launch V4 pool. Pancake V3 candidates use 0.01%, 0.05%, 0.25% and 1% fees. Eligible external V4 descriptors can pass adapter validation, but the current acquisition planner does not discover every external V4 pool. The external-pool fee cap is 5%, not an added fee. Pancake V2, Infinity CL/Bin and Aerodrome are not part of this controlled route integration.
The adapter preserves unexpected balances and rejects incomplete spending or output below the protected minimum. Simulate the selected route before signing, as with other chain integrations.
X Layer deployment
X Layer uses the same immutable ERC-20 minimal suite, with native OKB, USDC, xETH and 45 wrapped stocks as supported quotes. The launch fee is 0.02 OKB, and pool fees and claims use the selected quote currency. Native OKB has 18 decimals and uses the zero address; WOKB is its separate wrapper and pricing identity. The genericSwapXLaunchBuyAdapter uses the standard eight-field deadline interface and supports native-funded atomic Dev Buy into an OKB-paired launch pool. Atomic Dev Buy for a non-native quote requires an attached adapter that reports nativeV3InputSupported() == true, plus an executable acquisition route. Quote registration alone does not enable that route.
Token-page trading uses the X Layer SwapX proxy and its exact launch-pool route; sells approve that proxy. Compatible V3 acquisition is a separate path for registered ERC-20 quotes. The binding permits at most four hops and a 1% external-pool fee cap; external V4, V2, Infinity and custom external hooks are not enabled by this integration.
See X Layer contracts and configuration.