o1.exchange 백서 전문

reator-fee recipient is the documented exception for future creator credits. See [Configuration and governance](/launchpad/architecture/deployment-governance) for the complete boundary. Governance role assignments and the platform fee receiver are listed in [Production contracts](/launchpad/reference/production-contracts#governance-and-fee-recipient). ## Tax-suite boundaries * **Pool-scoped taxes:** only swaps through the Tax Hook collect these fees. Ordinary transfers and unrelated pools are outside that collection mechanism. * **Reward timing:** trading rewards are assigned at the Hook's fee-accounting checkpoint, so later buyers cannot claim an earlier trading backlog. Eligibility still follows actual transfer ordering; there is no holding-duration requirement. Voluntary `depositDividends` contributions reward balances eligible at execution and retain their timing exposure. * **No eligible holders:** that trade's dividend portion goes to the frozen protocol recipient. A high or unreachable minimum, burns or excluded custody balances can keep eligibility at zero. There is no later-holder allocation or automatic reduction of the threshold. * **Pool-held tokens:** the launch PoolManager, mandatory system addresses and configured custody addresses are excluded from dividends. Other pools may still qualify until explicitly excluded. Holding tokens through a pool or custodian is different from holding them in your own wallet. * **Claim authority:** dividend claims require the entitled wallet. Fee claims and burns can be started by another person, but still pay their recorded destination. * **Administrative trust:** the factory owner/creator admin can alter Dividend exclusions and receivers and recover assets, including unpaid reward backing. Entitlements remain recorded, but exclusion or insufficient backing can block payment. Falling below the minimum holding alone does not prevent claiming previously earned rewards. * **Claim limits:** fee claims withdraw a recipient's complete balance for that asset. Exceptionally large balances can exceed the underlying settlement limit; partial claims are not supported. * **External dependencies:** quote-token behavior, router permissions and upgrades, stock-token runtime support, live liquidity and custody systems remain deployment-specific. A quoted or tested route does not prove universal compatibility. See [Holder dividends](/launchpad/tax/dividends) and [Tax contract integration](/launchpad/integration/tax-tokens) before building reward or custody integrations. <span /> ## \$O launch security boundaries * **Actual quote burn:** the Hook burns only quote tokens it holds and verifies the exact supply reduction. It has no authority to burn arbitrary holders' balances. The launched token's fixed supply is unchanged. * **Pool scope:** ordinary transfers and unrelated pools do not pay the burn. There are no fee claims, dividends, referral allocations or deferred burn balances. * **Settlement inventory:** an immediate burn needs physical quote tokens in PoolManager before router settlement. An insufficient balance reverts the trade; reserve claims alone do not prove available inventory or route capacity. * **Reserve authority:** the current Factory owner can withdraw the reserve's entire own claim balance. There is no minimum buffer enforced by contract. This cannot remove the locked launch position, but it can affect swap availability. * **External trust:** the quote vault's backing, deposit controls and governance, plus the shared upgradeable router's implementation and permissions, require separate review. Registration is not proof that an arbitrary token has a safe burn implementation. * **Execution and rounding:** full fills, positive output, signed amount bounds, route-specific minimums and deadlines remain required. High rates and dust can make a validly configured trade unexecutable. Extra reserve funding does not solve external AMM liquidity shortages. * **Economic limits:** burning wstO leaves \$O backing in the vault and can increase backing per share. It does not destroy \$O or guarantee a higher USD price. Immediate deposits and redemptions also mean holding duration is not a protection against traders entering around a large burn. * **Independent scopes:** the [wstO burn-suite report](#wsto-burn-suite-audit) covers its reviewed suite version, not the Base or Robinhood ETH-funded Dev Buy adapters, shared routers, bridge or application. The vault has a separate review scope. Standard, Tax and staking reports do not extend to this suite; verified source or successful simulation is not an audit certification. See [\$O launch integration](/launchpad/integration/wsto) for custody, event attribution and exact funding rules. ## Launchpad of Launchpads boundaries * **Vault funds:** no role can move funds out of a vault. The owner share leaves only to the payout address. The burn fund leaves only through a burn of launchpad tokens. * **Pauses:** registry pauses have no expiry. They stop new launchpads and new token launches only. They never stop trades, owner withdrawals or burn claims. * **Membership:** a token is a member only when the hook recorded the acceptance of a vault of the same registry. A vault that gives no answer lets the launch complete without membership. The named integrator alone gives no membership. * **Sales:** the launchpad and the creator rights of its token move separately. The contracts hold no payment. The buyer must pay after both acceptances. * **Owner credits at a handover:** after the acceptance, the payout address of the new owner receives the unclaimed owner share. * **Uniqueness:** URLs and launchpad tokens are unique inside one registry only. * **Currency behavior:** a vault balance below its records, for example after an issuer seizure, blocks a split or a burn claim in that currency. An owner withdrawal can still succeed when the balance covers the recorded owner share. A failed call also reverts a batch that contains it. * **Roles:** the shared governance owner `0x5519...044D` holds the registry and child factory owner roles. The snapshots give no evidence that any role address is a multisig or a timelock. See [Configuration and governance](/launchpad/architecture/deployment-governance#launchpad-roles). ## 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 and compatible ERC-20 tokens on 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. The **[wstO backing vault](/launchpad/wsto/overview#what-is-wsto)** is a different contract and product. It holds \$O against wstO shares; it is not one of the fixed-epoch reward vaults described here. An \$O launch does not create a new backing vault or reward program. To deposit \$O for wstO, use [O Staking](/staking/introduction). 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. <CardGroup> <Card title="Fully funded rewards" icon="coins"> The creator funds the complete reward budget when the vault is created. </Card> <Card title="Time-weighted rewards" icon="clock"> Each completed epoch is shared according to how many tokens each participant staked and for how long. </Card> <Card title="Separate deposit lots" icon="wallet"> Every deposit has its own earning start, unlock time, and remaining principal. </Card> <Card title="Fixed vault rules" icon="lock"> The assets, schedule, rewards, and withdrawal policy cannot be changed or cancelled after creation. </Card> </CardGroup> Tax-token [holder dividends](/launchpad/tax/dividends) are separate from staking rewards. They use eligible wallet balances without a staking deposit. Tokens deposited in a staking contract no longer count toward your wallet's dividend eligibility. ## 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. <Note> Vaults are permissionless. Before staking, verify the network, creator, staking token, reward currency, schedule, and withdrawal policy shown on the vault page. </Note> ## 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 <Steps> <Step title="Choose the assets"> 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. </Step> <Step title="Set the schedule"> 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. </Step> <Step title="Choose the withdrawal policy"> Early withdrawals can be forbidden or allowed with a fixed penalty from 0% to 99.99%. </Step> <Step title="Review the funding"> 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. </Step> <Step title="Approve and create"> 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. </Step> </Steps> ### 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. <Warning> 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. </Warning> ## Stake tokens <Steps> <Step title="Find a vault"> 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. </Step> <Step title="Review the vault"> Check the creator, staking token, reward currency, schedule, rewards, total staked, and withdrawal policy. </Step> <Step title="Approve and deposit"> 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. </Step> </Steps> ### 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 | <Warning> 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. </Warning> ## 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. <CardGroup> <Card title="Production contracts" icon="code" href="/launchpad/reference/production-contracts#staking"> Verify the staking address and current fee configuration on each production network. </Card> <Card title="Functions and events" icon="brackets-curly" href="/launchpad/reference/events-functions#staking-contract"> Review the direct contract surface for vault creation, deposits, withdrawals, and claims. </Card> <Card title="Limits and validation" icon="list-check" href="/launchpad/reference/limits#staking-vault-limits"> See the contract and interface limits applied to staking vaults. </Card> <Card title="Security and audit" icon="file-shield" href="/launchpad/security"> Read the independent staking audit and the platform's verification guidance. </Card> </CardGroup> ## 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. # Community takeover Source: https://docs.o1.exchange/launchpad/takeover Apply to take over creator rights for an eligible token, understand the application fee, and follow your request. A community takeover (CTO) lets you apply to become the current creator of an existing o1 Launchpad token. If approved and confirmed onchain, the new creator address receives creator rights and future creator fees. <Info> **Which tokens are eligible?** CTO requests are available only for tokens launched through the upgraded o1 Launchpad v4 contracts that support community takeovers. Tokens launched on older contracts before this upgrade are **not eligible**. Eligibility depends on the contracts used to launch the token, not just its launch date. Tax tokens are not eligible for community takeover applications. Select the token's network and paste its contract address in **Developers → Takeover** to check eligibility before applying. </Info> <Note> The application fee is non-refundable. Payment submits your request for review and does not guarantee approval or transfer creator rights by itself. </Note> ## How to apply Open **Developers → Takeover** in [o1 Launchpad](https://launch.o1.exchange) and connect the wallet you want to submit from. 1. **Find the token.** Select its network in the header, then find the token or paste its contract address. Check the network and full address before continuing. The form checks whether the token is eligible for a takeover request. 2. **Fill in the details.** Enter the new creator wallet address and a Telegram handle or other contact details. The new creator address can differ from your submitting wallet. Use an address your intended creator controls: it will also receive future creator fees. 3. **Explain your request.** Complete the questions shown, including why you are requesting the takeover. Follow the displayed required fields and character limits. 4. **Sign and pay.** Review the displayed application fee, sign the wallet message, and complete the one-time card payment through Stripe. The signature authorizes your application; it does not perform the takeover. Your request enters review once payment is confirmed. ## Help us review your application Use clear, accurate information and a contact we can reach. In your answers, we recommend explaining: * your role in the project or community; * why a takeover is needed and what you plan to do next; * relevant public project or community links that help support your request. These details help us understand your plans and review your request. ## Track your request Return to Takeover with the same submitting wallet connected. **Your requests** appears below the form and includes requests across networks. | Status | What it means | | - | - | | Awaiting payment | Complete payment to send your request for review. You can resume an existing checkout while it remains open. | | In review | Payment is confirmed and your request is awaiting a decision. | | Approved | The takeover is complete. The new address holds creator rights and receives future creator fees. | | Rejected | The request was declined. You can update the application and apply again, but a new application fee is required. | Only one active application can proceed for a token at a time. If you were charged