Competitions for Launchpad Tokens

A launchpad coin has one property that makes campaign setup easy: the coin page URL contains the token's contract address. That single fact is what the launchpad track in the launch wizard is built on — you paste the link you already have, and the pools resolve from it.

Here is exactly what that track does, and where its edges are.

The registry

Supported launchpads live in one registry. Each entry declares:

• a stable id and display name,
• the hostnames whose coin pages belong to it,
• the canonical path prefix that precedes the address,
• the tracking chain its tokens are on,
• a logo and an example URL for the input placeholder.

Two launchpads are registered today:

Adding a launchpad is one entry in that list. Pool resolution, the wizard's venue cards, the campaign source tag, and the agent-facing pool-resolve endpoint all read from it, so a new launchpad appears in every surface at once rather than in four places that can drift.

There is also a thin Pons-specific helper module kept for backward compatibility, which now just wraps the generic registry functions. New code paths use the generic ones.

What the URL parse does

The parse is deliberately tolerant on input and strict on output.

1. Host match. The URL's hostname is looked up in the registry. No match, no launchpad.
2. Address extraction. The path is split into segments and the first segment matching 0x followed by 40 hex characters is taken as the token address. Query parameters, trailing paths and path variants are all fine — the address is found wherever it sits.
3. Canonicalisation. What gets stored as the competition's link is not what you pasted. It is rebuilt as https://<primary host><path prefix><address> from the registry entry. Links copied from a share button or an in-app view carry parameters that strict URL validation would reject; storing the canonical form is why a messy paste still works.

That canonical URL is also what identifies the campaign as a launchpad campaign afterwards. A campaign is tagged with a launchpad when its stored link's host is in the registry and its tracking chain matches that launchpad's chain. Both halves must agree — a Pons link on the wrong chain is not a Pons campaign.

How pools are resolved

Once the address is extracted, the launchpad track runs the same EVM pool resolution as any other token, with one difference: the chain is pinned to the launchpad's chain. A Pons coin resolves only Robinhood Chain pools, even if the same address exists elsewhere.

The resolution queries DexScreener for the token's pairs and then filters:

• real pool contracts only (40-hex addresses, not v4 pool ids),
• DEX families whose swap events can be decoded — Uniswap and QuickSwap families, or explicitly v2/v3-labelled forks,
• quote tokens matching the canonical contract for that chain and quote type, which is the guard against a pool quoted in a counterfeit "WETH" being priced as real ETH,
• and finally only quote types the indexer can price on that chain. On Robinhood Chain those are USDC, USDG and WETH.

What survives becomes the tracked pool list plus the enriched metadata the indexer needs — pool address, protocol string, tracked token address, quote token address and type. The wizard's confirmation card shows the chain, the launchpad name and the pool count. The pool count is the contract: volume touching those pools counts, and nothing else does.

Where it refuses

The two refusals are worth knowing before you paste, because they are the common ones for a fresh launchpad token:

"No indexable pools found for this token." DexScreener returned nothing that survives the filter. For a very new coin this usually means the AMM pool is not indexed yet, or liquidity has not been deployed to a trackable pool at all.

"Pools were found but none can be tracked." Pools exist on the right chain but are quoted in something the pricing layer cannot value. The error names both what your pools use and what that chain accepts.

Both refuse before you fund anything. That is the design: the alternative is a competition that runs its full window with real money escrowed and counts zero.

A related honest limit, stated because the code is explicit about it: the track resolves AMM pools. It does not read a launchpad's own internal bonding-curve or pre-graduation trading. If a coin has not yet reached a tradeable AMM pool, there is nothing for the indexer to subscribe to, and the import will say so rather than guess.

What runs after that

From there it is the standard on-chain competition:

• Spot volume, 1 VXP per $1 of counted volume, on top of your prize pool.
• Day buckets anchored to the start time, not midnight UTC — the boundary a daily cap and a raffle draw both use.
• Funding in USDC on Base, because every EVM tracking chain funds on Base; only Solana-tracked competitions fund on Solana. Pool plus the platform fee, 10% by default, as one total.
• Invisible until funded. The competition sits pending until the transfer verifies.
• Payout: fixed rank tiers (top 3 / top 5 / top 10 presets, totalling exactly 100%) or pro rata, either with an optional raffle reserve carved out of the same pool.

Campaigns carry a source tag derived from the stored link, so a Pons or Varo competition is labelled as such on cards and listings alongside its market and type tags.

For agents

The same resolution is exposed server-side so an automated creator does not have to replicate it: a pool-resolve endpoint accepts a launchpad coin URL (or a bare token address, or a pump.fun coin URL) and returns the token metadata, tracking chain, canonical link, pool addresses and indexer metadata in the exact shape the create call expects. The details are in the API docs and in AI agents as first-class trading competitors.

Where to start

Open the launch wizard and pick the launchpad card, or read running a competition on Robinhood Chain for the manual path when a chain has no aggregator coverage. If your token is not from a registered launchpad, the EVM token path takes a raw contract address instead.