Creator fee reconciliation
Splitpaid follows a token's creator fee from the moment it is claimed to the wallet that keeps it, and holds the whole record against the split that was announced on launch day.
A fee split is stated once, in one post, in a sentence nobody is asked to sign. After that it lives in transaction data that few people ever open. Splitpaid opens it: every claim a token makes on Robinhood Chain, ordered, attributed, and measured against the shares the project said it would pay.
01 / The problem
Launches talk about fee splits in the language of a commitment. Sixty percent to the treasury, thirty to the team, ten held back for buybacks. It reads like a term sheet, and buyers price it that way: a project that routes most of its fee income back into the token is worth more than one that routes it into a private wallet. The trouble is that the sentence is the whole instrument. There is no counterparty, no filing, and no date by which anyone has to show their work.
Weeks later the split is still quoted by people who were there on day one, and it has quietly stopped being true. A treasury wallet gets replaced during a multisig handover and the replacement was never announced. An operations share appears that nobody remembers voting for. The team share creeps from thirty percent to forty across four claims, none of which looks unusual on its own. Every one of those movements is public. All of them are also invisible, because reading them means pulling a token's entire claim history out of a block explorer and rebuilding the arithmetic by hand.
That gap is the product. The information is not hidden; it is unreconciled. Splitpaid exists to close the distance between what a project said it would pay and what its own transaction record shows it actually paid, and to keep closing it for as long as the token keeps earning fees.
02 / How it works
Splitpaid does not ask a project for a report. It builds one from the same data any observer can reach, then keeps it current so that checking a split takes a glance rather than an afternoon.
When a token is indexed, the split it announced is captured as structured data: each named recipient, the address behind it, and the share it was said to receive. Where the announcement is vague, the entry records that it is vague instead of guessing a number. A split that cannot be pinned down is itself a finding, and it is kept as one rather than quietly rounded into something tidier.
Creator fees on Robinhood Chain are not paid out continuously. They accumulate and are claimed, and each claim is a transaction with a sender, a recipient, an amount and a block timestamp. Splitpaid reads those transactions for every token it covers and stores each claim as its own row. Nothing is sampled and nothing is averaged away, because the useful detail is usually in the single claim that does not look like the others.
For each recipient, Splitpaid works out what proportion of the fee actually reached that address, claim by claim and across the token's whole life. That figure comes from the amounts in the transactions themselves, so it holds regardless of what any dashboard, pinned post or spokesperson says the split is this week.
The promised share and the recorded share are shown together with the difference between them. A claim that lands within two points of its promise is marked as on split. Anything wider is flagged and stays flagged, with the date attached, so that a drift which started in September is still visible in December instead of being averaged out by the months that followed it.
03 / The fee ledger
This is a worked sample rather than a live feed: fifteen claims across six tokens, shaped exactly like the entries Splitpaid keeps. Sort any column by clicking its heading, filter by outcome, and select a row to see that token's full fee record against the split it announced.
Tolerance: a recorded share within two points of its promise counts as on split.
| Date | Token | Recipient | Amount | Promised | Recorded | Variance | Outcome |
|---|
loading the sample record
Select any row above to open that token's full fee record.
04 / Methodology
A reconciliation tool is only useful if its limits are written down next to its output. These are ours, stated plainly rather than buried in a footnote.
Every figure comes from two places and no others: the token's own launch announcement, captured as the promise, and the settled transactions on Robinhood Chain, captured as the record. No survey data, no estimates supplied by the project, and no numbers taken from a dashboard the project controls.
A recorded share is compared against the promised share for the same recipient on the same claim. Two points of tolerance absorbs rounding and gas variance. Past that, the claim is marked off split and carries the date it happened, because the timing of a change is usually more informative than its size.
Off split means the arithmetic moved, not that anyone acted in bad faith. Wallets get rotated for good reasons and treasuries get restructured openly. Splitpaid reports the variance and the date; the reason belongs to the project, and asking for it is the visitor's business rather than ours.
A split that was never stated clearly cannot be reconciled, only described. Funds moved after a claim lands are outside the scope of a fee record. Tokens whose fee contract routes through an intermediary are marked as such rather than being reported with false precision.
No. Claims are public transactions, and the promise is a public statement. Coverage begins when a token is indexed and continues whether or not the project engages with it. A project that wants to correct the recorded promise can supply the announcement it considers authoritative, and the change is dated and shown as an amendment rather than replacing the earlier figure.
The old address stops receiving and a new one starts. Splitpaid keeps both in the record with the date of the handover, so the history reads as one continuous share that changed custody rather than as one recipient disappearing and a stranger appearing in its place.
A lifetime average hides the shape of what happened. A token that paid its promised split for three months and then stopped shows a perfectly respectable average and a very clear per-claim record. The row-level view is the one that answers the question people actually have, which is what the split looks like now.
It is not. The table above is a fixed sample built to show the structure of a record: the columns, the tolerance, the per-token breakdown. Labelling sample data as live would be the same kind of unchecked claim this project exists to measure.
It was simply never added up. Splitpaid does the adding up, and keeps doing it.
