Security and audit

o1 Launchpad is designed around fixed token supply, token-only opening liquidity, permanent Uniswap v4 liquidity, and transparent fee accounting.

​

Standard launch audits

​

Tax token audits

​

$O launch audit

The report covers the reviewed suite version and its original direct-wstO adapter specialization. The Base and Robinhood ETH-funded Dev Buy adapters, including Robinhood’s mixed-v3/v4 acquisition adapter, shared SwapX routers and application are outside that scope. The report refers to a separate vault review; it is not a combined audit of every dependency. See the report for its findings and $O launch security boundaries for the integration risks.

​

Launchpad of Launchpads audits

The Robinhood launchpad registry uses the same pad and Tax contract source as the reviewed commit a276a30. The Robinhood deployment itself is outside these reviews.

​

Staking and vesting audits

​

Audit results

Each report covers the contract version reviewed at the time and includes its findings and resolution status. See Production contracts for deployed addresses. Chain-specific additions, including ArcTaxDividend and adapter specializations, are not automatically covered by an earlier Base report. Published source and local route tests do not constitute an independent audit of those additions.

​

Historical reports

These reports cover earlier contract versions and remain available for reference.

​

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;
• Standard and Tax recipient fee balances are backed by Uniswap v4 claims until withdrawn; $O launch quote fees instead undergo an actual supply burn during the swap;
• creator rights are project-side authority only: they cover rights transfers, announcements and optional profile editing, plus future creator-fee routing on Standard/Tax, but never minting, balance control, upgrades or liquidity custody;
• the configured creator admin can immediately reassign creator rights and, on Standard/Tax, future creator-fee routing, but cannot seize launch-token wallet balances or remove launch liquidity; Tax Dividend administration has the separate recovery powers described below;
• 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 Standard/Tax managed factories used by crypto-paired and stock-paired creation preserve their immutable token, single-sided seed, permanent lock, fee escrow and announcement boundaries. Their managed controls include:

• a paired-asset registry; within each supported product, one factory and hook can 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 a current launch factory;
• a creation switch that affects all new launches through that factory, across its supported creation routes, and does not pause existing markets.

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

Economic defaults apply to future launches. Existing Tax Dividend clones additionally retain their explicit exclusion, receiver and asset-recovery administration. A completed launch keeps its token supply, pool, trading rates, fixed fee recipients and permanent liquidity. The current creator-fee recipient is the documented exception for future creator credits. See Configuration and governance for the complete boundary. Governance role assignments and the platform fee receiver are listed in Production contracts.

​

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 and Tax contract integration before building reward or custody integrations.

​

$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 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 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.

​

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.