Running a Trading Competition on Robinhood Chain

Robinhood Chain is one of the tracking chains competitions can run on: chain ID 4663, sitting alongside Ethereum (1), Base (8453) and Solana (101). It is also the chain that best illustrates what happens when the usual token-to-pools resolution is not available yet — because the answer is a path that does not depend on it at all.

Why this chain is a special case

The normal EVM flow leans on DexScreener: you paste a token address, DexScreener returns its pairs, and the pools are filtered and imported. That path works on Robinhood Chain. The chain is mapped to DexScreener's robinhood id, so the self-serve launch wizard's EVM track and the agent's resolve_token_pools endpoint auto-fetch its pools exactly as they would on Base.

What makes the chain a special case is that a manual path is kept alongside the automatic one. In the admin creation form, Robinhood Chain is flagged as a manual chain: selecting it hides the token-address auto-fetch and shows a pool-address entry field instead. You add each AMM pool address by hand — validated as a 40-hex address — and set its metadata below. The step's completion gate changes to match: instead of requiring a successful auto-fetch, it requires at least one pool address and at least one entry of indexer metadata. You cannot advance past a half-configured chain.

That fallback earns its place because coverage on a young chain is recent and partial. A pool DexScreener has not indexed yet is still trackable by hand rather than unlaunchable, which is the difference between "wait for a third party" and "run the competition".

The launchpad tracks come at it from the third direction. A Pons or Varo coin URL resolves to Robinhood Chain pools through DexScreener automatically. All three paths land on the same stored record.

What the indexer needs per pool

A bare address is not enough to score anything. Each tracked pool carries:

• address — the pool contract.
• protocol — which decoder to use: uniswap-v2, uniswap-v3, quickswap-v3 and similar. Get this wrong and the indexer subscribes with the wrong ABI and records nothing at all, silently.
• memetoken_address — the token being tracked.
• stablecoin_address and stablecoin_type — the quote side, and its normalised type.

On Robinhood Chain the indexer can price three quote types: USDC, USDG and WETH. A pool quoted in anything else is not trackable, because the pricing layer would have no way to turn its swaps into dollars. WETH there is priced through a reference pool against USDG.

There is a second guard behind the type. For a chain and quote type with a known canonical contract, the pool's quote token must be that exact contract. On Robinhood Chain, canonical addresses are pinned for WETH and USDG. This is the anti-counterfeit rule: a pool quoted in a token that merely calls itself WETH would otherwise have its volume valued at real ETH prices, and a competition scored on inflated dollars pays real money for fake volume.

The rest of the flow is unchanged

Once pools and metadata are in, a Robinhood Chain competition behaves like any other on-chain competition:

• Spot volume, scored at 1 VXP per $1 of counted volume.
• Day buckets anchored to the start time, not midnight UTC.
• Funding in USDC on Base. The Solana rail is only for Solana-tracked competitions; every EVM tracking chain — Robinhood Chain included — funds its pool on Base. Pool plus the platform fee, 10% by default, in one transfer.
• Pending until funded. Traders never see an unfunded competition.
• Payout structures: fixed rank tiers, pro rata, or either with a raffle reserve carved out of the same pool.

The leaderboard reads counted volume and raw traded volume as two separate columns, exactly as elsewhere. Nothing about the scoring is chain-specific; only the pool discovery is.

Who this is for

Three situations, honestly delimited.

A launchpad token on the chain. If the coin came from Pons or Varo, use the launchpad track — it resolves pools from the coin URL and pins the chain for you. No manual entry, no metadata to fill in. That is the common case, and it is covered in competitions for launchpad tokens.

A team that knows its own pool addresses. If you deployed the liquidity, you already have the pool address, the protocol version, and the quote token. Manual entry is faster than waiting for an aggregator to index you, and it is exact — you are stating the scope rather than accepting whatever a third party returns.

Nobody who is guessing. If you do not know which pool contract holds your liquidity or which Uniswap version it is, do not fill this in from a block explorer search. A wrong protocol string produces a competition that runs its full window and counts zero, and a missing pool means real volume that traders expected to count did not. The failure is silent by construction: there is no error to see, just a leaderboard that stays flat.

The chain-maturity caveat

This is worth saying plainly rather than burying. A newer chain means thinner liquidity and fewer traders already present. A prize pool induces competitive volume; it does not create depth. Volume pushed into a shallow book produces bad fills, and the trader's takeaway becomes "this slips" — which is a worse outcome than not having run the campaign.

So size the pool against the depth that exists, not the depth you want. On a thin market, a smaller pool over a longer window with a per-day counted-volume cap does more good than a large pool over three days, because the cap spreads the induced flow instead of concentrating it into a few blocks of terrible execution.

Where to start

Open the launch wizard for the automatic paths, read launching a competition for an EVM token for how pool resolution works where DexScreener does cover the chain, and what is on-chain volume acquisition for what this class of campaign is buying in the first place.