ROBINHOOD CHAIN $INDEX ·PROTOCOLS ·ROUNDS ·KEEPER connecting…

The Indices launchpad, measured

every bound coin on one line · fee figures on the cash basis (swept in / reached holders), the mark shown separately because it is not a cash flow

Distribution activity

value pushed to holders per interval (columns) with the running total (line, right axis) · all times Eastern · marked at current prices

Distribution feed

payouts landing in holder wallets, newest first

Most distributions

payout rounds finalized on chain

Most traded, 24h

migrated books only

What this ecosystem pays in

reward assets by how many protocols route fees into them

Paying soonest

next payout clock across every live treasury

Pairing vs throughput

does the asset a coin trades against change how often it actually pays?

Full ledger

every live protocol, ranked by distributions executed · click a tag to filter · deeper sorting on the PROTOCOLS tab
SUBDEX

$SUBINDEX SAME BASKET · SUPPORTS INDEX EXPERIMENT 01 · 17-ASSET STRESS TEST

the official page for the SUBDEX treasury coin · pays the same tokenized stock basket while routing part of its fees to INDEX payouts — 17 assets on a 15-minute epoch, 100% to holders, 0% to the creator
VIEW ON INDICES ↗ @THESUBINDEXFI ↗
CONTRACT 0xfb52da75945a4965183a5cfec1dca7af5881ce24 TREASURY 0xa50b…0b2a verify both on Blockscout ↗
LAB LOG2026-08-05 SUBDEX IS AN EXPERIMENT RUN IN PUBLIC — WE PUBLISH WHAT BREAKS, INCLUDING OURS

Basket breadth, not fee volume, is what stalls these payouts — and we are testing where the ceiling is.

Distributions on this launchpad are not autonomous. A single keeper wallet executes every round for every treasury, and a round is not one transfer — it is a Merkle commit followed by one transaction per holder. We measured 43 payout transactions in four minutes for one coin with 32 holders, zero failures. Keeper throughput is ~11 tx/min against ~900 holder-leaves across the live set, so a full sweep of the ecosystem takes roughly 84 minutes at best. A treasury advertising a 15-minute epoch is describing an intention the architecture cannot currently honour; a 15-minute epoch is a floor, not a schedule.

Basket breadth multiplies that cost. Every additional reward asset adds a conversion step before a round can even be computed, and then adds transfers per holder. The pattern in the data is suggestive rather than proven — the two widest baskets on the launchpad (17 and 8 assets) have executed zero rounds, while single-asset baskets fill the top of the rounds table — but it is confounded: those wide-basket coins also have no trading volume yet, and therefore no fees to distribute at all. Untangling breadth from fee starvation needs a case where one is held fixed.

So that is what SUBDEX is for. We operate SUBINDEX — deliberately the most demanding configuration available on the launchpad: 17 reward assets, a 15-minute epoch, 100% of distributions to holders, nothing to the creator. It is a test instrument, not a pitch. Every round it completes, fails, or delays is published here alongside every other protocol on the same terms, and we will report what breaks even when what breaks is ours. Disclosure: SUBDEX operates the SUBINDEX treasury. Nothing on this site is investment advice.

What SUBINDEX has actually shown, including where it failed.

The honest scoreboard: SUBINDEX has executed zero rounds and paid nobody anything. It holds 17 reward assets on a 15-minute epoch with 100% of distributions to holders — the most demanding configuration on the launchpad — and none of that is why it has paid nothing.

It is not that there were no fees. The fees exist and have not moved. The coin's own page reports $155.56 of fees collected against $0.00 distributed to holders and $0.00 creator earnings, across zero rounds. So the failure is not an empty treasury — it is a full one that has never executed a distribution. SUBINDEX also never graduated its bonding curve, and the most likely explanation is that the two are the same fact: the payout machinery does not begin running rounds until the coin migrates. We are stating the measurement and naming that as a hypothesis, because we have not yet watched a coin cross that boundary and start paying.

A correction, in public, on our own page. This section previously said there were no fees to distribute at all. That was wrong — $155.56 had been collected. We had been reading a treasury field named harvested as "distributed to holders"; for SUBINDEX it reads $0.08 while the coin page reads $155.56 collected, so the two are plainly different quantities and our label was the mistaken one. The fee columns on this site are being re-sourced against the figures the coin page itself publishes, and until that reconciles we would rather show the discrepancy than a number we cannot defend.

What we cannot yet claim. The tempting story is that 17 assets is too many, and the surface data looks supportive — every coin with eight or more reward assets has zero rounds. But that is two coins, SUBINDEX and one other, and neither has graduated either, so breadth is not being tested at the high end at all; the sample cannot separate it from the same fee starvation. Against it: BRRR runs 7 assets and 49 rounds, TEST 7 assets and 35. The keeper arithmetic is real and measured — ~11 tx/min, one transaction per holder, ~84 minutes for a full sweep, so a 15-minute epoch remains a floor rather than a schedule — but the claim that breadth is what stalls a payout is unproven, and we are not going to assert it because it flatters our own next launch. Nor does the distribution split explain anything: JACKET routes 100% to holders and has executed 184 rounds.

So the next instrument fixes the variable that actually failed. The lesson SUBINDEX taught is not "use fewer assets" — it is that a treasury is worth nothing until its coin graduates and trades. The next instrument is built to clear that bar first and to keep every round cheap enough that breadth never becomes the excuse: SUBDEX ($YLD), deliberately the cheapest round we can construct rather than the most demanding: a single reward asset, an epoch longer than the measured sweep, and USDG as the pair. Same operator, same publishing terms, opposite end of the cost curve. SUBINDEX stays live and stays reported — a control is only useful if you keep running it. $YLD is not deployed yet; nothing on this page is an offer or investment advice.

Experiment 02 — SUBDEX ticker $YLD

the efficiency counterpart to SUBINDEX · pre-launch
/ 01 / DESIGN INTENT
Reward assets1 vs 17 on SUBINDEX — one conversion per round
Epochlonger than the sweep a schedule the keeper can keep, not a floor
PairUSDG the currency the distributor already spends
Distribution splitto be set at launch SUBINDEX's 0%-to-creator left nobody to fund liquidity
/ 02 / WHY USDG IS THE PAIR

Verified on chain, not from documentation: the contract behind every one of these payouts is USDGBuyerDistributorV2 (0x39ADB8ac…B7c4). It spends USDG through buyStocksRialto() to buy the reward asset, then fans it out with distributeBatch(). USDG is the input currency of the only working distribution machinery on this chain, so a USDG-paired pool accumulates exactly what the distributor consumes — no sell-into-USDG leg before a round can start. Every other pair adds a hop to every round, forever.

Not deployed. No contract address exists yet, so this panel shows design intent only. The moment a treasury named SUBDEX or ticker YLD appears on the launchpad, the live metrics above populate from the same chain feed as every other protocol on this site — the figures are not hand-entered here and never will be.
loading registry…
Badges are earned from observable behaviour, never opinion. PAYER ≥1 payout round finalized on chain · FULL 100% of distributions go to holders · CURVE still on the bonding curve, no external book yet · HELD in your connected wallet. Where a creator takes a cut the exact split is printed. Click any column to sort.

Dividend tracker

read-only · we never request a signature, a transaction, or a private key
or paste any address —

Launch funnel

where coins fall out between deployment and a holder actually being paid

Launch rate over time

cumulative treasuries deployed vs coins bound

Treasuries built, no coin bound yet

the payout machinery exists before the coin does · the basket shown is what the future coin will pay its holders

Pools created, not yet trading

v4 pools initialized on chain whose token has no price feed yet · a pool with a treasury behind it is a dividend coin assembling; one without is an ordinary launch
All three stages — treasury built, pool initialized, coin bound — are public chain events. A launch is observable long before it is tradeable, and what a treasury will pay is knowable before anyone can buy it.

Throughput, measured

the arithmetic behind every "late payout" on this site

What the keeper is actually working on

calls per treasury in the sampled window — a short list means everything else is queued

How distributions actually execute

measured from transaction history, not documentation

Payouts are keeper-driven, not autonomous. Every distribution step on every treasury is submitted by a single externally-owned wallet, in scripted bursts of five to seven transactions inside roughly sixteen seconds: harvestclaimProtocol → commit → finalize → payout. The bursts arrive one epoch apart, which is what a scheduled job looks like on chain.

Why that matters if you hold one of these. A treasury's epoch is therefore a minimum interval, not a guarantee. No holder can force a distribution, and if the keeper wallet runs out of gas or stops running, payouts pause across every coin at once. The protocol's own disclaimer names keeper availability as a dependency; it is rarely quantified, so we track this wallet's gas and time-since-last-run and treat them as the ecosystem's liveness signal.

The protocol fee is being collected. claimProtocol runs on the same cadence as the payouts and the proceeds arrive as tokenized stock in the keeper wallet, which forwards them onward. We have not observed a transfer from there to the $INDEX distributor or stock treasury, so any claim that the protocol's cut is recycled to $INDEX holders is, on the evidence we can see, unverified at the final hop. We will publish it either way when the trail resolves.

Recent keeper activity

latest calls, newest first

What $INDEX pays its holders

reading the distributor…

INDEX reward mix

value distributed by asset

Fees arriving at the distributor

launchpad tokens flowing in, by sender token — the flywheel's first observable hop

The flywheel, and what of it is proven

how launchpad activity is meant to reach INDEX holders

Recent INDEX distributions

newest first, straight from the distributor contract
$INDEX contract 0x5691…9870 · distributor 0x39ad…b7c4. SUBDEX is not affiliated with Index. Nothing here is investment advice.

What the dividends are paid in

the tokenized equities these treasuries buy · issuer verified independently rather than assumed
Issuer verification. These reward tokens are verified proxy contracts deployed from a single upgradeable factory, with holder counts in the tens of thousands and no minting in recent windows. That factory is independent of the launchpad team's deployer wallets — so the protocols distribute the chain's existing tokenized equities rather than paper they issued themselves. It is the most important structural fact about this ecosystem, and it checks out. Holdings are tokens, not brokerage shares: no voting rights, no corporate dividends.

Contract map

$INDEX core · verify every one yourself

Methodology

every number on this terminal, and exactly where it comes from
What is live, and what is a snapshot — the honest split
Prices, liquidity, volume, holder counts, keeper gas, keeper activity, pool creation, your wallet's transfers: all read live in your browser at load. The treasury registry — which coin is bound to which treasury, its basket, epoch, split and round count — is a scheduled snapshot, and its age is stamped in the header.
Why the registry is a snapshot, and not laziness
The treasury contracts on this chain are unverified: they publish no ABI, so their getters cannot be discovered from chain data alone. Reading them from your browser would mean guessing function selectors — we tried, and they return nothing. Publishing guessed numbers is worse than publishing a labelled snapshot, so we label it. We are deriving the same fields from treasury event logs, which removes the snapshot entirely.
Dividend attribution
Incoming token transfers to your address are matched against the treasury registry and the $INDEX distributor by sending contract. A payment from a treasury is attributed to that treasury's coin; that is why the SOURCE column can name a memecoin while the asset received is a stock.
Payout rounds and countdowns
Round counts come from finalized rounds. The countdown is last round + epoch. Because execution is keeper-dependent, a countdown past zero means a payout is due, not that one has failed.
Prices, market cap, liquidity, volume
DexScreener, deepest pool per token. Coins still on the bonding curve have no external pool and are marked CURVE rather than shown as zero — absent data is labelled absent, never rendered as a zero.
Wallet access
The connector requests your address only (eth_requestAccounts) and nothing else. We never request a signature, never construct a transaction, and never ask for a key or seed phrase. Watch-only mode needs no wallet at all — paste any address. Nothing is sent anywhere: the lookups go straight from your browser to public explorers.
What we will not do
We do not label projects as scams, do not publish accusations about identifiable people, and do not give buy or sell recommendations. Where a structure is unusual — a large creator cut, a concentrated holder, an unverified fee trail — we print the measurement and let it speak.
Corrections
If a figure here is wrong, it is wrong in public and we want to know. We have already retracted one of our own indicators after proving it could never fire; that record stays visible rather than being quietly deleted.
SUBDEX is independent and unaffiliated. Not affiliated with, endorsed by, or speaking for The Index, Robinhood Markets, or any project or token listed here. Nothing on this site is financial, investment, legal or tax advice, and nothing here is an offer or solicitation. Distributions are tokenized assets, not brokerage shares — no voting rights, no corporate dividends. Payouts depend on trading-fee volume, market liquidity, price feeds and keeper availability; they are not guaranteed and can stop. Liquidity on early tokens is thin and prices can move violently. Chain data and third-party feeds can be wrong or delayed. Verify every address yourself.

Provenance, field by field

every figure on this terminal, its source, and whether it is read live or from the snapshot