# Alliance DAO Source: https://docs.o1.exchange/AllianceDAO Strategic Partnerships Powering o1.exchange Alliance DAO Partnership ## Elite Backing First investor in pump.fun, Moonshot, Believe App We're proud to announce that o1.exchange is backed by these elite investors in the blockchain space and many more, bringing institutional credibility and strategic resources to our platform. These strategic partnerships empower o1.exchange to push the boundaries of DeFi trading technology. We're rapidly developing cutting-edge solutions to deliver a divine trading experience that sets new standards in the industry. # o1 Alpha Token API Source: https://docs.o1.exchange/api/alpha-tokens Fetch the ranked o1 Alpha token contract-address list for a network without authentication. Use this public read endpoint to retrieve the token contract addresses currently included in o1 Alpha for one network. ## Endpoint ```http theme={null} GET https://api.o1.exchange/api/v1/alpha-tokens?networkId={networkId} ``` No API key or bearer token is required. ## Query parameter | Parameter | Type | Required | Description | | ----------- | ---------------- | -------- | ------------------------------------------------------------------ | | `networkId` | Positive integer | Yes | Registered network ID used by o1.exchange, such as `8453` for Base | The endpoint rejects a missing, duplicated, non-integer, or non-positive `networkId` with `400 Bad Request`. ## Request example ```bash theme={null} curl "https://api.o1.exchange/api/v1/alpha-tokens?networkId=8453" ``` ## Response A successful response is an unwrapped JSON array containing only contract addresses: ```json theme={null} [ "0x1111111111111111111111111111111111111111", "0x2222222222222222222222222222222222222222" ] ``` Addresses are ordered by their current o1 Alpha rank. Duplicate addresses are omitted while preserving the first ranked occurrence. The endpoint returns up to 1,000 addresses. If the network currently has no o1 Alpha tokens, the response is: ```json theme={null} [] ``` The response intentionally contains no token metadata, rank values, pagination fields, or network wrapper. Use the requested `networkId` as the chain context for every returned address. ## JavaScript example ```javascript theme={null} const response = await fetch( "https://api.o1.exchange/api/v1/alpha-tokens?networkId=8453", ); if (response.status === 429) { throw new Error("Rate limit exceeded. Wait before retrying."); } if (!response.ok) { throw new Error(`o1 API request failed with ${response.status}`); } const contractAddresses = await response.json(); ``` ## Errors Invalid request parameters return a JSON error: ```json theme={null} { "success": false, "code": 400, "message": "networkId must be a positive integer" } ``` | Status | Meaning | Client action | | ------ | --------------------------------------- | --------------------------------------------------------- | | `200` | Address list returned successfully | Consume the JSON array | | `400` | `networkId` is missing or invalid | Correct the request before retrying | | `429` | The source exceeded the edge rate limit | Wait before retrying and honor `Retry-After` when present | | `500` | Unexpected service error | Retry with capped exponential backoff and jitter | ## Rate limits and caching Cloudflare enforces source-based rate limits at the public API edge. Limits may change as traffic patterns and service capacity evolve, so clients must handle `429` responses instead of assuming a fixed quota. Successful responses include: ```http theme={null} Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=60 Access-Control-Allow-Origin: * ``` Browsers may call the endpoint across origins. Shared caches can reuse a successful response for up to five minutes, while browser caches can reuse it for up to one minute. # API overview Source: https://docs.o1.exchange/api/introduction Choose the o1.exchange API surface that matches your integration. o1.exchange provides separate API surfaces for public market data, authenticated trading, and o1 Launchpad integrations. ## Choose an API | API | Base URL | Authentication | Use it for | | ----------------------- | ----------------------------------- | --------------------------------- | ------------------------------------------------------------------ | | o1 Alpha Token API | `https://api.o1.exchange` | None | Read the ranked o1 Alpha token contract-address list for a network | | Trading API | `https://api.o1.exchange` | Bearer token | Prepare and submit programmatic trades | | o1 Launchpad Public API | `https://api.launch.o1.exchange/v1` | `x-api-key`, except health checks | Browse launches and prepare launchpad transactions | Fetch an unpaginated list containing only token contract addresses. No API key is required. Build and submit trades with MEV protection, Permit2 support, and configurable slippage. Integrate with o1 Launchpad through its separately versioned API and scoped API keys. ## Versioned routes The route path identifies the API version. Use the complete endpoint shown on each API page rather than adding a version to the base URL yourself. For example: ```text theme={null} GET https://api.o1.exchange/api/v1/alpha-tokens POST https://api.o1.exchange/api/v2/order ``` The o1 Launchpad Public API uses a different host and places `/v1` in its base URL. ## Common client behavior * Send and accept JSON unless an endpoint says otherwise. * Treat `429 Too Many Requests` as retryable after waiting. Honor `Retry-After` when the response includes it. * Use exponential backoff with jitter for transient `500` class errors. * Do not retry invalid `400` class requests without correcting them. * Keep private keys and API tokens out of client-side code and source control. # Trading API Source: https://docs.o1.exchange/api/trading Execute trades programmatically with MEV protection, Permit2 support, and automatic slippage handling ## Overview The o1.exchange Trading API enables programmatic trading with enterprise-grade features including built-in MEV protection, Permit2 support for gasless approvals, and automatic slippage handling. * **MEV Protection**: Private mempool routing to prevent sandwich attacks * **Gasless Approvals**: One-time Permit2 signatures for unlimited trading * **Automatic Slippage**: Built-in slippage protection with customizable limits ## Prerequisites Ethereum wallet with private key ETH for transaction costs Node.js environment ## Quick Start ### 1. Generate API Key Visit [https://o1.exchange/api-trading](https://o1.exchange/api-trading) Generate your secure API token for authentication ### 2. Create Transaction Batch **Endpoint:** `POST https://api.o1.exchange/api/v2/order` **Headers:** ```json theme={null} { "Authorization": "Bearer ", "Content-Type": "application/json" } ``` **Body:** ```json theme={null} { "networkId": 8453, // Network ID (8453 = Base, 56 = BSC, 1399811149 = Solana) "signerAddress": "0x...", // Your wallet address "tokenAddress": "0x...", // Token contract address "uiAmount": "1.0", // Amount in human-readable format "direction": "buy", // "buy" or "sell" "slippageBps": 300, // Slippage in basis points (300 = 3%) "mevProtection": true, // Enable MEV protection "quoteTokenAddress": "0x...", // (Optional) Quote token for stablecoin trades (Base only) "poolAddress": "0x..." // (Optional) Specific liquidity pool (Base, BSC) } ``` ```json theme={null} { "success": true, "id": "batch_123...", "transactions": [ { "id": "tx_456...", "unsigned": { "to": "0x...", "data": "0x...", "value": "0x...", "gasLimit": "0x...", "chainId": 1 }, "permit2": { "eip712": { "domain": {...}, "types": {...}, "values": {...} } } } ] } ``` ### 3. Sign Transaction and Permit2 For each transaction in the response: 1. **Sign Permit2 (if present):** * Extract the EIP-712 typed data from `permit2.eip712` * Sign using wallet's `signTypedData` method * Replace the signature placeholder in transaction data 2. **Sign the transaction:** * Create transaction object from the unsigned data * Sign using wallet's `signTransaction` method ```javascript theme={null} // Fixed signature placeholder - don't change const SIGNATURE_PLACEHOLDER = "42f68902113a2a579bcc207c91254c8516d921250e748c18a082d91d74908f8e9a05f27b72a030c6a42d77d0e0aab6fb09219b01a01e7b5b24e4f322ee1762ff1b"; for (const ctx of data.transactions) { const unsignedTx = Transaction.from(ctx.unsigned); // Handle Permit2 signature if present if (ctx?.permit2?.eip712) { const { domain, types, values } = ctx.permit2.eip712; const signature = await wallet.signTypedData(domain, types, values); // Replace placeholder with actual signature let txData = unsignedTx.data; txData = txData.replace(SIGNATURE_PLACEHOLDER, signature.slice(2)); unsignedTx.data = txData; } // Sign the transaction const signedTx = await wallet.signTransaction(unsignedTx); } ``` ### 4. Submit Transaction **Endpoint:** `POST https://api.o1.exchange/api/v2/order/complete` **Headers:** ```json theme={null} { "Authorization": "Bearer ", "Content-Type": "application/json" } ``` **Body:** ```json theme={null} { "id": "batch_123...", // Batch ID from create response "transactions": [ { "id": "tx_456...", // Transaction ID "signed": "0x...", // Signed transaction hex "permit2": { "eip712": { "signature": "0x..." // Permit2 signature } } } ] } ``` ```json theme={null} { "success": true, "transactions": [ { "hash": "0x...", // Transaction hash "status": "pending", // Transaction status "tokenDelta": "1000000" // Token balance change } ] } ``` ## Sample Scripts & Examples **GitHub Repository:** [https://github.com/CohumanSpace/o1-api](https://github.com/CohumanSpace/o1-api) This repository contains complete sample scripts for using the o1.exchange API, including: * Interactive CLI trading application * Complete integration examples * Proper error handling patterns * Environment setup guides ## Interactive Example See `execute-trade-interactive.js` in the [sample repository](https://github.com/CohumanSpace/o1-api) for a fully functional CLI trading application that demonstrates all integration steps with proper error handling and user interaction. ### Setup Environment Create a `.env.local` file: ```env theme={null} EXECUTE_TRADE_PRIVATE_KEY= EXECUTE_TRADE_API_TOKEN= EXECUTE_TRADE_BASE_URL= EXECUTE_TRADE_RPC_URL= ``` ### Run Interactive CLI ```bash theme={null} node execute-trade-interactive.js ``` Enter token contract address (e.g., `0x06ca615ac72a18e76b63bd4b5c320b6c8e291f8b`) Choose `buy` or `sell` Enter amount in ETH (for buy) or tokens (for sell) Review trade details and execute View balance changes after execution ## Advanced Features

**Gasless token approvals** using EIP-712 signatures

  • Automatic signature placeholder replacement
  • One-time approval for unlimited trading
  • Reduced gas costs for frequent traders

**Protection against sandwich attacks**

  • Private mempool routing
  • Reduced slippage from MEV bots
  • Enable with `mevProtection: true`
 ### Slippage Control Specify `slippageBps` in basis points where **100 bps = 1%** **Recommendations:** * **Normal conditions:** 300 bps (3%) * **Volatile tokens:** 500-1000 bps (5-10%) * **Large trades:** Increase as needed ## Error Handling Always implement proper error handling for: * Network connectivity issues * Insufficient balance or gas * Transaction reverts * API rate limiting The interactive example includes comprehensive error handling patterns you can reference for your own implementation. # Bug Bounty Program Source: https://docs.o1.exchange/community/bug-bounty Help secure o1.exchange and earn rewards for finding vulnerabilities ## Protecting Our Community At o1.exchange, security is our top priority. We've established a comprehensive bug bounty program to incentivize security researchers and developers to help identify vulnerabilities in our platform. Your contributions help us maintain the highest security standards for our users. Discover and report security issues to earn rewards Get paid for valid security findings based on severity ## Reward Structure Rewards are determined based on the severity and impact of the vulnerability: | Severity | Description | Reward Range | | ---------- | -------------------------------------------- | --------------- | | **High** | loss of funds, significant impact | $1,000 - $5,000 | | **Medium** | Limited impact, requires specific conditions | $500 - $1,000 | | **Low** | Minimal impact, informational issues | $100 - $500 | ### In Scope * Smart contract vulnerabilities * Trading engine exploits * Authentication bypass * Fund manipulation * Oracle manipulation * Cross-site scripting (XSS) * SQL injection * Remote code execution ### Out of Scope * Known issues or already reported vulnerabilities * Social engineering attacks * Physical attacks * Denial of service attacks * Issues in third-party services * Generic product bugs, including but not limited to UI/UX, application clients, product stability, etc. * Attempting to exploit vulnerabilities on the mainnet or causing actual harm to users is strictly prohibited and may result in legal action. * No one should break nor exploit the mainnet (production o1.exchange site) without the admin/team's approval; otherwise it would lead to a smaller final payout. ## How to Participate Review our smart contracts, trading platform, and infrastructure for potential vulnerabilities Create a detailed report including: * Clear description of the vulnerability * Steps to reproduce * Impact assessment * Suggested fix (if applicable) * Payments would be sent when attack and solution documentations are shared, given no follow-up attack within the next 1 month Send your report to our X account @o1\_exchange via DM Our security team will review your submission within 48 hours Upon validation, receive your bounty payment in USDC or ETH ## Recognition Top contributors to our bug bounty program will be featured in our Security Hall of Fame and receive exclusive NFT badges recognizing their contributions to platform security. ## Legal Safe Harbor We commit to not pursuing legal action against security researchers who: * Comply with this bug bounty policy * Act in good faith * Make a reasonable effort to avoid privacy violations * Do not exploit vulnerabilities beyond what's necessary for verification Join our security-focused Discord channel to discuss potential findings with our team and other security researchers. Remember: collaboration makes our platform stronger! ## Contact For questions about the bug bounty program or to submit a vulnerability report: **Twitter**: Send your report to our X account @o1\_exchange via DM.\ **Response Time**: Within 48 hours. # Platform Metrics Source: https://docs.o1.exchange/community/metrics View comprehensive platform metrics including trading volumes, active users, fee generation, and network distribution Bookmark the Dune dashboard to stay updated on platform performance and trading trends. The data is particularly useful for understanding market dynamics and making informed trading decisions. # Community & Socials Source: https://docs.o1.exchange/community/socials Connect with thousands of traders, developers, and DeFi enthusiasts in the o1.exchange community. Get real-time updates, trading insights, and direct support from our team. Our community is global and active 24/7. Whether you're a beginner or experienced trader, you'll find valuable insights and supportive community members ready to help you succeed. # Explore Tokens Source: https://docs.o1.exchange/features/explore-tokens o1.exchange provides comprehensive token exploration tools to help you discover new opportunities, research projects, and make informed trading decisions across multiple blockchain networks. ### Token Discovery Features Discover the most popular and trending tokens based on trading volume and community interest Stay updated with newly listed tokens and early-stage opportunities Track the best and worst performing tokens over various time periods Find tokens with exceptional trading volume and liquidity

Explore Tokens in Pulse

Pulse page showing new token pairs

Use the Pulse page to discover new trading pairs that have been recently launched. This section highlights tokens that are gaining traction, allowing you to spot emerging opportunities early.

Filter Tokens by Your Criteria

Pulse page filter options

Apply advanced filters to narrow down tokens based on your selection criteria—such as trading volume, price change, liquidity, or launch time. This helps you focus on tokens that best match your investment or trading strategy.

# Onramp Fiat to Crypto Source: https://docs.o1.exchange/features/onramp o1.exchange provides integrated fiat onramp solutions powered by Coinbase, allowing you to convert traditional currencies (USD, EUR, etc.) directly into cryptocurrency without leaving the platform. ### Supported Payment Methods Instant purchases with major credit and debit cards Lower fees with ACH and wire transfer options Support for Apple Pay, Google Pay, and other digital wallets

1. Input the amount of chain native token to purchase

Onramp process illustration

2. Complete the purchase

Coinbase integration illustration
# Portfolio Source: https://docs.o1.exchange/features/portfolio Comprehensive portfolio tracking and analytics ## Portfolio Overview Easily track your entire crypto portfolio in one place. The portfolio dashboard provides a comprehensive summary of your assets, including real-time balances, performance stats, and detailed analytics.
Portfolio summary dashboard
### Multi-Wallet Analytics You can view your portfolio analytics for: * **All wallets combined** for a complete overview * **Main wallet** or any **active wallet** * **Custom wallet combinations**—select any set of wallets to analyze their aggregated balances, performance, and token distribution

1. Select Wallets to Analyze

Select wallets for analytics

Choose your main, active, or any combination of wallets to customize your analytics view.

2. View Aggregated Analytics

Aggregated analytics across wallets

Instantly see aggregated stats, token allocations, and performance metrics across your selected wallets.

The portfolio dashboard gives you full flexibility to analyze your holdings across any wallet or group of wallets, helping you make informed decisions with complete visibility. # Referrals & Rewards Source: https://docs.o1.exchange/features/referrals-rewards Earn rewards through referrals and trading activities ## Rewards & Referral Dashboard Manage and track all your rewards and referral activities in one place. The dashboard provides a comprehensive overview of your trading and referral performance, including: * **Trading Tier**: View your current trading tier and the benefits it unlocks. * **Cashback Rate**: See your current cashback percentage based on your trading activity. * **Cashback Rewards**: Track the total cashback you've earned. * **Total Trading Volume (per chain)**: Monitor your trading volume across different supported blockchains. * **Referral Rewards**: View the total rewards earned from referring others. * **Total Referred Users**: See how many users have signed up using your referral code. * **Referred Volume**: Track the trading volume generated by your referred users. * **Cashback History**: Review a detailed history of your cashback rewards. * **Reward History**: Access a log of all rewards earned through trading and referrals. * **Multi-Tier Referrals**: Analyze your referred users across multiple tiers and their corresponding trading volumes.
Rewards and referral dashboard
*** ## Set Your Referral Code Personalize your referral code to make it easy to share with friends and track your referrals. Setting your code is simple:
Set referral code
1. Choose a unique referral code. 2. Save your code to activate it. 3. Share your code with friends to start earning rewards. *** ## Share and Earn Together Invite friends to o1.exchange using your referral code. When they trade, you both benefit—your friends receive a portion of their trading commission back as cashback, and you earn referral rewards based on their activity.
Share referral code
* Share your code via social media, messaging apps, or directly. * Track the rewards and cashback earned by you and your referred users in real time. * Multi-tier referrals let you benefit from the activity of users referred by your direct referrals as well. Set your referral code, share it, and start earning rewards together! All referral and cashback rewards are transparently tracked in your dashboard. # Trading Source: https://docs.o1.exchange/features/trading Advanced trading features and order types ## Trading Features Unlock powerful trading tools designed for both beginners and advanced users. Our platform supports a variety of order types to help you execute your strategies with precision. ### 1. Spot Order A spot order allows you to buy or sell tokens instantly at the current market price. ### 2. Limit Order Set your desired price and let the system execute your trade when the market reaches your target. ### 3. Sniper Order Sniper orders are designed for high-speed execution, letting you target specific liquidity events or new token launches. ### 4. TWAP (Time-Weighted Average Price) TWAP orders help you minimize market impact by splitting your trade into smaller orders executed over a set period. *** ## How to Trade Follow these simple steps to place a trade: ### 1. Review Token Details
Token Detail
Check the token's information, including price, liquidity, and recent activity, to make informed decisions. ### 2. Configure Your Wallet
Wallet Configuration
Select your active wallet for multi-wallet trading. ### 3. Place Your Trade
Place Trade
Choose your order type (Spot, Limit, Sniper, or TWAP), enter the trade details, and confirm your transaction. *** Advanced trading features are continuously being improved. Stay tuned for updates and new order types! # Wallets Source: https://docs.o1.exchange/features/wallets Secure wallet integration and management ## Wallet Management Features Manage your wallets seamlessly within o1.exchange. Our platform provides a robust set of tools for creating, importing, exporting, and organizing your wallets—all under your single o1.exchange account. ### 1. Create New Wallets Easily generate new wallets directly from your o1.exchange dashboard. Each wallet is securely managed and linked to your account, allowing you to organize multiple wallets for different purposes or strategies. ### 2. Import Existing Wallets Bring your existing wallets into o1.exchange by importing them using your secret key. All imported wallets are managed in a non-custodial manner, ensuring you retain full control and ownership. ### 3. Export Wallets with Recovery Phrase Export all your wallets at once using a single 12-word recovery phrase. This allows you to back up and restore up to 100 wallets simultaneously, making wallet management and migration simple and efficient. ### 4. Individual Wallet Actions For each wallet, you can: * **Archive**: Move wallets you no longer use to an archived state. * **Set as Main Wallet**: Designate any wallet as your primary wallet for transactions. * **Export Private Key**: Access and export the private key for any wallet when needed. * **Set Active/Inactive**: Toggle wallets between active and inactive status to keep your dashboard organized. Generate new wallets or import existing ones using your secret key. All wallets are managed securely and non-custodially. Export up to 100 wallets at once with a single 12-word recovery phrase. Archive, set main, or export private keys for any wallet. ## Split & Consolidate Tokens Easily manage your assets by splitting or consolidating tokens directly from the wallets page. This feature allows you to move tokens between your wallets for better organization or strategy execution.

1. View and Select Wallets

Wallets overview

Access all your wallets in one place. Select the wallet you want to split tokens from or consolidate tokens into.

2. Initiate Token Transfer

Initiate token transfer

Choose the "Transfer" option to move tokens between your wallets. Specify the amount and the destination wallet to split or consolidate your holdings.

3. Confirm and Complete

Confirm token transfer

Review the details and confirm the transfer. Your tokens will be moved instantly, allowing you to efficiently manage your portfolio across multiple wallets.

Wallets on o1.exchange are managed in a non-custodial way, giving you full control and flexibility. You can organize, back up, and manage multiple wallets with ease. # Trading Fees Source: https://docs.o1.exchange/getting-started/fees The more you trade, the more you earn back! ## Fees ### Cashback Program Our universal cashback program applies across all markets - spot, prediction markets, and future markets. You level up as you trade more, earning greater cashbacks that reduce your effective trading fees. #### Tier 1 * Cashback: 0.2% * Net Fee Reduction: 0.20% #### Tier 2 * Cashback: 0.25% * Net Fee Reduction: 0.25% #### Tier 3 * Cashback: 0.30% * Net Fee Reduction: 0.30% #### Tier 4 * Cashback: 0.35% * Net Fee Reduction: 0.35% #### Tier 5 * Cashback: 0.40% * Net Fee Reduction: 0.40% The cashback is applied to your base trading fee, regardless of the market type you're trading in. ### Spot Market **Base Fee:** 1.00% With our cashback program, your effective trading fees for spot markets are: * **Tier 1:** 0.80% (1.00% - 0.20% cashback) * **Tier 2:** 0.75% (1.00% - 0.25% cashback) * **Tier 3:** 0.70% (1.00% - 0.30% cashback) * **Tier 4:** 0.65% (1.00% - 0.35% cashback) * **Tier 5:** 0.60% (1.00% - 0.40% cashback) ### Prediction Market For prediction market trades, we use a dynamic fee structure based on market conditions: **Base Fee Formula:** `Fee = round_up(0.07 × C × P × (1 - P))` Where: * **C** is the amount of shares being traded * **P** is the current probability (price) of the outcome, expressed as a decimal between 0 and 1 * The result is rounded up to the nearest unit **Note:** Cashback from our tier program applies to the calculated fee, reducing your effective trading costs. #### How it Works The fee calculation automatically adjusts based on: 1. **Trade Size (C):** Larger trades incur proportionally higher fees 2. **Market Probability (P):** The fee changes based on how certain the market is about an outcome 3. **Volatility Factor (P × (1 - P)):** This reaches maximum when P = 0.5 (50% probability), meaning the market is most uncertain #### Base Fee Examples (Before Cashback) * When **P = 0.5** (50% probability): Maximum fee = `0.07 × C × 0.25 = 0.0175 × C` * When **P = 0.1** (10% probability): Fee = `0.07 × C × 0.09 = 0.0063 × C` * When **P = 0.9** (90% probability): Fee = `0.07 × C × 0.09 = 0.0063 × C` * When **P = 0.01 or 0.99** (extreme probabilities): Minimum fee = `0.07 × C × 0.0099 ≈ 0.000693 × C` This dynamic fee structure ensures: * **Fair pricing** based on market uncertainty * **Lower fees** when outcomes are more certain (very high or very low probabilities) * **Balanced liquidity provision** across all probability levels * **Additional savings** through our universal cashback program ### Perpetuals (Perps) We integrate with Hyperliquid Build Code to provide perpetual futures trading. Our platform charges the industry's lowest builder fee of **0.010%** for perpetual trades. **Builder Fee:** 0.010% This ultra-low builder fee provides exceptional value for perpetual futures traders. # Points System Season 1.1 Source: https://docs.o1.exchange/getting-started/points-system-season1 Points system rewards active traders and contributors to the o1.exchange community **Points System Season 1.1** - Active since August 19, 2025, until January 19, 2026, 00:00:00 UTC (Monday). See [Points System Season 2](/getting-started/points-system-season2) for the new competitive weekly leaderboard system. ## Points Overview o1.exchange features a comprehensive rewards system that recognizes and incentivizes various trading activities and community contributions. Earn points through trading, referrals, and early adoption across multiple trading seasons. Earn points based on your trading volume across all supported networks Gain points from the trading activity of users in your referral network Special bonus points and badges available during trading seasons ## Trading Seasons Explore the different trading seasons and their unique reward structures: Early beta rewards program with exclusive OG Trader badges and bonus points for early participants (May - September 2025) Foundation season with enhanced trading rewards and expanded network support (Details coming soon) ## Trading Volume Points Earn points for every trade you execute on the platform. * **Multi-Network Support**: Points aggregate across Solana, Base, and all supported networks * **Token-Specific Rates**: Different tokens may have different point multipliers * **Default Rate**: 50 points per 1 SOL traded (or equivalent) * **Formula**: `trade_volume × points_rate` If you trade 10 SOL worth of tokens: * Base points: 10 × 50 = **500 points** * Additional multipliers may apply based on specific token configurations ## Multi-Level Referral Points Earn points from the trading activity of users in your referral network, up to 4 levels deep. [Learn more about rewards & point structure →](/getting-started/referral-system) ### Referral Points Structure * Each level has different point rates * Rates are configurable per network and token * Points accumulate from all levels simultaneously ## Additional Point Sources **200 points** for each direct invite who joins the platform Bonus points during promotional periods and campaigns Update (Aug 27, 2025): Transaction Points are no longer awarded for each transaction. Points are now earned only based on trading volume to prevent abuse and ensure fair rewards. Please focus on increasing your trading volume to maximize your points. ## Total Points Calculation Your total points are calculated by aggregating: 1. **OG Trader Bonus** (if eligible) 2. **Trading Volume Points** across all networks 3. **Referral Points** from all 4 levels 4. **Invite Points** for direct referrals 5. **Transaction Points** for activity All calculations use high-precision decimal arithmetic to ensure accuracy in point distribution. # Points System Season 1.2 Source: https://docs.o1.exchange/getting-started/points-system-season2 Competitive weekly leaderboard mechanism distributing predetermined point pools based on trading volume ## Overview The Points System Season 1.2 is a competitive weekly leaderboard mechanism that distributes a predetermined pool of points to users based on their proportional trading volume. Unlike traditional transaction-based point systems, Season 1.2 allocates a fixed amount of points each week that users compete for based on their share of the total weekly trading volume. ## System Architecture ### Phase-Based Point Allocation Points System Season 1.2 launches with Phase 1, offering the highest weekly point rewards: | Phase | Weeks | Points Per Week | Total Points | | ------- | ----- | --------------- | ------------ | | Phase 1 | 1-20 | 2,000,000 | 40,000,000 | | Phase 2 | 21 | 2,000,000 | 2,000,000 | **Phase 1:** Distributes 40,000,000 points over weeks 1–20.\ **Phase 2:** Distributes 2,000,000 points over the week 21. ### Epoch System * **Start Date:** January 19, 2026, 00:00:00 UTC (Monday) * **End Date:** June 15, 2026, 00:00:00 UTC (Monday) * **Duration:** Exactly 7 days per epoch * **Reset:** Weekly at the same time * **Current Implementation:** Week-based epochs with precise timestamp boundaries ## Point Distribution Mechanism ### Volume Share Calculation Points are distributed to all users each week in proportion to their trading volume. The weekly point pool is shared among all users who have trading volume, with each user receiving points based on their percentage of the total weekly volume. **All users are rewarded:** Every user with trading volume receives points proportional to their share of the week's total volume. The leaderboard shows the top 30 users for the current week, but all participating users earn points. ### Trading Volume Calculation **Supported Fee Currencies:** * **Native Tokens:** SOL, ETH (converted from smallest units) * **USDC:** Direct USD value (handles both atomic units and human-readable format) * **Quote tokens**: ZORA, etc. ### Price Conversion For non-USD transactions, the system uses cached major token prices to convert to USD equivalent: * Real-time price feeds from majorTokenV2 table * Network-specific price mappings * Fallback handling for price discovery failures **Leaderboard Table:** * Top 30 users by trading volume * Rank badges for top 3 positions (Gold/Silver/Bronze) - these are visual recognition only and do not provide additional points * Wallet addresses (truncated for privacy) * USD trading volume * Points allocated ### Real-Time Features * **Live Updates:** Query-based real-time data refresh * **Countdown Timer:** Precise remaining time until epoch reset * **Progress Tracking:** Personal performance metrics * **Competition Status:** Clear ranking and reward information This system creates a competitive yet fair environment where users compete weekly for their share of predetermined point pools, with rewards directly proportional to their trading activity and contribution to platform volume. # Referral System Source: https://docs.o1.exchange/getting-started/referral-system Earn rewards through our 4-tier referral program Referral System ## Multi-Tier Referral Program o1.exchange offers a powerful 4-tier referral system that rewards you for bringing new traders to the platform. Earn a percentage of trading fees from not only your direct referrals but also from their referrals up to 4 levels deep. Create your unique referral link from your account dashboard Share your link with friends, on social media, or in trading communities ## Referral Reward Structure **April 10, 2026 Update:** o1.exchange revamped its cashback and referral system to discourage self-referral and encourage the use of official o1.exchange KOL/partner referral links. ### Cashback Rules (from April 10, 2026) Users who sign up with an o1.exchange **KOL/partner referral link** receive **45% cashback** ready to go from day one. Users who sign up with a **regular referral link** receive **20% cashback**, with the ability to upgrade to higher cashback tiers as their trading volume grows. ### Reward Tiers (before April 10, 2026) Our industry-leading 4-tier referral system offered some of the most competitive rates in DeFi: | Tier | Relationship | Reward (% of Trading Fees) | | ---- | ------------------------- | -------------------------- | | 1 | Direct referrals | **35%** | | 2 | Your referrals' referrals | **3%** | | 3 | Third-level referrals | **2%** | | 4 | Fourth-level referrals | **1%** | If your network generated \$10,000 in trading fees: * **Tier 1 (35%)**: \$3,500 from direct referrals * **Tier 2 (3%)**: \$300 from second-level referrals * **Tier 3-4**: Additional earnings from your extended network All referral rewards are automatically credited to your account in real-time as your network trades on the platform. ## Maximizing Your Referral Income Focus on referring active traders who trade frequently and in high volumes to maximize your tier 1 rewards. Help your direct referrals understand the benefits of referring others, which can increase your tier 2-4 rewards. Share your referral link in trading communities, Discord servers, and social media groups where potential traders gather. The power of compound networking means that even a small network of active traders can generate significant passive income through our 4-tier system. ## Getting Started Access your o1.exchange dashboard using your credentials Find the "Referrals" section in your user dashboard Create your unique referral link with one click Distribute your link and watch your rewards grow in real-time # Trading Season 1: Early Beta Source: https://docs.o1.exchange/getting-started/rewards/season-1 OG Trader rewards during early Beta period ## OG Trader Program Trading Season 1 recognizes early adopters who participated in the o1.exchange beta period. This exclusive program rewards traders who helped shape the platform during its initial launch. ### Eligibility Period **May 17, 2025** - First day of eligibility **September 5, 2025** - Last day to qualify ### OG Trader Badge Requirements OG Badge To earn the exclusive OG Trader Badge: * Trade during the eligibility period (May 17 - September 5, 2025) * Reach **Level Tier 2 (Silver tier)** through trading activity * Maintain active participation throughout the season ### Points Calculation The OG Trader program rewards early participation with higher points for earlier trading dates: | Trading Start Date | Points Earned | Bonus Type | | ------------------ | ---------------- | ------------------ | | Day 1 (May 17) | **5,000 points** | Maximum Early Bird | | Week 1 | \~4,500 points | High Early Bird | | Month 1 | \~3,500 points | Early Bird | | Mid-period | \~2,550 points | Standard | | Month 3 | \~1,000 points | Late Entry | | Last day (Sep 5) | **100 points** | Minimum | | After Sep 5 | 0 points | Ineligible | * Points decrease linearly from the maximum to minimum over the eligibility period * Earlier traders receive significantly more rewards * No points are awarded for trading after the season ends * Points are awarded once per trader based on their first trade date ## Benefits & Recognition Permanent OG Trader status displayed on your profile Up to 5,000 additional points for early participation Special recognition in the o1.exchange community The OG Trader program was a one-time opportunity for early beta participants. Future seasons will have different reward structures and requirements. ## Maximizing Season 1 Rewards Start trading as close to May 17, 2025 as possible for maximum points Focus on achieving Level Tier 2 through consistent trading activity Maintain regular trading throughout the season to build your profile Use the referral system to compound your rewards beyond the OG bonus # Trading Season 2: Base Source: https://docs.o1.exchange/getting-started/rewards/season-2 Base Season rewards and point structure ## Base Season Overview Trading Season 2 represents the foundation of o1.exchange's ongoing rewards program, focusing on Base chain trading with a comprehensive tier system based on ETH trading volume. ### Season Timeline **September 5, 2025** - Season 2 begins immediately after Season 1 ends ## Base Wizard Badge 🧙‍♂️ Base Wizard Badge Earn the exclusive Base Wizard Badge by completing one of the following requirements: **Trade 100 ETH** in total volume on Base chain **Refer 300 ETH** in total volume through your referral network The Base Wizard Badge is a special achievement that recognizes both active traders and successful community builders. You only need to complete ONE of the two paths to earn this badge. ## Tier Benefits Each Base Chain tier unlocks exclusive benefits and recognition: Enter trading contest with generous bounty Higher tiers earn increased points per trade Special recognition and leaderboard placement Season 2 focuses exclusively on Base chain ETH trading volume. Other networks and tokens may be included in future seasons. # Zora Trading Contest Source: https://docs.o1.exchange/getting-started/rewards/zora-trading-contest Eight-week trading contest for Zora Creator and Content Coins ## Contest Overview The first Zora Trading Contest is an eight-week competitive campaign with a total reward pool of 2,500,000 \$ZORA tokens. ### Campaign Duration **November 3, 2025 - December 27, 2025** 8 consecutive weekly periods, resetting every Monday at 00:00 SGT ## Rewards Pool **2,500,000 \$ZORA** Allocated as 312,500 \$ZORA per weekly window across 8 weeks ## Eligibility Requirements Only trades executed directly through o1.exchange count toward eligibility. External trades (including after wallet export) are not eligible. ## Eligible Trading Activity The contest tracks bona fide trades of: * **Zora Creator Coins** * **Zora Content Coins** All trades must be executed via the o1.exchange platform to qualify for leaderboard rankings. ## Weekly Leaderboards & Rewards Each week features a volume-based leaderboard with the following reward structure: ### Volume Leaderboard (312,500 \$ZORA per week) For users with Base Wizard Badge, we will apply a multiplier of 2X to count your trading volume. Top 100 accounts by aggregate trading volume across all wallets linked to the same o1 account: | Rank | Reward per Account (\$ZORA) | | ------ | --------------------------- | | 1 | 29,738.75 | | 2 | 26,523.75 | | 3 | 24,916.25 | | 4 | 21,701.25 | | 5 | 20,093.75 | | 6 | 19,290.00 | | 7 | 16,878.75 | | 8 | 15,271.25 | | 9 | 12,860.00 | | 10 | 12,056.25 | | 11–15 | 4,822.50 | | 16–20 | 3,536.50 | | 21–25 | 2,411.25 | | 26–50 | 1,607.50 | | 51–100 | 382.625 | ## Reward Claims Rewards will be distributed within 7 days of the weekly volume window. Winners must claim rewards within 14 days after each Weekly Campaign Period ends. Unclaimed rewards are forfeited and revert to Zora's control. # Zora Trading Contest Season 2 Source: https://docs.o1.exchange/getting-started/rewards/zora-trading-contest-season2 Season 2 for Zora Creator and Content Coins ## Contest Overview The second Zora Trading Contest is a competitive campaign with a total reward pool of 1,250,000 \$ZORA tokens for traders. ### Campaign Duration **January 5, 2026 - January 12, 2026** Contest ends at 12:00 AM PDT (7:00 AM UTC) on January 12, 2026 ## Rewards Pool **1,250,000 \$ZORA** Allocated to top 100 winners during the contest week ## Eligibility Requirements Only trades executed directly through o1.exchange count toward eligibility. External trades (including after wallet export) are not eligible. ## Eligible Trading Activity The contest tracks bona fide trades of: * **Zora Creator Coins** * **Zora Content Coins** All trades must be executed via the o1.exchange platform to qualify for leaderboard rankings. ## Weekly Leaderboards & Rewards Each week features a volume-based leaderboard with the following reward structure: ### Volume Leaderboard (1,250,000 \$ZORA total) For users with Base Wizard Badge, we will apply a multiplier of 2X to count your trading volume. Top 100 accounts by aggregate trading volume across all wallets linked to the same o1 account: | Rank | Reward per Account (\$ZORA) | | ------ | --------------------------- | | 1 | 119,047.50 | | 2 | 106,095.00 | | 3 | 99,665.00 | | 4 | 86,805.00 | | 5 | 80,375.00 | | 6 | 77,160.00 | | 7 | 67,515.00 | | 8 | 61,085.00 | | 9 | 51,440.00 | | 10 | 48,225.00 | | 11–15 | 19,290.00 | | 16–20 | 14,146.00 | | 21–25 | 9,645.00 | | 26–50 | 6,430.00 | | 51–100 | 1,530.50 | ## Reward Claims Rewards will be distributed within 7 days of the contest end. Winners must claim rewards within 14 days after the Contest Period ends. Unclaimed rewards are forfeited and revert to Zora's control. # Sign Up for o1.exchange Source: https://docs.o1.exchange/getting-started/signup Quick onboarding ## Create Your Account ### Account Creation Go to [o1.exchange](https://o1.exchange) and click the "Enter App" button o1.exchange signup page There are 3 signup options: 1. Gmail account 2. One time password for any email you choose 3. Wallet logins including Phantom, Backpack, MetaMask, Rabby, Coinbase, and over 120 wallet options. o1.exchange wallet login options Set up your trading profile and preferences ## Next Steps After creating your account: 1. **Fund Your Wallet**: Ensure you have sufficient balance on supported networks Fund your wallet on o1.exchange 2. **Explore the Platform**: Familiarize yourself with the trading interface 3. **Join the Community**: Connect with other traders on Discord 4. **Start Trading**: Begin with small positions to get comfortable with the platform [Start Trading Now](https://o1.exchange) - Create your account and join thousands of traders on o1.exchange # o1.exchange - Democratizing Alpha for Traders Source: https://docs.o1.exchange/introduction The Ultimate Trading Terminal for DeFi o1 Exchange Banner o1.exchange represents the pinnacle of high-frequency trading infrastructure on-chain — architected for unparalleled execution speed, engineered for quantitative edge, and optimized for full-range traders, from beginners to the pro. o1.exchange is the next-generation trading platform built for the DeFi ecosystem, combining institutional-grade infrastructure with an intuitive user experience for traders of all levels. ## Unmatched Trading Performance Achieve microsecond-level transaction finality for optimal trade execution Leverage proprietary algorithms designed for maximum market advantage Intuitive interface that scales from beginners to professional traders ## Powered by Advanced Intelligence Our platform identifies profitable trading opportunities before they appear in market prices, giving you the edge to act first. Comprehensive analysis of on-chain metrics, social sentiment, and liquidity patterns delivered in real-time to inform your trading decisions. Access exclusive market insights typically reserved for institutional traders, now available on our platform. ## Full-spectrum Trading Ecosystem Trade memecoins with confidence using our advanced predictive analytics that help identify trends before the market. Access a wide range of tokenized equities and synthetic assets all from one unified platform. Seamlessly trade across multiple blockchains with our unified liquidity pools and cross-chain infrastructure. Experience the future of trading with o1.exchange - where speed, intelligence, and accessibility converge. # Authentication and API keys Source: https://docs.o1.exchange/launchpad/api/authentication Create, scope, rotate, and protect o1 Launchpad API keys. ## API key header ```http theme={null} x-api-key: o1_launch_<8-character-prefix>_ ``` The prefix is eight lowercase hexadecimal characters used for indexed lookup. The secret is 32 cryptographically random bytes encoded as URL-safe base64. Keys are not accepted in query parameters, and the server stores a peppered HMAC digest rather than the plaintext secret. ## Create and manage keys Use [launch.o1.exchange/developers](https://launch.o1.exchange/developers). Key management requires a short-lived, domain-bound wallet signature. It supports EOAs and compatible smart-contract wallets. The signed message states that it is off-chain and does not approve tokens or move funds. Self-service keys: * use the Developer plan by default * are owned by the signing wallet * are limited to two active production keys * allow up to 10 newly created or rotated keys per wallet in 24 hours * allow up to 120 signed key-management actions per wallet each hour * expose the plaintext secret once * can be rotated with a short overlap window so clients can change secrets without downtime * can be revoked, with gateway authorization caches expiring within five seconds Lost keys cannot be recovered. Rotate or revoke and replace them. Rotation copies the existing plan, scopes, origin allowlist, and any operator-assigned policy override. The previous key is marked `rotating` and expires after the configured overlap. ## Scopes | Scope | Access | | ------------------- | ------------------------------------------------------------------------------------- | | `config:read` | Production configuration | | `tokens:read` | Token browsing, search, creator launches, details, trades, announcements, and holders | | `wallets:read` | Public wallet summaries, activity, and fee claims | | `transactions:read` | Indexed transaction and launchpad operation state | | `launches:prepare` | Launch transaction preparation | | `swaps:quote` | Exact-input quotes | | `swaps:prepare` | Universal Router transaction preparation | | `claims:prepare` | Trading-fee claim preparation | | `creator:prepare` | Announcements and metadata | Choose only the scopes an integration needs. No API scope authorizes direct edits to launchpad product records in Convex. Read scopes return public data. Prepare scopes validate live state and return unsigned wallet steps. The user's wallet remains the only component that can authorize an on-chain action. ## Browser origins An allowed origin is the website scheme, host, and port. It covers every page and API call made from that site. ```text theme={null} https://example.com https://app.example.com ``` The key form accepts multiple origins separated by commas and normalizes pasted URLs to their origin. Add each subdomain separately; wildcards are not accepted. For example, allowing `https://test.com` also allows calls made from `https://test.com/test` because URL paths are not part of an origin. Leave the list empty to allow the key from any website or server integration. Add origins only when a browser key should be limited to specific sites. API-key authentication, scopes, and rate limits still apply either way. Server integrations normally send no browser `Origin` header and are unaffected by this setting. Browser responses expose request IDs, retry timing, and rate-limit headers so integrations can handle errors and throttling without losing diagnostic details to CORS. CORS permission does not replace API-key authentication. The public `/health` route is the only exception and can be called from any valid website origin without a key. ## Secret handling * keep production keys in a secret manager * do not commit `.env` files * do not log full keys * use separate keys for separate integrations * revoke a key before sharing logs or code that may contain it * use idempotency keys on all retryable state-building requests # Claims and creator actions Source: https://docs.o1.exchange/launchpad/api/claims-and-creator-actions Prepare fee claims, announcements, and token metadata updates. ## Fee claims Fee claims use their own preparation route and do not need a `kind` field. `POST /claims/fees/prepare` accepts 1 to 10 fee positions returned by `GET /wallets/{address}/fee-claims`: ```json theme={null} { "chain_id": 8453, "caller": "0x1111111111111111111111111111111111111111", "claims": [ { "recipient": "0x1111111111111111111111111111111111111111", "fee_escrow": "0x2222222222222222222222222222222222222222", "currency": "0x0000000000000000000000000000000000000000", "mode": "to_recipient" } ] } ``` `recipient` is the wallet entitled to the fee balance. Use the position's `fee_escrow_address` as `fee_escrow` and `currency.address` as `currency`. Fee claim modes: * `to_recipient` calls `FeeEscrow.claimFor(recipient, currency)` on a current fee contract or the equivalent function on an earlier launch's recorded fee contract, and always pays the recorded recipient * `redirect` calls `FeeEscrow.claimTo(currency, destination)` and requires the caller to be the recorded recipient The API verifies that the fee contract belongs to a recognized launch deployment and reads live `owed` state. It never lets one caller redirect another recipient's balance. Creator, platform, and valid referrer balances use this same endpoint. For a referral balance, use the referrer's address as `recipient`, then either pay that address directly or let that same wallet authorize a redirect. The wallet route defaults to claimable positions and supports cursor pagination. Each preparation batch uses one chain and caller, rejects duplicate positions before RPC work, and simulates every returned transaction independently. `review.claims` records the exact live claimable amount and linked step ID. The steps are independent, not atomic, and each receives Base builder attribution when applicable. Claim preparation costs 3 weighted units per position, so a 10-position batch costs 30 units. ## Creator announcements ```http theme={null} POST /tokens/{chain_id}/{token_address}/announcements/prepare ``` The API resolves the exact contracts recorded for the token. For launches from any current factory it verifies `currentCreatorOf(token)` through the factory plus `isTokenRegistered(token)` through the registry, then builds `postAnnouncement`. Earlier launch contracts use their original `creatorOf` and `post` surface. Descriptions must be non-empty and are limited to 1000 UTF-8 bytes. The URI is optional; non-empty values use `https://`, `ipfs://`, or `ar://`. ## Token metadata On-chain name, symbol, and extra-metadata updates use: ```http theme={null} POST /tokens/{chain_id}/{token_address}/metadata/onchain/prepare ``` Supported operations: * `update_name` * `update_symbol` * `update_extra_metadata` These operations perform live authority checks and simulation but do not upload content to IPFS. They cost 3 units. Description, image, and public-link updates use the dedicated idempotent metadata-document route: ```http theme={null} POST /tokens/{chain_id}/{token_address}/metadata/document/prepare Idempotency-Key: unique-request-key ``` Its body contains `actor` and `document` directly; there is no `operation` field: ```json theme={null} { "actor": "0x1111111111111111111111111111111111111111", "document": { "description": "Updated token description", "website": "https://example.com", "x": "https://x.com/example", "telegram": "https://t.me/example", "image_uri": "ipfs://bafy..." } } ``` Document preparation is a partial update. Omitted description and link fields preserve their current values; an explicit empty string or `null` clears a link. Omitting both image fields preserves the current effective image. `image_uri` must be a non-empty `ipfs://` URI; use it to select an existing IPFS image, or supply `image_base64` and `image_type` together to upload a replacement. Each document update creates one metadata JSON object, plus one image object only when new image bytes are supplied. Descriptions are limited to 2000 UTF-8 bytes. A replacement image follows the same MIME validation and 2 MB decoded-size limit as launch creation. Extra-metadata keys are 1 to 64 characters and values are at most 512 characters. For launches from any current factory, the API verifies the caller's creator rights through the factory and prepares its typed metadata-forwarding function. Earlier Base B20 and Robinhood ERC-20 contracts use their original metadata-authority model. The API does not expose mint, burn, pause, operator, rebase, ownership, or governance operations. The API selects the correct B20 or ERC-20 token interface for the launch's chain and simulates the requested operation. Unsupported earlier contracts fail with `unsupported_operation` instead of guessing. A Base B20 name update returns an `eip712_domain_changes` warning because the token's EIP-712 domain follows its name. Every creator-action response includes RFC3339 preparation and expiry times, the observed chain block, a normalized operation review, and simulation state. Metadata-document preparation requires `Idempotency-Key`; an expired replay returns `409 stale_plan` and must be prepared with a new key. It also returns `409 stale_plan` when the live contract URI is newer than the indexed document, so the API never builds an update from stale metadata. Wait for indexing, then prepare again. The earlier `/metadata/prepare` and `/metadata/profile/prepare` forms remain available during migration and return deprecation headers. New integrations should use the focused on-chain or document route. # Errors, rate limits, and retries Source: https://docs.o1.exchange/launchpad/api/errors-and-limits Handle problem responses, weighted quotas, cursors, idempotency, and safe retries. ## Problem responses Errors use `application/problem+json`: ```json theme={null} { "type": "https://docs.o1.exchange/launchpad/api/errors-and-limits#stale-plan", "title": "Transaction plan is stale", "status": 409, "code": "stale_plan", "detail": "The transaction plan expired. Prepare it again.", "action": "Prepare a new transaction plan before signing or broadcasting.", "instance": "urn:o1:request:req_...", "request_id": "req_..." } ``` `type` links to the exact code section on this page. `code` is the stable value for program logic, `detail` explains this occurrence, `action` gives the safe next step, and `request_id` identifies the request for support. Validation problems can also include `invalid_parameters`. Resource errors can include `resource`, `chain_id`, `token_address`, and `suggested_endpoint`. Balance errors can include `asset`, `actual_raw`, and `required_raw`. Raw RPC errors, stack traces, internal IDs, provider bodies, and secrets are never returned. Treat `detail` and `action` as human-readable text that may improve over time. Branch only on `status` and `code`. ## Problem code reference ### Request validation * `invalid_request` (`400` or `413`): the request, JSON transport, or body size is invalid. Correct the request using `detail`, then send it again. * `unknown_parameter` (`400`): one or more fields are not supported. Remove the fields listed in `invalid_parameters`. * `duplicate_parameter` (`400`): a query parameter was supplied more than once. Supply it once. * `incompatible_parameters` (`400`): individually valid parameters cannot be used together. Follow `invalid_parameters` and `suggested_endpoint` when present. * `invalid_parameter` (`400`): one or more fields have invalid values or formats. Correct the fields listed in `invalid_parameters`. * `missing_idempotency_key` (`400`): an operation that can create off-chain work needs `Idempotency-Key`. Send a new random UUID. * `invalid_idempotency_key` (`400`): the retry ID is empty or too long. Send 1 to 255 characters. ### Authentication and authorization * `missing_api_key` (`401`): `x-api-key` is absent. Send an active API key in that header. * `invalid_api_key` (`401`): the key is malformed, inactive, revoked, expired, or does not verify. Use an active key or create a replacement. * `origin_not_allowed` (`403`): the browser origin is not allowed by the key. Use an allowed origin or update the key's origin restrictions. * `insufficient_scope` (`403`): the key lacks the scope named in `detail`. Use a key with that scope. * `wallet_not_authorized` (`403`): the wallet does not own the required role, quote, claim, or resource. Use the authorized wallet. ### Resources and current state * `not_found` (`404`): the tracked resource or API operation does not exist. Verify the chain and identifier, use `suggested_endpoint` when present, and do not continuously retry an unchanged `404`. * `stale_plan` (`409`): a transaction plan expired or its chain configuration changed. Prepare a new plan before signing or broadcasting. * `stale_quote` (`409`): the quote expired or current execution state moved outside its reviewed limits. Request and review a fresh quote. * `salt_unavailable` (`409`): the prepared launch salt is already used. Prepare the launch again for a new salt and token address. * `invalid_permit` (`409`): Permit2 state changed or the signature no longer matches. Request a fresh quote, sign its current data, and prepare again. * `approval_not_confirmed` (`409`): the required token approval is not confirmed on-chain. Confirm it, then prepare again. * `announcement_id_conflict` (`409`): the generated announcement identifier is already used. Prepare again for a new identifier. * `cursor_filter_mismatch` (`409`): the cursor belongs to another route or filter set. Restart without a cursor and keep the same route and filters on later pages. * `cursor_stale` (`409`): the resource ordering changed after the cursor was issued. Restart from the first page. * `idempotency_in_progress` (`409`): an identical request is still running. Wait briefly, then retry the exact request with the same key. * `nothing_to_claim` (`409`): the requested position currently has no claimable value. Refresh the wallet's claim positions after state changes. ### Unsupported or non-executable requests * `unsupported_operation` (`422`): the resource, contract configuration, paired asset, or operation is not supported. Read `/config` and use a supported combination. * `unsupported_chain` (`422`): the chain is not supported. Use Base `8453`, Robinhood `4663` or Monad `143`. * `idempotency_key_reused` (`422`): the retry ID was already used with different input. Generate a new UUID. * `invalid_amount` (`422`): the amount is invalid for the requested operation or current wallet state. Correct it using `detail`. * `invalid_referrer` (`422`): the referrer is reserved, duplicated, or otherwise ineligible. Remove it or use a separate eligible wallet. * `insufficient_balance` (`422`): the wallet cannot fund the requested operation. Fund at least `required_raw` of `asset`, then prepare again. * `quote_unavailable` (`422`): no safe executable quote exists for the token, side, amount, or current pool state. Correct the input or retry after market state changes. * `simulation_failed` (`422`): the unsigned transaction did not simulate successfully. Resolve the condition in `detail`, then prepare again. ### Limits and service failures * `rate_limit_exceeded` (`429`): the API key exceeded a weighted burst, minute, day, or month limit. Wait for `Retry-After`. * `quota_exceeded` (`429`): a key, wallet, token, creator, source, service, or concurrency safety ceiling was reached. Wait for `Retry-After` and reduce frequency or concurrency. * `internal_error` (`500`): an unexpected server fault occurred. Retry once; if it persists, contact support with `request_id`. * `upstream_error` (`502`): a required chain, metadata, indexer, holder, or internal origin dependency returned an invalid response. Retry with capped exponential backoff and jitter. * `temporarily_unavailable` (`503`): a required service or verified live state is unavailable. Retry with capped exponential backoff and jitter. * `upstream_timeout` (`504`): a required dependency timed out. Retry with capped exponential backoff and jitter. ## Weighted rate limits `GET /health` and browser preflight requests do not consume API-key units. Every other operation is authenticated and metered against the calling key. A successful preflight only confirms browser transport; the following API request must still pass API-key, scope, origin, validation, and rate-limit checks. Requests consume units: | Operation | Units | | --------------------------------------------------------------------------------------------- | -------------: | | configuration: `include=chains` only, or transaction status | 1 | | configuration: live crypto-paired contracts or paired assets | 5 | | configuration: live stock-paired or `market=all` contracts or paired assets | 20 | | token list, search, creator list, detail, or wallet summary | 2 | | token trades, wallet activity, fee claims, announcement prepare, or on-chain metadata prepare | 3 | | fee claim preparation | 3 per position | | token announcements | 2 | | swap quote or prepare | 5 | | holder snapshot | 10 | | IPFS metadata-document prepare | 10 | | launch prepare | 20 | Configuration costs reflect whether a request needs live chain reads. Paginated reads scale with the requested page size: token lists, search, creator lists, and announcements use 2 units per 25 rows; trades, wallet activity, and fee claims use 3 units per 25 rows; holders use 10 units per 50 rows. Claim batches scale by position, so 10 prepared claims cost 30 units. For example, `GET /tokens?limit=100` costs 8 units and a 200-holder page costs 40 units. Initial plans: | Plan | Units/min | Burst/sec | Daily | Monthly | Max page | | ---------- | --------: | --------: | ------: | --------: | -------: | | Playground | 60 | 20 | 2,500 | 50,000 | 50 | | Developer | 300 | 20 | 25,000 | 500,000 | 100 | | Builder | 1,200 | 100 | 250,000 | 5,000,000 | 200 | | Partner | Custom | Custom | Custom | Custom | Custom | Additional safety ceilings apply before expensive work begins: * **Launch preparation:** protects the complete launch workflow, including live configuration reads, Pinata uploads, `01` address mining, calldata construction, and simulation. One key can prepare up to 3 launches per minute and 100 per day. Within that key, the same creator is limited to 1 per minute and 25 per day; a different key cannot consume the counter. * **Metadata documents:** the IPFS document route allows up to 10 preparations per key each minute and 100 per day. Within that key, the same token is limited to 2 per minute and 25 per day. Name, symbol, and extra-metadata preparation does not use these pinning caps. * **Trading:** the same wallet can request up to 60 swap quotes and 30 swap preparations per minute across all keys. * **Claims:** one key can prepare up to 20 fee-claim batches per minute. The same chain and caller are limited to 10 batches per minute across all keys; each batch contains 1 to 10 independent positions. * **Creator actions:** within each key, the same creator or metadata actor is limited to 20 announcement or metadata preparations per minute. * **Holder protection:** holder snapshots allow 2 concurrent requests per key. Shared safeguards stop fresh-key cycling without changing ordinary use: * **Authentication:** uncached key-prefix lookups allow 60 requests per source each minute. Valid authorization metadata is cached for at most 5 seconds, and an unknown prefix for 2 seconds, so repeated invalid keys cannot turn Convex into an unbounded lookup service. * **Live configuration:** 15 requests per source and 120 across the service each minute, with 10 in flight. * **Holder snapshots:** 60 requests per source and 300 across the service each minute, with 20 in flight. * **Launch workflow:** 6 requests per source each minute and 200 per day; 60 across the service each minute and 2,000 per day. * **Metadata-document pinning:** 20 requests per source each minute and 500 per day; 120 across the service each minute and 5,000 per day. These limits apply only to the document preparation route, which can upload content. * **All live transaction preparation:** 120 requests per source and 1,000 across the service each minute, with 50 preparations in flight. New keys use the Developer limits. Higher limits are reviewed per key, and Partner access uses a custom per-key policy. Responses include `RateLimit`, `RateLimit-Policy`, `X-RateLimit-*`, and `X-Request-Id`. A 429 includes `Retry-After`. Compatibility routes also expose `Deprecation` and `Link` headers. These headers do not change route behavior; follow the linked migration guide for the focused replacement. Limits are enforced atomically in a separately managed Redis service. Durable hourly and daily usage summaries are stored in the API-owned usage table in Convex. Operators can assign a bounded per-key policy override, including a custom Partner policy, without creating another policy table. ## Safe request retries Mintlify labels this as **Unique retry ID**. Send it in the standard `Idempotency-Key` header. Generate a random UUID for each new launch or metadata-document update, then reuse it only when retrying that exact request. * it can contain 1 to 255 characters and is kept for 24 hours * the same API key, retry ID, and body replay the completed response * using the same retry ID for different input returns `idempotency_key_reused`; the second request is not prepared * different API keys may safely use the same retry ID ## Retry policy * retry 429 after `Retry-After` * retry 500 once; if it persists, contact support with the `request_id` * retry 502, 503, and 504 with capped exponential backoff and jitter * do not blindly retry 400, 401, 403, or 422 * prepare again after `stale_plan` * restart pagination after a stale or filter-mismatched cursor * never broadcast a transaction after its expiry ## Caching and data freshness Each response includes `meta.generated_at`, which records when the gateway formed the response. Source freshness comes from resource-level `updated_at`, observed or confirmed block, and finality fields. Configuration exposes `as_of_block` whenever contract or paired-asset data requires a live one-block chain read. Every request admitted by the weighted limiter consumes its documented route weight, including an idempotent replay or an internal Convex query-cache hit. Units measure access to the operation, not the gateway's internal compute cost. With a valid key, insufficient-scope and oversized-page rejections consume the route's base weight. Missing or invalid authentication, body-size enforcement, and requests rejected by an already-exhausted quota record zero units. A request that passes the limiter and later fails endpoint validation, simulation, or an upstream dependency consumes the route weight because execution capacity was reserved. The gateway does not keep a second TTL snapshot of product responses. Convex-backed reads use Convex's dependency-aware query cache, so a database change invalidates the affected query result without waiting for a gateway TTL. Ranked and trending values still follow the existing materialized-view refresh schedule shown by their `updated_at` field. Live configuration, swap quotes, wallet balances, allowances, claims, transaction plans, and simulations are never response-cached. External holder pages are requested from their provider without a stale fallback. If a required dependency is unavailable, the API returns a mapped error instead of silently returning an older snapshot. Redis is still used for short-lived API-key authorization metadata, rate counters, concurrency, idempotency, leases, and usage aggregation. Exact idempotent launch and metadata-document retries may replay their original response to avoid duplicate Pinata and simulation work, but that response is scoped to the same API key, idempotency key, route, and request body. Use a new idempotency key after a returned plan expires. # Public API Source: https://docs.o1.exchange/launchpad/api/introduction Read o1 Launchpad data and prepare safe wallet transactions on Base, Robinhood and Monad. Monad (chain `143`) has MON, USDC and WETH registered in its new minimal suite. At block `102277088` on **2026-09-05**, creation was enabled and the configured fee was **100 MON**. Contract deployment does not establish app/API rollout availability. See [Live configuration](/launchpad/reference/live-configuration) before preparing a launch. The o1 Launchpad Public API exposes the useful actions available in the live application without exposing internal analytics, governance, or infrastructure controls. It supports: * Base mainnet (`8453`), Robinhood Chain (`4663`) and Monad (`143`) * token browsing, search, creator launches, details, trades, announcements, holders, wallets, and fee claims * crypto-paired token creation on Base, Robinhood and Monad when enabled, plus stock-paired creation wherever the platform catalog and live factory state make it available, with editable metadata, Pinata uploads, and the required `01` token-address suffix * exact-input launch-pool quotes and Universal Router transaction preparation * fee claims, creator announcements, and authorized metadata updates The API never signs or broadcasts an on-chain transaction. It returns explicit transaction steps for the requested wallet to review, sign, and submit. ## Base URL ```text theme={null} https://api.launch.o1.exchange/v1 ``` Only `GET /health` is unauthenticated. Send `x-api-key` on every other request. ## Resource model The API keeps related data together without mixing incompatible query modes: * `/config` combines production chains, contract configurations, paired assets, and capabilities. Its exact response field names remain `suites` and `quotes` for API compatibility. * `/tokens` browses and ranks launches, `/tokens/search` searches them, and `/creators/{address}/tokens` lists one creator's launches. * one token detail endpoint can include pool, market, and recent announcements. * trades and announcements have independent collection routes and cursors. * fee claims expose their own state and filters. * on-chain name, symbol, and key-value updates are separate from token metadata-document updates that pin IPFS content. This keeps the API compact while ensuring every parameter displayed for an endpoint is valid for that resource. ## Non-custodial transaction flow ```mermaid theme={null} flowchart LR A["Your app"] -->|"prepare or quote"| B["o1 Public API"] B -->|"validate live state"| C["Convex and chain RPC"] B -->|"transaction steps"| A A -->|"user signs"| D["Wallet"] D -->|"broadcast"| E["Base or Robinhood"] E -->|"verified chain events"| C ``` Every prepare response identifies the expected chain, sender, destination, calldata, value, expiry, issues, and ordered prerequisites. Never replace an API-provided spender or destination with a guessed address. The existing launchpad indexer discovers confirmed chain events normally. Public clients cannot ask the API to write product records or force an indexing job. ## Next Create and manage a scoped production key with your wallet. List launches and prepare your first trade. Create keys, select scopes, and configure browser origins. Search and paginate launchpad resources. Handle API errors, quotas, and safe retries. Download the complete machine-readable schema. # Prepare a launch Source: https://docs.o1.exchange/launchpad/api/launches Prepare a crypto-paired or stock-paired launch with the same validation as the platform. Monad (chain `143`) has MON, USDC and WETH registered in its new minimal suite. At block `102277088` on **2026-09-05**, creation was enabled and the configured fee was **100 MON**. Contract deployment does not establish app/API rollout availability. See [Live configuration](/launchpad/reference/live-configuration) before preparing a launch. `POST /launches/prepare` validates and prepares one launch. The caller's wallet remains the creator and signer. Crypto-paired and stock-paired creation are available on Base and Robinhood. On each chain, both markets use the same active factory. A stock-paired launch requires the selected Stock Token to be present in the platform catalog, registered on the live factory, and enabled for creation. Base currently has ten registered Stock Tokens; Robinhood has 194. The API rejects a market or paired asset that is not currently available instead of falling back to another factory. ## Request ```json theme={null} { "chain_id": 8453, "creator": "0x1111111111111111111111111111111111111111", "market": "standard", "quote_address": "0x0000000000000000000000000000000000000000", "token": { "name": "Example 01", "symbol": "EX01", "description": "Example launch", "website": "https://example.com", "x": "https://x.com/example", "telegram": "https://t.me/example", "editable_metadata": false, "extra_metadata": [], "image_base64": "", "image_type": "image/png" } } ``` ## What preparation verifies The API: 1. resolves exactly one active factory for the requested chain and market 2. confirms the paired asset is supported by that factory and registered onchain 3. reads the current supply, configuration version, quote terms, fee terms, and block time at one chain block 4. validates token identity, URLs, image limits, profile settings, and complete pool supply 5. checks any current creation-fee requirement before uploading anything 6. pins the image and ERC-7572 metadata through the same protected Convex Pinata flow and configured gateway used by the Launchpad app 7. mines a token salt whose resulting address ends in `01` 8. confirms that the mined salt is still unused and builds a short-deadline `createLaunch` call committed to the current configuration 9. adds a creation-fee approval only when the live factory requires a nonzero ERC-20 fee 10. includes native value only when the selected market requires a nonzero native fee 11. simulates the final launch against the same observed chain block when all prerequisites are already satisfied 12. appends the same ERC-8021 builder attribution used by the Launchpad UI on Base The API does not assume a fixed launch fee. Fee fields and approval steps come from the selected live contract and appear only when its current fee is nonzero. This endpoint prepares the ordinary `createLaunch` path. The optional atomic Base, Robinhood and Monad `createLaunchAndBuy` browser flows are not currently exposed by the Public API, so integrations must not add Dev Buy fields to this request or modify the returned calldata. The returned transaction `value` covers the exact launch value only. The wallet must still retain native currency for gas, and performs the final gas estimate before signing. A normal launch creates two IPFS objects through Pinata: the image and one ERC-7572 metadata JSON document that references that image. The individual metadata fields do not create separate uploads. `extra_metadata` is encoded in the launch transaction and normally remains empty unless the integration needs token-specific key-value data. Images must be valid PNG, JPEG, WebP, or GIF data, match the declared MIME type, and decode to no more than 2 MB. Token descriptions are limited to 2000 UTF-8 bytes. Extra metadata accepts at most 16 unique keys and 4096 UTF-8 bytes in total. ## Supply and liquidity The complete fixed supply is placed into permanent Uniswap v4 liquidity. ## Response and execution The response contains: * `prepared_at`, `expires_at`, and the chain block used for validation * a normalized `review` of token settings, total supply, and pool supply * the predicted `01` address, resolved contract configuration, metadata URI, and image URL * a creation-fee object only when the live fee is nonzero * ordered transaction `steps`, dependencies, and simulation state * structured `issues` An insufficient creation-fee balance returns `422 insufficient_balance` with `asset`, `actual_raw`, and `required_raw` before any image or metadata is pinned. When an ERC-20 fee approval is required, the launch step depends on that approval and is marked `simulation.status=not_run`. Submit the approval, wait for confirmation, then prepare again so the API can verify and simulate current state. Use a unique `Idempotency-Key` for each logical launch preparation. Reusing it with a different body is rejected. An exact retry may replay the completed result while it remains executable; after its plan expires, it returns `409 stale_plan` and requires a new key. Launch preparation is limited to 3 requests per API key each minute and 100 per day. Within each key, one creator can prepare once per minute and 25 times per day. Another API key cannot consume that creator counter. Completed idempotent retries return the saved response without repeating Pinata or simulation work. # API migration Source: https://docs.o1.exchange/launchpad/api/migration Move from combined query modes to focused collection routes. The focused routes make every displayed parameter valid for its endpoint. Earlier combined read and token-metadata forms remain available during migration and return `Deprecation` and `Link` response headers. The earlier combined claim-write route is retired; use the fee-claim route below. ## Route replacements | Existing request | Focused route | | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------- | | `GET /tokens?q=...` | `GET /tokens/search?q=...` | | `GET /tokens?creator=...` | `GET /creators/{address}/tokens` | | `GET /tokens/{chain}/{token}/activity?kind=trades` | `GET /tokens/{chain}/{token}/trades` | | `GET /tokens/{chain}/{token}/activity?kind=announcements` | `GET /tokens/{chain}/{token}/announcements` | | `GET /wallets/{address}/claims?kind=fee` | `GET /wallets/{address}/fee-claims` | | Retired `POST /claims/prepare` with `kind=fee` | `POST /claims/fees/prepare` | | `POST /tokens/{chain}/{token}/metadata/prepare` with `update_name`, `update_symbol`, or `update_extra_metadata` | `POST /tokens/{chain}/{token}/metadata/onchain/prepare` | | `POST /tokens/{chain}/{token}/metadata/prepare` with `update_profile` | `POST /tokens/{chain}/{token}/metadata/document/prepare` | | `POST /tokens/{chain}/{token}/metadata/profile/prepare` | `POST /tokens/{chain}/{token}/metadata/document/prepare` | Token browsing now uses self-contained sort values: `newest`, `oldest`, `trending`, `liquidity`, `market_cap`, or `volume_24h`. Do not send a separate `order` parameter. Metadata-document preparation removes the `operation` field. Send `actor` and `document` directly and continue supplying `Idempotency-Key`. No sunset date is currently announced. Integrations should migrate to the focused routes so unsupported parameter combinations cannot be constructed. # API quickstart Source: https://docs.o1.exchange/launchpad/api/quickstart Authenticate, list launches, quote a swap, and submit wallet calldata. ## 1. Create a key Open [Developers](https://launch.o1.exchange/developers), connect the wallet that will own the key, choose scopes, and sign the off-chain management message. The plaintext key is displayed once: ```text theme={null} o1_launch_a1b2c3d4_ ``` Store backend keys in a secret manager. For a browser integration, use a dedicated key with only the scopes it needs and add a website restriction when appropriate. ## 2. List Base launches ```bash theme={null} curl "https://api.launch.o1.exchange/v1/tokens?chain_id=8453&market=all&sort=trending&limit=25" \ -H "x-api-key: $O1_API_KEY" ``` Use `pagination.next_cursor` as the next request's `cursor`. Cursors are opaque, short-lived, and bound to the original filters. Ranked results remain live, so a token can move between pages; de-duplicate by `(chain_id, token.address)` and restart if the API returns `409 cursor_stale`. ## 3. Quote an exact-input buy ```bash theme={null} curl "https://api.launch.o1.exchange/v1/swaps/quote" \ -X POST \ -H "content-type: application/json" \ -H "x-api-key: $O1_API_KEY" \ -d '{ "chain_id": 8453, "wallet": "0x1111111111111111111111111111111111111111", "token_address": "0x2222222222222222222222222222222222222201", "side": "buy", "amount_in_raw": "10000000000000000", "slippage_bps": 50 }' ``` `slippage_bps` is the maximum output tolerance in basis points. `50` means 0.5%, and `100` means 1%. The response contains: * `quote_id`, signed and short-lived * expected and minimum output in base units * an `issues` array for balance or approval prerequisites * ERC-20 approval transaction steps when required * Permit2 typed data when an off-chain Permit2 signature is required ## 4. Prepare the swap After completing any ERC-20 approval and signing any returned Permit2 typed data: ```bash theme={null} curl "https://api.launch.o1.exchange/v1/swaps/prepare" \ -X POST \ -H "content-type: application/json" \ -H "x-api-key: $O1_API_KEY" \ -d '{ "quote_id": "", "wallet": "0x1111111111111111111111111111111111111111" }' ``` Include `permit2_signature` only when the quote returned a Permit2 typed-data step. The API requotes, preserves the reviewed slippage floor, builds Universal Router calldata, and simulates it. Submit the returned transaction unchanged from the specified wallet. ## 5. Check indexing status After confirmation: ```bash theme={null} curl "https://api.launch.o1.exchange/v1/transactions/8453/0x" \ -H "x-api-key: $O1_API_KEY" ``` This is the indexed public view, not a live RPC receipt endpoint. Normal chain workers discover wallet-broadcast transactions without a notification call. Use your chain provider for immediate receipt status; this endpoint may return `data: null` until the transaction is observed, then reports indexed chain and launchpad operation state. # Read endpoints Source: https://docs.o1.exchange/launchpad/api/read-endpoints Search tokens and read launch, pool, wallet, claim, holder, and transaction state. All read endpoints except `/health` require an API key. Product queries require an explicit `chain_id`; the API never combines chains implicitly. ## Endpoint summary | Method and path | Returns | | ------------------------------------------------------ | ------------------------------------------------------------------- | | `GET /health` | Process health and build version | | `GET /config` | Production contract configurations, paired assets, and capabilities | | `GET /tokens` | Browsable and ranked token summaries | | `GET /tokens/search` | Token search results | | `GET /creators/{address}/tokens` | Launches created by one wallet | | `GET /tokens/{chain_id}/{token_address}` | Token, launch, pool, market, and announcement detail | | `GET /tokens/{chain_id}/{token_address}/trades` | Canonical trades | | `GET /tokens/{chain_id}/{token_address}/announcements` | Creator announcements | | `GET /tokens/{chain_id}/{token_address}/holders` | Provider-backed holder snapshot | | `GET /wallets/{address}` | Compact launchpad wallet overview | | `GET /wallets/{address}/activity` | Structured wallet activity | | `GET /wallets/{address}/fee-claims` | Fee positions | | `GET /transactions/{chain_id}/{tx_hash}` | Indexed transaction and launchpad operation state | `GET /health` is public liveness only: it returns service status, API version, build ID, and time. It requires no API key, consumes no API-key units, and can be called from browser or server integrations. It does not guarantee that Convex, Redis, RPC, Pinata, or transaction preparation is available. Ordinary token, wallet, activity, claim, and transaction-status reads use the existing indexed or materialized launchpad data and do not add a chain RPC per request. Holder snapshots use their documented holder provider. Live contract and paired-asset sections in `/config`, swap operations, claim preparation, creator actions, and launch preparation verify the chain state they need. ## Live configuration `GET /config` accepts `include=chains,suites,quotes`. The field names `suites` and `quotes` are retained for API compatibility; they represent launch contract configurations and paired assets. The default returns all three sections. * `include=chains` uses the static production chain registry and does not call an RPC. Its chain capabilities report the launch token mode; Base activation is `not_checked`, while Robinhood is `not_applicable`. * Contract or paired-asset sections are read at one chain block and include `as_of_block`. On Base, the same block also verifies B20 activation. * `active_only=true` omits earlier contract configurations and paired assets that cannot create new launches. * Stock-paired markets follow the shared public chain allowlist, platform catalog, and live factory state. An active response includes stock-paired support only when catalogued assets are registered on the live factory and creation is enabled. * Each `suites` item exposes supported route codes, integration capabilities, contract addresses, current supply, `config_version`, and creation state. Capabilities identify creator rights, atomic launch-buy support, generic fee components, paired-asset revisions, and the creation switch without requiring clients to infer behavior from an identifier. * The active Base and Robinhood configurations each report both `standard` (crypto-paired) and `rwa` (stock-paired) in `supported_routes` and expose their `launch_buy_adapter_address`. * A creation fee appears only when its live amount is nonzero. Base creation is available only when `chain.capabilities.b20_asset_status` is `active`. If ActivationRegistry cannot be verified, the API returns `503 temporarily_unavailable` instead of reporting a potentially executable route. Earlier contract configurations remain available with `active_only=false` so direct integrations can resolve existing launches safely. ## Poll the paired-asset catalog Use `GET /v1/config?chain_id=8453&market=all&include=chains,suites,quotes&active_only=false` with an `x-api-key` that has `config:read`. Change `chain_id` to `4663` for Robinhood or `143` for Monad. Quote rows are in `data.quotes`; factory references and creation fees are in `data.suites`. Use `data.as_of_block` for the live-state observation block. The API combines the platform catalog with live registration checks. `active_only=false` includes configured entries that are not registered or not currently usable; `active_only=true` filters to creation-available entries. It does not discover arbitrary addresses added by a factory owner outside the platform catalog. Pair registration monitoring with catalog polling and review any unknown address. The current production schema exposes address, symbol, name, decimals, route, suite, registration status, selectability, and quote revision. `route` is a product classification, not an issuer identity or a complete asset taxonomy. The downloadable JSON snapshots are dated reference data; poll the API for current registration status. The staged API reference adds `asset_type` and `issuer` metadata and includes Base, Robinhood and Monad as public chains. Publish this API reference only after the matching gateway release is verified. Clients should tolerate absent metadata fields until rollout is confirmed. The same update uses catalog decimals for unregistered entries and factory decimals for registered quotes. The planned asset types distinguish native currency, stablecoins, wrapped crypto, and tokenized securities (including stock and ETF tokens). Issuer metadata carries a stable ID, name, verified legal entities, and official sources. A null issuer means native currency or unverified attribution, and an empty legal-entity list means only the brand is confirmed. Neither classification constitutes token security approval. Quote revisions track onchain settings, so issuer metadata changes must be compared separately. The dated Base/Robinhood catalog and Monad live snapshot contain these issuer groups: | Chain | Quote group | Attribution | | ---------------- | ------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Base | 10 tokenized stocks | Coinbase Onchain SPV Ltd, linked through the [official stock prospectuses](https://www.base.org/stocks) | | Base | 8 wrapped crypto assets | [Coinbase Wrapped Assets](https://help.coinbase.com/en/coinbase/trading-and-funding/sending-or-receiving-cryptocurrency/coinbase-wrapped-btc); legal entity attribution is not asserted | | Base | USDC | [Circle](https://www.circle.com/legal/mica-usdc-whitepaper) | | Robinhood | 194 stock and ETF tokens | [Robinhood Assets (Jersey) Limited](https://robinhood.com/rhj/stocktokens/) | | Robinhood | USDG | [Paxos](https://www.paxos.com/terms-and-conditions/usdg-eu-whitepaper) | | Base / Robinhood | Native ETH | No issuer | | Monad | MON | Native currency; no issuer | | Monad | USDC | Circle | | Monad | WETH | Wrapped crypto; issuer attribution unverified | The factory owner controls quote registration; creators can use only registered quote tokens. The contracts do not enforce a fixed issuer set, and the catalog is not a promise that issuers will never change. In particular, cbZEC and cbHYPE are wrapped crypto despite sharing an address prefix with Base stock tokens. Issuer metadata stays offchain, so this change adds no contract storage or registration gas. `QuoteRegistered` and `quoteConfig(address)` remain the onchain registration evidence; issuer identity comes from the catalog's explicit source-backed attribution. ## Token browsing `GET /tokens` browses and ranks tracked launches: | Parameter | Behavior | | --------------- | -------------------------------------------------------------------------- | | `chain_id` | `8453`, `4663` or `143`, required | | `market` | `standard` for crypto-paired, `rwa` for stock-paired, or `all` | | `quote_address` | Exact quote asset | | `sort` | `newest`, `oldest`, `trending`, `liquidity`, `market_cap`, or `volume_24h` | | `cursor` | Opaque continuation cursor | | `limit` | Default `25`, maximum `100` | Direction is part of `sort`, so there is no separate `order` parameter and every displayed sort is executable. Each result has stable sections: * `token`: address, name, symbol, decimals, and effective image * `launch`: backward-compatible creator, immutable original creator, current and pending creator rights when supported, current creator fee recipient, recorded contract configuration, pool, paired asset, feature flags, transaction provenance, creation time, and a creation fee only when the paid amount was nonzero * `market_data`: price, market cap, liquidity, 1-hour, 6-hour, 24-hour, and lifetime activity, plus freshness fields Missing market values are `null`, not zero. Trending returns ordinary market values and order only; ranking scores, scoring explanations, pins, and internal quality fields are private. Quote decimals come from the indexed launch or the shared quote registry. A truly unknown historical admin-added quote returns `quote.decimals: null`; the API never guesses units. Ranked lists are live rather than frozen snapshots. A cursor binds the filters and source position, not an immutable ranking snapshot, so tokens can move between pages while ranking updates. Deduplicate by `(chain_id, token.address)` and restart when the API returns `409 cursor_stale`. ## Token search and creator launches Use the focused routes when the query has different ordering semantics: ```http theme={null} GET /tokens/search?chain_id=8453&q=alpha GET /creators/0x1111111111111111111111111111111111111111/tokens?chain_id=8453&sort=newest ``` Search accepts `chain_id`, `market`, `quote_address`, `q`, `cursor`, and `limit`. It matches token address, name, symbol, creator, pool ID, or launch transaction and uses one deterministic liquidity ordering. Creator launches accept the same chain, market, quote, and pagination fields plus `sort=newest|oldest`. Search and creator cursors are not interchangeable with browsing cursors. Earlier combined query forms remain available during migration and return deprecation headers. New integrations should use the focused routes described here. See the [migration guide](/launchpad/api/migration). ## Token detail ```http theme={null} GET /tokens/8453/0x...01?include=pool,market,announcements ``` The default include set is `pool,market`. `announcements_limit` defaults to 3 and is capped at 10. Supply it only when `include` contains `announcements`. The detailed token object adds full metadata, links, total supply, historical contract addresses, and these optional sections: * `pool`: currencies, PoolManager, hook, frozen fee split, anti-snipe clock, locked seed ranges, and initial seeded token amount * `market_data`: ATH market cap in quote currency, unique traders, pool state, and fee revenue by currency * `announcements`: recent creator messages and their on-chain provenance Arbitrary token extra-metadata keys are not returned by default. ## Trades and announcements Use independent collection routes: ```http theme={null} GET /tokens/{chain_id}/{token_address}/trades GET /tokens/{chain_id}/{token_address}/announcements ``` Trades contain structured token and quote amounts, pool state, fee credits, referrer, comment, timestamp, and on-chain provenance. Announcements contain the creator message, URI, timestamp, and provenance. Trades accept one optional identity filter: `wallet`, `transaction_hash`, or `referrer`. `from` is inclusive and `to` is exclusive; both use Unix seconds. Announcements accept only pagination, so trade-only filters never appear on their reference page. Token detail, activity, and holder routes first verify that the address is a visible launchpad token on the selected chain. An unknown or arbitrary external token returns `404 not_found` with the checked chain, token address, and a `suggested_endpoint` for token search. Verify the identifier or rediscover it through `GET /tokens` or `GET /tokens/search`; do not poll an unchanged `404`. ## Holder snapshots A holder response has a normal page plus top-level `summary`: ```json theme={null} { "summary": { "status": "ready", "total_holders": 128, "top_10_percent": 62.4 } } ``` Balances remain exact strings, and `supply_percent` is derived from indexed total supply. `meta.generated_at` records when the gateway formed the response; the API does not invent a provider snapshot timestamp. If the provider cannot produce a holder result, it returns `503 temporarily_unavailable` instead of a misleading empty list. ## Wallet activity and fee claims Wallet activity is structured by `kind`; it does not return UI titles, raw metadata JSON, or internal event keys. Current launch flows use launch, launch fee, trade, fee credit or claim, announcement, and metadata activity kinds. Fee positions use a separate cursor domain, default to 25 results, and are capped at 50. * `GET /wallets/{address}/fee-claims` supports `state=claimable|all` and optional `currency_address`. * A fee balance is scoped to escrow, recipient, and currency. It may represent credits from multiple pools, so it is not assigned to one launch incorrectly. ## Transaction status `GET /transactions/{chain_id}/{tx_hash}` is the indexed public view, not a live RPC receipt endpoint. When indexed, it separates two states: * `chain.status`: unknown, pending, succeeded, reverted, or replaced * `indexing.status`: not seen, processing, or complete `operations` contains only public launchpad actions with their transaction provenance. Raw worker jobs, provider responses, governance events, queue state, and internal errors are never returned. Existing chain indexers and webhooks discover wallet-broadcast transactions normally, so the API does not expose a transaction-notification write. Before a hash is observed, `data` is `null`; use your own chain provider to poll the receipt for immediate confirmation and retry this endpoint for launchpad indexing state. ## Pagination and freshness ```json theme={null} { "pagination": { "next_cursor": "opaque-signed-cursor", "has_more": true, "limit": 25 }, "meta": { "request_id": "req_...", "generated_at": "2026-07-31T12:00:00.000Z", "warnings": [] } } ``` Do not parse or edit cursors. They are bound to the route, filters, ordering, API version, and expiry. `meta.generated_at` is when the gateway formed the response. Resource-level `updated_at`, observed or confirmed block, and finality fields describe source freshness. The gateway does not add another product-response cache. ## Monad configuration Use `GET /v1/config?chain_id=143&market=standard&include=chains,suites,quotes&active_only=false`. The current suite supports `standard` only. MON is native, USDC is a Circle stablecoin and WETH is wrapped crypto with unverified issuer attribution. At the latest onchain snapshot, creation is enabled and all three quotes are registered. `active_only=true` filters to creation-available catalog entries; `false` also retains entries if creation is later disabled. This documentation matches the repository API artifact; confirm the deployed gateway supports chain 143 before integrating. # Quote and prepare trades Source: https://docs.o1.exchange/launchpad/api/trading Use the launch pool's Uniswap v4 Quoter, Permit2, and Universal Router safely. The trading API supports exact-input buys and sells against the token's own Uniswap v4 launch pool. ## Quote `POST /swaps/quote` ```json theme={null} { "chain_id": 4663, "wallet": "0x1111111111111111111111111111111111111111", "token_address": "0x2222222222222222222222222222222222222201", "side": "sell", "amount_in_raw": "1000000000000000000", "slippage_bps": 50, "referrer": "0x3333333333333333333333333333333333333333", "comment": "API trade" } ``` `amount_in_raw` uses the input currency's base units: quote units for a buy and launch-token units for a sell. Slippage uses basis points, where 1 bps is 0.01%; `50` means 0.5%, `100` means 1%, and the maximum is `4999`. The API resolves the contracts recorded for the token, including its pool key, hook, paired asset, tick spacing, router, Permit2, and Quoter. It does not guess from `tx.to` or use only the latest factory. The optional referrer is preserved through quote and preparation and encoded in the same hook data used by the Launchpad app. It must be a separate eligible wallet, not zero, the trader, creator, platform treasury, or router. Invalid choices return `422 invalid_referrer`; valid referrals accrue their fee share in FeeEscrow and claim it through `POST /claims/fees/prepare`. The response contains: * signed `quote_id` and expiry * `prepared_at` and the chain block used for all quote, balance, and allowance reads * input and output currencies * expected and minimum output * estimated quote gas * a normalized `review` of the exact route, amounts, slippage, referrer, and comment * balance and allowance issues * an ERC-20 approval transaction when the input token has not approved Permit2 * Permit2 typed data when the router allowance is missing or expired ## Actionable issues A valid request can return HTTP 200 with: ```json theme={null} { "code": "erc20_allowance_required", "severity": "action_required", "asset": "0x...", "spender": "0x...", "actual_raw": "0", "required_raw": "1000000", "remediation_step_id": "approve-input-token" } ``` `blocking` means funds or state must change. `action_required` points to a provided step. `warning` is reviewable but does not stop preparation. ## Prepare `POST /swaps/prepare` accepts the reviewed `quote_id`, wallet, and optional Permit2 signature. The API: 1. verifies the quote signature, wallet binding, and expiry 2. rereads wallet balance, ERC-20 approval, and Permit2 allowance at one block 3. requotes the exact route 4. rejects a price move beyond the reviewed minimum 5. uses the stricter valid minimum 6. validates the Permit2 nonce, deadline, and signature requirement 7. builds official Universal Router v4 commands 8. appends ERC-8021 builder attribution on Base 9. simulates the exact transaction from the expected wallet The prepare response shows reviewed, refreshed, and execution-minimum amounts together. An expired or moved quote returns `409 stale_quote`, an unconfirmed ERC-20 approval returns `409 approval_not_confirmed`, and changed Permit2 state returns `409 invalid_permit`. A missing or unexpected signature is a `400 invalid_request`; 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. Exact-output swaps are not exposed. During the anti-snipe window the launch hook intentionally rejects exact-output execution. ## Monad settlement scope Use `chain_id: 143`. API buys spend the launch pool's paired MON, USDC or WETH; sells return that asset. The API does not expose the browser's MON-to-USDC/WETH multihop settlement or atomic developer-buy flow. Native MON needs transaction value; ERC-20 USDC/WETH use the returned approval/Permit2 requirements. WMON is routing infrastructure, not a registered quote. # 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. Base, Robinhood and Monad use the same `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 and Monad 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. 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. The trader signs a swap through Uniswap. The launch hook applies the fee, the user receives the trade output, and the fee escrow records claimable balances. 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. ## 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 the Robinhood or Monad 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 | `SwapXLaunchBuyAdapter` executes the optional atomic buy after the selected Base, Robinhood or Monad factory creates and seeds a launch | Each deployment is bound to its chain's active 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 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 determines the production factory, and the paired asset determines the market type. Base and Robinhood each use one active factory for both crypto-paired and stock-paired launches. Both active 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`. | 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, the platform fee receiver, and announcement support for future launches. Both active 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 on its chain because both market types use the same factory. 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 ETH 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 active factory keeps its chain's native asset, supported stablecoin, registered crypto majors where configured, and registered Stock Tokens in one paired-asset registry. Every 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 currently has 20 registered quotes in the shared factory: ETH, USDC, eight Coinbase crypto majors, and ten stock quotes listed in the [Base stock catalog](/launchpad/create/stock-paired-launches#base-stock-token-catalog). The crypto majors are cbBTC, cbDOGE, cbXRP, cbLTC, cbADA, cbMEGA, cbZEC, and cbHYPE. The ten registered Base stock quotes come from a 13-asset catalog. Robinhood has ETH, USDG, and 194 registered stock quotes. The platform requires a catalogued quote to be registered on the live factory with creation enabled before it is selectable. ## 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 until the total fee reaches the normal 1% rate. The detailed callback and function surface is available in [Functions and events](/launchpad/reference/events-functions). ## Escrow, staking, and announcements `FeeEscrow` tracks claimable balances in each pool's paired asset. 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. ## Trust boundaries * The factory owner can change defaults for launches that have not happened yet. * 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. Its creation switch was enabled at the [dated live snapshot](/launchpad/reference/live-configuration#monad-snapshot). 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. # 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. Base and Robinhood each use one active `launchpad-v4-minimal` factory for both crypto-paired and stock-paired creation. Base creates native B20 tokens, while Robinhood and Monad 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. ## Who controls what | Area | Current authority | Boundary | | ---------------------------------- | -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | | Future launch settings | Launchpad governance owner | Changes apply only to launches created afterward | | Platform swap fees | Platform fee receiver | 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 creator rights and change the destination for future creator-fee credits; receives no token or liquidity control | | Creator-rights administration | Creator admin | Can immediately reassign current creator rights and future creator-fee routing; receives no token or liquidity control | | Token profile editing | Current creator, only when enabled at launch | Limited to supported profile information | | 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; * the base fee, anti-snipe fee, recipient split, and platform fee receiver; * announcement support. All three current 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 supports the standard crypto route 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. ## 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; * fee component rates and fixed recipients, except that the current creator-fee recipient can change for future credits; * anti-snipe start time and duration; * permanent liquidity position. Future governance changes cannot mint more tokens or remove liquidity. A valid creator-rights transfer can update the current creator and future creator-fee recipient. Already credited balances do not move. ## Token authority Tokens launch without an owner who can mint, pause, upgrade, or take balances. Creator rights cover project-side authority, future creator-fee routing, announcements, and optional profile editing. They do not grant control over token transfers or liquidity. ## 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 Base and Robinhood 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 a standard crypto route only. The current owner, creator admin and treasury match Base/Robinhood at the [Monad snapshot](/launchpad/reference/live-configuration#monad-snapshot). Creation was enabled at that snapshot. Registration and selecting a suite in source do not activate launch creation. # 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 | 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 copy a token referral link | | Profile | View a creator's launches and public identity; connected owners can edit their o1 profile, claim fees, review 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 and Robinhood currently 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 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. The o1 confirmation screen shows the paired asset, supply, permanent liquidity, current creation fee, profile permission, and the predicted address when available. 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 uses the same factory for crypto-paired and stock-paired creation. The creator then confirms the launch transaction in their wallet. After confirmation, the token page presents the new token, live Uniswap market, trades, holders, and public announcements. 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 10-minute deadline, then asks the wallet to submit the swap through Uniswap's Universal Router. The wallet includes ETH in the swap transaction. No token approval is needed for the ETH input. When needed, the wallet first approves Uniswap's Permit2 contract and signs a time-limited Universal Router authorization. The submitted swap still uses only the amount shown for that trade. The same flow carries an optional referral and public trade comment. 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 | 10 minutes from submission | ## 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. ## 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 and market type. This lets older launches remain visible without sending a new launch to a retired contract. 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. # Stock-paired launches Source: https://docs.o1.exchange/launchpad/create/stock-paired-launches Launch a Base or Robinhood token against a supported Stock Token with permanent Uniswap v4 liquidity and stock-denominated trading fees. Stock-paired launches let a creator open a market between a new o1 launch token and a supported Stock Token on Base or Robinhood Chain. The Stock Token is the pool's paired asset, so it sets the opening-price reference, is used to buy the launch token, and is received when the launch token is sold. Ten Base Stock Tokens and 194 Robinhood Stock Tokens are currently registered for creation. Base stock-paired launches currently pay the same 0.001 ETH fee as Base crypto-paired launches. Robinhood stock-paired launches also currently pay 0.001 ETH. Network gas is additional. Every stock-paired market charges its swap fee in the selected Stock Token. The new token's pool supply enters a token-only Uniswap v4 position that cannot be removed. ## How a stock-paired market works Select Base or Robinhood, open the Stocks market, and choose one of the supported Stock Tokens for that chain. Add the token identity, public profile, and profile-editing preference. The launch review shows the selected Stock Token, fixed supply, opening-value estimate, permanent liquidity, and current creation fee. The selected factory creates a fixed-supply B20 token on Base or ERC-20 token on Robinhood, opens its Uniswap v4 pool, and permanently locks the pool supply. Each chain uses the same active factory for crypto-paired and stock-paired launches. No Stock Token liquidity deposit is required from the creator. The resulting launch token address ends in `01`. The address is prepared after the final token metadata is ready and remains part of the same wallet-signed launch flow. ## Trading and fees For a launch paired with any supported Stock Token: * buyers pay the paired Stock Token and receive launch tokens; * sellers return launch tokens and receive the paired Stock Token; * the normal 1% swap fee is charged in that paired Stock Token; * creator, platform, and valid referrer fee balances are claimable in that paired Stock Token; * the opening anti-snipe fee follows the same 20-second schedule on both chains. The selected Stock Token is an existing onchain asset supplied by its provider. Creating an o1 launch token does not create, modify, or administer the paired Stock Token. USD estimates use the available current price for the selected Stock Token. If that price is missing or stale, the interface preserves an unavailable or partial-data state instead of substituting a guessed value. ## Chain availability | Chain | Onchain stock quote registration | Registered Stock Tokens | | --------------- | -------------------------------- | ----------------------: | | Base mainnet | Registered | 10 | | Robinhood Chain | Registered | 194 | These counts describe factory registration. The app can disable creation or hide individual settlement options independently. ## Base Stock Token catalog As of **September 5, 2026** at Base block `50,902,528`, AAPL, AMZN, GOOGL, META, MSFT, MSTR, NVDA, SNDK, SPCX, and TSLA were registered on the active shared Base factory. All ten use 8 decimals, new creation is enabled, and the global Base launch fee is 0.001 ETH. Developers and data clients can use the [machine-readable Base stock catalog](/launchpad/reference/base-stock-quotes.json). | Symbol | Paired asset | Base token | | ------ | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------- | | AAPL | Apple Inc. | [`0xb200000000000000000000C2e324d24d7eEcd1fb`](https://basescan.org/address/0xb200000000000000000000C2e324d24d7eEcd1fb) | | AMZN | Amazon.com Inc. | [`0xb200000000000000000000d9192b6B456483C2E8`](https://basescan.org/address/0xb200000000000000000000d9192b6B456483C2E8) | | GOOGL | Alphabet Inc. | [`0xb2000000000000000000002D0BA3164cc74f58B7`](https://basescan.org/address/0xb2000000000000000000002D0BA3164cc74f58B7) | | META | Meta Platforms Inc. | [`0xb2000000000000000000008bC8786B856E61707C`](https://basescan.org/address/0xb2000000000000000000008bC8786B856E61707C) | | MSFT | Microsoft Corporation | [`0xB200000000000000000000Ab99cFa739E253872B`](https://basescan.org/address/0xB200000000000000000000Ab99cFa739E253872B) | | MSTR | Strategy Inc. | [`0xb2000000000000000000004884b426556b92883d`](https://basescan.org/address/0xb2000000000000000000004884b426556b92883d) | | NVDA | NVIDIA Corporation | [`0xb20000000000000000000078ee7ce2fE4908108C`](https://basescan.org/address/0xb20000000000000000000078ee7ce2fE4908108C) | | SNDK | Sandisk Corporation | [`0xb200000000000000000000397293Cb8cda9a10c5`](https://basescan.org/address/0xb200000000000000000000397293Cb8cda9a10c5) | | SPCX | Space Exploration Technologies Corp. | [`0xb2000000000000000000007b9fcbd005511aCBd5`](https://basescan.org/address/0xb2000000000000000000007b9fcbd005511aCBd5) | | TSLA | Tesla Inc. | [`0xb2000000000000000000001e800a7f5189430cD0`](https://basescan.org/address/0xb2000000000000000000001e800a7f5189430cD0) | COIN, CRCL, and INTC remain in the internal catalog but were unregistered at this snapshot. Registration does not establish liquidity or executable settlement routes. ## Robinhood Stock Token catalog All 194 entries below were reread as registered with 18 decimals on the active Robinhood factory on **September 5, 2026** at block `54,953,301`. The active factory uses a 0.001 ETH native launch fee for every paired asset. Developers and data clients can use the [machine-readable Robinhood stock catalog](/launchpad/reference/robinhood-stock-quotes.json). | Symbol | Paired asset | Robinhood Chain token | | ------ | --------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | | AAOI | Applied Optoelectronics | [`0x521cf887e6531c6f667b5bc4d896e5d9bfe8eb2e`](https://rh-scan.com/address/0x521cf887e6531c6f667b5bc4d896e5d9bfe8eb2e) | | AAPL | Apple | [`0xaf3d76f1834a1d425780943c99ea8a608f8a93f9`](https://rh-scan.com/address/0xaf3d76f1834a1d425780943c99ea8a608f8a93f9) | | ABCL | Abcellera Biologics | [`0x3139d77ace0cbaa5bdfd38bd1f1911a794af0b0e`](https://rh-scan.com/address/0x3139d77ace0cbaa5bdfd38bd1f1911a794af0b0e) | | ADBE | Adobe | [`0x232b8ed6377be97813853b0ac104c4cda8378d1b`](https://rh-scan.com/address/0x232b8ed6377be97813853b0ac104c4cda8378d1b) | | AEHR | Aehr | [`0x5f604fba1162193a4388a5dfa56f556f3e133cc2`](https://rh-scan.com/address/0x5f604fba1162193a4388a5dfa56f556f3e133cc2) | | AEIS | Advanced Energy | [`0xfaf9cb261b5fcc1f404bb10cd39c5c6c1974e612`](https://rh-scan.com/address/0xfaf9cb261b5fcc1f404bb10cd39c5c6c1974e612) | | ALAB | Astera Labs, Inc. | [`0x748c32c3ca24edf31ea597db1f3d330a7a6da3dc`](https://rh-scan.com/address/0x748c32c3ca24edf31ea597db1f3d330a7a6da3dc) | | AMAT | Applied Materials | [`0x36046893810a7e7fce501229d57dc3fc8c8716d0`](https://rh-scan.com/address/0x36046893810a7e7fce501229d57dc3fc8c8716d0) | | AMBA | Ambarella | [`0x99d9d8663545151603863c5acbd6fc3218899009`](https://rh-scan.com/address/0x99d9d8663545151603863c5acbd6fc3218899009) | | AMC | AMC Entertainment | [`0x05a3d1cd21d0c88145e82600e62e7e496e0f222b`](https://rh-scan.com/address/0x05a3d1cd21d0c88145e82600e62e7e496e0f222b) | | AMD | AMD | [`0x86923f96303d656e4aa86d9d42d1e57ad2023fdc`](https://rh-scan.com/address/0x86923f96303d656e4aa86d9d42d1e57ad2023fdc) | | AMKR | Amkor Technology | [`0xdd356aa38f40a7b7076755ac854b6fbb1f0d305b`](https://rh-scan.com/address/0xdd356aa38f40a7b7076755ac854b6fbb1f0d305b) | | AMZN | Amazon | [`0x12f190a9f9d7d37a250758b26824b97ce941bf54`](https://rh-scan.com/address/0x12f190a9f9d7d37a250758b26824b97ce941bf54) | | ANET | Arista | [`0x28babd556b60e53663b8615036479a29c2cdd1bf`](https://rh-scan.com/address/0x28babd556b60e53663b8615036479a29c2cdd1bf) | | APLD | Applied Digital | [`0xb8dbf92f9741c9ac1c32115e78581f23509916fd`](https://rh-scan.com/address/0xb8dbf92f9741c9ac1c32115e78581f23509916fd) | | APP | AppLovin | [`0xa249baf1063af884807c1e1400aef7784836917e`](https://rh-scan.com/address/0xa249baf1063af884807c1e1400aef7784836917e) | | ASML | ASML Holding NV | [`0x47f93d52cbec7c6d2cfc080e154002370a60daea`](https://rh-scan.com/address/0x47f93d52cbec7c6d2cfc080e154002370a60daea) | | ASTS | AST SpaceMobile | [`0x1af6446f07eb1d97c546afc8c9544cbdf3ad5137`](https://rh-scan.com/address/0x1af6446f07eb1d97c546afc8c9544cbdf3ad5137) | | AUR | Aurora Innovation | [`0x373c06c4f7bde527d7dae4ba169e42b55e393ced`](https://rh-scan.com/address/0x373c06c4f7bde527d7dae4ba169e42b55e393ced) | | AVAV | AeroVironment | [`0xf6290b5e7c26502e2da514c31509849718ea76a5`](https://rh-scan.com/address/0xf6290b5e7c26502e2da514c31509849718ea76a5) | | AVGO | Broadcom | [`0x156e175dd063a8ce274c50654ef40e0032b3fbcf`](https://rh-scan.com/address/0x156e175dd063a8ce274c50654ef40e0032b3fbcf) | | AXON | Axon | [`0xc27dbd474af5181c5a8777903690d8d262d12648`](https://rh-scan.com/address/0xc27dbd474af5181c5a8777903690d8d262d12648) | | AXTI | AXT | [`0x141eea040c2250eec0314e336975e81f85f6585e`](https://rh-scan.com/address/0x141eea040c2250eec0314e336975e81f85f6585e) | | BA | Boeing | [`0x4d21483a44bf67a86b77e3da301411880797d452`](https://rh-scan.com/address/0x4d21483a44bf67a86b77e3da301411880797d452) | | BABA | Alibaba | [`0xad25ac6c84d497db898fa1e8387bf6af3532a1c4`](https://rh-scan.com/address/0xad25ac6c84d497db898fa1e8387bf6af3532a1c4) | | BB | Blackberry | [`0x48e39e56acdba37b09020c0b734a613c9a2f100a`](https://rh-scan.com/address/0x48e39e56acdba37b09020c0b734a613c9a2f100a) | | BE | Bloom Energy | [`0x822cc93ffd030293e9842c30bbd678f530701867`](https://rh-scan.com/address/0x822cc93ffd030293e9842c30bbd678f530701867) | | BND | Vanguard Total Bond Market ETF | [`0x2f62fc9fabb470c690f141c28340ed832bb27020`](https://rh-scan.com/address/0x2f62fc9fabb470c690f141c28340ed832bb27020) | | BULL | Webull | [`0xcef9027c7d6985b85f0ba431125073529a947a68`](https://rh-scan.com/address/0xcef9027c7d6985b85f0ba431125073529a947a68) | | CBRS | Cerebras Systems | [`0x5c90450bbb4273d7b2f17cf6917aeb237a569679`](https://rh-scan.com/address/0x5c90450bbb4273d7b2f17cf6917aeb237a569679) | | CCL | Carnival Corporation | [`0x9651342cea770ae9a2969ba2a52611523146aef9`](https://rh-scan.com/address/0x9651342cea770ae9a2969ba2a52611523146aef9) | | CEG | Constellation Energy | [`0xae517a2903e68bd929dfd15be875f8369d53e94a`](https://rh-scan.com/address/0xae517a2903e68bd929dfd15be875f8369d53e94a) | | CELH | Celsius | [`0x8cf07c5a878945185d327aaa6e33faa95f95e7bf`](https://rh-scan.com/address/0x8cf07c5a878945185d327aaa6e33faa95f95e7bf) | | CIEN | Ciena | [`0x44f6d488021f8233b9416294d1fe9b1fee28382d`](https://rh-scan.com/address/0x44f6d488021f8233b9416294d1fe9b1fee28382d) | | CLOV | Clover Health Investments | [`0x62200915e7deab1ec7f79fb246dadbb80eacddd0`](https://rh-scan.com/address/0x62200915e7deab1ec7f79fb246dadbb80eacddd0) | | CLS | Celestica | [`0xbf449977089c718c004a66c554b26b94ef3ad4de`](https://rh-scan.com/address/0xbf449977089c718c004a66c554b26b94ef3ad4de) | | CLSK | CleanSpark | [`0xcbb95bbf36099d34da091dc6fa6f49efa257cee3`](https://rh-scan.com/address/0xcbb95bbf36099d34da091dc6fa6f49efa257cee3) | | COHR | Coherent | [`0x92f9f459f1a9a5ad266b182be7bffd1c6c666894`](https://rh-scan.com/address/0x92f9f459f1a9a5ad266b182be7bffd1c6c666894) | | COIN | Coinbase | [`0x6330d8c3178a418788df01a47479c0ce7ccf450b`](https://rh-scan.com/address/0x6330d8c3178a418788df01a47479c0ce7ccf450b) | | COST | Costco | [`0x4ea005168d7f09a7a0ba9d1def21a479950e44c2`](https://rh-scan.com/address/0x4ea005168d7f09a7a0ba9d1def21a479950e44c2) | | CRCL | Circle Internet Group | [`0xdf0992e440dd0be65bd8439b609d6d4366bf1cb5`](https://rh-scan.com/address/0xdf0992e440dd0be65bd8439b609d6d4366bf1cb5) | | CRDO | Credo Technology Group | [`0x4d67253bc223e6b0e104f1084c1fb2b669ddc41b`](https://rh-scan.com/address/0x4d67253bc223e6b0e104f1084c1fb2b669ddc41b) | | CRM | Salesforce | [`0xd95b44124e475743a7589e68f3d74008a5536d44`](https://rh-scan.com/address/0xd95b44124e475743a7589e68f3d74008a5536d44) | | CRWD | CrowdStrike Holdings | [`0xea72ecca2d0f6bfa1394dbbcff85b52cd4233931`](https://rh-scan.com/address/0xea72ecca2d0f6bfa1394dbbcff85b52cd4233931) | | CRWV | CoreWeave | [`0x5f10a1c971b69e47e059e1dc91901b59b3fb49c3`](https://rh-scan.com/address/0x5f10a1c971b69e47e059e1dc91901b59b3fb49c3) | | CSCO | Cisco Systems | [`0xf543967eebb6f1917992ef0e68de63ab07a5a0da`](https://rh-scan.com/address/0xf543967eebb6f1917992ef0e68de63ab07a5a0da) | | CTSH | Cognizant | [`0x63d5a3b6939a33f1e75d8bcd85759858239600db`](https://rh-scan.com/address/0x63d5a3b6939a33f1e75d8bcd85759858239600db) | | CVNA | Carvana | [`0xa4f319104089fe321dc8093c6e707d4fe190a988`](https://rh-scan.com/address/0xa4f319104089fe321dc8093c6e707d4fe190a988) | | DDOG | Datadog | [`0x27c99fbde9d0d2aa4f4bfb4943f237843ddf6958`](https://rh-scan.com/address/0x27c99fbde9d0d2aa4f4bfb4943f237843ddf6958) | | DELL | Dell | [`0x941ae714ec6d8130c7b75d67160ca08f1e7d11dd`](https://rh-scan.com/address/0x941ae714ec6d8130c7b75d67160ca08f1e7d11dd) | | DJT | Trump Media & Technology Group | [`0x1d11f0496982706c5e14a514d4e79f2e6bde4516`](https://rh-scan.com/address/0x1d11f0496982706c5e14a514d4e79f2e6bde4516) | | DOCN | DigitalOcean | [`0xc02f12b9fe9e707079ec0d546f3050d3f6c1f8bd`](https://rh-scan.com/address/0xc02f12b9fe9e707079ec0d546f3050d3f6c1f8bd) | | ELF | e.l.f. Beauty | [`0x39ec44bee4f6a116c6f9b8de566848a985c53c60`](https://rh-scan.com/address/0x39ec44bee4f6a116c6f9b8de566848a985c53c60) | | EWT | iShares MSCI Taiwan Capped ETF | [`0x1c690498150252222c275a5ced69d3a6b1f52d5e`](https://rh-scan.com/address/0x1c690498150252222c275a5ced69d3a6b1f52d5e) | | EWY | iShares MSCI South Korea fund | [`0x7f0abef0c07280f82c6a08ead09ded6bae2c13fc`](https://rh-scan.com/address/0x7f0abef0c07280f82c6a08ead09ded6bae2c13fc) | | F | Ford Motor | [`0x25c288e6d899b9bc30160965ad9644c67e73be0c`](https://rh-scan.com/address/0x25c288e6d899b9bc30160965ad9644c67e73be0c) | | FICO | Fair Isaac | [`0xa48f22a46c0f1c46ca7d111cb6c137c271987180`](https://rh-scan.com/address/0xa48f22a46c0f1c46ca7d111cb6c137c271987180) | | FIG | Figma | [`0x41f4267525a8aff329540ef24fd83d9044758b33`](https://rh-scan.com/address/0x41f4267525a8aff329540ef24fd83d9044758b33) | | FISV | Fiserv | [`0x9ece29a4a2397c0a35fb5fa8ee2b9509130a98cc`](https://rh-scan.com/address/0x9ece29a4a2397c0a35fb5fa8ee2b9509130a98cc) | | FIX | Comfort Systems | [`0x93dbb1d2dc5d63f4abacff30485273f538df68ac`](https://rh-scan.com/address/0x93dbb1d2dc5d63f4abacff30485273f538df68ac) | | FLNC | Fluence Energy | [`0x282e87451e10fa6679bc7d76c69be44cd3fc777c`](https://rh-scan.com/address/0x282e87451e10fa6679bc7d76c69be44cd3fc777c) | | FLY | Firefly Aerospace Inc. | [`0x03bc731ffb162cdd7b98d3c6542bfc291126075d`](https://rh-scan.com/address/0x03bc731ffb162cdd7b98d3c6542bfc291126075d) | | FTNT | Fortinet | [`0x3fb8976980d486084b2eb4a404bd12e72823958f`](https://rh-scan.com/address/0x3fb8976980d486084b2eb4a404bd12e72823958f) | | FUTU | Futu Holdings | [`0xeb30663bdff0622ef4e4e5cbb4e975f19f33f51d`](https://rh-scan.com/address/0xeb30663bdff0622ef4e4e5cbb4e975f19f33f51d) | | GE | General Electric | [`0x63b814ddbd6bf339f25fed8c36158a008d5b373e`](https://rh-scan.com/address/0x63b814ddbd6bf339f25fed8c36158a008d5b373e) | | GEV | GE Vernova | [`0x94b8aae43a1ccc08aa64b7d1f29b4d920af4a0c9`](https://rh-scan.com/address/0x94b8aae43a1ccc08aa64b7d1f29b4d920af4a0c9) | | GLD | SPDR Gold Trust | [`0xc9a981fee1f9dec688bb123ccdecc63d0debfc4e`](https://rh-scan.com/address/0xc9a981fee1f9dec688bb123ccdecc63d0debfc4e) | | GLW | Corning | [`0x7c04e6a3368f2a1de3874f0e80d2e0a1a9915da6`](https://rh-scan.com/address/0x7c04e6a3368f2a1de3874f0e80d2e0a1a9915da6) | | GLXY | Galaxy Digital Inc. | [`0x2d427692e928fa156ec22acfabafa0447c5805b7`](https://rh-scan.com/address/0x2d427692e928fa156ec22acfabafa0447c5805b7) | | GME | GameStop | [`0x1b0e319c6a659f002271b69db8a7df2f911c153e`](https://rh-scan.com/address/0x1b0e319c6a659f002271b69db8a7df2f911c153e) | | GOOGL | Alphabet Class A | [`0x2e0847e8910a9732eb3fb1bb4b70a580adad4fe3`](https://rh-scan.com/address/0x2e0847e8910a9732eb3fb1bb4b70a580adad4fe3) | | HII | Huntington Ingalls | [`0xeb61c0ed490a367d4e3631ccf8a74b3bfc7e775d`](https://rh-scan.com/address/0xeb61c0ed490a367d4e3631ccf8a74b3bfc7e775d) | | HIMS | Hims & Hers Health | [`0xccee82fe024c36fa15e1005ede3e9e4787e23d09`](https://rh-scan.com/address/0xccee82fe024c36fa15e1005ede3e9e4787e23d09) | | HPE | HP Enterprise | [`0x59dd09d4900c2e4b5f75b7c0d4e6796fcc234cb1`](https://rh-scan.com/address/0x59dd09d4900c2e4b5f75b7c0d4e6796fcc234cb1) | | HWM | Howmet Aerospace | [`0xaea445c5f3db1a462998ccc422a875a361ee5d99`](https://rh-scan.com/address/0xaea445c5f3db1a462998ccc422a875a361ee5d99) | | IBM | IBM | [`0x980dcf6766fa79f5cf0c4aadb3ab477ff15a9619`](https://rh-scan.com/address/0x980dcf6766fa79f5cf0c4aadb3ab477ff15a9619) | | IBRX | ImmunityBio | [`0x7c148f74ac7445d1f28366b7fcdc6792a9fcd0cf`](https://rh-scan.com/address/0x7c148f74ac7445d1f28366b7fcdc6792a9fcd0cf) | | INDA | iShares MSCI India ETF | [`0xacef2e09adb47ad6abebad9ff06689e60615c2b6`](https://rh-scan.com/address/0xacef2e09adb47ad6abebad9ff06689e60615c2b6) | | INFQ | Infleqtion | [`0xb853bc83a753342a4f8320ea680b4b1e84118d21`](https://rh-scan.com/address/0xb853bc83a753342a4f8320ea680b4b1e84118d21) | | INOD | Innodata | [`0xf1953dab6fad537488d5a022361ffaa8b4c95ec6`](https://rh-scan.com/address/0xf1953dab6fad537488d5a022361ffaa8b4c95ec6) | | INTC | Intel | [`0xc72b96e0e48ecd4dc75e1e45396e26300bc39681`](https://rh-scan.com/address/0xc72b96e0e48ecd4dc75e1e45396e26300bc39681) | | INTU | Intuit | [`0x56d23bee5f41a7120170b0c603dae30128e460e9`](https://rh-scan.com/address/0x56d23bee5f41a7120170b0c603dae30128e460e9) | | IONQ | IonQ | [`0x558378e000d634a36593e338ebacdd6207640efe`](https://rh-scan.com/address/0x558378e000d634a36593e338ebacdd6207640efe) | | IREN | IREN Limited | [`0xf0ab0c93be6f41369d302e55db1a96b3c430212d`](https://rh-scan.com/address/0xf0ab0c93be6f41369d302e55db1a96b3c430212d) | | JBL | Jabil Inc. | [`0xeaf2512dfc1beac608f8794b3793cd4e02894aa6`](https://rh-scan.com/address/0xeaf2512dfc1beac608f8794b3793cd4e02894aa6) | | JNJ | Johnson & Johnson | [`0x03dfbbe0ac4e7bcdafd08ed41a400326b77d8c80`](https://rh-scan.com/address/0x03dfbbe0ac4e7bcdafd08ed41a400326b77d8c80) | | JOBY | Joby Aviation | [`0xb334c5ce741b80b5b671f47f5c269cb193fe8e24`](https://rh-scan.com/address/0xb334c5ce741b80b5b671f47f5c269cb193fe8e24) | | KLAC | KLA | [`0x96b933c74ecb4a0926b9210cef7b743ef46be2e9`](https://rh-scan.com/address/0x96b933c74ecb4a0926b9210cef7b743ef46be2e9) | | KSS | Kohls Corporation | [`0x12e3c047bf9aecaf9ddc98c05c31bfd1dd043993`](https://rh-scan.com/address/0x12e3c047bf9aecaf9ddc98c05c31bfd1dd043993) | | KTOS | Kratos Defense & Security Solutions | [`0x7fd06a4d81ccfa3f351394e144d5191874c31313`](https://rh-scan.com/address/0x7fd06a4d81ccfa3f351394e144d5191874c31313) | | LHX | L3Harris | [`0x48d60243c66437c6ac3c2495be94747aed5dfe25`](https://rh-scan.com/address/0x48d60243c66437c6ac3c2495be94747aed5dfe25) | | LITE | Lumentum | [`0x8ef20885f94e3d9bc7eb3080279188bd5ed7c08c`](https://rh-scan.com/address/0x8ef20885f94e3d9bc7eb3080279188bd5ed7c08c) | | LLY | Eli Lilly | [`0x8005d266423c7ea827372c9c864491e5786600ea`](https://rh-scan.com/address/0x8005d266423c7ea827372c9c864491e5786600ea) | | LMT | Lockheed | [`0x329fcaceb9ad6f9580dd5f643fed0646900d043c`](https://rh-scan.com/address/0x329fcaceb9ad6f9580dd5f643fed0646900d043c) | | LRCX | Lam Research Corp | [`0x57b0030166db0c31690d1a5aa167e2e26e2c29a4`](https://rh-scan.com/address/0x57b0030166db0c31690d1a5aa167e2e26e2c29a4) | | LULU | Lululemon | [`0x4e62068525ab11fe768e29dfd00ef909b9803016`](https://rh-scan.com/address/0x4e62068525ab11fe768e29dfd00ef909b9803016) | | LUNR | Intuitive Machines | [`0xa5d4968421ba94814be3b136b15cf422101ac1a3`](https://rh-scan.com/address/0xa5d4968421ba94814be3b136b15cf422101ac1a3) | | MDB | MongoDB | [`0xddf2266b79abf0b48898959b0ed6e6adf512be74`](https://rh-scan.com/address/0xddf2266b79abf0b48898959b0ed6e6adf512be74) | | META | Meta Platforms | [`0xc0d6457c16cc70d6790dd43521c899c87ce02f35`](https://rh-scan.com/address/0xc0d6457c16cc70d6790dd43521c899c87ce02f35) | | MOD | Modine | [`0xc6cbad1016b38b797610c25e1dc7d95988b1f362`](https://rh-scan.com/address/0xc6cbad1016b38b797610c25e1dc7d95988b1f362) | | MPWR | Monolithic Power Systems | [`0x52d50d0280ad1054b43f052bd70a49a212a1b128`](https://rh-scan.com/address/0x52d50d0280ad1054b43f052bd70a49a212a1b128) | | MRNA | Moderna | [`0x43b07d15ce533bec5476d70c22a78a1b2b662155`](https://rh-scan.com/address/0x43b07d15ce533bec5476d70c22a78a1b2b662155) | | MRVL | Marvell Technology | [`0x62fd0668e10d8b72339be2dcf7643001688ff13b`](https://rh-scan.com/address/0x62fd0668e10d8b72339be2dcf7643001688ff13b) | | MSFT | Microsoft | [`0xe93237c50d904957cf27e7b1133b510c669c2e74`](https://rh-scan.com/address/0xe93237c50d904957cf27e7b1133b510c669c2e74) | | MSTR | Strategy Inc. | [`0xec262a75e413fafd0df80480274532c79d42da09`](https://rh-scan.com/address/0xec262a75e413fafd0df80480274532c79d42da09) | | MTSI | MACOM | [`0xc93f4d80e268ab922e871bd169156c3cc41894e6`](https://rh-scan.com/address/0xc93f4d80e268ab922e871bd169156c3cc41894e6) | | MU | Micron Technology | [`0xff080c8ce2e5feadaca0da81314ae59d232d4afd`](https://rh-scan.com/address/0xff080c8ce2e5feadaca0da81314ae59d232d4afd) | | MXL | MaxLinear | [`0x48961813349333209994750ffa89b3c5c22ec969`](https://rh-scan.com/address/0x48961813349333209994750ffa89b3c5c22ec969) | | NAVN | Navan | [`0xf7181b63fdb858558a74ba96bc42732684cd7965`](https://rh-scan.com/address/0xf7181b63fdb858558a74ba96bc42732684cd7965) | | NBIS | Nebius Group | [`0x9d9c6684f596f66a64c030b93a886d51fd4d7931`](https://rh-scan.com/address/0x9d9c6684f596f66a64c030b93a886d51fd4d7931) | | NET | Cloudflare | [`0x116f00968269b7bfbad4109ce591d6e74c0601d4`](https://rh-scan.com/address/0x116f00968269b7bfbad4109ce591d6e74c0601d4) | | NFLX | Netflix | [`0xe0444ef8bf4ed74f74fd73686e2ddf4c1c5591e8`](https://rh-scan.com/address/0xe0444ef8bf4ed74f74fd73686e2ddf4c1c5591e8) | | NNE | Nano Nuclear Energy | [`0xbef75684c43c4ea7bd18dd532a2244674ee8b926`](https://rh-scan.com/address/0xbef75684c43c4ea7bd18dd532a2244674ee8b926) | | NOW | ServiceNow | [`0x0c3260af4b8f13a69c4c2dfb84fd667890cdfa14`](https://rh-scan.com/address/0x0c3260af4b8f13a69c4c2dfb84fd667890cdfa14) | | NU | Nu | [`0x408c14038a04f7bd235329e26d2bf569ee20e250`](https://rh-scan.com/address/0x408c14038a04f7bd235329e26d2bf569ee20e250) | | NVDA | NVIDIA | [`0xd0601ce157db5bdc3162bbac2a2c8af5320d9eec`](https://rh-scan.com/address/0xd0601ce157db5bdc3162bbac2a2c8af5320d9eec) | | NVTS | Navitas Semiconductor | [`0xbe6702d7b70315376dc48a3293f24f0982f86386`](https://rh-scan.com/address/0xbe6702d7b70315376dc48a3293f24f0982f86386) | | OKLO | Oklo | [`0x8b2f88497f15a18e9d4ffa1a8ffb8538399ae774`](https://rh-scan.com/address/0x8b2f88497f15a18e9d4ffa1a8ffb8538399ae774) | | ON | ON Semiconductor | [`0xbbd09f72b025360fee5c928053dca6248d35be54`](https://rh-scan.com/address/0xbbd09f72b025360fee5c928053dca6248d35be54) | | ONTO | Onto Innovation | [`0x8ff63eaeee3fe54ba450c4f5538064ec5a893aef`](https://rh-scan.com/address/0x8ff63eaeee3fe54ba450c4f5538064ec5a893aef) | | ORCL | Oracle | [`0xb0992820e760d836549ba69bc7598b4af75dee03`](https://rh-scan.com/address/0xb0992820e760d836549ba69bc7598b4af75dee03) | | OUST | Ouster | [`0x40e7a279850e443f582059ae5dc1c3b6563e6395`](https://rh-scan.com/address/0x40e7a279850e443f582059ae5dc1c3b6563e6395) | | P | Everpure | [`0x1cdad396db64bda184d5182a97dd9b3c62100b7d`](https://rh-scan.com/address/0x1cdad396db64bda184d5182a97dd9b3c62100b7d) | | PANW | Palo Alto Networks | [`0xb039597ed45cba7b6e2fb9e8be51802969cee5be`](https://rh-scan.com/address/0xb039597ed45cba7b6e2fb9e8be51802969cee5be) | | PATH | UiPath | [`0xfb2664f07b6aadd29ea7a59d8859b1aeb8645cda`](https://rh-scan.com/address/0xfb2664f07b6aadd29ea7a59d8859b1aeb8645cda) | | PENG | Penguin Solutions | [`0x9b23573b156b52565012f5ce02cdf60afbaa70be`](https://rh-scan.com/address/0x9b23573b156b52565012f5ce02cdf60afbaa70be) | | PFE | Pfizer | [`0x7066a64c24e4206cd62e83bf198c1e7eb361f51e`](https://rh-scan.com/address/0x7066a64c24e4206cd62e83bf198c1e7eb361f51e) | | PL | Planet Labs | [`0xaa4d64474c172010ab57719cb9951e6142a100d3`](https://rh-scan.com/address/0xaa4d64474c172010ab57719cb9951e6142a100d3) | | PLTR | Palantir Technologies | [`0x894e1ec2d74ffe5aef8dc8a9e84686accb964f2a`](https://rh-scan.com/address/0x894e1ec2d74ffe5aef8dc8a9e84686accb964f2a) | | POET | POET Technologies | [`0xcf6b2d875361be807eafa57458c80f28521f9333`](https://rh-scan.com/address/0xcf6b2d875361be807eafa57458c80f28521f9333) | | POWL | Powell Industries | [`0x237c16d66590f67b886d978acd362eaead8b18c7`](https://rh-scan.com/address/0x237c16d66590f67b886d978acd362eaead8b18c7) | | PR | Permian Resources | [`0x4189f0c66ebbb0bfef1c31f763131361ef32f77c`](https://rh-scan.com/address/0x4189f0c66ebbb0bfef1c31f763131361ef32f77c) | | PWR | Quanta | [`0x9ab02ead789b6903c3c44d0ed32f9c707cdf12fd`](https://rh-scan.com/address/0x9ab02ead789b6903c3c44d0ed32f9c707cdf12fd) | | QBTS | D-Wave Quantum Inc. Common Stock | [`0xc583c60aef9dc401da72cec1b404743a93cea1cc`](https://rh-scan.com/address/0xc583c60aef9dc401da72cec1b404743a93cea1cc) | | QCOM | Qualcomm | [`0x0f17206447090e464c277571124dd2688e48aea9`](https://rh-scan.com/address/0x0f17206447090e464c277571124dd2688e48aea9) | | QQQ | Invesco QQQ | [`0xd5f3879160bc7c32ebb4dc785f8a4f505888de68`](https://rh-scan.com/address/0xd5f3879160bc7c32ebb4dc785f8a4f505888de68) | | QUBT | Quantum Computing | [`0x59818904ab4ce163b3ce4ffb64f2d6ca02c434b4`](https://rh-scan.com/address/0x59818904ab4ce163b3ce4ffb64f2d6ca02c434b4) | | RBLX | Roblox | [`0xf0c4bf4c582cb3836e98394b1d4e7b7281101be8`](https://rh-scan.com/address/0xf0c4bf4c582cb3836e98394b1d4e7b7281101be8) | | RCAT | Red Cat | [`0xfde6b5d9bb419b10c23268c74e369abff39c0460`](https://rh-scan.com/address/0xfde6b5d9bb419b10c23268c74e369abff39c0460) | | RDDT | Reddit | [`0x05b37fb53a299a1b874a619e1c4c404d52c36f4c`](https://rh-scan.com/address/0x05b37fb53a299a1b874a619e1c4c404d52c36f4c) | | RDW | Redwire | [`0x92ef19e82bd8ff36661de838d5eae7e5cef0effe`](https://rh-scan.com/address/0x92ef19e82bd8ff36661de838d5eae7e5cef0effe) | | RGTI | Rigetti Computing | [`0x284358abc07f9359f19f4b5b4ac91901be2597ba`](https://rh-scan.com/address/0x284358abc07f9359f19f4b5b4ac91901be2597ba) | | RIVN | Rivian Automotive | [`0xb1bf26c1d20ff267a4f93550d1e0d06ac40a114b`](https://rh-scan.com/address/0xb1bf26c1d20ff267a4f93550d1e0d06ac40a114b) | | RKLB | Rocket Lab Corporation | [`0x3b14c39e89d60d627b42a1a4ca45b5bb45fc12e2`](https://rh-scan.com/address/0x3b14c39e89d60d627b42a1a4ca45b5bb45fc12e2) | | RUN | Sunrun | [`0x756bc80af765c82da966a788858d65adf14f3793`](https://rh-scan.com/address/0x756bc80af765c82da966a788858d65adf14f3793) | | SATS | EchoStar | [`0x95052ddcd5dc25641657424a8cf04834997e1730`](https://rh-scan.com/address/0x95052ddcd5dc25641657424a8cf04834997e1730) | | SCHD | Schwab US Dividend Equity ETF | [`0xd63abb2c13d7a8421a8017a712802053568e3c1d`](https://rh-scan.com/address/0xd63abb2c13d7a8421a8017a712802053568e3c1d) | | SGOV | iShares 0-3 Month Treasury Bond | [`0x92fd66527192e3e61d4ddd13322aa222de86f9b5`](https://rh-scan.com/address/0x92fd66527192e3e61d4ddd13322aa222de86f9b5) | | SHOP | Shopify | [`0xf53f66751b1eff985311b693531e3290f600c410`](https://rh-scan.com/address/0xf53f66751b1eff985311b693531e3290f600c410) | | SHY | iShares 1-3 Year Treasury Bond ETF | [`0xbe274710bf3d9567e1b290ef6a5f9f90ca016fd8`](https://rh-scan.com/address/0xbe274710bf3d9567e1b290ef6a5f9f90ca016fd8) | | SIMO | Silicon Motion | [`0x77e655e37f4d913fb9540e0d541d824171a60e81`](https://rh-scan.com/address/0x77e655e37f4d913fb9540e0d541d824171a60e81) | | SKHY | SK hynix Inc. American Depositary Shares | [`0x84cab63bc87912e71ad199ff14a0ba45de68fef8`](https://rh-scan.com/address/0x84cab63bc87912e71ad199ff14a0ba45de68fef8) | | SLS | SELLAS Life Sciences | [`0x285b231728c7e4333799183df1094d775246a535`](https://rh-scan.com/address/0x285b231728c7e4333799183df1094d775246a535) | | SLV | iShares Silver Trust | [`0x411efb0e7f985935daec3d4c3ebaea0d0ad7d89f`](https://rh-scan.com/address/0x411efb0e7f985935daec3d4c3ebaea0d0ad7d89f) | | SMCI | Super Micro Computer | [`0xc01aa1fecec0605b13bc84874ff7256c0f5f562a`](https://rh-scan.com/address/0xc01aa1fecec0605b13bc84874ff7256c0f5f562a) | | SMH | VanEck Semiconductor ETF | [`0x072f979c2cac8e1391b0162a87fee094bf8744a0`](https://rh-scan.com/address/0x072f979c2cac8e1391b0162a87fee094bf8744a0) | | SMR | NuScale Power | [`0x1eebee7f74517e0279dfb09d25b0407beec3fdd6`](https://rh-scan.com/address/0x1eebee7f74517e0279dfb09d25b0407beec3fdd6) | | SNAP | Snap | [`0xf6589f11bc40b669e584073f428b05562f568733`](https://rh-scan.com/address/0xf6589f11bc40b669e584073f428b05562f568733) | | SNDK | Sandisk Corporation | [`0xb90a19ff0af67f7779aff50a882a9cff42446400`](https://rh-scan.com/address/0xb90a19ff0af67f7779aff50a882a9cff42446400) | | SNOW | Snowflake | [`0xba0cab75495255d0cb58e22b648bfed4ecd1f47e`](https://rh-scan.com/address/0xba0cab75495255d0cb58e22b648bfed4ecd1f47e) | | SOFI | SoFi Technologies | [`0x98e75885157c80992a8d41b696d8c9c6fb30a926`](https://rh-scan.com/address/0x98e75885157c80992a8d41b696d8c9c6fb30a926) | | SOUN | SoundHound AI | [`0x6e3dfd9f7e1649baa14d25cac18c94d62db10a54`](https://rh-scan.com/address/0x6e3dfd9f7e1649baa14d25cac18c94d62db10a54) | | SOXX | iShares Semiconductor ETF | [`0x75742c18bc1f1c5c5f448f4c9d9c6f66dafaaa38`](https://rh-scan.com/address/0x75742c18bc1f1c5c5f448f4c9d9c6f66dafaaa38) | | SPCX | Space Exploration Technologies Corp. Class A Common Stock | [`0x4a0e65a3eccec6dbe60ae065f2e7bb85fae35eea`](https://rh-scan.com/address/0x4a0e65a3eccec6dbe60ae065f2e7bb85fae35eea) | | SPMO | Invesco S\&P 500 Momentum ETF | [`0xad622320e520de39e72d41ef07438c3fd3354875`](https://rh-scan.com/address/0xad622320e520de39e72d41ef07438c3fd3354875) | | SPY | SPDR S\&P 500 ETF Trust | [`0x117cc2133c37b721f49de2a7a74833232b3b4c0c`](https://rh-scan.com/address/0x117cc2133c37b721f49de2a7a74833232b3b4c0c) | | TE | T1 Energy | [`0xb1969f6604ca1ae7a2cd3f1827876e914594ca2d`](https://rh-scan.com/address/0xb1969f6604ca1ae7a2cd3f1827876e914594ca2d) | | TEAM | Atlassian Corporation | [`0x5b97476b922f3305131b8f0b9d333172e87f4aae`](https://rh-scan.com/address/0x5b97476b922f3305131b8f0b9d333172e87f4aae) | | TEM | Tempus AI | [`0xb1cc0ec7db69cf43539119814df40071b9d61793`](https://rh-scan.com/address/0xb1cc0ec7db69cf43539119814df40071b9d61793) | | TER | Teradyne | [`0x2778c5024d5ca2cdb0f8ead671ffc69963adcd9c`](https://rh-scan.com/address/0x2778c5024d5ca2cdb0f8ead671ffc69963adcd9c) | | TSEM | Tower Semiconductor | [`0x89776d4cd68193597a2fc132cfac1fde36ccea8a`](https://rh-scan.com/address/0x89776d4cd68193597a2fc132cfac1fde36ccea8a) | | TSLA | Tesla | [`0x322f0929c4625ed5bad873c95208d54e1c003b2d`](https://rh-scan.com/address/0x322f0929c4625ed5bad873c95208d54e1c003b2d) | | TSM | Taiwan Semiconductor Manufacturing | [`0x58ffe4a942d3885baa22d7520691f611ef09e7aa`](https://rh-scan.com/address/0x58ffe4a942d3885baa22d7520691f611ef09e7aa) | | TTD | Trade Desk | [`0x0b5fb4031cae9163db10b169ee72685f0edc8545`](https://rh-scan.com/address/0x0b5fb4031cae9163db10b169ee72685f0edc8545) | | TTWO | Take-Two Interactive Software | [`0x5e81213613b6b86eab4c6c50d718d34359459786`](https://rh-scan.com/address/0x5e81213613b6b86eab4c6c50d718d34359459786) | | UMC | United Microelectronics | [`0x0e6e67ba88e7b5d9b67636a215c76779b948de79`](https://rh-scan.com/address/0x0e6e67ba88e7b5d9b67636a215c76779b948de79) | | UNH | UnitedHealth | [`0xcf364ea52787e289de6f32077834056e3e70d6a8`](https://rh-scan.com/address/0xcf364ea52787e289de6f32077834056e3e70d6a8) | | UPS | UPS | [`0xf23250dac154d05bb671cb0d0ebef3c635c79ce2`](https://rh-scan.com/address/0xf23250dac154d05bb671cb0d0ebef3c635c79ce2) | | USAR | USA Rare Earth | [`0xd917b029c761d264c6a312bbbcda868658ef86a6`](https://rh-scan.com/address/0xd917b029c761d264c6a312bbbcda868658ef86a6) | | USO | United States Oil Fund | [`0xa30fa36db767ad9ed3f7a60fc79526fb4d56d344`](https://rh-scan.com/address/0xa30fa36db767ad9ed3f7a60fc79526fb4d56d344) | | VICR | Vicor | [`0x6006ed4b2f94110851ff7509d97d034f0eed9226`](https://rh-scan.com/address/0x6006ed4b2f94110851ff7509d97d034f0eed9226) | | VRT | Vertiv | [`0xfa78c12e6488814a0262e4e802749a4a737d5fb7`](https://rh-scan.com/address/0xfa78c12e6488814a0262e4e802749a4a737d5fb7) | | VSAT | ViaSat | [`0x26dcbfb34fc83cabd6990f449674efdc6097ff85`](https://rh-scan.com/address/0x26dcbfb34fc83cabd6990f449674efdc6097ff85) | | VST | Vistra | [`0x561e2a49212b7ccf47f2744ccb83e200722fadbc`](https://rh-scan.com/address/0x561e2a49212b7ccf47f2744ccb83e200722fadbc) | | VTI | Vanguard Morningstar Total Stock Market ETF | [`0x0594134df3f171a354d9c85ebd65b7a6148f6d09`](https://rh-scan.com/address/0x0594134df3f171a354d9c85ebd65b7a6148f6d09) | | WDAY | Workday | [`0x82da4646242e1d962e96e932269dc644c94a9caa`](https://rh-scan.com/address/0x82da4646242e1d962e96e932269dc644c94a9caa) | | WDC | Western Digital | [`0xf52597345a8edf418bc4071b4a35112472277d3e`](https://rh-scan.com/address/0xf52597345a8edf418bc4071b4a35112472277d3e) | | WULF | TeraWulf | [`0x348be1a8663f15edde5cdf8a96bb69078f7ab6fd`](https://rh-scan.com/address/0x348be1a8663f15edde5cdf8a96bb69078f7ab6fd) | | WYFI | WhiteFiber, Inc. | [`0x9e7abd3c9139d14e4c86dce0e455aab7a0c2fb3e`](https://rh-scan.com/address/0x9e7abd3c9139d14e4c86dce0e455aab7a0c2fb3e) | | XLK | State Street Technology Select Sector SPDR ETF | [`0x15cd20759ce7f3285c29a319de2d1a2e098c6f43`](https://rh-scan.com/address/0x15cd20759ce7f3285c29a319de2d1a2e098c6f43) | | XNDU | Xanadu Quantum | [`0xa8eb3bccbf2017ee7cbfb652eb51cf2e1b153289`](https://rh-scan.com/address/0xa8eb3bccbf2017ee7cbfb652eb51cf2e1b153289) | | XOM | ExxonMobil Holdings Corporation | [`0xf9b46d3d1b22199d4d1025a9cedb540a33f1a2d5`](https://rh-scan.com/address/0xf9b46d3d1b22199d4d1025a9cedb540a33f1a2d5) | | ZM | Zoom | [`0x44c4f142009036cf477ed2d09932051843137cf1`](https://rh-scan.com/address/0x44c4f142009036cf477ed2d09932051843137cf1) | | ZS | Zscaler | [`0x7dc013eb55e436f30d7ed1afe4e36d6e45e3c3f7`](https://rh-scan.com/address/0x7dc013eb55e436f30d7ed1afe4e36d6e45e3c3f7) | The paired-asset catalog and opening-price settings can change for future launches. Existing pools keep the exact Stock Token, price frame, fee settings, and liquidity position recorded when they opened. # Token creation Source: https://docs.o1.exchange/launchpad/create/token-creation Create a fixed-supply Base B20 or Robinhood/Monad ERC-20 token, choose an available pair, publish its profile, and open permanent liquidity. Monad (chain `143`) has MON, USDC and WETH registered in its new minimal suite. At block `102277088` on **2026-09-05**, creation was enabled and the configured fee was **100 MON**. Contract deployment does not establish app/API rollout availability. See [Live configuration](/launchpad/reference/live-configuration) before preparing a launch. Every launch creates a new fixed-supply token and opens its Uniswap v4 market in the same transaction. The creator does not deposit the paired asset and cannot create more tokens later. ## Form fields | Field | Requirement | | ----------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Name | Required, maximum 50 characters | | Symbol | Required, maximum 11 characters and no spaces; letter casing is preserved | | Image | Required, maximum 2 MB; PNG, JPG, WEBP, or GIF | | Paired asset | Required; choose the chain's native currency, Monad WETH, the supported stablecoin, a registered Coinbase crypto major on Base, or a registered Stock Token on Base or Robinhood | | Description | Optional, included in the token's public IPFS profile | | Website | Optional valid website URL | | X | Optional X profile URL | | Telegram | Optional Telegram link | | Extra information | Optional public key/value entries; keys cannot be empty | | Profile editing | Optional; grants permission to edit token information only | ## Address suffix Current Base launches use a B20 address ending in `01`, and the create page previews it before signing. Current Robinhood and Monad launches also require an ERC-20 address ending in `01`; the app generates it after the final metadata is ready. The suffix identifies the current o1 launch flow. It does not change the token's permissions, supply, price, or market. ## Supply and liquidity Current launches create a fixed supply of **1 billion (1,000,000,000) tokens**. The supply cannot increase after launch. The complete supply is placed into the permanent Uniswap liquidity position when the token launches. ## Token implementation The protocol creates a native B20 token with no administrator. Its 1 billion supply is created once. The creator may optionally retain permission to edit profile information, but cannot mint more tokens or control transfers. Base's B20 protocol contracts are listed in [Production contracts](/launchpad/reference/production-contracts). o1 creates a standard fixed-supply ERC-20 with no owner. Its 1 billion supply is created once, and the contract cannot mint more tokens, pause transfers, or be upgraded. The token supports normal ERC-20 transfers and approvals. Optional profile editing does not grant control over balances or the market. ## Crypto-paired and stock-paired routes Both routes use the same fixed supply, announcements, fee split, anti-snipe schedule, and permanent liquidity model. Base and Robinhood each use one active launch factory for both crypto-paired and stock-paired creation. The selected paired asset determines the market type. | Route | Current paired assets | Trading-fee currency | | ---------------- | ------------------------------------------------ | --------------------- | | Base crypto | ETH, USDC, or a registered Coinbase crypto major | Selected paired asset | | Base stocks | Registered Base Stock Tokens | Selected Stock Token | | Robinhood crypto | ETH or USDG | Selected ETH or USDG | | Robinhood stocks | Supported Stock Tokens | Selected Stock Token | | Monad crypto | MON, USDC or WETH | Selected paired asset | See [Stock-paired launches](/launchpad/create/stock-paired-launches) for the current Base and Robinhood catalogs. ## Optional Dev Buy The current Base, Robinhood and Monad launch factories can create the token, seed permanent liquidity, and execute one creator purchase atomically through `createLaunchAndBuy`. The **Include Dev Buy** toggle is off by default. When enabled, the creator enters a native ETH amount on Base/Robinhood or MON amount on Monad and reviews the protected minimum output and slippage setting before signing. The Dev Buy pays the normal 1% base swap fee but does not pay the anti-snipe surcharge. This exemption applies only to that one atomic creator purchase. Any failure, including output below the protected minimum, reverts the complete launch and buy together. Later purchases are ordinary trades and follow the live anti-snipe schedule. ## Profile editing The default profile is permanently immutable. If the creator opts in, the active launch factory lets the current creator update token profile information after launch. The creator can update: * token name; * token symbol; * public profile information, including the image, description, website, X, and Telegram; * extra profile information. This permission cannot create more tokens, change balances, pause transfers, upgrade the token, or remove liquidity. ## Creator rights The active launch factory records the launch-time `originalCreator` permanently and separately tracks the `currentCreator` and `creatorFeeRecipient`. The current creator can propose a two-step creator-rights transfer and can change the destination for future creator-fee credits. If profile editing was enabled at launch, metadata and announcement authorization follow the current creator. Creator rights are not token ownership. They do not grant minting, transfer control, upgrades, balance recovery, or liquidity removal. Already credited fee balances stay with the recipient that earned them. The current application does not expose creator-rights management controls; direct integrations must use the verified active-factory ABI. ## Transaction safety The factory rejects a launch if: * the quote is no longer registered; * the unique launch identifier was already used; * the launch settings changed after the app prepared the transaction; * the deadline has passed; * the current creation fee or transaction value does not match the active factory configuration; * profile or liquidity requirements fail; * the token cannot be created exactly as shown; * opening the pool would require the creator to supply the paired asset. The frontend refreshes the launch settings and chain time immediately before submission. If a protected global setting changes while the transaction is pending, the call stops instead of silently using a different configuration. A paired asset's opening-price refresh intentionally uses the latest registered frame when the launch executes. ## Creation result After confirmation, the app shows the token address and live pool. It also records the paired asset, creation fee, creation route, and market settings from the confirmed transaction. Developers can find exact function and event names in [Functions and events](/launchpad/reference/events-functions). # How it works Source: https://docs.o1.exchange/launchpad/how-it-works The complete o1 Launchpad lifecycle from setup and token creation to trading, fee claims, announcements, and staking. Creators use the o1 interface to configure a token and approve the launch transaction in their wallet. The launch contracts create the token and its Uniswap market together. The creator pays the current global native creation fee plus network gas. The blockchain is the source of truth, while o1 organizes confirmed public data so launches, trades, fees, holders, and announcements are easy to view. ## End-to-end lifecycle The creator supplies a name, symbol, image, paired asset, optional links and description, and a profile-editing preference. The o1 confirmation screen presents the paired asset, fixed supply, permanent liquidity, current creation fee, profile permission, and the predicted address when available. After the creator confirms the review, the app stores the token image and public profile on IPFS, includes that metadata link in the launch request, and refreshes the selected paired asset, creation fee, supply, liquidity settings, and current chain time. The creator approves the launch transaction and pays the displayed creation fee plus the chain's network gas. Base and Robinhood currently use one 0.001 ETH fee for both crypto-paired and stock-paired launches. Monad uses a 100 MON fee for each crypto quote; creation is enabled at the snapshot. On Base, the protocol creates a native B20 token with no administrator. On Robinhood and Monad, o1 creates a fixed-supply ERC-20 with no owner or additional minting function. The fixed 1 billion supply is created once. The launch contracts open the Uniswap v4 pool at the configured starting price and place the complete fixed supply into permanent liquidity. When the creator explicitly enables it, the Base, Robinhood or Monad launch contracts execute one protected native-funded purchase in the same transaction. The toggle is off by default, and a failed purchase reverts the complete launch. After confirmation, the launch page shows the token profile, live market, trading interface, trades, holders, and announcements. Wallet-held tokens may be deposited into a separate compatible staking vault. A launch does not create a vault automatically, and vault creation remains an independent permissionless transaction. ## Where each asset lives | Asset | Location | Who can move it | | --------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------------------------- | | Tradable token supply | The permanent Uniswap liquidity position | The launch contracts prevent its removal | | Staked wallet tokens | The separate staking contract | The participant can withdraw principal according to the selected vault's fixed policy | | Creation fee | Paid to the configured fee recipient in the launch transaction | The creator's wallet pays the exact live fee shown before signing | | Accrued swap fees | A dedicated claimable balance for each recipient | Creator, platform, or valid referrer according to the fee split | | User trade funds | The user's wallet and the Uniswap pool during the trade | The transaction approved by the user | ## Swap lifecycle The interface shows the input amount, estimated output, minimum received, price impact, current fee, slippage limit, and estimated network fee. It automatically applies a 10-minute transaction deadline. The wallet submits a trade for the amount the user chose to spend or sell. Uniswap calculates the result, and the launch contract applies the swap fee in the pool's paired asset. A stock-paired market therefore charges its fee in that Stock Token. The user receives the purchased or sold asset. Creator, platform, and valid referrer fee balances become claimable independently. Trading begins immediately. o1 uses input-amount swaps for both buys and sells: the trader chooses how much to spend or sell, and the interface protects the minimum amount received with a slippage limit. These swaps remain available while the anti-snipe fee decreases. The current window is 20 seconds on all three chains. The optional atomic Dev Buy is a one-time launch path on Base, Robinhood and Monad. It pays the normal base swap fee but not the anti-snipe surcharge. Later buys use the ordinary trading rules. ## Chain-specific token creation The protocol creates a native B20 token with a fixed supply and no administrator. One launch factory supports ETH, USDC, registered Coinbase crypto majors, and registered Base Stock Tokens. If the creator opts in, they may retain permission to update profile information only. o1 creates a standard ERC-20 with a fixed supply. It has no owner and no function to mint more tokens, pause transfers, upgrade the contract, or recover tokens. The selected route can pair it with a supported crypto asset or Stock Token. ## Crypto and stock markets Crypto-paired launches use ETH, the supported stablecoin for the selected chain, or a registered Coinbase crypto major on Base. Swap fees and creator or referral claims use that same paired asset. Stock-paired launches are currently available on Base and Robinhood. Buys spend the selected Stock Token, sells receive it, and all swap-fee claims for that pool are denominated in it. See [Stock-paired launches](/launchpad/create/stock-paired-launches). ## Profile information, comments, and announcements | Feature | How it appears | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | Token profile | The image, description, website, X, Telegram, and other public fields are loaded from the IPFS metadata referenced by the token | | Profile updates | When profile editing is enabled, the creator wallet can update the supported token identity and public information | | Trade comments | A trader may attach a short comment of up to 32 UTF-8 bytes; it becomes public onchain data | | Creator announcements | The current creator can publish updates through the separate announcement contract; original launch provenance remains unchanged | Comments and announcements are public onchain records. Announcements use a separate contract, so the creator does not gain permission to create tokens, control transfers, or remove liquidity. ## What can change later o1 governance can update supported paired assets, their opening-price references, creation fees, supply, liquidity settings, swap fees, and the announcement contract for **future** launches. Integrations must read the live fee before preparing a transaction. Each completed launch keeps its token, original creator, paired asset, fee rates, opening price, liquidity range, and permanent position. Creator rights and the destination for future creator-fee credits can change through their explicit onchain processes. Later global configuration changes apply only to new launches. # Data and AI access Source: https://docs.o1.exchange/launchpad/integration/data-ai Public documentation, machine-readable launchpad configuration, onchain data, and safe wallet-based agent workflows. o1 Launchpad documentation and production configuration are available in formats that work for people, search tools, coding agents, and other AI clients. ## Documentation resources | Resource | Access | Use | | ------------------- | -------------------------------------------------------- | ----------------------------------------------------------------- | | Documentation index | [Open `llms.txt`](https://docs.o1.exchange/llms.txt) | Discover available documentation pages | | Full documentation | [Open full text](https://docs.o1.exchange/llms-full.txt) | Retrieve the public documentation as one text corpus | | Page Markdown | Add `.md` to a documentation page URL | Retrieve clean context for one page | | Skill description | [Open `skill.md`](https://docs.o1.exchange/skill.md) | Read the documentation's agent-facing capability summary | | Documentation MCP | `https://docs.o1.exchange/mcp` | Connect an MCP client to search and retrieve public documentation | The MCP URL is a client endpoint, not a web page. Opening it directly in a browser may return a method-not-allowed response. ## Machine-readable production configuration The [`production-deployments.json`](/launchpad/reference/production-deployments.json) data file provides the current Base, Robinhood and Monad contract addresses, staking deployments, dated availability state, Uniswap dependencies, paired assets, fees, opening settings, governance addresses, and contract caps. The [`launch-contract-suites.json`](/launchpad/reference/launch-contract-suites.json) registry provides every active and historical Base, Robinhood and Monad launch suite needed to recognize earlier o1 tokens. Base and Robinhood each share one factory across crypto and stock launches; Monad has a standard crypto factory. The current snapshot includes the exact eight registered Base crypto majors. The human-readable [Stock-paired launches](/launchpad/create/stock-paired-launches) page lists both stock catalogs. The [`base-stock-quotes.json`](/launchpad/reference/base-stock-quotes.json) data file lists the ten registered Base Stock Tokens, while [`robinhood-stock-quotes.json`](/launchpad/reference/robinhood-stock-quotes.json) lists all 194 registered Robinhood Stock Tokens. These snapshots do not gate the application or Public API. Current creation availability comes from the shared platform catalog together with live quote registration and the active factory's launch-enabled state. Historical-suite entries exist for attribution, indexing, trading, claims, vesting, and announcements; they must not be treated as current creation targets. These JSON files are dated public snapshots that clients can fetch and parse directly. Resolve an existing token using its chain ID and originating factory rather than substituting the current factory. Applications that prepare new creation transactions should also read the current active factory configuration before asking a wallet to sign. ## Public market and launch data The o1 interface presents: * launch discovery across All, Crypto, and Stocks views, global search, newest tokens, liquidity, trending, and 24-hour volume; * token profiles, creators, socials, and explorer links; * pool price, FDV, liquidity, charts, recent trades, and holders; * creator announcements and token profile updates; * creator, referral, and platform fee-claim information. Contract state and chain events are the authoritative sources for tokens, pools, trades, fees, and claims. The interface adds searchable and historical views around that public data. ## Safe agent workflow Retrieve the relevant documentation, production addresses, and live contract configuration. Build the launch, trade, or claim request with the selected chain, creation route, paired asset, current fees, recipients, slippage, and deadline. Present the contract, assets, amounts, recipients, and expected outcome before requesting approval. The user reviews and signs in their wallet. Documentation and data tools never need the private key. Agents and integrations should never store a private key, auto-sign transactions, reuse a stale factory configuration, or infer a creation route from a token symbol alone. # Direct contract integration Source: https://docs.o1.exchange/launchpad/integration/direct Read current launch configuration, build safe launch transactions, trade through Uniswap v4, and consume canonical launch events. This page intentionally uses exact contract fields for developers. For a plain-language product flow, start with [How it works](/launchpad/how-it-works). Direct integrations should discover the active chain and creation route, read current factory state, build an unsigned transaction, and let the user's wallet sign it. Never hardcode a mutable configuration version, opening frame, or creation fee. Existing-token discovery has a different boundary from new creation. Index every factory in the [`launch-contract-suites.json`](/launchpad/reference/launch-contract-suites.json) registry from its recorded `firstBlock`, retain the originating `(chainId, factory)` with each launch, and select the matching contract-version ABI. A historical factory is no longer selected by the current interface, but its tokens, pools, fee escrow, vesting vault, and announcement registry remain part of the protocol history. ## Integration sequence Resolve the current factory by chain. Base and Robinhood each use one active factory for crypto-paired and stock-paired launches. The selected quote still determines the market type; do not infer it from a symbol. For the active factory, read `configVersion`, `launchSupply`, `tickSpacing`, `bandTemplate`, the named fee getters, every indexed fee component, `quoteConfig(selectedQuote)`, `quoteRevision(selectedQuote)`, `launchCreationEnabled`, and `nativeLaunchFee` at one recent block. Use the exact ABI for the contracts recorded for earlier launches because their aggregate getter names differ. Apply the hard limits in [Limits and validation](/launchpad/reference/limits), confirm the quote remains registered, and use the complete fixed supply for the pool. Each active factory uses one global native fee for every paired asset. Set ordinary `createLaunch` value to exactly `nativeLaunchFee`; it is currently 0.001 ETH on Base/Robinhood and 100 MON on Monad. Set `expectedConfigVersion` to the fresh read and choose a short chain-time deadline. The o1 Launchpad interface uses the latest block timestamp plus 30 minutes. Paired-asset tick-only updates advance the selected quote revision without changing the global version, so execution intentionally uses the latest registered opening frame. Simulate `createLaunch`, present the complete launch economics to the user, then request a wallet signature and wait for a successful receipt. Read `Launched` for token and pool ID, then index the other factory, hook, PoolManager, escrow, and announcement events from the same transaction. For trades, derive direction and wallet attribution from the complete receipt rather than treating `Trade.executor` as the user's address. ## Read the current snapshot with viem The example below reads the active Base factory. The current Robinhood and Monad factories expose the same configuration surface. Use the current factory and paired-asset addresses for the selected chain from [Production contracts](/launchpad/reference/production-contracts). ```ts theme={null} theme={null} import { createPublicClient, http, parseAbi, zeroAddress } from "viem"; import { base } from "viem/chains"; const FACTORY = "0x1176122eb77AD6a2339322Cda7C4D7ea9BfA63dC"; const factoryReads = parseAbi([ "function configVersion() view returns (uint64)", "function launchSupply() view returns (uint256)", "function tickSpacing() view returns (int24)", "function bandTemplate() view returns ((int24 lowerOffset,int24 upperOffset,uint16 supplyShareBps)[] bands)", "function quoteConfig(address) view returns (bool registered,uint8 quoteDecimals,int24 startTickToken0Frame)", "function quoteRevision(address) view returns (uint64)", "function nativeLaunchFee() view returns (uint256)", "function launchCreationEnabled() view returns (bool)", "function baseFeeBps() view returns (uint16)", "function antiSnipeStartTotalBps() view returns (uint16)", "function antiSnipeWindowSeconds() view returns (uint32)", "function feeComponentCount() view returns (uint256)", "function feeComponents(uint256) view returns (bytes32 componentId,uint8 recipientKind,address configuredRecipient,uint16 feeBps)", "function platformFeeRecipient() view returns (address)", ]); const client = createPublicClient({ chain: base, transport: http() }); const [version, supply, spacing, bands, nativeQuote, quoteRevision, launchFee, enabled, baseFee, antiSnipeStart, antiSnipeWindow, componentCount, platformRecipient] = await Promise.all([ client.readContract({ address: FACTORY, abi: factoryReads, functionName: "configVersion" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "launchSupply" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "tickSpacing" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "bandTemplate" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "quoteConfig", args: [zeroAddress] }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "quoteRevision", args: [zeroAddress] }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "nativeLaunchFee" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "launchCreationEnabled" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "baseFeeBps" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "antiSnipeStartTotalBps" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "antiSnipeWindowSeconds" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "feeComponentCount" }), client.readContract({ address: FACTORY, abi: factoryReads, functionName: "platformFeeRecipient" }), ]); const feeComponents = await Promise.all( Array.from({ length: Number(componentCount) }, (_, componentIndex) => client.readContract({ address: FACTORY, abi: factoryReads, functionName: "feeComponents", args: [BigInt(componentIndex)], }), ), ); ``` Factory fee getters describe the configuration that a new pool would freeze. To read one existing pool, use its exact `poolId` with the hook recorded for that launch: ```ts theme={null} theme={null} const hookReads = parseAbi([ "function poolConfig(bytes32) view returns (bool initialized,bool tokenIsCurrency0,address currentCreator,address creatorFeeRecipient,uint16 baseFeeBps,uint16 antiSnipeStartTotalBps,uint32 antiSnipeWindowSeconds,uint48 launchTime)", "function poolFeeComponents(bytes32) view returns ((bytes32 componentId,uint8 recipientKind,address configuredRecipient,uint16 feeBps)[] components)", ]); ``` `recipientKind` is `0` for the current creator fee recipient, `1` for the configured platform recipient, `2` for a valid transaction referrer, and `3` for another fixed recipient. Component bps are direct shares of the traded paired-asset amount. The current rows on all three chains are creator `50`, platform `30`, and referrer `20`, which sum to the `100` bps base fee. An absent or invalid referrer component rolls into the platform remainder. For a transaction integration, obtain the complete verified factory ABI from the chain explorer and encode the exact struct it defines. A partial handwritten write ABI is easy to get wrong. `startTickToken0Frame` is the onchain opening-price value for a registered paired asset. The factory handles token ordering and tick spacing when it creates the pool; a launch transaction selects the asset and does not submit a starting tick. ## Atomic launch-buy `createLaunchAndBuy` accepts the ordinary `LaunchParams` plus `LaunchBuyParams(fundingToken, amountIn, minAmountOut, routeData)`. The current browser flow uses native funding, so `fundingToken` is the zero address and the exact transaction value is: ```text theme={null} msg.value = nativeLaunchFee + amountIn ``` The adapter route data and protected minimum output must be prepared from a fresh executable route. The atomic buy pays the normal base fee, waives only the anti-snipe surcharge for that one original-creator purchase, and reverts the complete launch if execution fails. The ordinary `createLaunch` path sends only `nativeLaunchFee`. ## Creator-rights integration For a launch from any current factory, `creatorRights(token)` returns the immutable original creator, current creator, pending creator, current creator fee recipient, pool ID, and whether metadata editing was enabled at launch. `currentCreatorOf(token)` is the compact authorization read used by the active announcement registry. Use `proposeCreatorRightsTransfer` and `acceptCreatorRightsTransfer` for an ordinary two-step wallet transfer. The current creator can cancel a pending transfer or update only the destination for future creator-fee credits with `setCreatorFeeRecipient`. `safeTransferCreatorRights` is for a contract that implements the required receiver callback; do not use it as an ordinary EOA transfer. Creator-rights changes update future announcement authority, optional metadata authority, and future creator-fee credits. They do not move already credited escrow balances, transfer token balances, change supply, grant minting or pause power, or unlock liquidity. Use the factory recorded for each launch because earlier factories do not expose this surface. ## Robinhood and Monad token prediction The current Base, Robinhood and Monad ABIs include the configuration and quote reads above. Add the following ERC-20 factory reads when preparing its fixed-supply ERC-20 deployment: ```ts theme={null} theme={null} const erc20FactoryReads = parseAbi([ "function TOKEN_ADDRESS_SUFFIX() view returns (uint8)", "function launchTokenBytecodeHash((string tokenName,string tokenSymbol,string tokenContractURI,bytes32 creatorSalt,address quoteToken,uint64 expectedConfigVersion,uint64 deadline,bool metadataEditable,string[] metadataKeys,string[] metadataValues) launchParams) view returns (bytes32 bytecodeHash)", ]); ``` Fail closed unless creation is enabled, the selected quote is registered on the selected factory, and the address-suffix constant is `1`. Every current Robinhood or Monad launch must prepare the finalized token metadata first, read `launchTokenBytecodeHash`, and mine a salt whose predicted ERC-20 address ends in `01`. Base B20 addresses can be predicted before signing through the B20 creation formula. Obtain the complete verified active-factory ABI before encoding a write. ## Supported launch inputs The current product inputs are: | Field | Meaning | | -------------------------------- | ------------------------------------------------------------------------------------------------ | | `tokenName`, `tokenSymbol` | Token identity | | `tokenContractURI` | Pinned token metadata URI | | `creatorSalt` | User salt, scoped by factory to the caller | | `quoteToken` | Registered paired-asset address; zero address means native ETH on Base/Robinhood or MON on Monad | | `expectedConfigVersion` | Exact fresh factory version | | `deadline` | Latest allowed chain timestamp | | `metadataEditable` | Whether the creator keeps the limited token-profile editing right | | `metadataKeys`, `metadataValues` | Parallel on-chain metadata arrays | Use the complete verified ABI when encoding `LaunchParams`; this table explains the supported product inputs and is not a replacement for the contract type definition. ## Trading integration Launch pools are ordinary Uniswap v4 pools with a required hook. Use the listed v4 Quoter for price discovery and the Universal Router plus Permit2 for execution. Preserve the exact pool key: sorted currencies, LP fee `0`, launch tick spacing, and the hook address recorded for that launch. `tickSpacing` is part of the exact Uniswap pool identifier and controls valid liquidity range boundaries. The current value `200` represents about 2.02% between allowed boundaries; it does not make swap prices move in fixed 2.02% increments. Use exact-input during the anti-snipe window. Encode optional hook data as the referrer address followed by a `bytes32` comment. Simulate at current timestamp and include slippage and deadline protection. Current pools charge hook fees in the paired asset, including the selected Stock Token for stock-paired markets. ## Failure handling For user launches, treat `StaleConfig` and `LaunchExpired` as refresh-and-rebuild errors. `StaleQuoteRevision` applies to restricted opening-price updates, not to launch submission. Treat quote removal, disabled creation, fee mismatch, invalid `01` suffix, salt reuse, immutability, and single-sided failures as blocking errors that require changed inputs or configuration. Do not silently fall back to another factory, route, or quote. # Introduction Source: https://docs.o1.exchange/launchpad/introduction Create a fixed-supply token with permanent Uniswap v4 liquidity and built-in fee sharing on Base, Robinhood or Monad. Monad (chain `143`) has MON, USDC and WETH registered in its new minimal suite. At block `102277088` on **2026-09-05**, creation was enabled and the configured fee was **100 MON**. Contract deployment does not establish app/API rollout availability. See [Live configuration](/launchpad/reference/live-configuration) before preparing a launch. o1 Launchpad turns a token concept into a live onchain market. Creators configure the token, choose an available paired asset for the selected chain, and launch with permanently locked Uniswap v4 liquidity. Base currently supports ETH, USDC, eight registered Coinbase crypto majors, and ten registered Base Stock Tokens through one launch factory. Robinhood supports ETH, USDG, and 194 registered Robinhood Stock Tokens through one launch factory. Current launches create exactly 1 billion tokens with 18 decimals. Current launches target an opening fully diluted valuation close to USD 4,000. The Uniswap v4 market opens at launch, and its liquidity is permanently locked by the launch contracts. The complete fixed supply seeds the token side of the market without a creator ETH or quote-token deposit. Base and Robinhood launches can pair with supported Stock Tokens. On each chain, crypto-paired and stock-paired launches use the same active factory, hook, and fee contract. Base and Robinhood launches currently pay a 0.001 ETH protocol fee for every paired asset. Monad is configured to charge 100 MON for every paired asset. Network gas is additional. ## Current production model | Property | Current value | | ------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Mainnet deployments | Base (`8453`), Robinhood (`4663`) and Monad (`143`) | | Token type | Native B20 token on Base; fixed-supply ERC-20 on Robinhood and Monad | | Market routes | Crypto and stocks on Base/Robinhood; crypto only on Monad | | Paired assets | Base: ETH, USDC, registered Coinbase crypto majors, and registered Base Stock Tokens; Robinhood: ETH, USDG, and registered Robinhood Stock Tokens; Monad: MON, USDC and WETH | | Supply | 1,000,000,000 tokens, 18 decimals | | Opening FDV | Close to USD 4,000 at the configured opening price | | Pool | A real Uniswap v4 market between the launch token and its selected paired asset | | Liquidity | The complete fixed supply, added without a creator paired-asset deposit | | Lock | Permanent and enforced by the launch contracts | | Base swap fee | 1% in the paired asset | | Fee split | 50% creator, 30% platform, 20% referrer of the base fee | | Anti-snipe | 99% to 1% over 20 seconds on all three chains | | Creation fee | Base/Robinhood: 0.001 ETH; Monad: 100 MON | | Optional at launch | Editable profile information, socials, and other public details | The active contracts and mutable settings were verified onchain on **September 2, 2026** at Base block `50,751,475` and Robinhood block `51,982,726`. Quote registration, decimals, opening frames, revisions, creation-enabled state, native launch fees, and configuration versions were refreshed on **September 5, 2026**, at Base block `50,902,528` and Robinhood block `54,953,301`. Supported assets and other settings may change for future launches, so developers should read the current values before building a transaction. See [Live configuration](/launchpad/reference/live-configuration). ## From token setup to live market Choose the token identity, paired asset, public profile, and profile-editing preference. The launch contracts create 1 billion tokens with no ongoing mint authority. The complete supply is placed into the token's Uniswap v4 pool, permanently locked, and available for trading immediately. Trading fees, referrals, token profile tools, creator announcements, and optional staking become available through the platform. The Uniswap v4 pool is the token's market from launch. Buyers exchange the paired asset for tokens from the locked position. As trading continues, the paired asset accumulates inside the same position and remains part of its permanent liquidity. ## Choose a path Identity, metadata, paired-asset selection, profile control, and the wallet transaction. How supported Base and Robinhood Stock Tokens work as paired assets and fee currencies. Opening-price assumptions, changing pool inventory, and the permanent liquidity lock. Creation fees, the anti-snipe clock, paired-asset swap fees, referrals, and comments. Fund a fixed-epoch reward program or stake wallet-held tokens for time-weighted rewards. Prepare the market, public profile, launch review, and post-launch communication. # Plan your launch Source: https://docs.o1.exchange/launchpad/launch-planning Prepare the token identity, market pair, public profile, launch review, and post-launch communication. o1 Launchpad creates a fixed-supply token and opens its permanent onchain market in one transaction. Before launching, prepare the token identity, select the market pair, decide whether its public profile can be updated, and review the market settings shown by the app. ## Built-in launch options | Option | How it works | Best for | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Paired asset | Choose the chain's native currency, Monad WETH, the supported stablecoin, a registered Coinbase crypto major on Base, or a registered Stock Token on Base or Robinhood | Defining the market pair and the asset used for trading fees and claims | | Profile editing | Optionally let the creator wallet update the token name, symbol, profile link, and extra information | Projects that expect their public profile to evolve | | Fixed profile | Launch without profile editing permission | Projects that want token information fixed from launch | | Social links | Publish website, X, Telegram, description, image, and extra metadata | Token discovery and profile context | | Creator announcements | Post updates through the separate announcement contract | Public milestones and launch communications | | Referral attribution | Attach a valid referrer to a trade | Community and partner growth programs | | Staking | Create a separate, fully funded reward vault after launch | Optional token reward programs | ## A practical launch flow Select the chain and paired asset. Crypto markets use ETH, the chain's supported stablecoin, or a registered Coinbase crypto major on Base, while stock markets use a supported Stock Token. The paired asset determines the market, opening-price configuration, and currency used for swap-fee claims. Choose the name, symbol, image, description, website, and social links that users will see. The image and public profile are stored on IPFS as part of the launch flow. Keep profile information fixed or allow the creator wallet to edit it. This choice never allows new tokens to be created, transfers to be paused, the token to be upgraded, or liquidity to be removed. Confirm the selected pair, fixed supply, opening-price assumption, approximate FDV, permanent liquidity, current creation fee, base swap fee, fee currency, and anti-snipe schedule shown by the application. The current window is 20 seconds on all three chains. Sign from the creator wallet, wait for confirmation, then use the token page and announcement registry to share updates with the community. ## Supply and liquidity Current launches create **1 billion tokens** and place the complete supply into one permanent Uniswap v4 liquidity position. The creator does not deposit the paired asset, cannot remove the position, and cannot mint more tokens later. Tokens enter user wallets through trading. Staking is a separate optional product for tokens already held in a wallet and does not change the launch supply or liquidity position. ## After launch * share the confirmed token address and market link; * use creator announcements for public updates; * monitor trading, holders, liquidity, and claimable fee balances; * use referrals when attributing community trading activity; * optionally create a separate staking vault with its complete reward budget funded in advance. ## Before you launch * verify the selected network and paired asset; * review the token name, symbol, image, description, and public links; * enable profile editing only when ongoing updates are needed; * check the opening-price assumption, approximate FDV, permanent liquidity, current creation fee, fee currency, and fee split; * confirm the creator and referral addresses; * open the final transaction details in the wallet before signing; * publish the confirmed token address and pool after confirmation. # Prepare fee claims Source: https://docs.o1.exchange/launchpad/public-api/reference/claims/prepare-fee-claims /launchpad-api-openapi.yaml post /claims/fees/prepare Verify fee-claim positions and return one independent unsigned transaction per position. # Prepare vesting claims Source: https://docs.o1.exchange/launchpad/public-api/reference/claims/prepare-vesting-claims /launchpad-api-openapi.yaml post /claims/vesting/prepare Verify unlocked vesting positions and return one independent unsigned transaction per position. # Prepare a metadata document update Source: https://docs.o1.exchange/launchpad/public-api/reference/creators/prepare-a-metadata-document-update /launchpad-api-openapi.yaml post /tokens/{chain_id}/{token_address}/metadata/document/prepare Merge and pin token description, image, website, X, or Telegram updates, then return one unsigned contract-URI transaction. # Prepare an announcement Source: https://docs.o1.exchange/launchpad/public-api/reference/creators/prepare-an-announcement /launchpad-api-openapi.yaml post /tokens/{chain_id}/{token_address}/announcements/prepare Verify the launch creator and return an unsigned AnnouncementRegistry transaction. # Prepare an on-chain metadata update Source: https://docs.o1.exchange/launchpad/public-api/reference/creators/prepare-an-on-chain-metadata-update /launchpad-api-openapi.yaml post /tokens/{chain_id}/{token_address}/metadata/onchain/prepare Update the token name, symbol, or one on-chain extra-metadata key. # Prepare a launch Source: https://docs.o1.exchange/launchpad/public-api/reference/launches/prepare-a-launch /launchpad-api-openapi.yaml post /launches/prepare Validate inputs and any current creation-fee requirement, pin metadata, mine an 01 address, simulate against the verified chain snapshot, and return unsigned wallet steps. # Check API health Source: https://docs.o1.exchange/launchpad/public-api/reference/meta/check-api-health /launchpad-api-openapi.yaml get /health Check service availability and the running API build without querying launchpad data. # Get API configuration Source: https://docs.o1.exchange/launchpad/public-api/reference/meta/get-api-configuration /launchpad-api-openapi.yaml get /config Get production suites, contract addresses, quote assets, capabilities, and live creation state for one chain. # Prepare a swap Source: https://docs.o1.exchange/launchpad/public-api/reference/swaps/prepare-a-swap /launchpad-api-openapi.yaml post /swaps/prepare Requote an unmodified quote_id, preserve its reviewed slippage floor, simulate, and return an unsigned Universal Router transaction. # Quote a swap Source: https://docs.o1.exchange/launchpad/public-api/reference/swaps/quote-a-swap /launchpad-api-openapi.yaml post /swaps/quote Get a live exact-input launch-pool quote, minimum output, and any ERC-20 approval or Permit2 signature requirements. The quote expires after 2 minutes. # Get token details Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/get-token-details /launchpad-api-openapi.yaml get /tokens/{chain_id}/{token_address} Get one token's launch data and optionally include its pool, market, allocations, vesting, and recent announcements. # List announcements Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/list-announcements /launchpad-api-openapi.yaml get /tokens/{chain_id}/{token_address}/announcements Page through creator announcements for one tracked launch token. # List creator tokens Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/list-creator-tokens /launchpad-api-openapi.yaml get /creators/{address}/tokens List launches created by one wallet in newest or oldest order. # List token holders Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/list-token-holders /launchpad-api-openapi.yaml get /tokens/{chain_id}/{token_address}/holders Get a provider-backed holder snapshot for one tracked launch token. # List token trades Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/list-token-trades /launchpad-api-openapi.yaml get /tokens/{chain_id}/{token_address}/trades Page through canonical trades for one tracked launch token. Use at most one identity filter per request. # List tokens Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/list-tokens /launchpad-api-openapi.yaml get /tokens Browse launches by market, quote, and indexed ordering with cursor pagination. # Search tokens Source: https://docs.o1.exchange/launchpad/public-api/reference/tokens/search-tokens /launchpad-api-openapi.yaml get /tokens/search Search tracked launches by token address, name, symbol, creator, pool ID, or launch transaction. Matching results use one deterministic liquidity ordering. # Get transaction status Source: https://docs.o1.exchange/launchpad/public-api/reference/transactions/get-transaction-status /launchpad-api-openapi.yaml get /transactions/{chain_id}/{tx_hash} Read indexed status for a wallet-broadcast transaction. Data is null until the transaction is observed. # Get wallet overview Source: https://docs.o1.exchange/launchpad/public-api/reference/wallets/get-wallet-overview /launchpad-api-openapi.yaml get /wallets/{address} Get a compact launchpad overview with the wallet's latest launch, latest activity, and claimable-position flags. # List fee claims Source: https://docs.o1.exchange/launchpad/public-api/reference/wallets/list-fee-claims /launchpad-api-openapi.yaml get /wallets/{address}/fee-claims Page through fee positions for one wallet. # List vesting positions Source: https://docs.o1.exchange/launchpad/public-api/reference/wallets/list-vesting-positions /launchpad-api-openapi.yaml get /wallets/{address}/vesting Page through vesting positions for one beneficiary. # List wallet activity Source: https://docs.o1.exchange/launchpad/public-api/reference/wallets/list-wallet-activity /launchpad-api-openapi.yaml get /wallets/{address}/activity Page through structured public launchpad activity involving one wallet. # Functions and events Source: https://docs.o1.exchange/launchpad/reference/events-functions Public functions, important reads, and events for the current o1 Launchpad contracts. This developer reference summarizes the public contract surface. Use the verified explorer ABI for exact transaction encoding. ## Launch factories Base and Robinhood each use one current launch factory for both crypto-paired and stock-paired creation. The current and historical addresses are linked from [Production contracts](/launchpad/reference/production-contracts), and the complete topology is available in [`launch-contract-suites.json`](/launchpad/reference/launch-contract-suites.json). Event consumers must retain historical factories and use the ABI matching each suite's `contractVersion`. ### Active production factories | Surface | Important members | | ----------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Create | `createLaunch(LaunchParams)` creates and seeds a launch; `createLaunchAndBuy(LaunchParams, LaunchBuyParams)` also executes one protected buy through the configured adapter | | Core configuration | `configVersion`, `launchSupply`, `tickSpacing`, `bandTemplate`, `nativeLaunchFee`, `announcementRegistry`, and `launchBuyAdapter` | | Fee configuration | `baseFeeBps`, `antiSnipeStartTotalBps`, `antiSnipeWindowSeconds`, `feeComponentCount`, indexed `feeComponents(index)`, and `platformFeeRecipient` | | Quote state | `quoteConfig(quote)` and `quoteRevision(quote)` | | Creation state | `launchCreationEnabled`, `priceUpdater`, and `TOKEN_ADDRESS_SUFFIX` | | Transaction safety | `isLaunchSaltUsed(scopedSalt)` plus the fresh `configVersion` supplied in `LaunchParams` | | Quote management | `registerQuote`, `setQuoteStartTick`, and `unregisterQuote`, plus their bounded batch forms with at most 64 entries | | Creator-rights reads | `creatorRights(token)` and `currentCreatorOf(token)` | | Creator self-service | `proposeCreatorRightsTransfer`, `acceptCreatorRightsTransfer`, `cancelCreatorRightsTransfer`, `safeTransferCreatorRights`, and `setCreatorFeeRecipient` | | Creator-rights administration | `creatorAdmin`, `pendingCreatorAdmin`, `adminReassignCreatorRights`, `transferCreatorAdmin`, `acceptCreatorAdmin`, `cancelCreatorAdminTransfer`, and `revokeCreatorAdmin` | | Token metadata | `updateTokenName`, `updateTokenSymbol`, `updateTokenContractURI`, and `updateTokenExtraMetadata` for launches that enabled editing | The current Base, Robinhood and Monad factories do not expose the older `feeDefaults()` aggregate read. Read the named fee getters and enumerate `feeComponents(0..feeComponentCount-1)`. They also replace the older `quotes()` tuple with `quoteConfig()`, use one global `nativeLaunchFee()` for every quote, and use `bandTemplate()` instead of `bands()`. The current fee component rows on all three chains are `CREATOR` at 50 bps, `PLATFORM` at 30 bps, and `REFERRER` at 20 bps. Their sum is the 100 bps base fee. Component bps are direct shares of the trade amount, not percentages that need to be applied to `baseFeeBps` again. ### Chain-specific token deployment Base creates and validates native B20 tokens. Robinhood and Monad call their dedicated `LaunchTokenDeployer` to create immutable ERC-20 tokens. Robinhood and Monad integrations can read `launchTokenBytecodeHash(LaunchParams)` and `TOKEN_ADDRESS_SUFFIX` to prepare a deterministic token address ending in `01` before signing. ### Launch events | Event | Meaning | | ----------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | `Launched` | Token, pool ID, creator, quote, supply, and liquidity spacing | | `NativeLaunchFeePaid` | Creation-fee payer, configured recipient, and native amount | | `LaunchBuyExecuted` | Token, pool, creator, funding token, input amount, output amount, and adapter for an atomic launch-buy | | `QuoteRegistered` / `QuoteUnregistered` | Supported quote changes | | `QuoteStartTickUpdated` | Revision-aware future opening-frame update | | `BandTemplateUpdated` | Future liquidity-range change | | `FeeConfigurationUpdated` / `FeeComponentConfigured` | Future base fee, anti-snipe, and component configuration | | `LaunchSupplyUpdated` / `TickSpacingUpdated` | Future supply or range-alignment change | | `NativeLaunchFeeUpdated` / `LaunchBuyAdapterUpdated` | Future global launch-fee or atomic adapter change | | `ConfigVersionUpdated` / `AnnouncementRegistrySet` | Future launch configuration version or announcement-registry change | | `CreatorRightsTransferProposed` / `CreatorRightsTransferCancelled` / `CreatorRightsTransferred` | Two-step creator-rights transfer history | | `CreatorRightsReassigned` / creator-admin transfer events | Administrative creator-rights reassignment or creator-admin authority changes | | `CreatorFeeRecipientUpdated` | Future creator-fee routing | | `OwnershipTransferStarted` / `OwnershipTransferred` | Governance ownership change | Both active factories additionally emit `PriceUpdaterUpdated` and `LaunchCreationEnabledUpdated`. Historical factories retain their original event names; use the ABI for the exact contract that produced the event. ## LaunchHook The hook exposes `poolConfig(poolId)` and `poolFeeComponents(poolId)` for each launch pool. These reads return the pool's frozen fee and anti-snipe configuration plus its current creator and creator fee recipient. The factory registers and seeds a pool; ordinary trading then occurs through Uniswap v4. | Event | Meaning | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------ | | `PoolRegistered` | The pool's immutable original creator, initial creator fee recipient, and base fee | | `CreatorRightsUpdated` | Current creator and creator fee-recipient changes | | `FeeComponentCredited` | Per-component fee credit, recipient, currency, and amount | | `Seeded` | Token amount placed into the permanent position | | `Trade` | Executor, referrer, fee currency, fee amount, and optional comment; swap direction comes from the matching Uniswap event | `Trade.executor` is the router or callback sender and is not guaranteed to be the trader's wallet. Indexers should derive direction and trader attribution from the complete transaction receipt, including the matching Uniswap swap and router execution context. ## FeeEscrow | Function | Who can call | Result | | -------------------------------- | ------------- | --------------------------------------------------------------------------- | | `owed(recipient, currency)` | Anyone | Returns the raw claimable fee balance | | `claimFor(recipient, currency)` | Anyone | Pays the full balance to the recorded recipient on the current fee contract | | `claimTo(currency, destination)` | Balance owner | Pays the caller's balance to a chosen address | Events: `Credited` and `Claimed`. Earlier launch contracts use their original claim function names. Resolve the fee contract recorded for the launch before encoding a claim. ## AnnouncementRegistry | Function | Who can call | Result | | ----------------------------------------------- | ------------------------ | --------------------------------------------------------- | | `isTokenRegistered(token)` | Anyone | Checks whether the active registry knows the launch token | | `isAnnouncementIdUsed(token, id)` | Anyone | Checks whether an announcement ID was used | | `postAnnouncement(token, id, description, uri)` | Current recorded creator | Publishes a unique announcement | Events: `TokenRegistered` and `AnnouncementPosted`. Earlier launch contracts retain their original `creatorOf`, `usedId`, `post`, `CreatorRegistered`, and `Announcement` surface. ## Robinhood and Monad launch tokens Robinhood and Monad tokens expose standard ERC-20 reads and transfers. When profile editing was enabled at launch, the metadata authority can call `updateName`, `updateSymbol`, `updateContractURI`, and `updateExtraMetadata`. No mint, burn, pause, owner, upgrade, or recovery function exists. Current Robinhood crypto-paired/stock-paired and Monad crypto-paired tokens use the same `LaunchToken` implementation, are created through their chain-specific current factory, and must end in `01`. ## Staking contract One staking contract serves every vault on its chain. The vault creator and complete immutable configuration determine the `vaultId`. | Function | Who can call | Result | | ----------------------------------------------- | -------------- | ------------------------------------------------------------------------------------------------------------ | | `createVault(params, expectedFeeConfigVersion)` | Anyone | Creates and completely funds an immutable vault plus its one-time protocol fee | | `deposit(vaultId, amount)` | Token holder | Transfers staking tokens into a new deposit lot | | `withdraw(vaultId, lotId, amount, to)` | Lot owner | Withdraws one lot amount under the vault's early-exit and forfeiture rules | | `withdrawLots(vaultId, lotIds, amounts, to)` | Lot owner | Atomically withdraws ordered amounts from several lots | | `claim(vaultId, epochs, to)` | Participant | Claims the caller's rewards from ordered completed epochs | | `previewWithdraw` / `previewClaim` | Anyone | Previews one withdrawal or an ordered claim batch | | `deriveVaultId` | Anyone | Derives the vault ID from its creator and complete configuration | | `getVault` | Anyone | Returns immutable configuration, creator, end time, total staked, reward remaining, and deposit-opening time | | `getUserState` / `getLot` / `getUserLots` | Anyone | Returns aggregate principal and paginated deposit-lot state | | `isClaimed` / `epochBounds` | Anyone | Returns claim status and epoch timing | | `feeConfig` | Anyone | Returns the current creation-fee rate, recipient, and change counter | | `setFeeConfig` | Contract owner | Updates only the fee used by future vault creation | | Event | Meaning | | -------------------- | ---------------------------------------------------------------------------------------------- | | `VaultCreated` | Vault ID, creator, assets, schedule, reward budget, exit policy, and fee snapshot | | `Deposited` | Participant, deposit lot, amount, deposit time, and unlock time | | `Withdrawn` | Lot amount, recipient, remaining principal, penalty result, and current-epoch forfeited weight | | `EpochRewardClaimed` | Participant reward paid for one completed epoch | | `FeeConfigUpdated` | New fee rate, recipient, and change counter for later vault creation | Use the verified explorer ABI for exact types and encoding. See the [staking guide](/launchpad/staking/overview) for the reward, withdrawal, and claim rules. ## Common launch errors | Error | Meaning | | ----------------------------------------------------------- | ------------------------------------------------------------------------ | | `StaleConfig` | Refresh the current factory settings and rebuild the transaction | | `LaunchExpired` | Use a fresh deadline | | `QuoteNotRegistered` | The selected quote is unavailable | | `LaunchCreationDisabled` | New launches through the selected factory are currently switched off | | `StaleQuoteRevision` | A paired-asset opening-price update used an outdated quote revision | | `InvalidTokenAddressSuffix` | The prepared token address does not meet that factory's `01` suffix rule | | `LaunchSaltUsed` | Use a new launch identifier | | `InvalidNativeLaunchFeePayment` / `InvalidLaunchBuyPayment` | The native creation fee or combined launch-buy payment was not exact | | `OutOfBounds` / `InvalidConfig` | A hard limit or related-field rule failed | | `NotImmutable` | The created token failed its fixed-authority checks | | `NotSingleSided` | Opening liquidity would require the paired asset | | `LiquidityLocked` | The requested liquidity change is not allowed | | `ExactOutputDisabledDuringAntiSnipe` | Use an input-amount trade or wait until the normal fee begins | | `PartialFillUnsupported` | The requested quote-specified amount could not be filled completely | # Limits and validation Source: https://docs.o1.exchange/launchpad/reference/limits Current launch defaults, contract hard caps, form limits, fee limits, quote requirements, and staking limits. The interface checks launch inputs before the wallet asks for a signature. The contracts enforce the hard caps again onchain. ## Current defaults | Setting | Current value | | -------------------------------- | ----------------------------------------: | | Supply | 1 billion (1,000,000,000) tokens | | Liquidity ranges | 1 | | Base swap fee | 1% | | Starting total fee | 99% | | Anti-snipe period | 20 seconds on all three chains | | Base-fee split | 50% creator / 30% platform / 20% referrer | | Creation fee | Base/Robinhood: 0.001 ETH; Monad: 100 MON | | Launch supply placed in the pool | 100% | ## Contract hard caps | Constraint | Hard limit | | ---------------------------- | --------------------------------------------------------------------------: | | Token supply | 1 million to 1 trillion tokens | | Liquidity ranges | 1 to 10 | | Base swap fee | At most 10% | | Starting total fee | At most 99% | | Fee components | At most 20, including exactly one creator, platform, and referrer component | | Profile authority choice | Fixed profile or editable profile | | Managed quote batch | At most 64 entries | | Atomic launch-buy route data | At most 4,096 bytes | The supply caps assume the launch token's standard 18 decimals. ## Token fields | Field | Interface limit | | ----------------- | ------------------------------------------------- | | Name | 50 characters | | Symbol | 11 characters with no spaces; casing is preserved | | Image | 2 MB; PNG, JPG, WEBP, or GIF | | Website | Valid website URL | | X | Valid X profile URL | | Telegram | Valid Telegram link | | Extra information | Non-empty keys with public values | | Trade comment | 32 UTF-8 bytes | ## Creator profile fields | Field | Interface limit | | ------------ | ---------------------------- | | Display name | 40 characters | | Bio | 180 characters | | Avatar | 2 MB; PNG, JPG, WEBP, or GIF | | Website | Valid website URL | | X | Valid X profile URL | | Telegram | Valid Telegram link | Creator-profile changes use a wallet signature and affect the public o1 profile only. They do not change token permissions, balances, or liquidity. ## Fee and referral rules * every configured fee component must be valid and all component bps must add up exactly to the base fee; the current configuration uses creator, platform, and referrer components; * the starting total fee cannot be lower than the normal base fee; * the anti-snipe period must be longer than zero; * the platform fee receiver must be a valid address; * the o1 interface and Public API reject the trader, original or current creator, current creator fee recipient, platform fee receiver, empty address, and protocol or execution dependencies as referrers; * the hook independently rejects the empty address, the v4 executor, current creator, current creator fee recipient, hook, factory, fee escrow, and PoolManager; direct integrations must apply the broader product restrictions themselves; * the unused referral share goes to the platform. ## Quote requirements Only quote currencies registered by o1 governance can be selected. Quote tokens must behave like standard ERC-20 tokens. Transfer-tax, rebasing, and other non-standard balance behavior is not supported because it can break pool and fee accounting. Base currently has eight registered Coinbase crypto majors and ten registered Stock Tokens from a 13-asset stock catalog. Robinhood has 194 registered Stock Tokens and no crypto-major catalog entries. Monad has MON, USDC and WETH registered, with creation enabled at the dated snapshot. Every token from a current factory must have an address ending in `01`. A managed quote's opening frame must remain aligned with the active tick spacing. Price updates use per-quote revisions so stale writes fail. ## Staking vault limits | Constraint | Staking limit | | ------------------------ | -----------------------------------------------------------------------: | | Epoch duration | 1 to 365 days | | Epoch count | 1 to 50,000 | | Reward per epoch | Greater than zero and no more than the contract's `uint192` amount limit | | Early-withdrawal penalty | 0% to 99.99% | | Pre-deposit window | One epoch before the program starts | | Protocol fee hard cap | 100% of the complete reward budget | When early withdrawal is forbidden, the configured penalty must be zero. When it is allowed, a zero penalty provides a penalty-free early exit. Each deposit creates a separate lot. The interface supports partial withdrawals, withdrawing from several lots together, and claiming multiple completed epochs together. Staking accepts B20 and ERC-20 assets only when their balances change by the exact transferred amount. Fee-on-transfer, rebasing, reflection, and other non-standard balance behavior is unsupported. See the [staking guide](/launchpad/staking/overview) for the complete lifecycle. ## Transaction checks A launch stops when the selected paired asset or creation route is unavailable, the payment is wrong, creation is disabled, the address suffix is invalid, the transaction has expired, protected settings differ from the values the creator reviewed, or the pool cannot open with token-only liquidity. Developers who need the exact encoded caps and field names can use [Functions and events](/launchpad/reference/events-functions) and the [machine-readable production snapshot](/launchpad/reference/production-deployments.json). # Live configuration Source: https://docs.o1.exchange/launchpad/reference/live-configuration Current settings for Base, Robinhood and Monad launches, including supply, opening value, liquidity, and fees. The active contracts and mutable configuration were checked onchain on **September 2, 2026** at Base block `50,751,475` and Robinhood block `51,982,726`. Quote registration, decimals, opening frames, revisions, creation-enabled state, native launch fee, and configuration version were reread on **September 5, 2026** at Base block `50,902,528` and Robinhood block `54,953,301`: 20 of 23 Base catalog entries and all 196 Robinhood entries were registered. ## Current launch settings All three deployed chains use the same fixed-supply and permanent-liquidity model. Their current time and fee settings are also aligned: | Setting | Current value | | --------------------- | ------------------------------------------------------------------------ | | Token supply | 1 billion (1,000,000,000) tokens with 18 decimals | | Opening value | FDV close to USD 4,000 under the quote assumptions below | | Liquidity | One permanent token-side range using the complete fixed supply | | Base swap fee | 1% of the paired-asset amount | | Base-fee distribution | 50% creator, 30% platform, 20% valid referrer | | Anti-snipe fee | Starts at 99% total and decays to 1% over 20 seconds on all three chains | | Fee currency | The pool's selected paired asset | | Creation fee | Base/Robinhood: 0.001 ETH; Monad: 100 MON | The platform share of swap fees goes to `0x1cAa...1C90`, and the restricted opening-price updater is `0x8BF6...5F29` on all three chains. The full addresses are listed in [Production contracts](/launchpad/reference/production-contracts#governance-and-fee-recipient). ## Routes and paired assets | Chain and route | Active factory | Paired assets | Creation fee | | --------------- | ---------------- | ----------------------------------------------------------------------------------- | -----------: | | Base | `0x1176...63dC` | ETH, USDC, 8 registered Coinbase crypto majors, and 10 registered Base Stock Tokens | 0.001 ETH | | Robinhood | `0xcE9C...E5B0d` | ETH, USDG, and 194 registered Robinhood Stock Tokens | 0.001 ETH | | Monad | `0x99C0...5b5b7` | MON, USDC and WETH | 100 MON | Base and Robinhood each share one factory across crypto and stock creation. Monad has one selected crypto factory, with creation enabled at the snapshot. Base has 13 catalogued Stock Tokens, of which ten are currently registered for creation. The Base and Robinhood catalogs are listed in [Stock-paired launches](/launchpad/create/stock-paired-launches). ## Opening assumptions | Paired asset | Current opening reference | | -------------------------------- | ------------------------------------------------------------------- | | ETH, MON or WETH | Asset-specific opening reference maintained for future launches | | USDC or USDG | USD 1 | | Registered Coinbase crypto major | Asset-specific price reference maintained for future Base launches | | Supported Stock Token | Route-specific stock price reference maintained for future launches | Each paired asset is configured to target an opening FDV close to USD 4,000. The actual USD value of an ETH, MON, WETH, crypto-major, or stock-paired launch changes with the paired asset's market price. ## Opening value FDV means token price multiplied by the complete fixed supply: ```text theme={null} opening FDV = opening token price x 1,000,000,000 ``` It is a valuation reference. It is not money raised, paired assets deposited by the creator, or a guaranteed future price. ## Liquidity range The current configuration places the complete fixed supply into one token-side liquidity range beginning at the opening price. The range boundaries use Uniswap's spacing value of `200`, which is about 2.02% between places where a range boundary may be set. This does not make trades or prices move in 2.02% jumps; trading moves continuously through the active liquidity. ## Values that can change Governance may update supply, supported paired assets, opening settings, creation fees, liquidity settings, swap fees, the platform fee receiver, and announcement support for future launches. Every registered paired asset uses per-asset revisions, bounded asset updates, the restricted price updater, and the shared switch for new creation. Integrations should resolve the active factory and read its current values before preparing a transaction. Once a pool opens, its token supply, original creator, paired asset, opening range, fee rates, anti-snipe timing, and permanent liquidity are fixed for that launch. Current creator rights and the destination for future creator-fee credits can change through explicit onchain functions; already credited balances remain with their recorded recipient. Use [`production-deployments.json`](/launchpad/reference/production-deployments.json) for exact machine-readable values and [Production contracts](/launchpad/reference/production-contracts) for explorer-linked addresses. ## Monad snapshot Read on **2026-09-05** at block **102277088**: owner and creator admin `0x5519a8Cc7211F483e19ff8d50A3B0c892701044D`, treasury `0x1cAa1962428382106Eb3f29B9719bdF797621C90`, updater `0x8BF6eb1EaA9bE34a068c56945a36a23520705F29`, configuration version `15`, and creation **enabled**. MON/USDC/WETH are registered with 18/6/18 decimals. Their initial ticks are -87400/-400600/-202400 and all revisions are 1. Governance and fee settings apply to future launches; read the factory again before signing. # Production contracts Source: https://docs.o1.exchange/launchpad/reference/production-contracts Current and historical launch contracts, staking contracts, market readiness, Uniswap v4 dependencies, paired assets, and chain-specific token dependencies. This page lists the current production contracts used for crypto-paired and stock-paired o1 Launchpad tokens on Base, Robinhood Chain and Monad, the historical launch suites that remain authoritative for earlier tokens, and staking on Base and Robinhood. All three chains use the current `launchpad-v4-minimal` contract family and the same launch, fee, creator-rights, permanent-liquidity, and optional atomic Dev Buy model. Monad currently supports crypto quotes only and has creation enabled at its snapshot. The chain-specific token step is the main implementation difference: Base creates and validates a native B20 token, while Robinhood and Monad create a fixed-supply ERC-20 through its dedicated token deployer. The active contracts, reciprocal wiring, creation state, fees, governance, and restricted price updater were verified onchain on **September 2, 2026** at Base block `50,751,475` and Robinhood block `51,982,726`. Quote registration, decimals, opening frames, revisions, creation-enabled state, native launch fee, and configuration version were reread on **September 5, 2026** at Base block `50,902,528` and Robinhood block `54,953,301`: 20 of 23 Base catalog entries and all 196 Robinhood entries were registered. The staking deployment and fee configuration have a separate verification date below. Always confirm the chain ID and active factory before signing. The same-looking address on another chain is not interchangeable. ## Base mainnet Chain ID `8453`. View the network on [Basescan](https://basescan.org). ### Shared crypto-paired and stock-paired launch contracts | Contract | Address | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0x1176122eb77AD6a2339322Cda7C4D7ea9BfA63dC`](https://basescan.org/address/0x1176122eb77AD6a2339322Cda7C4D7ea9BfA63dC) | | Launch Hook | [`0x1f91c998e7c2F4b690D75BDBf6502BDcD6e02AcC`](https://basescan.org/address/0x1f91c998e7c2F4b690D75BDBf6502BDcD6e02AcC) | | Fee Escrow | [`0xB3F11a3fb06A88059b7F7F423Ec0Dda506356866`](https://basescan.org/address/0xB3F11a3fb06A88059b7F7F423Ec0Dda506356866) | | Announcement Registry | [`0xAB1243C97a37361115d5Cef7666bf49AD2Fb6BAa`](https://basescan.org/address/0xAB1243C97a37361115d5Cef7666bf49AD2Fb6BAa) | | B20 Launch Token Validator | [`0x653886f66824E677a5E34c9Cdf8E198519f62A4d`](https://basescan.org/address/0x653886f66824E677a5E34c9Cdf8E198519f62A4d) | | Launch-Buy Adapter | [`0xdAaF9B2C5014c5EdD608060Ed92D62529E37aABC`](https://basescan.org/address/0xdAaF9B2C5014c5EdD608060Ed92D62529E37aABC) | | SwapX Router Proxy | [`0xC3aCE43169bbF51752B1603067F91eF60f8A662A`](https://basescan.org/address/0xC3aCE43169bbF51752B1603067F91eF60f8A662A) | This one factory is active for both crypto-paired and stock-paired creation. ETH, USDC, cbBTC, cbDOGE, cbXRP, cbLTC, cbADA, cbMEGA, cbZEC, cbHYPE, AAPL, AMZN, GOOGL, META, MSFT, MSTR, NVDA, SNDK, SPCX, and TSLA are registered in the same factory. New creation is enabled, the global native launch fee is 0.001 ETH, the anti-snipe window is 20 seconds, and the configured base fee components are creator 50 bps, platform 30 bps, and referrer 20 bps. The current configuration version is `12`. The launch-buy adapter uses the listed SwapX router proxy for the optional atomic Dev Buy. ### Base B20 protocol contracts | Contract | Address | | ------------------- | ----------------------------------------------------------------------------------------------------------------------- | | B20 Factory | [`0xB20f000000000000000000000000000000000000`](https://basescan.org/address/0xB20f000000000000000000000000000000000000) | | Activation Registry | [`0x8453000000000000000000000000000000000001`](https://basescan.org/address/0x8453000000000000000000000000000000000001) | | Policy Registry | [`0x8453000000000000000000000000000000000002`](https://basescan.org/address/0x8453000000000000000000000000000000000002) | The factory checks activation of `keccak256("base.b20_asset")` before every B20 launch. ### Uniswap and paired assets | Contract | Address | | ---------------- | ----------------------------------------------------------------------------------------------------------------------- | | v4 PoolManager | [`0x498581fF718922c3f8e6A244956aF099B2652b2b`](https://basescan.org/address/0x498581fF718922c3f8e6A244956aF099B2652b2b) | | v4 Quoter | [`0x0d5e0F971ED27FBfF6c2837bf31316121532048D`](https://basescan.org/address/0x0d5e0F971ED27FBfF6c2837bf31316121532048D) | | v4 StateView | [`0xA3c0c9b65baD0b08107Aa264b0f3dB444b867A71`](https://basescan.org/address/0xA3c0c9b65baD0b08107Aa264b0f3dB444b867A71) | | Universal Router | [`0x6fF5693b99212Da76ad316178A184AB56D299b43`](https://basescan.org/address/0x6fF5693b99212Da76ad316178A184AB56D299b43) | | Permit2 | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://basescan.org/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) | | Native ETH | `0x0000000000000000000000000000000000000000` | | USDC | [`0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913`](https://basescan.org/address/0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913) | The exact addresses, decimals, opening frames, and revisions for all eight registered Base crypto majors are published in the [machine-readable production snapshot](/launchpad/reference/production-deployments.json). The registered Base stocks are published separately in [`base-stock-quotes.json`](/launchpad/reference/base-stock-quotes.json). ## Robinhood Chain Chain ID `4663`. View the network on [RH-scan](https://rh-scan.com). ### Shared crypto-paired and stock-paired launch contracts | Contract | Address | | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0xcE9C48cFa068947f77738c81Be406B53338E5B0d`](https://rh-scan.com/address/0xcE9C48cFa068947f77738c81Be406B53338E5B0d) | | Launch Hook | [`0x0310cFEbE1D7A69f2414f6595bBe9d17c5342aCc`](https://rh-scan.com/address/0x0310cFEbE1D7A69f2414f6595bBe9d17c5342aCc) | | Fee Escrow | [`0xc5444b417a04a7E1b9C1E327c7D499803c14E5EF`](https://rh-scan.com/address/0xc5444b417a04a7E1b9C1E327c7D499803c14E5EF) | | Launch Token Deployer | [`0xf86dfDb678D8E5d932100Ef479A59fa65a82a5Eb`](https://rh-scan.com/address/0xf86dfDb678D8E5d932100Ef479A59fa65a82a5Eb) | | Announcement Registry | [`0x19C4c024Aca11e4A3d47792C69C80c8f4E596b23`](https://rh-scan.com/address/0x19C4c024Aca11e4A3d47792C69C80c8f4E596b23) | | Launch-Buy Adapter | [`0xF9804FeAB2F9b16EDE0Cd92E5C6e75C5cf64462f`](https://rh-scan.com/address/0xF9804FeAB2F9b16EDE0Cd92E5C6e75C5cf64462f) | | SwapX Router Proxy | [`0x05cDAE36e0CB8Ba1D16BECfe92B9BFd1FE861a93`](https://rh-scan.com/address/0x05cDAE36e0CB8Ba1D16BECfe92B9BFd1FE861a93) | This one factory is active for ETH, USDG, and all 194 registered Robinhood Stock Tokens. New creation is enabled, the global native launch fee is 0.001 ETH for every quote, the anti-snipe window is 20 seconds, and the configured base fee components are creator 50 bps, platform 30 bps, and referrer 20 bps. The current configuration version is `14`. The launch-buy adapter uses the listed SwapX router proxy for the optional atomic Dev Buy. See [Stock-paired launches](/launchpad/create/stock-paired-launches) for every stock address. ### Uniswap and paired assets | Contract | Address | | ---------------- | ---------------------------------------------------------------------------------------------------------------------- | | v4 PoolManager | [`0x8366a39CC670B4001A1121B8F6A443A643e40951`](https://rh-scan.com/address/0x8366a39CC670B4001A1121B8F6A443A643e40951) | | v4 Quoter | [`0x8dc178efb8111bb0973dd9d722ebeff267c98f94`](https://rh-scan.com/address/0x8dc178efb8111bb0973dd9d722ebeff267c98f94) | | v4 StateView | [`0xf3334192d15450cdd385c8b70e03f9a6bd9e673b`](https://rh-scan.com/address/0xf3334192d15450cdd385c8b70e03f9a6bd9e673b) | | Universal Router | [`0x8876789976decbfcbbbe364623c63652db8c0904`](https://rh-scan.com/address/0x8876789976decbfcbbbe364623c63652db8c0904) | | Permit2 | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://rh-scan.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) | | Native ETH | `0x0000000000000000000000000000000000000000` | | USDG | [`0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168`](https://rh-scan.com/address/0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168) | ## Monad mainnet Chain ID `143`. Native currency is **MON**, represented by the zero address; WMON is its routing wrapper, while WETH is a separate ERC-20 paired asset. At block **102277088** on **2026-09-05**, the new minimal suite was deployed and all three quotes were registered, and **launch creation was enabled**. A deployed suite does not establish public app/API availability. ### Crypto-paired launch contracts | Contract | Address | | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | factory | [`0x99C09A90feED8D5e57A19A8C1F103AE29BA5b5b7`](https://monadscan.com/address/0x99C09A90feED8D5e57A19A8C1F103AE29BA5b5b7) | | hook | [`0x8AeA397f75d046fEAF43D2897548f3A18FD92acC`](https://monadscan.com/address/0x8AeA397f75d046fEAF43D2897548f3A18FD92acC) | | feeEscrow | [`0x27BC99240f2c3895Cb91663932D97A29DdD99A93`](https://monadscan.com/address/0x27BC99240f2c3895Cb91663932D97A29DdD99A93) | | launchTokenDeployer | [`0x409EFa96C1c97f0eEC05E530446ad11B84305978`](https://monadscan.com/address/0x409EFa96C1c97f0eEC05E530446ad11B84305978) | | announcementRegistry | [`0xB6E0E2e1C3a7edF66858fE7ef401B5fE26E1B597`](https://monadscan.com/address/0xB6E0E2e1C3a7edF66858fE7ef401B5fE26E1B597) | | launchBuyAdapter | [`0x6961e2F542B4ba40D364fC2B0430230e643Af17E`](https://monadscan.com/address/0x6961e2F542B4ba40D364fC2B0430230e643Af17E) | The suite `monad-mainnet-launchpad-v4-minimal` starts at block `102181199`. It supports the standard crypto route only. The native creation fee is **100 MON**, configuration version `15`. No staking deployment or new-suite vesting is configured. ### Uniswap and paired assets | Contract | Address | | ------------------- | ------------------------------------------------------------------------------------------------------------------------ | | poolManager | [`0x188d586Ddcf52439676Ca21A244753fA19F9Ea8e`](https://monadscan.com/address/0x188d586Ddcf52439676Ca21A244753fA19F9Ea8e) | | quoter | [`0xa222Dd357A9076d1091Ed6Aa2e16C9742dD26891`](https://monadscan.com/address/0xa222Dd357A9076d1091Ed6Aa2e16C9742dD26891) | | stateView | [`0x77395F3b2E73aE90843717371294fa97cC419D64`](https://monadscan.com/address/0x77395F3b2E73aE90843717371294fa97cC419D64) | | universalRouter | [`0x0D97Dc33264bfC1c226207428A79b26757fb9dc3`](https://monadscan.com/address/0x0D97Dc33264bfC1c226207428A79b26757fb9dc3) | | permit2 | [`0x000000000022D473030F116dDEE9F6B43aC78BA3`](https://monadscan.com/address/0x000000000022D473030F116dDEE9F6B43aC78BA3) | | SwapX router | [`0x5911212c0aB0c2C1796D1EB48c750b6820E35dc7`](https://monadscan.com/address/0x5911212c0aB0c2C1796D1EB48c750b6820E35dc7) | | WMON (routing only) | [`0x3bd359C1119dA7Da1D913D1C4D2B7c461115433A`](https://monadscan.com/address/0x3bd359C1119dA7Da1D913D1C4D2B7c461115433A) | | MON (18 decimals) | [`0x0000000000000000000000000000000000000000`](https://monadscan.com/address/0x0000000000000000000000000000000000000000) | | USDC (6 decimals) | [`0x754704Bc059F8C67012fEd69BC8A327a5aafb603`](https://monadscan.com/address/0x754704Bc059F8C67012fEd69BC8A327a5aafb603) | | WETH (18 decimals) | [`0xEE8c0E9f1BFFb4Eb878d8f15f368A02a35481242`](https://monadscan.com/address/0xEE8c0E9f1BFFb4Eb878d8f15f368A02a35481242) | The developer-buy adapter accepts native MON funding, configured Uniswap/Pancake V3 pools and permitted hook-free external ERC-20 V4 pools. The app compares direct routes and, for WETH pairs, a USDC bridge using the reviewed USDC/WETH V4 key. This is bounded route discovery, not every pool on Monad. Aerodrome and external hooked pools are excluded. The final launch pool uses the launch hook. Token-page users can use MON or the paired asset; the public API prepares paired-asset swaps only. Owner and creator admin are `0x5519a8Cc7211F483e19ff8d50A3B0c892701044D`; treasury is `0x1cAa1962428382106Eb3f29B9719bdF797621C90`; updater is `0x8BF6eb1EaA9bE34a068c56945a36a23520705F29`. Both pending governance roles are zero. These live reads do not constitute explorer source verification or a full external-router audit. ## Historical launch suites Historical factories are not selected by the current o1 interface for new creation, but tokens and pools created through them remain valid o1 Launchpad markets. Indexers, bots, terminals, analytics systems, trading integrations, and claim interfaces must retain every suite below. Do not classify an o1 token using only the current factory. The machine-readable [`launch-contract-suites.json`](/launchpad/reference/launch-contract-suites.json) registry contains the same active and historical suite topology. Resolve a launch by its chain ID and originating factory, then use that suite's hook, fee escrow, vesting vault, announcement registry, contract version, and first block. The `historical` label means the suite is no longer selected for new creation by the platform. It does not assert that direct calls to every legacy factory are disabled onchain. ### Base historical suites **Suite ID:** `base-mainnet-block-v1` · **Contract version:** `legacy-block-v1` · **Creation route:** Standard · **First indexed block:** `48,364,845` | Contract | Address | | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0xe3Ab924c72463c1Ac8d1d8352EE640b89eB1EA64`](https://basescan.org/address/0xe3Ab924c72463c1Ac8d1d8352EE640b89eB1EA64) | | Launch Hook | [`0xA068Cf4c52aBDd3479145c4B3cBD8E3d71542a44`](https://basescan.org/address/0xA068Cf4c52aBDd3479145c4B3cBD8E3d71542a44) | | Fee Escrow | [`0xabE87e4af23dAFad0A170Aa900d574c03D904597`](https://basescan.org/address/0xabE87e4af23dAFad0A170Aa900d574c03D904597) | | Vesting Vault | [`0xD6c4721eC7c0aAc8B57B3eA2a9698e288371E30e`](https://basescan.org/address/0xD6c4721eC7c0aAc8B57B3eA2a9698e288371E30e) | | Announcement Registry | [`0xa6Bb57ABD6d26cF862e6AAb84f2BcD51210a060E`](https://basescan.org/address/0xa6Bb57ABD6d26cF862e6AAb84f2BcD51210a060E) | **Suite ID:** `base-mainnet-timestamp-v2` · **Contract version:** `quote-timestamp-v2` · **Creation route:** Standard · **First indexed block:** `48,451,098` | Contract | Address | | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0xa52ad458cE0282a971ecC71C051A32f28946bb9F`](https://basescan.org/address/0xa52ad458cE0282a971ecC71C051A32f28946bb9F) | | Launch Hook | [`0x985C14BAa2a18316ffdA0aeFB3a632fAdfcA2AcC`](https://basescan.org/address/0x985C14BAa2a18316ffdA0aeFB3a632fAdfcA2AcC) | | Fee Escrow | [`0xa2cBD9065cec93c443CAFb0837A62800EE7C4A84`](https://basescan.org/address/0xa2cBD9065cec93c443CAFb0837A62800EE7C4A84) | | Vesting Vault | [`0x3beeA54dB87A632A5FAF20dB6765D3af94c81b31`](https://basescan.org/address/0x3beeA54dB87A632A5FAF20dB6765D3af94c81b31) | | Announcement Registry | [`0xABDcBE060724b9BEf5A2daad017d9eA3Ed72DE28`](https://basescan.org/address/0xABDcBE060724b9BEf5A2daad017d9eA3Ed72DE28) | **Suite ID:** `base-mainnet-rwa-timestamp-v3` · **Contract version:** `rwa-quote-updater-v3` · **Creation route:** Stock-paired · **First indexed block:** `49,121,014` | Contract | Address | | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0x1dE58A6769526a03a504d9d59B8757CD8097Dc57`](https://basescan.org/address/0x1dE58A6769526a03a504d9d59B8757CD8097Dc57) | | Launch Hook | [`0xbCA7774615c74b7991a111f1C7b2D0eFeA61AAcc`](https://basescan.org/address/0xbCA7774615c74b7991a111f1C7b2D0eFeA61AAcc) | | Fee Escrow | [`0xCF9ed8f4145eac9059Bcd83227eEb8591FaC0A9a`](https://basescan.org/address/0xCF9ed8f4145eac9059Bcd83227eEb8591FaC0A9a) | | Vesting Vault | [`0x6Ad89089E3ff684F875722D75e5CF24499aa7F35`](https://basescan.org/address/0x6Ad89089E3ff684F875722D75e5CF24499aa7F35) | | Announcement Registry | [`0x4fA46c840dF1d11b20750C08390f7daBfe0e1CCa`](https://basescan.org/address/0x4fA46c840dF1d11b20750C08390f7daBfe0e1CCa) | **Suite ID:** `base-mainnet-rwa-timestamp-v4` · **Contract version:** `rwa-quote-updater-v3` · **Creation route:** Stock-paired · **First indexed block:** `50,137,081` | Contract | Address | | --------------------- | ----------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0xFf70918Ef17A2D74d683a8297813B177BaFaD1f4`](https://basescan.org/address/0xFf70918Ef17A2D74d683a8297813B177BaFaD1f4) | | Launch Hook | [`0x3b2b979DF21036CEe51B8debB13100e2CB8DeaCC`](https://basescan.org/address/0x3b2b979DF21036CEe51B8debB13100e2CB8DeaCC) | | Fee Escrow | [`0x1D8c991A9019df7D72ADCd8deA6f12D600C9d02f`](https://basescan.org/address/0x1D8c991A9019df7D72ADCd8deA6f12D600C9d02f) | | Vesting Vault | [`0x9Ab963FB1De707a36a9f843c9E6eF596C9DCa2f3`](https://basescan.org/address/0x9Ab963FB1De707a36a9f843c9E6eF596C9DCa2f3) | | Announcement Registry | [`0x7CE9C6D4d0DcE30895E5e35798954947071029c0`](https://basescan.org/address/0x7CE9C6D4d0DcE30895E5e35798954947071029c0) | ### Robinhood historical suites **Suite ID:** `robinhood-block-v1` · **Contract version:** `legacy-block-v1` · **Creation route:** Standard · **First indexed block:** `2,131,131` | Contract | Address | | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0x8B40fc20c405d47D725c9723D056a1c6f62BBccf`](https://rh-scan.com/address/0x8B40fc20c405d47D725c9723D056a1c6f62BBccf) | | Launch Hook | [`0xe960E6C80C74cFDF03c91E7AF4e1F5f53f096a44`](https://rh-scan.com/address/0xe960E6C80C74cFDF03c91E7AF4e1F5f53f096a44) | | Fee Escrow | [`0xF5681c4C0dC0c2e32C9d127b3cc0Fc992B584553`](https://rh-scan.com/address/0xF5681c4C0dC0c2e32C9d127b3cc0Fc992B584553) | | Vesting Vault | [`0x9e70276922aCC214C468ad4699eA73206b8BA286`](https://rh-scan.com/address/0x9e70276922aCC214C468ad4699eA73206b8BA286) | | Announcement Registry | [`0x6bA99e83EC4925D55A32cA48C693F04d02C16758`](https://rh-scan.com/address/0x6bA99e83EC4925D55A32cA48C693F04d02C16758) | **Suite ID:** `robinhood-block-v2` · **Contract version:** `legacy-block-v1` · **Creation route:** Standard · **First indexed block:** `4,415,287` | Contract | Address | | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0x76f0923Ac4dF0A079A10F628A7bcE6426CCd344A`](https://rh-scan.com/address/0x76f0923Ac4dF0A079A10F628A7bcE6426CCd344A) | | Launch Hook | [`0xca4b035a5DBFa2a00fC5dcb08fD1c5A22d0eAA44`](https://rh-scan.com/address/0xca4b035a5DBFa2a00fC5dcb08fD1c5A22d0eAA44) | | Fee Escrow | [`0x00D5701a92794c3744428B62646E7bC4e77A0A9A`](https://rh-scan.com/address/0x00D5701a92794c3744428B62646E7bC4e77A0A9A) | | Vesting Vault | [`0x121962Ebf01a2E7e8f0e81792e90B8F222D29016`](https://rh-scan.com/address/0x121962Ebf01a2E7e8f0e81792e90B8F222D29016) | | Announcement Registry | [`0xF28620D32DB0856d60c3F95536FCa36D0B35fcF0`](https://rh-scan.com/address/0xF28620D32DB0856d60c3F95536FCa36D0B35fcF0) | **Suite ID:** `robinhood-timestamp-v3` · **Contract version:** `quote-timestamp-v2` · **Creation route:** Standard · **First indexed block:** `6,131,279` | Contract | Address | | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0x411F21283D3E492BC395027329e08f9F4F560Ba5`](https://rh-scan.com/address/0x411F21283D3E492BC395027329e08f9F4F560Ba5) | | Launch Hook | [`0x441F773B3bb1Ed4c6457D0528624112e43C02acc`](https://rh-scan.com/address/0x441F773B3bb1Ed4c6457D0528624112e43C02acc) | | Fee Escrow | [`0x32f7a9A05bD62487D085Ad494e14Ec42543e19d2`](https://rh-scan.com/address/0x32f7a9A05bD62487D085Ad494e14Ec42543e19d2) | | Vesting Vault | [`0x6bdAAe32F36da5896533fdAD5b7A72a2541063BE`](https://rh-scan.com/address/0x6bdAAe32F36da5896533fdAD5b7A72a2541063BE) | | Announcement Registry | [`0x163f3A09278918bDdaf74cF2a4178F6369a9a3c1`](https://rh-scan.com/address/0x163f3A09278918bDdaf74cF2a4178F6369a9a3c1) | **Suite ID:** `robinhood-rwa-timestamp-v4` · **Contract version:** `rwa-quote-updater-v3` · **Creation route:** Stock-paired · **First indexed block:** `18,487,505` | Contract | Address | | --------------------- | ---------------------------------------------------------------------------------------------------------------------- | | Launch Factory | [`0xe64AC4113848BBC1a6dDE1A6D1da96720A36F297`](https://rh-scan.com/address/0xe64AC4113848BBC1a6dDE1A6D1da96720A36F297) | | Launch Hook | [`0x778b0c4EeA7D35D66513B587bA87FC9084b0EaCC`](https://rh-scan.com/address/0x778b0c4EeA7D35D66513B587bA87FC9084b0EaCC) | | Fee Escrow | [`0x4f2b1cDa8748CD64C56039bf5E2e54bC13D4A3d7`](https://rh-scan.com/address/0x4f2b1cDa8748CD64C56039bf5E2e54bC13D4A3d7) | | Vesting Vault | [`0xCF9ed8f4145eac9059Bcd83227eEb8591FaC0A9a`](https://rh-scan.com/address/0xCF9ed8f4145eac9059Bcd83227eEb8591FaC0A9a) | | Announcement Registry | [`0x6a95911db04219674323AA0137c3377523c0E29F`](https://rh-scan.com/address/0x6a95911db04219674323AA0137c3377523c0E29F) | The current Base, Robinhood and Monad suites are listed earlier on this page and are also included in the machine-readable registry. Historical suite contracts continue to govern their own launches, fee claims, vesting, and announcements where those capabilities exist. ### Historical Monad suite The previous `monad-mainnet-timestamp-v1` suite remains authoritative for its existing tokens. Its first block is `94019515`; it is not selected for new creation. | Contract | Address | | -------------------- | ------------------------------------------------------------------------------------------------------------------------ | | factory | [`0x54668d06C538c44Fa08558283497a1B6685AF596`](https://monadscan.com/address/0x54668d06C538c44Fa08558283497a1B6685AF596) | | hook | [`0xF281561d2f667f9277d3b4D8553EffEE81206Acc`](https://monadscan.com/address/0xF281561d2f667f9277d3b4D8553EffEE81206Acc) | | feeEscrow | [`0xD1F7FAC02b2A6af030cf7e9B23B7E9b7ffe31595`](https://monadscan.com/address/0xD1F7FAC02b2A6af030cf7e9B23B7E9b7ffe31595) | | vestingVault | [`0x4e46C7f10A15eb1B98d70A7df0C9aDA8a00648E1`](https://monadscan.com/address/0x4e46C7f10A15eb1B98d70A7df0C9aDA8a00648E1) | | announcementRegistry | [`0xD65A370D8D224DD33706d71A46A4f8c365Fc4b16`](https://monadscan.com/address/0xD65A370D8D224DD33706d71A46A4f8c365Fc4b16) | Use this suite's original ABI and addresses for its fees, vesting and announcements. ## Staking The staking contract is deployed at the same address on Base and Robinhood. Vault state, balances, and claims remain independent on each chain. | Chain | Contract | Address | | ------------------------ | ---------------- | ----------------------------------------------------------------------------------------------------------------------- | | Base mainnet (`8453`) | Staking contract | [`0x6f25a9e1e677616c1bF7ab54b470b0c82839Adb4`](https://basescan.org/address/0x6f25a9e1e677616c1bF7ab54b470b0c82839Adb4) | | Robinhood Chain (`4663`) | Staking contract | [`0x6f25a9e1e677616c1bF7ab54b470b0c82839Adb4`](https://rh-scan.com/address/0x6f25a9e1e677616c1bF7ab54b470b0c82839Adb4) | The following mutable staking configuration is the same on both networks and was verified onchain on **August 19, 2026**: | Setting | Value | | --------------------- | ---------------------------------------------- | | One-time protocol fee | 50% of the complete reward budget (`5000` bps) | | Fee recipient | `0xDB781755E8fFaD2d6CBa99a9FAd06C1c79587957` | | Contract owner | `0xDB781755E8fFaD2d6CBa99a9FAd06C1c79587957` | The fee is added to the vault's reward budget and paid in the selected reward currency when the vault is created. The owner can update the fee rate and recipient for future vault creation, up to the contract's 100% hard cap. If the configuration changes between review and submission, creation stops so the creator can review the updated amount. Fee changes cannot alter an existing vault, withdraw its accounted principal or rewards, or affect participant claims. There is one separately deployed staking contract on each supported chain. Individual vaults are records inside that contract, not separate deployments. See the [staking guide](/launchpad/staking/overview) for the complete user flow. ## Governance and fee recipient These addresses match across Base, Robinhood and Monad at their respective verification blocks. `0x5519a8Cc7211F483e19ff8d50A3B0c892701044D` [Base explorer](https://basescan.org/address/0x5519a8Cc7211F483e19ff8d50A3B0c892701044D) · [Robinhood explorer](https://rh-scan.com/address/0x5519a8Cc7211F483e19ff8d50A3B0c892701044D) · [Monad explorer](https://monadscan.com/address/0x5519a8Cc7211F483e19ff8d50A3B0c892701044D) `0x1cAa1962428382106Eb3f29B9719bdF797621C90` [Base explorer](https://basescan.org/address/0x1cAa1962428382106Eb3f29B9719bdF797621C90) · [Robinhood explorer](https://rh-scan.com/address/0x1cAa1962428382106Eb3f29B9719bdF797621C90) · [Monad explorer](https://monadscan.com/address/0x1cAa1962428382106Eb3f29B9719bdF797621C90) `0x8BF6eb1EaA9bE34a068c56945a36a23520705F29` [Base explorer](https://basescan.org/address/0x8BF6eb1EaA9bE34a068c56945a36a23520705F29) · [Robinhood explorer](https://rh-scan.com/address/0x8BF6eb1EaA9bE34a068c56945a36a23520705F29) · [Monad explorer](https://monadscan.com/address/0x8BF6eb1EaA9bE34a068c56945a36a23520705F29) The current owner controls configuration for future launches, and the creator admin may immediately reassign creator rights without gaining token or liquidity custody. The platform fee receiver receives the platform share of swap fees and the configured native launch fee. The restricted price updater can change only the opening frame of an already registered quote for future launches. None of these roles can modify a completed token or remove its liquidity. ## Verification links Each address links to its chain explorer. Base's native B20 addresses are also defined in the [Base B20 specification](https://docs.base.org/base-chain/specs/upgrades/beryl/b20), and the Uniswap addresses match the [official Uniswap v4 deployment list](https://developers.uniswap.org/docs/protocols/v4/deployments). See the [machine-readable deployment snapshot](/launchpad/reference/production-deployments.json) for normalized contract addresses and current launch configuration values. The staking deployment and its dated live fee configuration are listed above. # Security and audit Source: https://docs.o1.exchange/launchpad/security Launchpad audit reports, production safety properties, stock-paired route boundaries, governance controls, and verification guidance. o1 Launchpad is designed around fixed token supply, token-only opening liquidity, permanent Uniswap v4 liquidity, and transparent fee accounting. Independent review of the Launchpad v4 contracts and atomic Dev Buy architecture dated August 28, 2026. Independent review of the preceding Launchpad contract architecture dated June 29, 2026. Independent review of the Launchpad staking feature dated August 10, 2026. Inspect the current Base, Robinhood and Monad addresses on their chain explorers. Review vault funding, time-weighted rewards, withdrawals, penalties, and claims. ## Audit results XORS completed an additional independent review of the Launchpad v4 contracts, dated August 28, 2026, covering commit `1d22cfa`. It covers the rewritten atomic launch-and-buy adapter architecture, B20 launch-token validation, Hook fee and anti-snipe behavior, Factory creation, and creator-rights controls. The report contains no Critical findings. It records one High, one Medium, and seven Low findings; seven are marked Resolved and two Low findings remain Open. The High and Medium findings concern trusted governance roles and are accepted under the report's multisig or timelock custody assumptions. The earlier independent o1 Launchpad contract review dated June 29, 2026 covers the preceding Launchpad architecture. It records seven Low findings and no Critical, High, or Medium findings, with the status of each finding documented in the report. Reviewed areas include launch initialization, governance and fee-recipient trust, referral protection, configuration changes, optional profile authority, opening-price bounds, and opening-window trading behavior. XORS also completed an independent review of the Launchpad staking feature dated August 10, 2026. This feature enables tokens created through o1 Launchpad to be used in staking vaults. The report records one High, four Medium, and two Low findings, with no Critical findings, and marks all seven findings Resolved. See the [staking guide](/launchpad/staking/overview) for the current product flow and contract boundaries. Each report should be read according to its date, reviewed source revision, platform, and stated scope. Source review does not independently verify a specific deployment or live configuration. ## Core safety properties * launch tokens have fixed supply and no mint, pause, upgrade, or balance-seizure authority; * opening liquidity uses launch tokens only, requires no creator paired-asset deposit, and stays in a hook-owned position that cannot be removed; * swap-fee balances are backed by Uniswap v4 claims until withdrawn, and all recipient credits add up to the charged fee; * creator rights are project-side authority only: they cover transfer of creator rights, future creator-fee routing, announcements, and optional profile editing, but never minting, balance control, upgrades, or liquidity custody; * the configured creator admin can immediately reassign creator rights and future creator-fee routing, but receives no token, balance, or liquidity authority; * a pending launch stops if a protected global setting changes before it confirms; paired-asset opening-price refreshes intentionally use the latest registered frame; * private keys and transaction signing remain in the user's wallet. ## Managed paired-asset safety boundaries The managed factory used by both crypto-paired and stock-paired creation preserves the same immutable token, single-sided seed, permanent lock, fee escrow, and announcement boundaries. It adds: * a paired-asset registry; on each chain, one active factory and hook serve both crypto-paired and stock-paired creation while each launch freezes its exact asset and market configuration; * per-quote revisions so an older paired-asset opening-price update cannot overwrite a newer one; * a restricted updater that can change only future opening-price frames; * a 64-item batch limit for quote-management operations; * an `01` address-suffix requirement for every launch through either active factory; * a creation switch that affects new launches through that factory only and does not pause existing markets. On each chain, the shared factory switch covers both crypto-paired and stock-paired creation. The paired Stock Tokens are external onchain assets. Their issuer, transfer behavior, availability, and market value are separate from the launch token and the o1 liquidity lock. The optional atomic Dev Buy has an additional adapter boundary. Only the configured launch hook may call it. The adapter validates the funding asset, connected route, permitted external venues, exact final launch pool and hook, four-hop maximum, protected minimum output, and unchanged unexpected route-asset and native-currency balances in the adapter and SwapX router. Base, Robinhood and Monad use chain-specific venue configuration, so a route supported on one chain is not automatically valid on another. A failed adapter check reverts the launch and buy together. ## Governance boundary Governance can update defaults for future launches only. A completed launch keeps its token supply, pool, fee component rates, fixed recipients, and permanent liquidity. The current creator-fee recipient is the documented exception for future creator credits. See [Configuration and governance](/launchpad/architecture/deployment-governance) for the complete boundary. The current governance owner and platform fee receiver are listed in [Production contracts](/launchpad/reference/production-contracts#governance-and-fee-recipient). ## What users and integrators should verify * use the current factory and contract addresses for the selected chain; * confirm the wallet is connected to the intended chain; * review current supply, paired asset, market type, opening value, creation fee, swap fee currency, and fee split; * inspect holders, pool liquidity, and a current sell quote before trading; * review the chain, contract, amounts, and wallet transaction details before signing. To report a potential issue, follow the [o1 Exchange bug bounty guidance](/community/bug-bounty). # How it works Source: https://docs.o1.exchange/launchpad/staking/overview Create or join a staking vault, understand its schedule and rewards, and know what happens when you withdraw or claim. Staking lets anyone create a fixed-schedule reward vault for a compatible token. This includes B20 tokens on Base and standard ERC-20 tokens on other supported networks. Staking is separate from token creation and Uniswap liquidity: launching a token does not create a staking vault, and creating a vault does not change the token, its supply, or its market. Tokens created through o1 Launchpad can be staked after users buy or otherwise receive them in a wallet. Vault creation is permissionless, so the vault creator does not have to be the token creator. The creator funds the complete reward budget when the vault is created. Each completed epoch is shared according to how many tokens each participant staked and for how long. Every deposit has its own earning start, unlock time, and remaining principal. The assets, schedule, rewards, and withdrawal policy cannot be changed or cancelled after creation. ## Supported networks and assets | Property | Support | | --------------- | ----------------------------------------------------------------------------------------------- | | Networks | Base mainnet (`8453`) and Robinhood Chain (`4663`) | | Staking token | Base: B20 or standard ERC-20; Robinhood: standard ERC-20 | | Reward currency | Native ETH or a compatible token on the selected network; it may be the same token being staked | | Vault creator | Any wallet; launch ownership is not required | The staking contract uses the same address on both networks, but vaults and balances remain independent on each network. See [Production contracts](/launchpad/reference/production-contracts#staking) for the address and current fee configuration. Vaults are permissionless. Before staking, verify the network, creator, staking token, reward currency, schedule, and withdrawal policy shown on the vault page. ## Relationship to a token launch Staking is an optional use for wallet-held tokens and does not replace the launch pool: * permanent Uniswap liquidity stays in the launch pool; * tokens bought or otherwise received in a wallet can be staked; * creating a vault does not change the token supply, permissions, or launch configuration. ## Create a vault Select the compatible B20 or ERC-20 token participants will stake and the asset they will earn. Rewards may use native ETH, another compatible token, or the staking token itself. Choose a future start time in UTC, an epoch duration from 1 to 365 days, 1 to 50,000 epochs, and a fixed reward amount for each epoch. Early withdrawals can be forbidden or allowed with a fixed penalty from 0% to 99.99%. The interface shows when deposits open, the program start and end, the complete reward budget, the current one-time protocol fee, and the total amount due. A native-reward vault is funded in the creation transaction. When rewards use a token, an approval is needed first if the existing allowance is too low, followed by the creation transaction. ### Funding and fixed terms ```text theme={null} reward budget = reward per epoch × number of epochs total due = reward budget + one-time protocol fee ``` The fee is charged in the selected reward currency. The interface refreshes it before submission, and creation stops for another review if the fee configuration changed. Creating a vault permanently commits its configuration and funding. The creator cannot cancel it or recover rewards left by empty epochs, rounding, or unclaimed entitlements. ## Stake tokens Open **Staking** from the Launchpad navigation or product switcher. You can browse the selected network or search by an exact staking-token address or vault ID. Wallet also provides a **Stake** shortcut for known Launchpad token holdings. Check the creator, staking token, reward currency, schedule, rewards, total staked, and withdrawal policy. If the staking contract does not already have enough allowance, approve the deposit amount first. The deposit transaction then creates a new lot and shows its expected unlock time. ### Deposit timing Deposits open one epoch before the program starts and remain open until the program ends. | Deposit time | Earning begins | Unlock time | | ------------------------- | -------------------- | ----------------------------------------------------------- | | Before the program starts | At the program start | One epoch after the start, unless the program ends sooner | | During an active epoch | At the deposit time | One epoch after the deposit, unless the program ends sooner | | During the final epoch | At the deposit time | At the program end | Every deposit remains a separate lot. You can make multiple deposits, partially withdraw a lot, or withdraw from several lots together. Principal that remains deposited continues into later epochs. ## How rewards are calculated Rewards are based on both amount and time. For each completed epoch: ```text theme={null} your reward = epoch reward × your weight ÷ total weight ``` Depositing earlier gives that amount more weight than depositing later, and a larger deposit has more weight when held for the same time. The vault does not quote a guaranteed APR or APY because each participant's share depends on the total stake during the epoch. Principal continues into later epochs while it remains deposited. Rewards are claimed separately and are not automatically added to principal. ## Withdraw principal The vault page lets you select one or more deposit lots, choose full or partial amounts, and preview the penalty and net amount before signing. | Situation | Result | | ----------------------------------------- | ------------------------------------------------- | | Before unlock, early withdrawal forbidden | The lot cannot be withdrawn | | Before unlock, early withdrawal allowed | The configured penalty is deducted from principal | | At or after unlock | No early-withdrawal penalty | | After the program ends | Principal is unlocked | Withdrawing during an active epoch forfeits the current epoch's reward for the amount withdrawn, even when that lot is already unlocked. Rewards from earlier completed epochs remain claimable. ## Claim rewards Rewards become claimable after each epoch ends. The interface shows completed, unclaimed epochs, previews the combined reward, and can claim multiple epochs in one transaction. * epochs do not have to be claimed in order; * each epoch can be claimed once per wallet; * claims do not expire; * withdrawing principal does not remove rewards earned in earlier completed epochs. ## Vault status and activity | Status | Meaning | | ----------- | --------------------------------------------------------------------- | | Scheduled | The vault exists, but deposits are not open yet | | Pre-deposit | Deposits are open; rewards begin at the program start | | Live | The reward program is active and deposits remain open | | Ended | Deposits are closed; principal and completed rewards remain available | After confirmation, vault creation, deposits, withdrawals, and claims appear in the staking pages and Wallet Activity. A short indexing delay may occur while the interface catches up with the confirmed transaction. ## Important considerations Staking supports B20 tokens on Base and standard ERC-20 tokens on both networks when they use normal balance, transfer, and approval behavior. Fee-on-transfer, rebasing, reflection, and similar non-standard tokens are not supported. Tokens with their own pause, blocklist, or upgrade controls can also affect whether users are able to deposit or withdraw. The staking contract owner can update the protocol fee and fee recipient for future vault creation. The owner cannot change or cancel an existing vault or withdraw its accounted principal and rewards. Verify the staking address and current fee configuration on each production network. Review the direct contract surface for vault creation, deposits, withdrawals, and claims. See the contract and interface limits applied to staking vaults. Read the independent staking audit and the platform's verification guidance. ## Monad The Monad launch integration does not include a staking deployment. Staking remains limited to the configured Base and Robinhood deployments; do not reuse those addresses on Monad. # Fee claims Source: https://docs.o1.exchange/launchpad/trading/claims View and claim creator, platform, and referral fee balances. Swap fees remain available until they are claimed. One inactive recipient cannot block swaps, launches, or anyone else's claim. ## Fee claims The connected wallet's Profile page groups available balances by paired asset, including ETH, USDC, USDG, supported Coinbase crypto majors, and supported Stock Tokens. Its **Claim** action always pays the recorded recipient. | Contract option | Who may start it | Destination | | ------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------- | ------------------------------- | | `claimFor` on a current fee contract, or the equivalent function on the fee contract recorded for an earlier launch | Anyone | Always the recorded recipient | | `claimTo` | The balance owner through a direct contract interaction | An address chosen by that owner | Claims pay the same paired asset used by the launch market. A USDC market pays USDC fees, a USDG market pays USDG fees, an ETH market pays ETH fees, a crypto-major market pays its selected Coinbase asset, and a stock-paired market pays its selected Stock Token. ## Profile overview The connected Profile page groups: * claimable hook-fee balances by asset; * referral activity and attributed trades; * the wallet's launches and supported management tools. Creator and referral earnings are claimed from **Profile > Fees**. **Profile > Referrals** shows attributed trade counts, hook-fee volume, and recent referral activity; it is not the claimable-balance view. Wallet Activity shows indexed claim transactions. Profile views may briefly sync after confirmation; the contracts remain authoritative. ## Currency handling The app claims native ETH (Base/Robinhood) or MON (Monad) directly to the destination. The app claims the exact ERC-20 used by that launch pool. This can be USDC, USDG, or a supported Stock Token. Developers should use the pool's recorded quote address and can verify current assets in [Production contracts](/launchpad/reference/production-contracts) and [Stock-paired launches](/launchpad/create/stock-paired-launches). Developers can find the exact read and claim functions in [Functions and events](/launchpad/reference/events-functions). # Fees, anti-snipe, and referrals Source: https://docs.o1.exchange/launchpad/trading/fees-referrals Creation fees, paired-asset swap fees, the opening anti-snipe period, referral links, attribution rules, and trade comments. Every launch pays the current global native creation fee, and every swap pays a fee in the pool's paired asset. Swap fees become claimable by the creator, platform, and valid referrer. ## Creation fees | Chain and route | Paired assets | Current creation fee | | ------------------------------------ | ------------------------------------------------------------------------------- | -------------------: | | Base | ETH, USDC, a registered Coinbase crypto major, or a registered Base Stock Token | 0.001 ETH | | Robinhood | ETH, USDG, or a registered Robinhood Stock Token | 0.001 ETH | | Monad (creation enabled at snapshot) | MON, USDC or WETH | 100 MON | The creator also pays the network gas required to confirm the launch transaction. Each active factory uses one global native fee for every quote, so Base/Robinhood launches send 0.001 ETH and Monad launches send 100 MON, regardless of their selected paired asset. A USDG-paired Robinhood launch does not pay its creation fee in USDG. Creation fees are mutable settings for future launches. Read the active factory immediately before preparing a transaction. ## Normal swap fee The normal swap fee is **1% of the paired-asset amount**. With a valid referrer, that 1% is divided as follows: | Recipient | Share of the 1% fee | Equivalent share of the trade | | --------- | ------------------: | ----------------------------: | | Creator | 50% | 0.5% | | Platform | 30% | 0.3% | | Referrer | 20% | 0.2% | If a trade has no valid referrer, the unused 0.2% referral share goes to the platform. Fees are always denominated in the selected paired asset: * an ETH market charges ETH; * a USDC market charges USDC; * a USDG market charges USDG; * a stock-paired market charges its selected Stock Token. For a stock-paired buy, the fee comes from the Stock Token paid. For a stock-paired sell, the fee comes from the Stock Token received. ## Opening anti-snipe period Trading remains open when the pool launches. The total fee starts at 99% and decreases linearly to the normal 1% fee. All three chains use a 20-second window. The schedule on all three chains is: | Time since launch | Approximate total fee | | -------------------: | --------------------: | | At launch | 99% | | 5 seconds | 74.5% | | 10 seconds | 50% | | 15 seconds | 25.5% | | 20 seconds and later | 1% | The creator and referrer shares are calculated from the normal 1% fee. The temporary amount above 1% is the anti-snipe surcharge and goes to the platform. The optional atomic Dev Buy is the only launch-time exception. It pays the normal 1% base fee but not the anti-snipe surcharge. The toggle is off by default, the exemption can be used only inside that launch transaction, and every later buy follows the schedule above. o1 uses input-amount swaps: traders enter how much they want to spend or sell, and those swaps remain available throughout the opening period. Direct integrations that request an exact output are rejected until the fee reaches 1%. ## Get a referral link o1 provides two types of referral links: | Link | Where to copy it | When it applies | | --------------- | -------------------------------------------------------------------- | ------------------------------------------------- | | Global referral | Open your profile and select **Referral** | Used as your general referral across o1 Launchpad | | Token referral | Open a token page, connect your wallet, and select **Referral link** | Applies first to that token on that chain | The **Profile** link on a profile page is only a public profile link. It does not set referral attribution unless it also contains a referral parameter. ## Which referral is used For each token, the interface checks referral attribution in this order: 1. a token-specific referral for that exact chain and token; 2. the connected wallet's previously saved global referral; 3. a global referral saved in the current browser. If the first candidate is invalid, the interface tries the next valid candidate. Opening a token-specific referral link also becomes the global fallback when the visitor does not already have one. Once a wallet has saved a global referral, later global links do not replace it; a token-specific link can still take priority for its exact chain and token. When a connected wallet first uses a browser-saved global referral, the interface may request a gasless signature to save that attribution to the wallet profile. This is not a token approval or an onchain transaction. When the trader submits a swap, the interface includes the selected referral address with that trade. `LaunchHook` applies its own onchain reserved-address checks before crediting the referrer's share. An invalid referral never blocks the swap: the hook ignores it and sends the unused referral share to the platform. ## Referral protections A referral is rejected by the o1 interface or Public API when it points to: * the trader's connected wallet; * the original or current launch creator, or the current creator fee recipient; * the platform fee receiver; * an empty or malformed address; * the hook, factory, fee escrow, PoolManager, swap router, or execution contract. The hook independently rejects the empty address, the v4 executor it sees as `sender`, the current creator, the current creator fee recipient, and its factory, escrow, PoolManager, or hook dependencies. Because a routed swap's onchain `sender` can be an execution contract rather than the trader wallet, direct integrations must enforce the broader trader and platform restrictions before encoding hook data. If no candidate is valid, the trade still works and the referral share goes to the platform. ## Trade comments A trader may attach an optional comment of up to 32 UTF-8 bytes. The comment is included with the public onchain trade record, together with the direction, paired asset, referrer, and fee. ## Claiming fees Creator, platform, and referral balances accumulate until claimed. Creators and referrers can open their connected Profile page and use **Fee claims**, where balances are grouped by ETH, stablecoin, or Stock Token. See [Claims](/launchpad/trading/claims) for the complete interface flow and [Functions and events](/launchpad/reference/events-functions) for direct contract integration. # Single-sided liquidity Source: https://docs.o1.exchange/launchpad/trading/liquidity How the opening value, token-only liquidity, changing pool inventory, and permanent Uniswap v4 market work. Every launch opens a real Uniswap v4 pool. All tokens available to the market begin on the token side of the opening price, so the creator does not need to deposit ETH, USDC, USDG, a Coinbase crypto major, or a Stock Token as liquidity. ## Current market setup | Setting | Current value | | -------------- | -------------------------------------------------------------- | | Pair | Launch token and the creator's selected paired asset | | Opening value | FDV close to USD 4,000 under the current quote assumptions | | Pool supply | Complete fixed supply | | Liquidity | One continuous token-side range beginning at the opening price | | Range share | 100% of the pool supply | | Position owner | `LaunchHook` | | Removal | Permanently disabled | The liquidity range uses Uniswap's spacing value of `200`. This controls where the range can begin and end; it does not force prices or trades to move in fixed steps. ## Opening FDV Current launches have a fixed supply of **1 billion (1,000,000,000) tokens**. The opening FDV is the opening token price multiplied by that complete supply. | Quote assumption | Current opening target | | ------------------------------------------------------- | ---------------------- | | ETH at the current factory-managed opening reference | FDV close to USD 4,000 | | USDC at USD 1 | FDV close to USD 4,000 | | USDG at USD 1 | FDV close to USD 4,000 | | Supported Stock Token at its configured reference price | FDV close to USD 4,000 | FDV is a valuation reference, not money raised or deposited. Its USD value changes with the paired asset's market price. Paired-asset price references can update the opening setting for future launches without changing an existing pool. Trading moves each live token price according to its own Uniswap v4 market activity. ## How inventory changes The permanent position starts with the pool supply in launch tokens and no paired-asset deposit from the creator. Buyers send the selected paired asset, such as ETH, USDC, USDG, a supported Coinbase crypto major, or a supported Stock Token, and receive launch tokens. Launch-token inventory decreases while paired-asset inventory increases. Sellers send launch tokens back to the pool and receive the paired asset at the live Uniswap v4 price. Remaining launch tokens and the accumulated paired asset continue supporting the market inside the same permanent position. Because the position starts with launch tokens and no paired-asset inventory, early sell quotes depend on assets added by earlier buys. A sell may be limited or unavailable until the pool has enough ETH, stablecoin, crypto-major, or Stock Token inventory to return. ```text theme={null} pool supply = 1,000,000,000 tokens ``` ## Token-only launch check Before the launch completes, the contracts verify that opening the position requires launch tokens only. If a configuration would require ETH, a stablecoin, a crypto major, or a Stock Token from the creator, the transaction stops. ## Why liquidity is permanent * `LaunchHook` owns the position; * its liquidity cannot be decreased or removed; * outside accounts cannot modify the locked position; * there is no transferable LP token or position NFT; * there is no administrator withdrawal or recovery path. The assets remain inside Uniswap. o1 can adjust settings for later launches but cannot remove or rewrite an existing position. # o1 Doll Source: https://docs.o1.exchange/mascot/o1-doll The official mascot of the o1 ecosystem o1 doll front view: a white Matryoshka doll with a hand-drawn stick figure wearing a blue hard hat The "o1 doll" is a stick-figure Matryoshka-style character wearing a blue hard hat. It originated as an official meme inspired by the numerous meme coins on o1 Launchpad that resemble "Basecat", an orange cat wearing a blue hard hat. It features bouncy, playful and vivid animations, chaotic yet lively group scenes, and approachable simple hand-drawn expressions. With a fun, relaxing and highly recognizable style, o1 doll fully embodies the casual, creative and co-building atmosphere of the o1 ecosystem community. ## Design at a glance A smooth, nesting-doll body in plain white with a visible seam at the waist The builder signature carried over from Basecat and the o1 Launchpad meme scene A simple black marker face, arms and legs drawn straight onto the doll ## Views o1 doll front view showing the smiling stick figure and blue hard hat The full character: smiling face, outstretched arms and planted legs, with the hard hat sitting over the drawn head. o1 doll side view with the hard hat and drawing wrapping around the profile In profile the drawing wraps around the doll, so the hat and limbs read as one continuous line across the surface. o1 doll back view: a plain white Matryoshka doll with no drawing The back is left completely blank. The character lives on the front face only, keeping the silhouette clean. ## Poses o1 doll in its neutral standing pose The neutral resting pose. Arms out, legs apart, calm smile. This is the default reference for the character. o1 doll in an action pose, waving with one arm raised and legs kicked out In motion the limbs break out past the edge of the doll, with drawn hands and feet, one arm waving and legs kicked out. This is where the bouncy, playful animation style comes from. A group of six o1 dolls in descending sizes, all waving Nesting-doll sets scale from large to tiny, each one waving with a slightly different expression. Group scenes are deliberately chaotic and lively, mirroring the community itself. ## Where it comes from o1 Launchpad hosts a large number of community meme coins built around "Basecat", an orange cat in a blue hard hat. The o1 doll takes that same builder hard hat and puts it on a stick figure, turning a recurring community joke into an official mascot. The nesting doll gives the character a group format by default. One doll is a single builder, a full set is the community, and the sizes make crowd scenes easy to compose without redrawing the character. # Token Contract Audits Source: https://docs.o1.exchange/token/audits Security audit reports for the $O token smart contracts Third-party security audits have been conducted on the \$O token contract and related smart contracts to ensure the integrity and safety of the protocol. ## Audit Reports View the first token contract audit report. View the second token contract audit report. # Community Source: https://docs.o1.exchange/token/community How o1.exchange rewards authentic traders through the Season 1 airdrop ## Season 1 Airdrop The community allocation rewards authentic o1.exchange traders through a carefully designed airdrop mechanism. While the exact algorithm is not open-sourced or publicly disclosed, it was built to ensure that genuine users are well rewarded for their contributions to the platform. The airdrop allocation for each user is determined by a sophisticated, nonlinear function that factors in: * **S1.1 and S1.2 Points** — Core trading points earned across both phases of Season 1. * **Net Fees Paid** — The actual fees paid to o1.exchange after accounting for each user's individual cashback rate, ensuring that users who contribute more to platform revenue are proportionally rewarded. * **Referrals** — The number of users referred to o1.exchange, rewarding those who helped grow the community. * **Trading Patterns** — Variety of token mints traded, token holding periods, user retention on the platform, and other behavioral signals used to differentiate real traders from farmers. * **Social Impact** — Contributions and engagement on X (Twitter) and Discord, including Discord Maxi roles and community participation. These inputs are combined in a way that disproportionately rewards consistent, organic platform usage over gameable single-dimension metrics. The goal is to distribute \$O to the users who genuinely contributed to o1.exchange's growth during Season 1. # Disclosure Source: https://docs.o1.exchange/token/disclosure o1.exchange / $O Token – Disclosure Writing as of June 2, 2026 The following disclosure is intended to provide an overview of o1.exchange and the \$O token. It does not purport to be complete or to contain all information that a recipient may consider relevant in making a decision regarding the token. Nothing in this disclosure should be viewed as a statement about the future of o1.exchange or the financial performance of the \$O token. ## 1. Project Information o1.exchange is the Onchain Everything Exchange — a non-custodial, lightning-fast trading platform that delivers institutional-grade execution for spot trading, perpetual futures, and prediction markets across Base, Solana, and BNB Chain. The platform aggregates liquidity from 100+ sources, offers sub-block latency execution, advanced order types (limit, TWAP, stops, sniping), real-time analytics, TradingView integration, and quantitative/algorithmic trading tools. o1.exchange has achieved \$180M+ in spot trading volume, 3M+ transactions, and 400,000+ user signups within 7 months of beta, reaching top-3 revenue protocols on Base. ### Executive Officers and Key Personnel **Company:** MoonX Foundation PO Box 144, 3119 9 Forum Lane, Camana Bay, George Town, Grand Cayman, KY1-9006, Cayman Islands **Founders and Executive Officers:** * Claudio Romildo Pezzia, Director * Jerry Pan, Founder ### Backers and Third-Party Contributors o1.exchange raised a \$4.8M seed round from the following institutional investors: * Coinbase Ventures * a16z (Andreessen Horowitz) * AllianceDAO * The House Fund * Amber Group * 30+ other select angels and institutional investors No third-party development shops or external contractors materially contributed to the development of the protocol or the token. ## 2. Token Sale Information o1.exchange has not conducted and does not plan to conduct a public token sale. \$O token distribution is driven entirely by usage (trading points program) and ecosystem growth. There is no public offering, presale, or crowdsale of \$O tokens. ## 3. Token and Token Distribution Information ### Token Overview \$O is the native utility token of the o1.exchange platform. It is an ERC-20 token deployed on the Base blockchain (L2 on Ethereum). \$O provides the following utility to holders: * **Tiered Trading Fee Discounts:** Holding or staking \$O reduces trading fees in real time across all markets on o1.exchange and swap.o1.exchange DEX Aggregator; discounts scale with amount held/staked. * **Early Access to Alpha Features:** Priority access to quantitative trading tools, strategy automation, advanced order types, and upcoming AI/alpha-generation features before public release. * **Limited Badge Claims & Revenue Sharing Eligibility:** Users who stake at least a required amount of \$O for a required period may become eligible to claim limited ecosystem badges. Badge holders qualify to apply for a portion of o1.exchange platform revenue sharing. The minimum staking amount and staking duration are still TBD. \$O does not represent equity, debt, or profit-sharing in any legal entity. Token holders are not entitled to dividends, interest, revenue share, or any other financial consideration. The platform may conduct discretionary ecosystem initiatives (grants, liquidity support) at the sole discretion of the project team; such actions do not confer enforceable rights on token holders. ### Token Supply and Dynamics * **Token Standard:** ERC-20 * **Blockchain:** Base (Ethereum L2) * **Total Supply:** 1,000,000,000 \$O (fixed; no inflation or minting after TGE) * **Circulating Supply at TGE:** 16% (160,000,000 \$O) * Community Airdrop / Trading Points: 3% (claimable at TGE) * Ecosystem / Trading Competition: 3% * Liquidity Fund (CEX/DEX): 6% (unlocked at TGE) * Treasury: 4% (unlocked at TGE) * No inflationary mechanics; token supply is fixed at genesis. * Future token issuances: None planned. Any changes will be publicly disclosed at least one week before taking effect. ### Token Allocation and Vesting The total supply of 1,000,000,000 \$O is allocated as follows: | Category | Allocation | Tokens | TGE Unlock | | :-------- | :--------: | :---------: | :--------: | | Community | 25% | 250,000,000 | 3% | | Ecosystem | 25% | 250,000,000 | 3% | | Investors | 18% | 180,000,000 | 0% | | Team | 10% | 100,000,000 | 0% | | Treasury | 16% | 160,000,000 | 4% | | Liquidity | 6% | 60,000,000 | 6% | **Vesting Details:** * **Community (25%)** — Trading points airdrop and rewards. Season 1: 3% at TGE; Season 2: 5%; Season 3+: TBD. * **Ecosystem (25%)** — Liquidity incentives and trading competitions. 1-year cliff followed by 36-month linear vesting. Only used for long-term development of the ecosystem and does not benefit insiders. * **Investors (18%)** — Private venture round investors. 1-year cliff followed by 36-month linear vesting. * **Team (10%)** — Project team. 1-year cliff followed by 36-month linear vesting. * **Treasury (16%)** — Platform development, operations, and ecosystem initiatives. 4% unlocked at TGE; remainder held under multi-sig control. Only used for long-term development of the platform and does not benefit insiders. * **Liquidity (6%)** — Initial DEX/CEX liquidity provisioning. Fully unlocked at TGE. ### Prior Funding Rounds o1.exchange has completed one funding round: * **Round:** Seed * **Year:** 2025 * **Amount Raised:** \$4.8M * **Investors:** Coinbase Ventures, a16z, AllianceDAO, The House Fund, Amber Group, and 30+ other select angels and institutional investors. * **Vesting:** Investor token allocation (18% of total supply) is subject to a 1-year cliff lock starting at TGE, followed by 36-month linear vesting. * Locked tokens cannot be staked. The staking program provides only non-financial utility benefits (fee discounts, feature access) and does not involve unvested token allocations. ## 4. Airdrop Information o1.exchange plans to distribute \$O tokens to the community via a trading points conversion program at TGE. * **Total Airdrop Allocation:** 25% of total supply (250,000,000 \$O). 12% of them, i.e. 3%, will be distributed at TGE (Season 1). * **Eligible Recipients:** Users who accumulated trading points on o1.exchange during the points program period (approximately 400,000 registered users). * **Eligibility Requirements:** Active trading on o1.exchange platform, completion of identity verification, and passing of sanctions screening. * **Geographic Restrictions:** Users in jurisdictions subject to OFAC and other applicable sanctions are excluded from claiming. * **Claim Process:** Eligible users will be able to claim \$O tokens through an on-chain distribution contract beginning at TGE. Wallet authentication and applicable compliance checks are required. Tokens are not automatically pushed to wallets. * **Unclaimed Tokens Policy:** Undeliverable tokens will be returned to the project treasury wallet and held for 90 days, during which affected users may contact the team. After 90 days, any undeliverable tokens will be permanently returned to the community treasury for future distribution programs as decided by the Project Team. ## 5. Conflicts of Interest Information No related-party transactions involving the token other than the token allocations described in this disclosure have occurred. ## 6. Market Makers & Liquidity Information o1.exchange will deploy liquidity for \$O via the Liquidity allocation (6% of total supply, 60,000,000 \$O) at TGE. This allocation is designated for initial DEX and CEX liquidity provisioning. No exchange listing fees have been paid to date. Market maker arrangements, if any, will be disclosed prior to TGE. Any contracted market maker identities, token allocations, and durations will be provided no later than one week before the Day 1 listing event. Specific market maker details are pending finalization as of the date of this disclosure and will be updated accordingly. No tokens have been allocated or granted to any market maker as of the date of this document. ## 7. Security Information * **Token Contract:** The \$O token contract (ERC-20) is deployed on Base. * **Smart Contract Audits:** Third-party security audits of the \$O token contract and all vesting contracts have been audited: [https://xors.xyz/audits/o1-exchange-2026-05-02.pdf](https://xors.xyz/audits/o1-exchange-2026-05-02.pdf). * **Vesting Enforcement:** Token vesting for team and investor allocations is enforced through time-bound smart contracts on the Base blockchain. These contracts programmatically release tokens according to the vesting schedule. Contract code will be publicly verifiable on Basescan. * **Platform Security:** o1.exchange is non-custodial. Users retain full control of assets. The platform supports multi-wallet authentication and on-chain verifiable transaction history. ### Public Resources * Website: [o1.exchange](https://o1.exchange) * Twitter/X: [x.com/o1\_exchange](https://x.com/o1_exchange) * Discord: [discord.gg/o1exchange](https://discord.gg/o1exchange) * Dune Analytics: [dune.com/stambouli\_o1/o1exchange](https://dune.com/stambouli_o1/o1exchange) * DefiLlama: [defillama.com/protocol/o1.exchange](https://defillama.com/protocol/o1.exchange) ## 8. Risks The following risks are material to holders and prospective holders of \$O: 1. **Utility Token Only:** \$O is a utility token providing platform benefits only. It does not represent equity, or debt in any legal entity. Token holders are not entitled to receive any payments, dividends, interest, revenue share, or other financial consideration by virtue of holding \$O. 2. **Market and Price Risk:** Token value is determined by market dynamics and utility. Cryptocurrencies are highly volatile and may lose substantial value. Past performance of other digital assets is not indicative of future results. 3. **No Guaranteed Revenue or Buybacks:** No guarantees are made regarding future revenue, token buybacks, or fee discounts. Any treasury ecosystem initiatives are discretionary and do not confer enforceable rights on token holders. 4. **Staking Cooldown:** Staking involves a 30-day cooldown period. Tokens are non-transferable during this period. The cooldown resets if additional unstaking occurs during an active cooldown. 5. **Regulatory Risk:** Regulatory treatment of digital assets and utility tokens varies by jurisdiction and may change. The platform applies geo-restrictions in sanctioned jurisdictions (OFAC-listed countries). Certain features, such as prediction market routing, may not be available in specific jurisdictions including the United States. 6. **Platform Development Risk:** Future platform features, governance mechanisms, and roadmap milestones are subject to change. Governance exploration (\$O-based voting) and synthetic assets are under consideration but not guaranteed. 7. **Concentration Risk:** The founding team and seed investors collectively control significant token allocations. While vesting schedules reduce short-term concentration risk, these parties may have significant influence after vesting periods. 8. **Liquidity Risk:** There is no guarantee of ongoing liquidity for \$O on any exchange. Market conditions may make it difficult to buy or sell \$O at desired prices. 9. **This Disclosure:** This disclosure is for informational purposes only and does not constitute investment advice, a solicitation to purchase \$O, or a prospectus. Recipients should conduct their own due diligence. # MiCA Whitepaper Source: https://docs.o1.exchange/token/mica-whitepaper Markets in Crypto-Assets (MiCA) Whitepaper for $O Token ## MiCA Whitepaper The Markets in Crypto-Assets (MiCA) whitepaper for the \$O token is available below in PDF and HTML/iXBRL formats. View or download the full MiCA whitepaper (PDF) Open the MiCA whitepaper (HTML/iXBRL) # Whitepaper Source: https://docs.o1.exchange/token/whitepaper $O – The Utility Token of the Onchain Everything Exchange **\$O – The Utility Token of the Onchain Everything Exchange** Writing as of June 2, 2026 Version 1.0 | April 2026 TGE: June 2026 17 | Deployed on Base (ERC-20) ## Executive Summary o1.exchange is the Onchain Everything Exchange — a lightning-fast, non-custodial trading platform that delivers institutional-grade execution for spot, perpetuals, prediction markets, and future synthetic/tokenized assets across Base, Solana, and BNB Chain. Built for retail traders, quant funds, and AI agents alike, o1.exchange aggregates liquidity from 100+ sources, offers sub-block latency execution, advanced order types (limit, TWAP, stops, sniping), real-time analytics, TradingView integration, and quantitative/algorithmic trading tools previously reserved for CeFi. The utility token \$O powers the ecosystem. Holders and stakers receive tiered trading fee discounts, early access to alpha features (quant automation, advanced order types, strategy builders). A trading points program further rewards active traders with \$O allocations, driving long-term platform loyalty. Backed by Coinbase Ventures, a16z, AllianceDAO, The House Fund, Amber Group, and 30+ other select angels and institutional investors in a \$4.8M seed round, o1.exchange has already achieved \$220M+ spot volume, 3M+ transactions, and 400k+ user signups in just 7 months of beta, reaching top-3 revenue protocols on Base while expanding to perps (Hyperliquid) and prediction markets (Kalshi). ## 1. The Problem: Fragmented, Expensive, and Underpowered Onchain Trading DeFi trading today suffers from: * Fragmented liquidity and poor price discovery across chains and venues. * High slippage, MEV exposure, and gas costs. * Lack of advanced execution tools (no native TWAP, limits, or algo strategies on most DEXs). * Slow, clunky UX compared to centralized exchanges. * No seamless support for perps, prediction markets, or emerging asset classes (synthetics, tokenized equities) in one unified interface. * High fees that erode retail and institutional profitability. Traders are forced to juggle multiple apps, bridges, and wallets, losing edge and paying premium prices. ## 2. The Solution: o1.exchange – Onchain Everything Exchange o1.exchange is a fully non-custodial trading terminal that brings CeFi-grade performance to DeFi rails. Key features include: * **Low-latency execution** (≤1 block or microsecond-level on supported chains). * **Aggregated liquidity** across 100+ DEXs, on-chain venues, and off-chain PMMs for best-in-class fills. * **Advanced order types** (limit, TWAP, stops/take-profit, sniping) with algorithmic automation. * **Quantitative & AI-powered tools** — strategy builders, backtesting, real-time analytics, PnL tracking, and multi-chain portfolio views. * **Multi-asset coverage** — spot, perpetual futures (via Hyperliquid), prediction markets (via Kalshi), and roadmap for tokenized equities/synthetics. * **Multi-chain & gas abstraction** — trade on Base (primary), Solana, BNB Chain without managing gas or bridges. * **Self-custodial security** — multi-wallet support, on-chain verifiable history, no custody. * **Institutional-ready** — sub-accounts, role-based access, post-trade reporting, order-flow masking. The result: traders get more tokens on every trade, lower costs, and professional-grade tools in one seamless platform. ## 3. \$O Token Utility \$O is the core utility token that aligns user incentives with platform growth. Primary benefits for \$O holders and stakers: ### Tiered Trading Fee Discounts Hold or stake \$O to unlock meaningful reductions in trading fees. Discounts are tiered by amount held/staked and apply in real time across all markets. ### Early Access to Alpha Features \$O holders gain priority access to quantitative trading tools, strategy automation, advanced order types, and upcoming AI/alpha-generation features before public release. ### Limited Badge Claim & Revenue Sharing Eligibility Users who stake at least a required amount of \$O for a required period may become eligible to claim limited ecosystem badges. Badge holders qualify to apply for a portion of o1.exchange platform revenue sharing, creating a direct link between long-term staking commitment and platform economic participation. ### Trading Points Program Active traders earn points convertible to \$O allocations. This incentivizes volume and loyalty from day one. ### Staking Mechanics * Navigate to the staking page on o1.exchange, connect wallet, and stake \$O. * 30-day cooldown on unstaking (resets if additional unstaking occurs during cooldown). * Staked tokens remain in your wallet; no lock-up beyond the cooldown. ## 4. Tokenomics * **Token Standard:** ERC-20 on Base * **Total Supply:** 1,000,000,000 \$O (fixed, no inflation) **Allocation Breakdown** (approximate, subject to final TGE parameters): | Category | Allocation | Description | | :-------- | :--------: | :--------------------------------------------------------------------------------------------------- | | Community | 25% | Trading points airdrop (3% at TGE for Season 1), rewards. Season 1: 3%; Season 2: 5%; Season 3+: TBD | | Ecosystem | 25% | Liquidity incentives and trading competitions | | Investors | 18% | Seed round backers | | Team | 10% | Vested with 12-month cliff + linear release | | Treasury | 16% | Platform development, operations, future initiatives | | Liquidity | 6% | Initial DEX/CEX liquidity provisioning | * **Circulating Supply at TGE:** 16% * **Vesting:** Investor and team tokens follow standard 1-year cliff + linear vesting to ensure long-term alignment. * **No public sale** — distribution driven by usage (points program) and ecosystem growth. ## 5. Platform Growth & Treasury Higher trading volume drives platform growth and operational sustainability. As the platform matures, the treasury may allocate resources toward ecosystem initiatives — including discretionary market operations such as liquidity support, grants, and ecosystem incentives — at the sole discretion of the project team. These actions, if implemented, are not guaranteed and do not confer any enforceable rights or financial entitlements to token holders. Staking \$O provides access to tiered fee discounts and early feature access, directly reducing trading costs and improving the user experience. Staking does not entitle holders to any payments, dividends, interest, revenue share, or other financial consideration. ## 6. Roadmap & Future Governance * **Q2–Q3 2026:** Expanded quant/AI tools, additional chain integrations, and discretionary treasury ecosystem initiatives. * **2026+:** Onchain governance exploration (potential \$O voting on select parameters), synthetic assets, deeper institutional tooling. Current governance is team-led with community feedback via Discord/Telegram. Future \$O-based governance is under active consideration. ## 7. Team & Backers * **Founder:** Jerry Pan * **Director:** Claudio Romildo Pezzia * **Company:** MoonX Foundation, incorporated in Cayman Islands * **Backers:** Coinbase Ventures, a16z, AllianceDAO, The House Fund, Amber Group, and 30+ other select angels and institutional investors. ## 8. Risks & Disclaimers * \$O is a utility token providing platform benefits only. It does not represent equity, debt, or profit-sharing rights in any legal entity. * Token value is determined by market dynamics and utility. Cryptocurrencies are volatile and may lose value. * Staking involves a 30-day cooldown; tokens are non-transferable during this period. * Token holders are not entitled to receive any payments, dividends, interest, revenue share, or other financial consideration by virtue of holding \$O. No guarantees are made regarding future revenue, buybacks, or fee discounts. * o1.exchange is non-custodial; users retain full control of assets. * The platform applies geo-restrictions to users in sanctioned jurisdictions (e.g., OFAC-listed countries). Certain third-party features, such as prediction market routing, may not be available in specific jurisdictions including the United States. Core platform functionality and \$O token utility remain available where legally permitted. * This whitepaper is for informational purposes only and does not constitute investment advice, a solicitation to purchase \$O, or a prospectus. For the latest updates, visit [o1.exchange](https://o1.exchange), follow official channels, and review the token contract upon deployment. *o1.exchange – Onchain Everything Exchange.*