o1.exchange 백서 전문

Robinhood, BSC and X Layer have published stock catalogs; only assets registered on the selected chain's live factory are available for new creation. Monad has a standard crypto market with MON/USDC/WETH filters, and the same chain-scoped Trending, Volume, New and Liquidity feeds. Token pages expose transactions, holders, fees and updates; allocations depend on launch data, and staking requires a chain deployment. Public availability and data completeness depend on deployed indexer and provider coverage. Indexed historical data remains chain-scoped. A creator's signed o1 profile, including its display name, bio, avatar, and socials, is separate from the optional onchain token profile permission chosen for each launch. ## Discovery and transparency The current interface adds context around the onchain market without replacing it as the source of truth: * homepage statistics distinguish activity in official launch pools from tracked activity across other pools for o1-launched tokens; * Trending now and ranked feeds use current market activity, liquidity, pool-coverage checks, and data freshness; * stock-paired rows show the selected Stock Token and its provider label; * token charts can mark launch start, creator or connected-wallet trades, and announcements; * holder rows label known launch infrastructure, liquidity pools, exchanges, DeFi contracts, the creator, and the connected wallet when data is available; * every token page carries a safety notice to review liquidity, live sell quotes, and holders before trading. Discovery labels and third-party identity enrichment are informational. Contract addresses, balances, pools, and confirmed events remain authoritative. ## Token creation flow <Steps> <Step title="Configure and preview"> The creator enters the token identity, socials, paired asset, and profile-editing preference. The page previews the fixed supply, opening value, current creation fee, and permanent pool. </Step> <Step title="Review the launch"> The o1 confirmation screen shows the paired asset, supply, permanent liquidity, current creation fee, profile permission, and the token address preview. </Step> <Step title="Prepare and sign"> After the creator confirms the review, the interface stores the public token profile on IPFS and refreshes the selected pair, active launch contracts, settings, and chain time. Base and Robinhood use a separate factory for each product. Standard and Tax each share their factory across crypto and stock routes; \$O launches use the wstO-paired route. The creator then confirms the launch transaction in their wallet. </Step> <Step title="Open the token page"> After confirmation, the token page presents the new token, live Uniswap market, trades, holders, and public announcements. </Step> </Steps> The wallet is the only signing surface. o1's interface and data services never hold the user's private key. ## Trading flow The token page asks Uniswap v4 for a quote based on how much the trader wants to spend or sell. The interface applies the selected slippage limit and a route-specific deadline, then asks the wallet to submit the exact reviewed transaction through the chain's configured router. X Layer uses SwapX. <Tabs> <Tab title="Paying with native currency"> The wallet includes native currency in the swap transaction, including OKB on X Layer. No token approval is needed for native input. </Tab> <Tab title="Paying with a token"> The wallet approves the spender required by the selected route. X Layer swaps approve the SwapX proxy directly; Permit2 is used only by routes that require it. The submitted swap uses the reviewed amount and minimum output. </Tab> </Tabs> The flow supports a public trade comment. Standard swaps can also carry financial referral attribution; inclusive Tax swaps use frozen launch-time integrator attribution instead. o1 always submits input-amount swaps, so its normal buy and sell flow remains available during the opening anti-snipe period. ### Trade safeguards | Setting | Current interface behavior | | - | - | | Automatic slippage | 5% | | Quick choices | 1%, 3%, or 10% | | High-slippage handling | Warns at 10% or higher and prevents submission at 50% | | Price impact | Warns at 5% or higher and marks 25% or higher as very high | | Swap deadline | 4 minutes for SwapX or 10 minutes for Universal Router, set during transaction preparation | <span /> ## Standard referral journey * A profile's **Referral** action copies a global referral link. * A token page's **Referral link** action copies a link for that token and chain. * A public **Profile** link is separate and does not set attribution by itself. * Token-specific attribution takes priority for that token. A previously saved global attribution is the fallback. * The interface may request one gasless signature to associate a browser-saved global referral with a connected wallet. See [Fees, anti-snipe, and referrals](/launchpad/trading/fees-referrals) for the full precedence and validation rules. ## Tax rewards and burns Tax labels identify the product in discovery and token views. The token's ordinary buy/sell taxes and any current surcharge are separate concepts: the current execution rate may be higher during enabled anti-sniping. The trade quote includes the applicable fees. **Fees** and **Dividends** are separate. Dividend views show claimable rewards, total earned, minimum holding and rewards claimed. Trading assigns rewards automatically; **Claim all** claims one group of payable earnings on the displayed profile page per transaction. When no holders qualify as a trade's dividend fee is recorded, that portion becomes a protocol fee credit, with separate source attribution. See [Holder dividends](/launchpad/tax/dividends). The burn section shows tokens collected through the creator's burn allocation and ready to send to the dead address. Balances refresh after confirmed transactions, including actions made through another interface. Trades in unrelated pools do not automatically contribute to these taxes. ## \$O launches and market data \$O launch labels identify wstO-paired tokens in discovery. Their Create flow uses ETH for optional Dev Buy. Token-page buys and sells can settle in ETH, USDC on Base or USDG on Robinhood, \$O or wstO when an executable route is available; the pool itself stays paired with wstO. There are no fee-allocation, dividend-claim or manual-burn controls for this product. The token page's **Total wstO burned** aggregates confirmed fee burns from that launch pool only. It does not sum all suite pools or infer burns from the global token supply. Canonical `QuoteBurned` and `Trade` events are matched once; retries and overlapping receipt collection must not create extra burns. Same-transaction creation and Dev Buy are indexed together, with the creator attributed from the complete receipt. Robinhood acquisition-pool v4 logs must not be counted as launch-pool trades; match the exact pool ID and suite Hook. wstO's displayed USD price is a reference derived from \$O's reference price and the current vault conversion on the selected chain. It is not a guaranteed trade price. Its supply is an onchain token read. Liquidity, top-market and holder estimates depend on provider coverage; unavailable data must not be interpreted as zero. A launch pool's own price and executable swap quote remain distinct from the paired asset's reference valuation. ## Live and indexed information | Source | Used for | | - | - | | Launch contracts | Current launch settings, fee balances, and creator permissions | | Uniswap v4 | Pool price, swap quotes, liquidity state, and transaction simulation | | Confirmed chain events | Launches, trades, claims, announcements, and profile updates | | IPFS | Public token image and profile document | | Indexed application data | Search, feeds, charts, holder views, histories, and wallet dashboards | The indexer keeps the contracts used by both earlier and current launches queryable, while the create flow selects exactly one active factory for the chosen chain, product and market type. Public visibility is separate from indexing: historical index-only Tax entries continue to be indexed without appearing in public views or transaction preparation. Other supported historical markets retain their normal visibility. Trade attribution uses the confirmed receipt and router context so smart-wallet activity is associated with the correct trader. The hook's `Trade.executor` field alone is not treated as a user-wallet identity. After a transaction confirms, a page may briefly show that it is syncing while the indexed view updates. Live contract state and confirmed chain events remain the source of truth. BSC uses the same chain-scoped feed, creation, token and claim model, with BNB, USDC and the published bStock catalog. Chain visibility and the onchain creation switch remain separate. Canonical event collection provides launch/trade/fee completeness; stock reference prices and crypto-provider enrichment do not replace that collection. X Layer uses the same chain-scoped feeds, search, profiles, token activity and fee projections. Canonical range collection and reconciliation own launch/trade/fee completeness; webhook and receipt hints trigger refresh rather than creating duplicate trades. Supported quotes are native OKB, USDC, xETH and 45 wrapped stocks. Crypto USD metrics use same-chain Codex prices, with WOKB as the native OKB pricing identity. Stock references use TickDB market data with wrapper conversion applied once. Quote amounts retain their exact token units before USD valuation: six decimals for USDC and 18 for the other quotes. External all-pool analytics are collected separately; partial coverage must not hide other chains' available totals. # X commands Source: https://docs.o1.exchange/launchpad/bot/commands Copyable o1 Bot V1 launch instructions, supported fields, corrections, and stop behavior. o1 Bot interprets launch instructions in Posts that mention **@o1\_bot**. Use the labeled format below to make your intent clear. It is not a general-purpose trading assistant or a slash-command interface. ## Command overview | Intent | Example | Result | | - | - | - | | Launch | `@o1_bot Launch on Base` plus the required fields and image | Prepare and submit a supported token launch | | Launch with a purchase | Add `Dev Buy: 0.001 ETH` to a complete launch request | Create and buy atomically, if eligible and funded | | Ask for guidance | `@o1_bot help` or `@o1_bot template` | Launch guidance or setup instructions, depending on eligibility | | Correct an awaiting request | Reply to its prompt with `@o1_bot Symbol: FIX` | Update that request, rather than start another launch | | Opt out | `@o1_bot stop` | Stop accepting future launch requests from that X identity | ## Buy, sell and withdraw guidance These messages ask for directions only. **They do not authorize or execute a trade or withdrawal.** | Message | Reply behavior | | - | - | | `@o1_bot buy more` | Explains that X buys are unsupported and Dev Buy is launch-only; links to the token page when the reply context can be verified | | `@o1_bot sell it` | Explains that X selling is unsupported; points to the portal and, when verified, the token page for manual trading | | `@o1_bot withdraw` | Links to the portal to withdraw to the bound Owner wallet, which signs and pays gas | For a token-specific link, reply directly to **your own launch's Bot success message** or its original launch Post. The launch must be confirmed. The Bot does not select the latest token in the conversation or guess a token from an unrelated reply, another creator's launch, or an explicit different target. Without verified context, it gives general instructions instead. These standalone guidance requests do not consume an active launch's correction attempts or cancel it. Reply rate limits and opt-out still apply. “Nothing submitted for this request” refers only to the guidance message, not to any earlier pending launch. ## Launch template Attach exactly one supported image to this Post: ```text theme={null} @o1_bot Launch on Base Name: My Token Symbol: MYTOKEN Quote: ETH Description: A community token. ``` Explicitly include **Base**, even if Base is selected in the portal. A portal chain selection is not part of your X instruction. ### Fields | Field | V1 behavior | | - | - | | Chain | Required. Use `Launch on Base` or `Chain: Base` | | Name | Required, up to 50 characters | | Symbol | Required, up to 11 characters, no spaces; casing is preserved | | Image | Exactly one attached PNG, JPG or WEBP photo, up to 2 MB and 4,096 pixels per dimension | | Quote | Optional; defaults to ETH. Include it explicitly in your Post | | Description | Optional, up to 2,000 UTF-8 bytes | | Website, X, Telegram | Optional explicit links; not inferred from your author profile | | Metadata | Optional `editable` or `immutable`; Bot requests default to **editable** | | Dev Buy | Optional exact positive ETH amount, such as `Dev Buy: 0.001 ETH`. See [Dev Buy](/launchpad/bot/dev-buy) | An image URL, video, GIF or multiple-image Post is not a substitute for the single attached photo. The Bot validates the image it receives from X. The V1 crypto quote allowlist includes **ETH, USDC, cbBTC, cbDOGE, cbXRP, cbLTC, cbADA, cbMEGA, cbZEC, cbHYPE, VVV, AERO and MORPHO**. A quote must also be registered and available when the request executes. This list does not guarantee live availability. <Warning> The Bot's default metadata mode is editable, unlike the web create form's immutable default. To prevent later profile edits, explicitly include `Metadata: immutable`. Profile editing does not grant minting, balance control or liquidity removal. </Warning> ### Optional public profile Add only the fields you want published: ```text theme={null} Website: https://example.com X: https://x.com/your_project Telegram: https://t.me/your_project Metadata: immutable ``` Extra public metadata can contain up to 16 key/value pairs. Keys must be unique and use 1–64 UTF-8 bytes; each value can use up to 512 bytes, with a 4,096-byte combined budget. Never put passwords, private keys or other secrets in public metadata. ## Replies and corrections * A standalone Post or a reply can request a launch. Explicitly mention **@o1\_bot**. Do not rely on a repost or quote Post to trigger processing. * Multiple independent launches can share a conversation. Start each with a complete new launch instruction and its own fields and image. * A new launch does not reuse an earlier launch's details, including its Dev Buy amount. * If the Bot asks for missing information in a launch you already requested, reply directly to that prompt or the awaiting request from the same X account. For example: `@o1_bot Symbol: FIX` supplies a missing symbol; it is not a complete launch request. * A `help` or `template` reply contains example values, not your saved launch parameters. Copy the template into a complete launch Post, replace the fields and attach your image. Sending only `Symbol: FIX` does not adopt the Bot's example name, chain or image. * Each request allows up to three classified user Posts and at most two guidance or correction replies. If it is closed without submission, start a complete new request. * Processing and uncertain submissions are not invitations to retry. Check the existing request's result first. <Note> Known V1 limitation: `help` and `template` can share the same request and consume this reply budget. If the third classified Post still does not form a valid launch, the request closes without another reply. For example, `help` → `template` → `Symbol: FIX` can end silently. This differs from the standalone buy, sell and withdraw guidance above. Silence alone is not proof that a transaction failed; check request status before retrying. </Note> ## Stop future requests Send a standalone command: ```text theme={null} @o1_bot stop ``` `unsubscribe`, `opt out` and `opt-out` are also recognized standalone opt-out commands. <Warning> Stop is a persistent opt-out tied to your X identity, not a way to correct or cancel one launch. It does not undo a submitted transaction or revoke onchain permissions. V1 does not document a self-service X resume command. To revoke signing access, use the portal's [permission controls](/launchpad/bot/permissions). </Warning> ## Outside V1 X commands do not support ordinary swaps, standalone buys or sells, deposits, withdrawals, fee claims, permission changes, custom supply, allocations, vesting, Tax settings, stock pairs or non-Base launches. Gas settings, signer selection, contract addresses and Dev Buy slippage are not user-configurable commands. Smart-account launch requests are limited to **5 per hour and 10 per day**. Recorded requests that fail can still count toward those limits. Additional service and abuse-prevention limits may apply. # Dev Buy Source: https://docs.o1.exchange/launchpad/bot/dev-buy Buy tokens during an ETH-paired Base launch with an explicit amount and atomic execution. Dev Buy is an optional purchase made in the same transaction as your launch. It is **off unless you explicitly request it**. It is not a command to buy an existing token. ## Example Attach one supported image and post from your connected X account: ```text theme={null} @o1_bot Launch on Base Name: My Token Symbol: MYTOKEN Quote: ETH Dev Buy: 0.001 ETH ``` The amount is the purchase input, **not** the total transaction budget. Your smart account also needs ETH for the launch fee and network gas. ## Requirements | Setting | Bot V1 | | - | - | | Chain and pair | Base, with `Quote: ETH` | | Account | Activated user smart account with a valid launch permission | | Amount | Explicit positive decimal ETH amount, up to 18 decimal places | | Slippage tolerance | Fixed at 1%; not configurable through X | | Token recipient | Your smart account | | No-setup creator path | Dev Buy is not supported | Do not use `max`, `all`, percentages, an omitted amount or a separate buy instruction. For a launch without a purchase, leave out the Dev Buy field. ## Execution and fees The launch and purchase execute atomically. If the purchase cannot satisfy the protected minimum output, or another step reverts, the entire launch and purchase revert together. There is no successful launch with a silently skipped requested Dev Buy. The purchase pays the pool's ordinary trading fee, but not the launch anti-snipe surcharge. The launch fee and network gas are separate. Slippage protection is not a guarantee of a future price or resale value. <Warning> A failure detected before submission does not send a launch transaction. A transaction submitted and then reverted can still consume network gas. If submission status is unknown, do not assume it failed and repost. </Warning> ## Verify the purchase After a successful launch: 1. Open the linked launch transaction and check the purchase and token transfers. 2. Open **Wallet** in the o1 Bot portal and inspect the smart account's token balance. 3. Use the token contract address, not just its name or symbol, to identify the asset. Being the creator alone does not mean you hold tokens. Without a Dev Buy, the initial supply goes into locked liquidity. If the activity is still indexing, check the transaction before treating a missing asset row as a failed purchase. Tokens held by the smart account can be [withdrawn to your bound Owner wallet](/launchpad/bot/wallet-and-fees#withdraw-to-your-owner-wallet). The Bot itself cannot perform ordinary withdrawals or sell those tokens through X. # Permissions and safety Source: https://docs.o1.exchange/launchpad/bot/permissions What o1 Bot can do, what stays under Owner control, and how expiry and revocation work. Setup authorizes restricted launch operations from your smart account so that a valid X request can execute without asking your