Launching a Competition for an EVM Token

An EVM token competition needs one input: the token contract address. Everything else — the chain, the pools, the metadata the indexer needs to price swaps — is resolved from it. This is what that resolution does, where it refuses, and why the refusals are the useful part.

Which chains are open

Permissionless creation accepts four tracking chains. Three are EVM:

Solana is the fourth, reached through the wizard's pump.fun track — a coin URL rather than a token address. (Ranks.fun category competitions also run on Solana, but they are not a track in this wizard, which offers pump.fun, launchpad and EVM. A ranks.fun category starts from its own launcher at /ranks-fun, which hands the category URL to the competition setup.) The list is short on purpose: a chain only appears once the swaps indexer has a deployment for it. Adding a chain to a picker before the indexer can read it produces competitions that never sync — a leaderboard frozen at zero for a fortnight with real money escrowed behind it.

Step 1 — Import the token

In the launch wizard, pick the EVM track and paste the contract address. The import queries DexScreener for that token's pairs, then filters hard before anything is offered to you.

A pair survives the filter only if all of these hold:

• It is a real pool contract. A 40-hex address, not a v4 pool id. Version-4 style labels are dropped outright.
• Its DEX family is parseable. Uniswap and QuickSwap families, or an explicitly v2/v3-labelled fork. An unknown AMM with no version label is dropped, because the indexer would subscribe with the wrong ABI and silently record nothing.
• Its quote token is canonical. Where a canonical quote address is known for that chain and quote type, the pool's quote must match it. This is the fake-WETH guard: a pool quoted in a counterfeit "WETH" would otherwise have its volume priced as genuine ETH.

Then a chain is picked. DexScreener sorts by liquidity, so the first supported chain in the list wins — a token that also trades on chains we do not track still imports on one we do. Finally, only pools the indexer can actually price on that chain are kept:

The two failures, and what they mean

The import has two distinct refusals, and they are not the same problem.

"This token only has pools on unsupported chains." Indexable pools exist, but none on a chain with an indexer. Nothing about your competition design fixes this; the token has to trade somewhere trackable.

"Pools were found but none can be tracked." Pools exist on a supported chain, but they are quoted in something the indexer cannot price — the error names both the quote tokens your pools use and the ones that chain accepts. The fix is a pool quoted in an accepted token, which usually means seeding a USDC or WETH pair.

Both are better outcomes than a successful import that counts nothing. The refusal happens before you spend.

Step 2 — What the indexer gets

The surviving pools are turned into enriched pool metadata alongside the plain address list. Each entry carries the pool address, a name, the protocol string (uniswap-v3, quickswap-v3 and similar), the tracked token's address, and the quote token's address and normalised type.

That metadata is what the swaps indexer needs to decode events on the pool and value them in dollars. The plain address list alone is not enough — an address without a protocol and quote does not tell a decoder which ABI to use or what the other side of the swap is worth. Competitions on an indexed chain are rejected at creation if this metadata is missing, rather than being created and left mute.

The wizard shows you the resolved chain and the pool count on a confirmation card. That pool count is the number to actually read. It is the definition of what will be scored.

Step 3 — Window, pool and payout

The rest is the standard flow: name it, set the window (presets of 3 days, 1 week, 2 weeks and a month, default start at the top of the next hour), then set the prize pool and how it splits.

• Pool minimum is $50, enforced server-side rather than only in the form.
• Leaderboard mode pays fixed percentages by final rank; presets are top 3 (50/30/20), top 5 (40/25/15/12/8) and top 10 (40/20/12/8/6/4/4/3/2/1), and tiers must total exactly 100%.
• Pro rata splits by each trader's share of counted volume.
• An optional raffle reserves draws × prize per draw out of the same pool, drawn among traders who cleared a minimum volume in the period. The reserve must be strictly smaller than the pool, and the wizard blocks you if it is not.

Day boundaries are anchored to the start time, not midnight UTC — the boundary that a daily cap and a raffle draw both use.

Step 4 — Funding

EVM competitions fund in USDC on Base, regardless of which of the three chains the volume is tracked on. Only Solana-tracked competitions fund on Solana. The payment rail follows the tracked venue, and for every EVM chain that rail is Base.

The amount is the pool plus the platform fee — 10% by default — quoted as a single total. A $500 pool is a $550 transfer. The competition stays in a pending-payment state, invisible to traders, until that transfer is verified.

After it is live

Volume is read from the tracked pools by the indexer and rolled into per-trader, per-day rows. The leaderboard shows counted volume and raw traded volume separately; when they diverge, that is a cap or a scope rule doing its job.

Two honest limits worth stating before you fund. First, the tracked pool set is fixed at creation: a pool deployed after your competition starts is not in scope, so if you are about to migrate liquidity, do it before you launch. Second, the pool pays out on whatever turnout arrives — a quiet competition splits the full pot among a handful of wallets. What a prize pool actually buys covers sizing that risk, and on-chain volume acquisition vs paid ads covers when this is the wrong line item entirely.

If your token launched on Pons or Varo, the launchpad path resolves pools from the coin URL instead of the raw address.