bitpro가 원문에서 글자만 모은 내용이에요. 표·그림·수식은 빠지거나 깨질 수 있어요. 전체 35쪽 중 9쪽
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](https://docs.arc.io/arc/tutorials/porting-contracts-to-arc).
`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](/launchpad/integration/direct#arc-usdc-amounts-and-approvals) for funding amounts and approval targets.
See [Arc configuration](/launchpad/reference/live-configuration#arc-mainnet) 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](/launchpad/integration/tax-tokens#arc-currency-and-claims).
## 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 generic `SwapXLaunchBuyAdapter` 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](/launchpad/reference/production-contracts#x-layer-mainnet) and [configuration](/launchpad/reference/live-configuration#x-layer-mainnet).
# Configuration and governance
Source: https://docs.o1.exchange/launchpad/architecture/deployment-governance
What o1 governance can change for future launches and which properties remain permanent after a token launches.
The Standard suites on Base, Robinhood, BSC and X Layer each use one `launchpad-v4-minimal` factory for both crypto-paired and stock-paired creation. Base Standard creates native B20 tokens, while Robinhood, Monad, Arc, BSC and X Layer create fixed-supply ERC-20 tokens. A catalogued paired asset becomes available when it is registered on the active factory and creation is enabled. Available market types share the same launch model, fee system, creator rights, announcements, and permanent Uniswap v4 liquidity.
Base, Robinhood, BSC, Monad, X Layer and Arc Tax have separate launch contracts and configurable trading taxes. Their governance roles follow the same structure as Standard. See the [Tax configuration overview](/launchpad/reference/live-configuration#tax-release-overview) for all six configurations and [Production contracts](/launchpad/reference/production-contracts) for their independently bound addresses.
## Who controls what
| Area | Current authority | Boundary |
| - | - | - |
| Future launch settings | Launchpad governance owner | Changes apply only to launches created afterward |
| Standard platform fees / Tax protocol share | The suite's configured recipient | Receives its share but cannot control tokens or pools |
| Paired-asset opening-price updates | Restricted price updater | Can update future opening frames only; cannot register assets, change fees, or modify pools |
| Creator rights | Current creator | Can transfer project rights; Standard/Tax also allow future creator-fee routing changes; no token or liquidity control |
| Creator-rights administration | Creator admin | Can immediately reassign project rights and, on Standard/Tax, future creator-fee routing; no token or liquidity control |
| Token profile editing | Current creator, only when enabled at launch | Limited to supported profile information |
| Tax Dividend administration | Factory owner or delegated creator admin | Can change per-launch exclusions and receivers, refresh shares and recover Dividend assets; cannot change frozen tax rates or unlock liquidity |
| Announcements | Current creator | Can publish updates but receives no token or liquidity control |
| Permanent liquidity | Launch hook | Cannot be removed, transferred, or redirected |
The current governance owner and platform fee receiver are listed in [Production contracts](/launchpad/reference/production-contracts#governance-and-fee-recipient).
## Settings for future launches
Governance can update these defaults:
* supported paired assets and any future creation fees;
* the opening price used for each paired asset;
* fixed token supply within the contract caps;
* liquidity range settings;
* Standard base fees, anti-sniping, recipient splits and the platform receiver, or the Tax policy described below.
The announcement registry is bound once and cannot be replaced.
The current Standard and Tax factories include a creation switch, bounded paired-asset updates, and per-asset revisions. The owner can register or remove paired assets. The restricted updater can change only the opening-price frame of an already registered asset, using its latest revision. Each factory's creation switch and global native launch fee apply to all its supported quotes. Monad and Arc support crypto-paired markets only.
The interface refreshes the current settings before a creator signs. If protected global settings change while a prepared transaction is pending, the transaction stops instead of silently using different economics. A paired asset's opening-price refresh intentionally applies the latest registered frame when the launch executes.
## Tax policy and Dividend administration
For future Tax launches, the owner can change buy/sell bounds, protocol share and clamps, the protocol recipient, anti-sniping opening and duration, and the dividend holding floor. The complete policy can be updated atomically. A zero protection duration allows launches with creator opt-out; it does not by itself disable creation.
Existing tokens retain selected taxes, allocation shares, integrator attribution, reward currency, dividend threshold and protection settings. The current creator can change future creator-fund routing through its existing right. Earlier credits do not move.
Additional default Dividend exclusions apply only to future clones. Authorized per-launch exclusion/unexclusion and receiver changes affect existing clones. Mandatory system exclusions cannot be removed. Exclusion keeps earned rewards recorded but blocks payment while excluded. Asset recovery can remove backing for unpaid rewards; replenishment restores backing without reallocating those rewards. These powers are part of the trust model, not ordinary creator or holder self-service.
See [Tax contract integration](/launchpad/integration/tax-tokens#exclusions-and-administrative-controls) for the exact functions.
<span />
## \$O launch governance
Each chain's separate \$O Factory owner sets buy/sell burn defaults from 0% through 99%, only for future launches. Existing pools keep their rates. There is no creation-fee, payout, allocation or anti-sniping policy to configure. The managed quote registry accepts reviewed burn-compatible ERC-20s; current public support is wstO, not the Standard or Tax quote catalog.
Creator rights retain profile and announcement authority without fee-recipient routing. Creator-admin reassignment does not control balances or locked liquidity. The owner, creator admin and price updater use the [shared governance addresses](/launchpad/reference/production-contracts#governance-and-fee-recipient). Read the selected Factory to verify current authority before an administrative transaction.
The reserve has no independent owner: its authority follows `Factory.owner()`. That owner can deposit reserve funds, redeem the reserve's own claims to a specified recipient, or recover direct donations. They cannot withdraw the launch LP position or other accounts' claims. Full reserve withdrawal is permitted and may make positive-burn swaps fail for insufficient physical inventory. See [reserve boundaries](/launchpad/integration/wsto#settlement-reserve).
Adapter replacement changes future atomic-buy execution and requires fresh approvals/configuration. It does not rewrite existing pools. Quote removal or disabling creation stops new launches, not ordinary swaps in existing pools. The vault's deposit controls and the shared router's upgrades are separate governance dependencies.
## What becomes permanent
When a launch succeeds, the following properties are fixed for that launch:
* token address and total supply;
* original creator and selected paired asset;
* market type and launch contracts;
* opening pool and liquidity range;
* trading rates, including the buy/sell burn rates for \$O launches;
* Standard/Tax allocations and fixed recipients, except that the current creator-fee recipient can change for future credits;
* Standard/Tax anti-snipe start time and duration;
* permanent liquidity position.
Future governance changes cannot mint more launched tokens or remove liquidity. A valid creator-rights transfer updates the current creator; Standard and Tax also support future creator-fee routing changes. Already credited balances do not move. \$O launches have no recipient-fee credits.
## Token authority
Tokens launch without an owner who can mint, pause, upgrade, or take balances. Creator rights cover project-side authority, announcements and optional profile editing, plus future creator-fee routing on Standard and Tax. They do not grant control over token transfers or liquidity.
<span />
## Launchpad of Launchpads roles
Each Launchpad of Launchpads registry, on Base and on Robinhood, has its own roles. The shared [governance owner and treasury](/launchpad/reference/production-contracts#governance-and-fee-recipient) hold these roles. They stay separate contract roles from the Standard and Tax roles.
| Area | Current authority | Boundary |
| - | - | - |
| Registration fee, default burn amount, owner share bounds and default, reserved URLs, suites and vault versions | Registry owner | Defaults and vault versions affect new launchpads. Child suite changes affect future token launches on existing launchpads. It cannot withdraw from a vault or change an existing owner share |
| Guardian, threshold setter and allowlist manager appointments | Registry owner | Each appointment changes only that role |
| Pauses of new launchpads, all child launches or the child launches of one launchpad | Registry owner or guardian | The guardian role controls only these pauses. No pause stops trades, owner withdrawals or burn claims |
| Burn amount of one launchpad | Threshold setter | Must stay from 0.0001% to 1% of the launchpad token supply |
| Owner allowlist | Allowlist manager | Has an effect only while the registry owner turns the allowlist on |
| Registration fees | Registration fee treasury. This is the platform treasury `0x1cAa...1C90` | Receives no vault funds |
| Launch rules, payout address, identity and owner proposals | Launchpad owner | Cannot change the owner share, the URL or the tax of an existing token |
The registry owner also controls pauses. The registry rejects a renounce of ownership. Ownership moves in two steps: a proposal, then an acceptance.
Two more roles affect launchpads:
* The child Tax factory owner and creator admin keep the Tax suite powers over dividend receivers, holder exclusions and tracker asset recovery. These powers can affect future vault receipts from Tax tokens that a vault holds. They cannot move funds that are already inside a vault.
* The \$O launch factory creator admin can reassign the creator rights of a launchpad token. This role belongs to the \$O launch product. At the October 9, 2026 reads, `0x5519...044D` held it on both chains.
See [Launchpad configuration](/launchpad/reference/live-configuration#launchpad-release-overview) for the current addresses and values.
## Current configuration
The human-readable values are listed in [Live configuration](/launchpad/reference/live-configuration). Developers can use the [machine-readable production snapshot](/launchpad/reference/production-deployments.json), review the chain-specific catalogs in [Stock-paired launches](/launchpad/create/stock-paired-launches), and refresh changeable values from the route-selected active factory before preparing a transaction.
## Monad scope
Monad uses the same managed configuration and creator-rights model, with crypto-paired markets only. Its owner, creator admin and treasury use the [shared governance addresses](/launchpad/reference/production-contracts#governance-and-fee-recipient). Read the factory's current configuration before preparing a launch.
## Arc scope
Arc uses the same governance methods and shared owner, creator-admin, treasury and updater configuration as the Standard suites on Base and Robinhood. Treasury changes apply to subsequent launch-fee payments and new pools; existing pool recipients and accrued claims remain unchanged. See [Arc configuration](/launchpad/reference/live-configuration#arc-mainnet) for current launch settings.
## BSC scope
BSC shares one managed factory across crypto and stock routes. Its owner and creator admin use the shared governance address; treasury and updater use the shared addresses as well. Read `owner()` and `creatorAdmin()` to determine current authority. Quote registration, suite selection and launch creation are separate controls. See [BSC configuration](/launchpad/reference/live-configuration#bsc-mainnet).
## X Layer scope
X Layer enables creation and uses the same [governance, creator-admin, treasury and updater addresses](/launchpad/reference/production-contracts#governance-and-fee-recipient) as the other chains. Read the factory for current administrative authority. Supply, permanent liquidity, quote revisions and creator-rights behavior follow the same minimal suite. See [X Layer configuration](/launchpad/reference/live-configuration#x-layer-mainnet).
# Interface and data flow
Source: https://docs.o1.exchange/launchpad/architecture/frontend-indexer
How the o1 Launchpad home, create, token, and profile pages connect wallet actions with live and indexed chain data.
The o1 Launchpad interface combines wallet-signed actions, live contract reads, Uniswap v4 market data, public token profiles, and confirmed chain events. The blockchain remains authoritative for tokens, pools, balances, fees, and ownership.
## Main pages
| Page | What users can do |
| - | - |
| Home | Discover launches, switch between All, Crypto, and available Stocks views, view **Trending now**, sort by trending, newest, liquidity, or 24-hour volume, and filter by paired asset |
| Create | Choose Standard, Tax or \$O launches, configure token identity, paired asset, public profile, and profile-editing preference, preview the result, and sign the launch transaction |
| Token | Review the token and creator, view the chart and market statistics, trade, inspect holders, read announcements, add comments, and use product-specific fee, dividend or burn actions |
| Profile | View a creator's launches and public identity; connected owners can edit their o1 profile, claim fees, claim Tax dividends, review Standard referrals, and manage supported token profile or announcement features |
**Trending now** is a discovery view based on indexed market activity. Ranked views also require adequate pool coverage and current market data, and placement is dynamic. They are not recommendations or guarantees of future performance.
Global search works across supported chains and accepts a token name, symbol, creator address, or token address. Results can be scoped to crypto-paired or stock-paired markets and filtered by paired asset. Base,프로젝트로 돌아가기