Verified against production on September 21, 2026. Fetch Capabilities at runtime. Do not copy a hook address from an old guide.
The whole flow
- Your server fetches the active deployment for the selected chain.
- The user’s wallet simulates and signs
createLaunchon that exact hook. - Your app records the transaction hash before it waits for a receipt.
- Your app accepts the launch only after it decodes one valid
LaunchCreatedevent from that hook. - Your server polls
GET /api/tokenuntil the token is indexed.
1. Resolve the current deployment
Call this from your server. InkyPump read APIs do not currently promise cross-origin browser access.57073 for Ink or 4663 for Robinhood. Always send chainId; never rely on a default.
2. Use the creation ABI
3. Simulate, sign, and prove the receipt
This browser example uses viem and an injected wallet.4. Wait for discovery
The receipt is the launch truth. The API is an indexed view and may appear shortly after the receipt.null, show Confirmed — indexing with the transaction link.
5. Link to the token
Native launch limits
Read contract limits from the selected deployment before exposing them in a long-lived client. For xStocks launches, the limits and units are per asset; use the xStocks guide.
Do not do these things
- Do not hardcode the deprecated Ink hook
0x4cC8…6AC4for new launches. - Do not retry
createLaunchbecause receipt waiting timed out. Resume by hash. - Do not treat an API
404just after confirmation as a failed launch. - Do not submit from a shared backend wallet unless that wallet should own the creator fees.
- Do not guess a post-bond pool. Use
getLaunchPoolKeyon corrected/current hooks and complete indexed fields onink-legacy, then validate the computed pool ID. - Do not expose a private key in a browser or partner API.
Deployments
Runtime discovery, active hooks, and legacy routing.
Production checklist
Failure cases and release gates before you ship.