$SUBINDEX SAME BASKET · SUPPORTS INDEX EXPERIMENT 01 · 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 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.
The proven cause is one thing, and it is not breadth. SUBINDEX never graduated its bonding curve. Graduation needs the curve to raise a set amount of ETH; until that happens there is no pool, so no trading fees, so nothing whatsoever to distribute. Zero rounds is the arithmetic consequence of zero fees, and no configuration choice would have changed it.
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| Reward assets | 1 vs 17 on SUBINDEX — one conversion per round |
| Epoch | longer than the sweep a schedule the keeper can keep, not a floor |
| Pair | USDG the currency the distributor already spends |
| Distribution split | to be set at launch SUBINDEX's 0%-to-creator left nobody to fund liquidity |
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.
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.