Docs

Overview

Lead Index is a token whose entire purpose is to turn its own trading activity into a diversified basket of the best-performing new coins on Pons, Robinhood Chain's launchpad. Everything it does breaks down into four mechanical steps, running on a schedule, with no manual picking involved.

1. Track. Every hour, find which coins on Pons have graduated to a real Uniswap v4 market.
2. Evaluate. Filter those down to the one genuine "runner" — the best performer that survives a set of anti-manipulation checks.
3. Buy. Lead Index's own accumulated trading fees are used to buy that runner.
4. Distribute. The runner tokens just bought are sent out to Lead Index holders, proportional to how much they hold.

The important structural point: there is no funding round, no treasury deposit, and no war chest. The wallet that does the buying starts empty and only ever holds what Lead Index's own trading fees put into it. If nobody trades Lead Index, nothing is bought and nothing is distributed. The mechanism is powered by exactly one thing, and that thing is publicly measurable.

These pages describe what the code actually does today, not a roadmap. Where something is built but has never run against real money, it says so.

Architecture

Lead Index deliberately has no server, no database, and no admin panel. There are three moving parts and nothing else:

• A tracker (Python) that reads the chain once an hour, decides the current runner, and commits the result to the project repository as plain files.
• A treasury script (Node.js, ethers v6) that claims fees, buys the runner and distributes it, then commits its own run log the same way.
• This website, a static site that reads those committed files directly in your browser. It has no backend to lie to you — what you see on Live Data and Treasury is the file itself.

Both scripts run as scheduled jobs on GitHub Actions. That choice is deliberate: every run leaves a public, timestamped log and a commit, so the history can't be quietly rewritten to look better than it was. A failed run stays visible as a failed run.

Reads and writes use different paths on purpose. Historical analysis goes through Bitquery's GraphQL API, which can answer questions about ranges of blocks that a plain node call cannot. Anything that spends money talks straight to a Robinhood Chain RPC node, because a transaction should never depend on a third-party indexer being correct or online.

Detecting graduations

A coin on Pons starts life on a bonding curve: a formula that sets its price automatically as people buy and sell, with no real market behind it. If enough real buying happens, the coin graduates — the curve closes and a genuine Uniswap v4 pool opens, where price is set by supply and demand between actual traders.

That moment is the only entry point Lead Index cares about. Out of everything Pons launches, only around 1% ever graduates; the rest die on the curve with almost no volume. Graduation is the line between "a real market exists for this" and "this is still just a formula".

The tracker detects it by watching for the PoolRegistered event emitted on Pons's shared meme hook — the contract Pons attaches to every graduated pool. Concretely, it queries for logs where the emitting address is the hook and the first topic is:

Each matching log is decoded to recover the token address and the exact graduation timestamp. That timestamp matters more than it sounds: it becomes the baseline every later performance figure is measured against.

Graduated coins are appended to a permanent list in data/graduated_tokens.json. Nothing is ever removed from it. On its very first run the tracker looks back 24 hours; after that each run only asks for graduations newer than the last one it saw, so the list grows by addition and the history stays stable.

Measuring performance

For every coin that graduated within the last 24 hours, the tracker fetches two prices from the same source, in the same units:

• Baseline: the earliest recorded trade price in the coin's Uniswap v4 pool — effectively its price at graduation.
• Current: the most recent recorded trade price at the moment of the run.

Performance is simply the change between the two, expressed as a percentage. Both come from the same indexed trade data, so a mismatch in pricing method can't quietly manufacture a gain.

Two supporting numbers are collected in the same pass, and they are what the filters in the next section actually depend on: the number of recorded trades since graduation, and the number of distinct wallet addresses that took part in them. The second is counted as distinct addresses, not distinct transactions, which is precisely what makes it hard to fake cheaply.

Market capitalisation is shown as an estimate, and labelled as one. Pons tokens have a fixed supply of 1,000,000,000 units, so the figure is the current price multiplied by that supply. It ignores burned or locked tokens, so treat it as an order of magnitude rather than a precise valuation.

Coins whose graduation is older than 24 hours drop out of the candidate pool. Lead Index is explicitly an index of new movers; a coin that has been trading for a week is no longer the thing this mechanism is trying to capture.

Choosing a winner

Candidates are ranked by price change since graduation. Ranking alone would be trivial to game, so three filters are applied before anything is crowned. A coin must pass all three:

• At least 20 recorded trades. A price can move a long way on two transactions. This requires that something resembling activity actually happened underneath the number.
• At least 10 distinct wallets. This is the one that does the real work. The cheapest way to fake a chart is one wallet trading against itself — which produces a high trade count and a beautiful price move while nobody has bought anything. Trade count alone can't see that; distinct participants can. Faking this one means funding and operating ten separate addresses, which costs real money in gas and real effort.
• No swing beyond +2000%. Past that point, on a market this young, the overwhelmingly likely explanation is a pricing artefact or a manipulated pool rather than genuine demand. Such coins are excluded from the podium.

Excluded coins are not hidden. They remain in the raw data and the count of exclusions is published on the Live Data page for every run, so you can see how many candidates were rejected and judge the filter for yourself. A mechanism that quietly discards inconvenient data is not verifiable, and the point of publishing the count is that it stays checkable.

If no candidate passes every filter, the run records no winner. That is a legitimate outcome, not an error, and it is written to the log as such rather than being papered over by relaxing a threshold.

These thresholds will be refined as more real data accumulates — they were chosen from a market that is only weeks old. One rule governs any change: filters get stricter over time, never looser, and every change is documented here.

How fees arrive

Pons pays a share of every trade to the wallet that created the token. Those fees do not simply land in the wallet, though — and this is the part most descriptions of "creator fees" gloss over. They accumulate inside contracts and have to be actively collected, in two steps:

1. Sweep. Fees sit where the token currently lives: on the bonding curve before graduation, or on the meme hook after it. A sweep moves whatever has accrued into Pons's fee escrow contract.
2. Claim. A claim then moves the escrowed balance out to the creator wallet, where it becomes ordinary spendable ETH.

The treasury script performs both on every run, reading the launch's current phase from the Pons factory to decide which contract to sweep from. If there is nothing to collect, both steps are no-ops and the run continues without spending gas needlessly.

Every claim is written to data/treasury_log.csv with the resulting wallet balance, and surfaced on the Treasury page. The wallet address is public, so the same figures can be checked independently on the block explorer — and if the two ever disagree, believe the explorer.

Buying the runner

Once fees are in the wallet, the script spends its ETH balance minus a reserve of 0.005 ETH on the current runner. The reserve exists so the wallet can always afford the gas for its own next run; a treasury that spends itself into being unable to distribute would be stuck permanently.

The buy is a direct Uniswap v4 swap routed through the Universal Router, into the runner's own pool. Before sending anything, the script:

• Reconstructs the pool key from the launch record, and checks the runner is actually paired against ETH. Pons launches can be paired against other assets; if the runner is one of those, the script logs the reason and skips the buy for that run rather than guessing a route.
• Asks the on-chain quoter what the swap would return at current state, then sets the minimum acceptable output to 97% of that. If the pool moves against the trade by more than 3% between quote and execution, the swap reverts and no money changes hands. This is a real protection, not a nominal one: passing a minimum of zero, which is common in quickly-written scripts, means accepting any price at all.
• Measures what it actually received by reading the wallet's token balance before and after the swap and taking the difference. It does not trust the amount reported in the transaction receipt. Tokens with transfer fees or rebasing behaviour can deliver less than the receipt implies, and the distribution step must divide what genuinely arrived.

Distribution

The runner tokens that were just bought are sent out to Lead Index holders in proportion to how much Lead Index each address holds, measured at that moment. Holder balances are read from the chain, not from any stored list.

Several addresses are deliberately excluded from the snapshot before any share is calculated:

• the treasury wallet itself — otherwise it would pay a share to itself and slowly hoard the basket;
• the Pons factory, meme hook, fee escrow and launch locker;
• the Uniswap v4 PoolManager, which holds pooled liquidity rather than anybody's position.

Without those exclusions a large share of every distribution would be sent to infrastructure contracts, where it would be effectively burned. This is one of the failure modes that dry-run testing caught before any real money was involved.

Amounts are converted to raw token units using each token's own declared decimals() value, handled as exact integers throughout. Floating-point arithmetic is never used for balances anywhere in the codebase — at eighteen decimal places, a rounding error is not cosmetic.

Schedule & data

Two scheduled jobs, both public:

The tracker log records one row per run, whether or not a winner was found: the run time, how many candidates were considered, how many were excluded, and — when there is a winner — its address, symbol, graduation time, baseline and current price, percentage change, trade count, distinct trader count and estimated market cap.

The treasury log records one row per run: the run time, whether fees were claimed, the resulting wallet balance, how much was spent, which runner was bought, and how many holders were paid.

Both are append-only CSV files committed to the repository. Nothing is aggregated, smoothed, or back-filled before publication; the site reads exactly the rows the scripts wrote. A bad hour stays in the record as a bad hour.

Security model

Automating on-chain purchases requires a private key in an automated environment. There is no way around that, and pretending otherwise would be dishonest, so here is precisely how it is handled.

• The key is stored as an encrypted GitHub Actions secret. It is injected into the job at run time and is masked in logs.
• It was never transmitted through any chat, email, or document, and exists in exactly one place besides the wallet owner's own storage.
• On every run the script derives the address from the key and compares it to the expected treasury address, aborting on mismatch. This catches a wrong or corrupted secret before a transaction is signed, rather than after funds have gone somewhere unintended.
• The treasury wallet holds only accrued fees and a small gas reserve. It is not a vault, and it is not where anybody's holdings live.

What this does not protect against: if that key were obtained by someone else, the balance in the treasury wallet at that moment could be taken. The mitigation is that the wallet is emptied into runner purchases regularly and holds a working balance rather than an accumulated one — but the risk is real and is stated plainly in Risks below.

The treasury script also has a read-only dry-run mode, which performs every check and quote without signing anything. It is run before any change to the buying or distribution path is allowed near real funds.

Contracts

Everything above runs against public, verifiable contracts on Robinhood Chain (chain ID 4663). No custom contract was written for Lead Index. It composes entirely from Pons's and Uniswap's own deployments, which means there is no bespoke contract of ours for you to have to trust, and no upgrade key of ours that could change the rules underneath you.

The treasury wallet's own address is published on the Treasury page, with a direct link to it on the block explorer.

Known limitations

These are current, real, and documented in the code itself rather than only here.

• The buy and distribute paths have never executed a real transaction. They are written and have been validated in dry-run mode against live chain data, but Lead Index does not exist yet, so no ETH has moved. Anyone claiming the treasury is already operating would be wrong.
• Holder queries are not paginated. With a very large holder count the snapshot could be truncated. This has to be fixed before the holder base grows to that size.
• Runners not paired against ETH are skipped, not routed through a conversion step. That hour's fees simply stay in the wallet and roll into the next run.
• The filters are heuristics. They raise the cost of faking a chart considerably; they do not make it impossible, and they cannot tell a genuine collapse from a manipulated one after the fact.
• Price data depends on an external indexer. Selection quality is bounded by the quality of that data. Anything that spends money is read from an RPC node instead, but selection is not.
• Pons has no public link to an individual coin page, so this site links coins to the block explorer and offers the contract address for copying instead.

Risks

Read this section before anything else on the site persuades you of something.

• The underlying market is extremely young and thin. Robinhood Chain launched in July 2026. Roughly 1% of Pons launches ever graduate, and the great majority of those still lose nearly all of their value. Buying the best performer of an hour is not the same as buying something that will hold value.
• Past performance on this page says nothing about future results. The hourly figures describe coins that already moved. Anything bought is bought after the move shown.
• Key compromise is an unrecoverable loss. The treasury wallet's private key lives in an automated environment. If it were obtained, the wallet's balance at that moment could be taken and there would be no way to reverse it.
• Software has bugs. Four real defects were found and fixed in the treasury code during dry-run testing before any money was involved. That is evidence testing works; it is not evidence that no defects remain.
• Fees depend entirely on trading volume. If Lead Index is not traded, there are no fees, nothing is bought, and nothing is distributed. There is no reserve to fall back on — by design.
• External dependencies can fail or change. Pons, Uniswap, the indexer and the RPC endpoint are all outside this project's control.
• Nothing here is financial advice, and nothing here is a promise of return. Do not commit money you cannot afford to lose entirely.