Technical reference

The launchpad has four parts. Contracts on Base (a factory, a Uniswap v4 hook and a small router) hold every rule that matters: supply, liquidity, fees and who may claim them. An indexer follows Base, waits for confirmations and stores confirmed launches, swaps, transfers, profile changes and fee events. The web app renders pages, widgets other sites can frame and a public JSON API from those rows; for new launches it also reads the factory directly so trading works while indexing catches up. A shared core library holds the stock registry, the price math, the launch quote and the event decoders used by all of them.

Everything on a page is a confirmed event, a number derived from confirmed events, or a live eth_call — with one exception, and it is signed: the creator of a token with a fixed profile may replace its presentation fields, and the server stores that only after checking the signature against the creator address recorded onchain. Nothing else the web app receives from a client is ever stored.

The launchpad's own addresses are under Deployments. Each deployment is one factory, one hook and one router.

StockPairFactory is Ownable2Step. The owner can register stocks (address, Chainlink feed, symbol, decimals), enable or disable a stock for new launches, set the creation fee (capped at 0.01 ETH), set the opening valuation (between $100 and $1,000,000) and change the treasury. The owner cannot touch any launched token, its pool or its profile, and the hook address can be set exactly once.

StockPairHook implements beforeInitialize (only the factory may create pools with this hook), beforeSwap and afterSwap with return deltas. It charges the fee on whichever side of the swap is the stock, mints the fee to itself as ERC-6909 claims inside the PoolManager and books 70% to the creator and 30% to the treasury. claim(stock) and claimMany(stocks) burn the claims and transfer real stock tokens to the caller. It rejects swaps in pools the factory has not registered yet.

StockPairRouter exposes swapExactIn(poolKey, zeroForOne, amountIn, minAmountOut, recipient, deadline). It pulls the input token from the caller, runs the swap through the PoolManager and pays the output to the recipient. Any Uniswap v4 router can trade these pools; this one is just the simplest.

A new deployment never replaces an old one. Hooks cannot be swapped on a live pool, so every factory and hook stays live: tokens launched through them keep trading, earning fees and claiming there, and the indexer follows all of them. Only the newest factory takes launches from this site.

The first deployment, from 2026-09-06, came before buy at launch, editable profiles and the partial-fill check. Its factory has launch only, so every token from it has a fixed profile. Its launch also registers the new pool with the hook before it pays the treasury, and it checks only the length of the name, symbol and contract URI, not for control characters. Its launch, Launched, launchOf, previewOpening, predictToken and stockInfo have the same signatures and selectors as the newer factory's, so one decoder reads both. Where this page describes the launch flow, buy at launch, editable profiles or partial fills, it describes the newest deployment.

The newest factory has three ways to launch; the first factory has only launch. All three take the same LaunchParams, must be sent with exactly the creation fee, and create the token at predictToken(creator, salt). This site sends launchWithOptions or launchAndBuy to a factory that has them. While the newest factory it is configured with has only launch, it sends that, with a fixed profile and no buy, and the create form hides both options.

struct LaunchParams  { string name; string symbol; string contractURI; address stock; bytes32 salt; }
struct LaunchOptions { bool metadataEditable; uint256 openingFdvUsd8; uint256 deadline; }
struct CreatorBuy    { uint128 stockIn; uint128 minTokensOut; }

launch(LaunchParams)                                  -> (address token, PoolId poolId)
launchWithOptions(LaunchParams, LaunchOptions)        -> (address token, PoolId poolId)
launchAndBuy(LaunchParams, LaunchOptions, CreatorBuy) -> (address token, PoolId poolId, uint256 tokensOut)

• launch: fixed profile, no buy, no deadline. The same function and selector as the first factory, so existing integrations keep working. The newest factory's checks are stricter: it also rejects control characters, and it pays the treasury before the pool is registered.
• launchWithOptions: adds a deadline (the launch reverts with Expired after it; the deadline itself still passes), a check that openingFdvUsd8 equals the valuation the creator reviewed (OpeningFdvChanged), and the choice of an editable profile, which needs an ipfs:// contract URI that is a bare CID, with no path.
• launchAndBuy: all of that, then a buy for the sender in the same transaction. stockIn and minTokensOut must both be above zero. See Buy at launch.

In one transaction the newest factory:

1. Checks the call: the hook is set, msg.value equals the creation fee, the stock is enabled, the name is 1 to 64 bytes, the symbol 1 to 16 and the contract URI at most 512, with no control characters.
2. Calls the Base-native B20 factory with createB20: version 1, 18 decimals, admin set to the zero address, and three bootstrap calls that cap the supply at 1,000,000,000, mint it to the factory and store the contractURI. For an editable profile a fourth call grants the factory METADATA_ROLE, and the factory checks the token holds exactly the role it asked for. The token address is predictToken(creator, salt), so the UI can open the token page before the block lands.
3. Reads the stock's Chainlink feed (rejecting readings older than 7 days or non-positive) and derives the opening sqrtPriceX96 so the full supply is worth the configured valuation in USD.
4. Initialises a PoolManager pool with LP fee 0, tick spacing 100 and the StockPairHook, and adds a single-sided position holding the entire supply from the opening tick to the edge of the range on the token side.
5. Burns any rounding dust to 0xdead, pays the creation fee to the treasury, records the launch, registers the pool with the hook and emits Launched, followed by MetadataEditable for an editable profile.
6. For launchAndBuy only: swaps exactly stockIn of the stock for the token, delivers the tokens to the sender and emits CreatorBought.

The treasury is paid before the pool is registered, on purpose. The treasury is an address the owner sets, and the payment is a call with full gas. Until registerPool runs, the hook rejects every swap in the new pool (UnknownPool), so nothing the treasury does during that call can trade it: not at the opening price, and not ahead of the creator's buy.

Log order: Initialize, ModifyLiquidity, PoolRegistered, Launched, MetadataEditable (editable only), then for a buy FeeCharged, Swap and CreatorBought. So Launched comes before any Swap in its pool.

The factory keeps the position forever; it has no function that calls modifyLiquidity with a negative delta.

On the newest factory only, launchAndBuy lets the creator buy their own token in the transaction that creates it. The buy runs after the pool is registered and before the transaction ends, so nobody can trade the pool before it.

The buy is an exact-input swap of stockIn. If it would return fewer than minTokensOut tokens, the factory reverts with TooLittleReceived and the whole launch is undone: no token, no pool, no creation fee. The factory never holds the stock or the tokens, and it only ever pulls stock from the sender of the launch, so a leftover approval cannot be spent by anyone else. The terms are the same as launching and then buying through the router a moment later; the difference is that nobody can get in between. CreatorBought(token, creator, poolId, stockIn, fee, tokensOut) records it, and the token page shows the share as "Dev buy P%".

Why the tolerance defaults to 2%. The quote itself is exact: quoteLaunchBuy in the core library replays the pool math and matches the contracts to the wei, checked against vectors the contract tests write. What can move between review and inclusion is the opening price, which the factory reads from the stock's Chainlink feed when the transaction runs. The opening range starts on a 100-tick boundary, so a feed move changes the output in steps of about 0.995%. A 1% tolerance would revert on ordinary feed moves; 2% covers a move of up to about 1.5%. A bigger move reverts, and costs only gas.

Off by default, and only on the newest factory. A creator who launches with launchWithOptions or launchAndBuy and sets metadataEditable can later point the token at a new profile. A token from launch, and every token from the first factory, is always fixed.

The bootstrap that creates an editable token has one extra call, which grants the B20 METADATA_ROLE to the factory and to nobody else. updateContractURI(token, uri) checks that the caller is the launch's creator and that the token is still editable, accepts only ipfs:// followed by a bare CID (letters and digits, so no path, dot, slash or percent sign can lead it anywhere else), sets it on the token and emits ContractURIChanged; the token emits ContractURIUpdated(). The launch itself checks an editable profile's first link the same way. The factory checks the link, not the document behind it. When the image that document names is also ipfs:// and a bare CID, every change to what the token shows is an onchain event, and a locked profile's content is fixed. A document can still name an image at a web address, which can change with no event at all; the token page says so whenever the link or the image is anything but a bare CID, and this site only ever pins bare-CID images.

lockMetadata(token) makes the factory renounce the role. The token has no admin, so nothing can ever grant it again. metadataStatus reads the role from the token itself, so it says Locked from that block on.

What it cannot do: at the token level the role also covers the name, symbol and extra-metadata setters. Only the factory's code keeps them out of reach, and that code has no path to them: no rename function, no generic call, no proxy, no upgrade. Tests pin the factory's complete list of state-changing functions and scan its bytecode for the rename selectors.

On this site an editable token is edited onchain only: the signed off-chain editor is closed for it. The token page shows how many times the profile changed and when. Until the profile is locked, whoever holds the creator's key can change its links.

When the stock is the amount a swap specifies (an exact-input buy, or an exact-output sell) the fee is taken from it in beforeSwap, so FeeCharged comes before the pool's Swap log. When the stock is the other side (an exact-input sell, which is every sell through this site's router, or an exact-output buy) it is taken from the stock amount in afterSwap, after Swap. A fee that rounds to zero is not charged and emits nothing. The current rate is currentFeeBps(poolId), which the quote endpoint reads from the token's own hook. Fees never sit in a server: they are ERC-6909 claims owned by the hook and booked per account, withdrawn with claim.

Partial fills. When the stock is the amount a swap specifies (an exact-input buy or an exact-output sell), the hook takes the fee on that whole amount before the swap runs. The newest hook then checks that the pool filled all of it, and otherwise reverts with PartialFill; Uniswap v4 delivers that inside WrappedError. Pools on the first deployment's hook have no such check: a swap there that stops early at a price limit its caller set still pays the fee on the full amount it asked for. This site's router sets no price limit of its own, so its swaps are not affected; third-party routers that set one can be overcharged.

Uniswap prices are currency1 per currency0 in raw units; the token has 18 decimals and every stock has 8. With the token as currency0, P = 10^8 · FDV / (stockUsd · 10^27); as currency1 the fraction inverts. The factory computes sqrtPriceX96 = sqrt(P · 2^128) · 2^32 with full-precision integer math and derives the tick.

The indexer stores every swap's post-trade price as whole stock per whole token with 30 decimals; the web app multiplies by the stock's latest Chainlink USD price to show dollars. FDV is that price times one billion. Pool reserves are computed from the locked position (liquidity, tick range) and the live sqrtPriceX96 from StateView.

The indexer polls Base every 2 seconds and processes blocks that are at least 3 confirmations deep (INDEXER_CONFIRMATIONS, its default). It fetches Launched, CreatorBought, MetadataEditable, ContractURIChanged and MetadataLocked from every factory, FeeCharged and FeesClaimed from every hook, PoolManager Swap logs filtered by the known pool ids, and ERC-20 Transfer logs of launched tokens, then writes everything in one database transaction: launches, swaps (with side, price and trader), fee events, profile changes, transfers, balances and rebuilt one-minute candles.

It follows every deployment in STOCKPAIR_DEPLOYMENTS, and a deployment added later gets a catch-up pass from its own deploy block. A creator's buy at launch is stored as a buy by the creator, taken from CreatorBought, so it is attributed correctly even when a bundler sent the transaction.

Reorgs are detected by comparing the stored hash of the last processed block with the chain; on mismatch the indexer rolls back to the last common ancestor and replays, including any profile change in the rolled-back blocks. Every minute it refreshes the 13 Chainlink quotes, and it fills token metadata (description, image, website, X, Telegram) from IPFS in the background, again whenever an editable token points at a new profile. The web app's /api/health reports how far behind the chain head the indexer is.

Launch metadata (name, symbol, description, image, website, X, Telegram) is written into the token's ERC-7572 contractURI on IPFS. For a token with a fixed profile (every launch that did not choose an editable one, and every token from the first factory) that record can never change, so the creator can update presentation fields off-chain instead: description, image, website, X and Telegram. Name, symbol and supply never change. A token with an editable profile is updated onchain (see Editable profile), and this off-chain path is closed for it.

An update is an EIP-712 message signed by the creator wallet over the token address, the normalised fields, the keccak256 of the new image (or zero when unchanged) and a timestamp. The server accepts it only when the signer equals the launch creator recorded onchain, the timestamp is within 15 minutes of its clock and newer than the stored profile, the uploaded image matches the signed hash, and the signature verifies (offline for EOAs, via ERC-1271 / ERC-6492 on Base for smart wallets such as Base Account). The stored profile overrides the launch metadata field by field and the token page says when the creator last updated it.

Every route is public, needs no key and answers JSON; reads come from the indexer and live pool reads, and a confirmed launch can be quoted and traded before it is indexed. Missing data is null, never a placeholder. The transaction routes return the exact calls this site sends, for the user's own wallet to sign. The full reference, with every parameter, error, a curl line and a live Try it, is on its own page, and the same list is published for tools and AI agents.

Building transactions. POST /api/tx/swap and POST /api/tx/launch return the calls for the account that will send them, built by the same code as this site's trade panel and create form: an approval for the exact amount when the allowance is short, then the swap or the launch, with the minimum output, a ten-minute deadline and a simulation. A buy at launch keeps this site's limits (15% of the supply needs acknowledgeShare, half is never built), and builderCode attributes the transaction to the caller beside this site.

Limits and partner access. Each caller may make 120 quotes, 30 transaction builds, 120 token reads and 60 wallet reads a minute; more answer 429. Browsers on listed partner origins (zkCodex by default; PARTNER_ORIGINS replaces the list) may call the routes the reference marks partner CORS, so those limits and the eligibility rule apply to each visitor. Any site can use the widgets instead, which need no listing.

Two pages exist to be framed by other sites: /embed/trade/:token, the buy / sell panel of one token, and /embed/create, the create form. Widgets builds the iframe code with a live preview. The widget pages answer Content-Security-Policy: frame-ancestors *; every other page answers X-Frame-Options: DENY.

A widget is this site running inside the frame: the same quote endpoint, slippage and impact limits, review step, eligibility rule and contracts. The visitor connects their own wallet in the frame and signs there; the host page never sees a key, an approval, a balance or an address. A launch from the create widget comes from the visitor's wallet, so the visitor is the creator and earns the creator's 70%; the host earns no share of the fees. The trade widget follows a new launch from submitted to indexed without reloading, and the create widget moves to the new token's trade widget once the wallet returns a hash. A link to any other page of the site opens in a new tab.

The price, fee, minimum received, review step, eligibility question and the "powered by" line cannot be hidden. The default frame is 820px tall for trade, taller with a chart or lists, and 900px for create, which scrolls inside the frame; the optional script on the Widgets page grows the frame to the widget. A host page with its own Content-Security-Policy has to allow this site in frame-src, and must not sandbox the iframe: wallets open popups and browser wallets inject into the frame.

Events. The widget posts to its host with source: 'bstocks-launchpad': ready with the widget, resize with its height, swap with the token, side and transaction hash, and launch with the token and transaction hash. Check event.origin. Any page can post a message that looks like these, so treat swap and launch as a hint to refresh, and look the transaction up on Base before rewarding anyone for it.

Every pool here is quoted in a Coinbase tokenized stock, and the issuer offers those only to eligible persons outside the United States. The site asks rather than guesses: an IP address says where a connection comes from, not who is behind it.

The trade panel and the create form ask right above their button; the site also asks once on arrival, and a widget asks at the button only, where a dialog could land outside the host page's view. A widget in another site's frame may be refused the cookie (Safari refuses it by default), so the browser also sends the answer as the x-bstocks-eligibility header. Reading stays open to everyone. The swap itself is a call from the visitor's own wallet to the contracts, which no server can stop; this rule covers only the routes this site controls.

A Telegram channel posts every launch, every large trade, every market cap milestone and every new high a token sets against its stock. It is fed by the indexer rather than by polling the API: a row is written into an outbox table inside the same database transaction that commits the swap it describes, so an announcement is exactly as durable as the fact behind it. A reorg deletes the unsent rows for the blocks it rolled back, so the channel cannot announce a trade that did not survive.

A trade qualifies by clearing an absolute dollar floor or a share of that token's own 24-hour volume, because one threshold cannot serve a token doing $200 a day and one doing $20,000. Not every buy and not every sell: nobody can filter a shared channel, so one busy token posting each of its trades would bury every other. Milestones are recorded only after the post is actually delivered, so a failed send retries rather than silently skipping a level.

A creator's buy at launch appears on the launch post rather than as a separate trade. Profile changes are not posted.

Coinbase tokenized stocks on Base, registered in the factory with their Chainlink total-return feeds (8 decimals, 24/5). Icons come from each token's onchain metadata.

The limits this site applies before a wallet opens. Only the rows marked onchain are enforced by the contracts; anyone calling the contracts directly sets their own.

Selectors and topics of the newest factory, hook and router. The first deployment has the subset its factory and hook implement, with the same selectors. PoolId is bytes32; structs are ABI-encoded as tuples. A PartialFill revert reaches callers as the reason inside Uniswap's WrappedError.

• No custody. The site holds no keys and no funds. Fees live in the PoolManager as claims owned by the hook and booked per account.
• No admin over tokens. Every token is created with the zero address as admin. No token launched here has an admin: nobody can mint, burn, pause, block transfers or touch the locked liquidity. If a creator chose an editable profile, the launch factory, a non-upgradeable contract, holds one metadata-only permission on that token. Its code uses it for exactly one thing: pointing the token at a new IPFS profile when the original creator asks. The creator can give it up for good. Name, symbol and supply can never change.
• Bounded owner powers. The factory owner can only manage the stock registry and fee parameters within hard caps, and can set the hook once. The owner has no power over any launched token, its pool or its profile.
• Nobody else trades inside a launch. On the newest factory the creation fee is paid before the pool is registered with the hook, and the hook rejects swaps in pools it does not know, so even a treasury contract cannot trade the new pool during the launch; the only swap inside a launch is the creator's own buy in launchAndBuy. The first factory registers the pool before it pays the treasury.
• Launch checks. On the newest factory, launchWithOptions and launchAndBuy revert after their deadline and when the opening valuation changed after the creator reviewed it; a changed creation fee already fails the exact msg.value check.
• Reentrancy and callbacks. The factory's launch and profile functions are nonReentrant; unlock callbacks accept calls only from the PoolManager.
• Stale feeds rejected. A launch reverts when the stock's Chainlink reading is older than 7 days or not positive.
• Confirmed data only. The indexer records blocks three confirmations deep and rolls back on reorgs. The single row the web app writes on a client's behalf is a creator's signed profile, and it is written only after the signature verifies against the launch creator.
• Profiles are signed, not trusted. Off-chain profile edits, for fixed-profile tokens only, require an EIP-712 signature from the launch creator over the exact fields and image hash, with a 15-minute validity window and monotonic timestamps against replay. Onchain edits of an editable profile come only from the creator's own transaction.
• Input validation. Every API parameter is schema-checked; addresses are checksummed and lower-cased; metadata uploads are limited to 2 MB images of four types and 1,000-character descriptions; X and Telegram links are normalised to https://x.com/handle and https://t.me/handle.
• Framing. Only the widget pages under /embed may be framed, and by any site; every other page refuses. A widget holds no keys either: each trade or launch still ends in the visitor's own wallet, which a host page cannot draw over or answer for. Links out of a widget open a new tab rather than loading the site inside the host's frame.
• Cross-origin reads and writes. Other origins get API access only on the listed partner routes, from a visitor's browser, and never with credentials; every route they can post to or poll carries a per-caller limit. The eligibility answer can only be given on this site's own pages: POST /api/region refuses a request whose Origin is another site.
• Trading safety. Quotes come from the v4 Quoter; swaps carry a minimum output from the user's slippage setting and a 10-minute deadline; the swap is simulated before the wallet opens. On the newest hook a swap that does not fill the stock amount it asked for reverts instead of paying a fee on the part that never traded.