$SUBINDEX SAME BASKET · SUPPORTS INDEX 17-ASSET STRESS TEST
0xfb52da75945a4965183a5cfec1dca7af5881ce24
TREASURY
0xa50b…0b2a
verify both on
Blockscout ↗
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 SubIndex 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: SubIndex operates the SUBINDEX treasury. Nothing on this site is investment advice.
Distribution activity
value pushed to holders per interval (columns) with the running total (line, right axis) · all times Eastern · marked at current pricesDistribution feed
payouts landing in holder wallets, newest firstMost distributions
payout rounds finalized on chainMost traded, 24h
migrated books onlyWhat this ecosystem pays in
reward assets by how many protocols route fees into themPaying soonest
next payout clock across every live treasuryPairing 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 tabDividend tracker
read-only · we never request a signature, a transaction, or a private keyLaunch funnel
where coins fall out between deployment and a holder actually being paidLaunch rate over time
cumulative treasuries deployed vs coins boundTreasuries built, no coin bound yet
the payout machinery exists before the coin does · the basket shown is what the future coin will pay its holdersPools 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 launchThroughput, measured
the arithmetic behind every "late payout" on this siteWhat the keeper is actually working on
calls per treasury in the sampled window — a short list means everything else is queuedHow distributions actually execute
measured from transaction history, not documentationPayouts 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: harvest → claimProtocol → 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 firstWhat $INDEX pays its holders
reading the distributor…INDEX reward mix
value distributed by assetFees arriving at the distributor
launchpad tokens flowing in, by sender token — the flywheel's first observable hopThe flywheel, and what of it is proven
how launchpad activity is meant to reach INDEX holdersRecent INDEX distributions
newest first, straight from the distributor contractWhat the dividends are paid in
the tokenized equities these treasuries buy · issuer verified independently rather than assumedContract map
$INDEX core · verify every one yourselfMethodology
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.