o1.exchange 백서 전문

`. Arc does not use Permit2; supplying a Permit2 signature to Arc preparation returns `409 stale_quote`. An unavailable route or failed simulation returns a specific `422` problem. The wallet must submit the returned `to`, `data`, and `value` unchanged before expiry. `value` is the exact swap value, not a gas budget; the wallet must retain additional native currency for gas. <Warning> Exact-output swaps are not exposed. Standard/Tax hooks reject exact-output execution while a pool's surcharge window is active. New Arc Standard pools have no active surcharge window, but this API still exposes exact-input swaps only. </Warning> ## Monad settlement scope Use `chain_id: 143`. Direct trades settle in the paired MON, USDC or WETH. Supported conversion routes also allow native MON settlement for configured ERC-20 pairs; use the quote's `swap_settlement_tokens`. Native MON needs transaction value, while ERC-20 inputs use the returned approval requirements. WMON is routing infrastructure, not a registered quote. ## Arc settlement and approvals Use `chain_id: 5042`. Direct USDC-paired buys spend six-decimal ERC-20 USDC and receive the launched token; sells receive ERC-20 USDC. For a cirBTC pair, direct API trades use eight-decimal cirBTC instead. Resolve Standard or Tax from the token's originating suite. For a USDC-paired buy, `amount_in_raw: "1000000"` means 1 USDC. The API trades through the exact launch pool using SwapX, with `value: "0"` and no Permit2 signature, wrapper or USDC-to-itself swap. Quotes simulate execution against the funded wallet and measure the recipient's output balance change. Insufficient input funds or a failed route simulation returns `422 quote_unavailable`. A quote cannot substitute for funding the wallet first. If approval is needed, the response approves the exact input amount to the configured SwapX router. A nonzero insufficient allowance includes a zero-reset step first; follow `depends_on` and wait for confirmations before preparation. Preparation refreshes the quote, verifies the confirmed allowance and preserves at least the reviewed minimum output. Approval can remain if the wallet approves but does not execute the swap. Native USDC pays gas with 18-decimal units and ERC-20 USDC uses six decimals, but both access the same balance. Leave enough USDC for gas rather than treating the two balances as separate funds. For alternative settlement, use only the assets advertised for that quote. Do not substitute native-USDC raw amounts for ERC-20 USDC amounts. Atomic Dev Buy uses the separate [launch endpoint](/launchpad/api/launches#atomic-dev-buy). ## BSC trading Use `chain_id: 56`. BSC supports Standard and Tax pools through the configured SwapX router. Use the returned transaction steps: BSC's ten-field route tuple differs from Arc and Base/Robinhood routes. Native BNB uses transaction value; Binance-Peg USDC and bStocks use their ERC-20 units and approvals. Binance-Peg USDC has **18 decimals**, not six. API swaps can settle in the paired asset or an admitted acquisition-route asset from `/config`. The preparation checks the complete route, including external pool fees, input funding and final output. Native BNB Dev Buy is prepared through the launch endpoint. ## X Layer trading Use `chain_id: 196` and the token's originating suite. The updated SwapX binding admits both minimal-v4 and Tax through an explicit Hook allowlist; unknown Hooks reject before executable calldata is prepared. Use the originating suite's pool and retain route validation, spender checks and final simulation. The [router review](/launchpad/reference/production-contracts#swapx-router-upgrade-review) records scoped fork evidence; each requested amount still requires a successful route simulation. Native OKB Dev Buy uses the launch endpoint. # Smart contract architecture Source: https://docs.o1.exchange/launchpad/architecture/contracts How the launch factories, launch hook, fee escrow, staking contract, announcement registry, and launch tokens work together. The Standard suites on Base, Robinhood, Monad, Arc, BSC and X Layer use the `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](#arc-deployment). <CardGroup> <Card title="Launch path" icon="rocket"> 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. </Card> <Card title="Trading path" icon="arrow-right-arrow-left"> 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. </Card> <Card title="Staking path" icon="vault"> 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. </Card> </CardGroup> <span /> ## Standard contract responsibilities | Contract | Responsibility | Custody or authority | | - | - | - | | Launch factory | Coordinates crypto-paired and stock-paired launches on its deployed chain | Controls future launch settings, paired assets, creator rights, and the global native launch fee on that chain | | Base token validator | Verifies each created B20 token's supply, policy, roles, and profile-authority boundary | Stateless and called by the Base factory; holds no user funds | | ERC-20 token deployer | Creates the fixed-supply ERC-20 for its bound launch factory | Callable only by that factory; holds no user funds | | Launch hook | Opens approved pools, owns permanent positions, and applies swap fees | Owns and permanently locks launch liquidity positions | | Fee escrow | `FeeEscrow` records and pays each recipient's swap-fee balance | Can pay only balances credited by the hook | | Launch-buy adapter | Executes the optional atomic buy after the selected factory creates and seeds a launch; Arc uses `ArcSwapXLaunchBuyAdapter` for USDC funding | Each deployment is bound to its chain's factory, hook, PoolManager, and supported routing path | | Staking contract | Stores fully funded reward programs and participant principal | Holds accounted principal and rewards; its owner controls only the fee for future vault creation | | Announcement registry | `AnnouncementRegistry` publishes creator-authenticated announcements | Has no token authority and holds no funds | | Robinhood / Monad / Arc / BSC / X Layer token | `LaunchToken` is the fixed-supply ERC-20 implementation | Has no owner or administrative control | ## 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. | Stage | Factory behavior | | - | - | | Validate | Confirms the selected paired asset, route, current creation fee, deadline, profile-editing choice, and launch limits | | Create token | Creates the fixed supply and verifies the expected immutable token properties | | Configure market | Records the original creator, current creator fee recipient, frozen fee components, anti-snipe schedule, currencies, and exact pool identity with `LaunchHook` | | Open pool | Initializes the Uniswap v4 pool at the configured opening price | | Seed liquidity | Sends the complete fixed supply to the permanent position owned by the hook | | Publish result | Emits the token address, creator, pool ID, quote, supply, and spacing in `Launched` | 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, while `SwapXLaunchBuyAdapter` 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. | Control | Purpose | | - | - | | Quote registration | Adds a supported paired asset and its opening-price frame | | Quote revision | Prevents a stale price update from overwriting a newer one | | Price updater | May update the opening frame of an existing quote, but cannot add or remove assets or change fees | | Creation switch | Pauses new launches through that factory; existing pools continue trading and claiming | | Batch limit | Bounds one quote-management transaction to 64 entries | Base Standard supports ETH, USDC, the configured Coinbase crypto assets and [Base Stock Tokens](/launchpad/create/stock-paired-launches#base-stock-token-catalog). 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](/launchpad/reference/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. | Responsibility | Behavior | | - | - | | Pool gate | Accepts initialization only for a factory-registered launch | | Liquidity seed | Creates the token-only position and verifies that no paired asset is required | | Permanent lock | Rejects every removal and every external liquidity addition | | Anti-snipe | Calculates the timestamp-based opening surcharge in the paired asset | | Fee accounting | Splits the base fee between creator, platform, and valid referrer | | Trade record | Publishes the callback executor, referrer, fee currency, fee amount, and optional comment in the `Trade` event; direction and trader attribution come from the complete receipt | 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](/launchpad/reference/events-functions). ## 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](/launchpad/staking/overview). 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. <span /> ## 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. | Contract | Tax-suite responsibility | | - | - | | `TaxRWAERC20LaunchpadFactory` | Validates launch inputs, quotes and policy; coordinates creation and creator administration | | `TaxLaunchOperations` / `TaxLaunchValidation` | Fixed linked execution and validation; no owner-selectable execution target | | `TaxLaunchTokenDeployer` / `TaxLaunchToken` | Creates fixed-supply ERC-20s and updates Dividend shares synchronously on transfers | | `TaxLaunchHook` | Enforces locked liquidity, frozen tax rates, settlement and currency-specific fee credits | | `FeeEscrow` | Aggregates recipient/currency claims, including optional dead-address redemption | | `TaxDividendDeployer` / `TaxDividend` (`ArcTaxDividend` on Arc) | Creates one clone for a dividend-enabled launch, assigns rewards when trading fees accrue and funds holder-authorized payments on demand | | `TaxDividendClaimHelper` | One immutable helper per suite; atomically claims for its caller across verified clones | | Launch-buy adapter | Connects this factory and Hook to the configured router for an atomic Dev Buy, with chain-specific funding and route encoding | | `AnnouncementRegistry` | Resolves current creator authority for registered tokens | See [Tax contract integration](/launchpad/integration/tax-tokens) 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. <span /> ## \$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. | Contract | Responsibility | | - | - | | `WstOLaunchpadFactory` | Validates creation, snapshots default burn rates, manages quote registration and creator rights | | `LaunchTokenDeployer` / `LaunchToken` | Deploys the fixed-supply ERC-20 through this suite's own bound deployer | | `WstOLaunchHook` | Locks liquidity and burns actual quote tokens during each swap | | `WstOSettlementReserve` | Holds its own PoolManager claims supporting physical settlement inventory; it does not own the launch LP position | | `WstOUsdcNativeLaunchBuyAdapter` (Base) / `WstORobinhoodV4LaunchBuyAdapter` (Robinhood) | Executes the chain-specific ETH-funded acquisition/vault/purchase route or a direct held-wstO Dev Buy | | `AnnouncementRegistry` | Uses the current creator recorded by this Factory | | External wstO vault and SwapX router | Convert \$O/shares and execute admitted routes; their governance is separate from the launch contracts | 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](/launchpad/integration/wsto) for exact accounting and interfaces. ## Launchpad of Launchpads architecture [Launchpad of Launchpads](/launchpad/launchpads/overview) 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. | Contract | Launchpad responsibility | | - | - | | `PadRegistry` | Registers an \$O launch token as a launchpad, creates its vault, records the owner and payout, relays vault events and holds the pauses | | `PadVault` (one clone for each launchpad) | Stores the launch rules, accepts or rejects each child launch, splits income into the owner share and the burn fund and runs the burn claim | | `WstOSuiteReader` | Reads the creator and the pool of a launchpad token from the \$O launch factory. It supports no child launches | | `TaxSuiteReader` | Reads the child Tax suite: tax policy, supply, escrow, dividends and launch consent | | Child `TaxRWAERC20LaunchpadFactory` and `TaxLaunchHook` | A Tax suite whose hook asks the named integrator vault for consent before it records a pool | 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