All docs ▾
Getting started
Using Vex
Token launches#
pools.fun and Virtuals: two launchpads, two very different shapes.
Vex can launch a token for you on two venues, and they are not variations on one idea. pools.fun on Robinhood Chain (chain id 4663) has no bonding curve and no graduation: the token opens directly into a real SushiSwap V3 pool and is acquired from its first block through an ordinary swap. Virtuals launches agent tokens onto a BondingV5 curve, and Vex signs those on Base and Robinhood Chain. A Virtuals launch takes two transactions and only the first one is yours.
Launching is a fund-moving action like any other: it is composed in a session, it runs only under explicit authority, and it is signed locally with your own keystore. What differs between the two venues is what a launch creates, who finishes it, and what the thing you approve actually binds.
The two launchpads, side by side#
| pools.fun | Virtuals | |
|---|---|---|
| Chain | Robinhood Chain (4663) only. | Base and Robinhood Chain. Solana and Ethereum are refused by name with the measured reason: a Solana agent’s curve is a pool the Virtuals backend creates, and Virtuals runs no launch contract on Ethereum. |
| What a launch creates | An ERC-20 with a fixed one billion supply and a live SushiSwap V3 pool against WETH, USDG or one of the tokenised stocks the launch factory allows. | An agent token whose name, ticker, description, picture URL, capability ids and anti-sniper window are written into contract storage permanently. |
| Curve or pool | No curve and no graduation. Every pool charges 1 percent per trade, and acquiring the token is a separate, normally quoted swap. | A bonding curve. The agent trades on that curve until it graduates, and Vex prices and executes those curve trades on Base and Robinhood Chain. |
| Who performs the second step | Nobody. One transaction creates the token and its pool, and an optional same-transaction prebuy fills at the simulated price. | The Virtuals keeper. Your preLaunch reserves the agent and takes your VIRTUAL; the keeper’s own launch(), about a minute later, is what makes it tradable and listed. Vex never sends that transaction, because pre-empting the keeper leaves the agent permanently unindexed. |
| How the image travels | Through the shared image locker. The launch pins metadata whose URI is what determines the salt, and therefore the token’s address. | Through the same locker, but it must already be published: the content-addressed URL is written into contract storage and can never be edited. |
| What the approval binds | Name, symbol, the pinned metadata and image, the chain and gateway, the paired asset, the predicted token address and its salt, the deployment fee and prebuy that make up msg.value exactly, the Vex fee, the gas ceiling, the block it was all read at, the fee recipient, your wallet, and the exact calldata by fingerprint. | The chain and BondingV5 address, the image URL, the exact on-chain name, the capability ids, the anti-sniper choice, the amount committed, the venue’s own launch fee, and the preLaunch calldata by fingerprint. |
| The Vex fee | 25 bps of the native value the launch sends, meaning the deployment fee plus any ETH prebuy, taken as a separate transfer after the launch confirms. | 25 bps of the VIRTUAL you commit, deducted from it, and collected only if the keeper acts while Vex still holds the approved signer. |
The three namespaces#
| Namespace | Tools | What it covers |
|---|---|---|
pools | 13 | pools.fun launchpad, launches and holder rewards (RBC) |
virtuals | 13 | agent tokens: research, curve trades, launches (Base, RBC) |
launchpads | 2 | launch images shared by the launchpads |
The agent reaches all of them the same way it reaches every protocol tool, through ToolSearch, which injects the matching tools into the turn as real function schemas. The launchpads namespace is deliberately venue-neutral: there is one image locker and one public image host, and both serve a launch on either venue. The full per-namespace count is on Protocols & tool counts.
The picture comes first#
Both venues write a picture into permanent state, so both require one, and the agent can never create or upload it. You stage an image from the card on the right of the app; the agent can only list what the locker already holds, as metadata, and name one. Over the Vex Studio MCP surface there is no locker, so the picture is a file inside the project Vex reads itself, without following symbolic links and never from outside the project. A URL of your own is refused on every surface.
Publishing is its own approval, separate from the launch, because making bytes fetchable by anyone is a consent decision that is not implied by consenting to a launch. The published URL is addressed by the sha256 of the exact bytes, so it can never later serve a different picture than the one you approved, and republishing the same bytes uploads nothing and returns the same address. On Virtuals a launch never publishes for you: a file edited after it was published no longer matches and is refused by name rather than launched against a stale address.
Authority for a pools.fun launch#
Where the authority comes from depends on where you are, and the launch tool refuses by name rather than improvising when it is missing.
| Where | What authorises the launch |
|---|---|
| In-app, restricted session | The launch tool refuses by name and the agent must open the app’s two-stage launch form instead, pre-filled with what it proposes. Stage two shows the exact predicted token address, the resolved fee recipient, every cost and a countdown; your Deploy click is the consent, and only that confirmed transaction can be signed. |
| In-app, full-permission session | Your standing session permission is the authority, and the launch tool executes directly, exactly as a swap would. |
| Mission run | The contract’s host-authored launch ceilings, which the agent cannot write. A contract carrying none refuses the launch outright and says so. |
| Vex Studio over MCP | The in-app form does not exist there, so the launch takes the ordinary approval card instead. |
Before signing, Vex decodes the launchpad’s own transaction and proves it against the chain at one anchored block: the gateway’s identity and version, its live deployment fee, the pair’s on-chain allowlist, the pinned metadata and image, the token address, the prebuy, the exact value, your balance and the fee destination. Any disagreement refuses by name instead of launching. The creator fee stream is pinned to your session wallet and the agent-facing tools have no recipient parameter at all; only the manual form can send it elsewhere, or to the token’s holders, which is locked at launch and irreversible. Read Approvals & the Safety Contract for how that gate behaves and Wallets & custody for which key signs.
A Virtuals launch has a middle state#
Because the keeper owns the second transaction, a Virtuals launch has a real, durable state between the two: the agent exists, your VIRTUAL is held by BondingV5, and it is not tradable yet. Vex reports that state as awaiting_keeper rather than as a failure, and it has its own two tools.
| State | What it means | What you can do |
|---|---|---|
awaiting_keeper | The pre-launch is on chain and the keeper has not run launch() yet. The launch reconciles on its own. | Check it, or take the initial purchase back. |
launched | The keeper ran it, the curve is live, and the anti-sniper window has started. | Trade it on the curve. A cancel would now revert. |
cancelled | The initial purchase was returned. The agent token stays on chain, permanently untradable. | Nothing further. A cancelled launch cannot be resumed. |
A cancel refunds the initial purchase and nothing else: any protocol launch fee the venue charged went to its fee recipient inside the pre-launch transaction, and gas is yours either way. For the normal immediate launches Vex signs, that venue fee is currently 0, read live from the contract every time rather than assumed. Vex’s own fee is waived permanently when a launch ends in awaiting_keeper: it is not deferred, not owed, and no background job collects it later, because a sweep that holds no signer and no approval could only take a transfer nobody authorised. Whether the agent is indexed on the Virtuals site is reported separately from what the chain says, and never used to contradict it.
A launch is not reversible. Read the parameters on the form or the approval card, not the summary in the chat. A token launched with no image renders blank on the launchpad forever, which is why the agent path refuses without one. The name on chain is not always the name you typed: Virtuals appends “by Virtuals” unless you turn the suffix off, and the preview shows the exact resulting name. Nothing here is ever retried: a launch whose outcome Vex cannot prove stays pending and is reconciled, because a second attempt is how one token becomes two.
Launch attribution and the VEX badge#
pools.fun grants a token the VEX badge when the wallet that launched it also signed a fixed attestation string naming that exact token and chain. There is no API key and no relay in that path: the signature is the proof, so the request carries nothing an attacker could reuse for anything other than the token it names. That string is versioned and domain-bound, so it cannot be replayed against another verifier on the same chain. Separately, both venues sign a creator proof for the public AgentScan registry over its own canonical string, which is why a launch produces two signatures rather than one shared one.
Attribution is a badge and never a gate. It cannot fail a launch, cannot move funds and cannot delay a signature: the identity record, the confirmation and the Vex fee settle first, and every outcome, including a refusal or an unreachable host, comes back as a named result to be logged. Only codes from a closed vocabulary can retire a row, so a partner’s free text never decides anything. A wallet that declines to sign costs the token its badge and nothing else.
Fees on a launch#
The 25 bps Vex Fee applies to launches on both venues, on different bases because the two launches spend different things. On pools.fun it is taken on the native value the launch sends, meaning the deployment fee plus any ETH prebuy, as a separate transfer that runs only after the launch confirms; a prebuy paid in USDG or another ERC-20 is a separate leg and is not part of that basis. On Virtuals it comes out of the VIRTUAL you commit, so the amount you name is exactly what leaves the wallet, and it is collected as a separate VIRTUAL transfer only once the keeper’s launch is observed.
Either way a reverted or unfinished launch is charged nothing, the fee is separate from gas and from whatever the venue itself charges, and the preview tools show every leg before you commit. On pools.fun the deployment fee is dynamic and read on chain at signing time, so a figure from an earlier turn is stale and is never presented as what the launch will cost. Full detail, including the public treasuries the fee accrues to, is on Fees.
Fees fund $VEX buyback and burn; the token itself was launched on Virtuals Protocol and trades on Robinhood Chain. See the token page.
One retired venue#
Trench Express was a third launchpad here and is retired: its namespace and its ten tools no longer exist, and a database migration ended its ability to hold live state. Confirmed history is untouched, and rows from that era are still read and labelled as legacy.