wsto-burn-v1 interfaces and ordinary ERC-20 launched tokens.
Use the suite’s ERC-20 launch interface, not the Standard B20 or Tax launch tuple.
See the Base and Robinhood deployed addresses and user guide. Keep the suite, quote and router identities bound to the prepared transaction, and simulate the complete route at the requested amount.
The XORS burn-suite audit covers the reviewed core suite and original direct-wstO adapter specialization. Its scope does not include the Base or Robinhood ETH-funded adapters, shared routers or application. Match audit coverage to the exact implementation used by your integration.
Read before preparing
Read these at a consistent recent block:defaultBurnRates() returns buyBurnRate and sellBurnRate. These apply to new pools. poolConfig(poolId) returns initialized, tokenIsCurrency0 and the pool’s frozen burnRates. It is the authoritative burn configuration for an existing pool.
There is no nativeLaunchFee(), FeeEscrow, fee-component list, Tax allocation graph or Dividend contract in this suite. Do not call those interfaces on this Factory.
Launch parameters and payment
TheLaunchParams fields for $O launches, in ABI order, are:
createLaunch(LaunchParams) for plain creation with zero value. Finalize metadata before predicting the address with launchTokenBytecodeHash(LaunchParams) and the bound token deployer’s prediction. The creator-scoped salt must be unused, and the token address must end in 01.
createLaunchAndBuy(LaunchParams, LaunchBuyParams) creates the pool and performs one exact-input creator buy. LaunchBuyParams contains fundingToken, amountIn, minAmountOut and routeData. Set a positive meaningful minimum from a simulation of the complete create-and-buy transaction, then simulate the final calldata again. A quote against an existing pool alone cannot validate atomic creation.
The adapter admits native ETH through the exact acquisition/vault path and a direct held-quote purchase. It does not admit $O-, USDC- or USDG-funded Dev Buy. Those assets’ token-page settlement support is a separate capability. A replacement adapter does not inherit approvals granted to its predecessor.
Both Factory and Hook must point to the selected adapter. The Factory initiates execution through the Hook; only the configured Hook may call the adapter. The Hook’s one-use context binds the exact new pool and expected swap caller. The purchased tokens go to the creator. This is not a buy-fee exemption.
An expired deadline, changed protected configuration, used salt, incomplete route spend, invalid binding or insufficient final output reverts the complete creation and purchase. Quote opening-frame revisions are separate from
configVersion: execution deliberately uses the latest registered starting tick. An atomic buy’s final minimum protects output, not a fixed USD launch valuation.
Rate units and swap accounting
Burn-rate scale D = 100,000,000. One percent is 1,000,000; the permitted range is 0 through 99,000,000. Inputs have six decimal places of percentage precision, not BPS. Token amounts use the currency’s own raw units; wstO has 18 decimals. The Hook supports all four swap modes, subject to full fills, meaningful positive output and signed amount bounds:
Use integer math with the documented rounding. Exact-output dust can round a positive fee up to one raw unit. Zero or rounded-zero fees skip
take and burn(0) but still emit Trade. Amounts and grossed-up values must fit the Hook’s positive int128 magnitude limit; a valid percentage alone does not guarantee an executable amount.
beforeSwap adjusts specified-side accounting when necessary. afterSwap checks full execution, takes the actual fee from PoolManager into the Hook and calls the quote’s burn(uint256). It verifies exact Hook and Manager balance changes and exact totalSupply reduction, preserving pre-existing Hook donations. Hook return deltas account for the fee. There is no redemption into $O, dead-address transfer, keeper or delayed burn.
Core exact-output support does not mean every router supports it. The website uses exact-input trades. Use actual core deltas, including any upstream protocol charge, rather than adding that charge twice.
Hook data
Final launch-poolhookData must be empty or exactly 32 bytes containing a UTF-8 comment padded with trailing zeroes. Reject comments over 32 bytes. There is no referral-address prefix or financial referral allocation. Do not reuse the two-word comment encoding from Standard or Tax routes; its 64-byte payload will revert.
Vault-operation descriptor data is separate. Never place its minimum/deadline tuple in the final Hook comment field.
Settlement reserve
Uniswap’safterSwap callback runs before a conventional router pays its input debt. The reserve provides physical quote tokens inside PoolManager so the Hook can perform an immediate burn during that callback. It permits ordinary swap-first, settle-later routing; it does not make arbitrary routers or unfunded quoters compatible.
WstOSettlementReserve accounts for its own ERC-6909 claims in PoolManager. quoteReserveBalance(quoteToken) reads that claim balance, not the pool’s LP balance or an accumulated burn total. Physical assets stay in PoolManager’s shared custody. Swaps do not spend down the reserve’s claims as fee revenue; the trader pays the burn through settlement.
Only the current Factory owner may call depositQuoteReserve(quoteToken, amount) or withdrawQuoteReserve(quoteToken, amount, recipient). Withdrawals redeem only this reserve’s claims and require available physical assets. recoverReserveAsset handles direct donations to the reserve, not launch liquidity. The owner may withdraw the whole reserve claim balance; there is no enforced minimum buffer.
Insufficient physical wstO at the moment of a positive burn causes the transaction to revert atomically. This is especially relevant to the first buy or large buys before input payment. Quote registration and enabled creation do not prove sufficient inventory. More reserve funding can address that constraint, but does not increase the separate acquisition pool’s liquidity. Never derive guaranteed route capacity from the claim balance alone.
Vault and router integration
The reviewed Base acquisition route uses the attachedWstOUsdcNativeLaunchBuyAdapter and existing SwapX proxy:
WstORobinhoodV4LaunchBuyAdapter and its chain’s SwapX proxy:
The external v4 pool ID is not a contract address: its SwapX descriptor uses zero
poolAddress and the complete pool key. For native Robinhood funding, the first descriptor names WETH while the Factory receives native ETH value. SwapX handles wrapping and native delivery. USDG has six decimals; ETH, WETH, $O and wstO have 18.
Both adapters enforce full input consumption and final output protection. Token-page trades use the router directly; Dev Buy uses the adapter attached to the Factory and Hook.
The deployed vaults have custom selectors:
burn destroys the caller’s own shares without returning underlying assets. Fee burning does not require arbitrary-holder burn permission. Quote admission also requires standard untaxed transfers; balance and supply checks are not a substitute for reviewing the vault’s governance and implementation.
Token-page routes may start or end with ETH, USDC on Base or USDG on Robinhood, $O or wstO. Quotes must simulate the real vault operation and Hook burn with a funded caller. Sells redeem after the burn, using the changed share conversion. Enforce final minimum output in the user’s selected receipt asset. A reference USD price, standalone pool quote or one successful small trade does not prove executable larger-route liquidity.
Events and attribution
Read the whole receipt before classifying logs.
PoolRegistered and Seeded precede the Factory’s Launched event; the optional Dev Buy’s burn/trade and LaunchBuyExecuted follow it in the same transaction. Resolve exactly one matching factory launch for each registration by its factory, token and pool; do not depend on a launch record already existing from an earlier log.
Trade.executor is a router/callback identity, not automatically the wallet. Use the Factory’s creator attribution for its atomic Dev Buy and verified router/receipt context for ordinary trades. Intermediate ETH/USDC/USDG/$O movements are not extra launch-pool volume. Robinhood’s external v4 acquisition emits PoolManager swap logs in the same receipt; attribute launch trading only to the exact launch pool ID and Hook. LaunchBuyExecuted.amountIn uses its funding currency; Trade.grossQuoteAmount uses wstO.
For per-pool burn totals, match QuoteBurned to the successful trade and count it once. Do not add Trade.burnAmount and QuoteBurned.burnAmount together. Retain zero-burn trades, deduplicate by chain/transaction/log identity and handle reorgs. totalSupply() is global wstO supply, not a read of one pool’s historical fee burns; deposits and redemptions also change it.
Public API
Selectlaunch_product=wsto on Base or Robinhood configuration queries and launch_product: "wsto" in launch requests. Use market: "standard" and the wstO address as quote_address; do not send a tax object. The API prepares the matching ERC-20 launch tuple and checks the live burn settings.
Optional dev_buy supports native ETH or held wstO. Set funding_token explicitly to the zero address for ETH or the wstO address for held shares. For compatibility, omitting it on an $O launch means held wstO, while Standard and Tax default to native funding. Native ETH uses transaction value and needs no input-token approval. Held wstO requires allowance to the attached adapter and may require approval followed by a second preparation.
For existing tokens, settlement_token selects ETH, USDC on Base or USDG on Robinhood, $O or wstO for exact-input buys and sells. Omitting it selects the pool’s wstO quote. Never substitute raw ETH amounts for wstO amounts or alter API-provided route calldata. The API does not expose the Hook’s exact-output modes.
See launch preparation, Dev Buy approvals, trading and configuration discovery for request examples and runtime checks.