SOMEONE sends RING trading fees and SOMEONE mint money to a splitter, which pays a share to the dev, a share to NFT holders and the rest to its treasury. Its published split files are written by hand. This page reads the chain directly and checks the files, the payouts and the contract's own counters against each other.
Reading the chain…
One row per source per distribute. "Holders actually paid" is no when the holder-rewards contract had no shares, so the holder share went to the treasury instead.
| Block | Tx | Source | Amount (ETH) | Dev / holders / treasury | Split used | Holders actually paid |
|---|
| Block | Tx | From | Amount (ETH) |
|---|
eth_call at Blockscout's newest indexed block, so events and counters describe the same moment. If that fails the page falls back to the latest block and says so.Deposited, Distributed, SplitSet; views split, totalReceived, pending, totalToDev/Holders/Treasury), holder rewards 0x28A4…50D7 (RewardNotified, Claimed, totalShares, balance), treasury 0x1327…b63c (balance)./data/splits.json (generatedAt 2026-10-18T06:30:00Z). If the project changes its splits, the on-chain check still catches it, because the chain is read live._distributeAll emits Distributed(source, toDev, toHolders, toTreasury) first, and only afterwards checks holderRewards.totalShares() == 0 and, if so, adds the holder share to the treasury transfer. The totalToHolders counter is only increased when holders are really paid. Anyone summing the events therefore over-counts holder payouts by everything paid before the first NFT existed.