The settlement layer a transfer count cannot see
On one Brazilian token a payment leaves no transfer behind. Tokens are minted into a customer's address and burned out of the same address a few seconds later, and no transfer between two addresses ever happens. Every other series on this site removes both of those legs, because on an ordinary token a mint is issuance rather than activity — so for this kind of payment those series report zero.
This dataset publishes that layer as its own column beside the peer transfers, so the two can be read together or apart. They are disjoint by construction, since a mint is precisely a row the peer side excludes. Since 25 September 2026 the stablecoins dashboard's settled value, transfer count and active wallets include the settlement population inside the same figures, without a separate series; this dataset is where the split, the size mix, the latency and the clock remain.
An address is a settlement address if it has received at least one mint and has never been either side of a transfer between two addresses. That test is applied over the token's whole history, not over the window being shown. It has to be: an address that makes one transfer in its life is not a settlement address in any month, and judging it inside a window would move it in and out of the class as the window moved.
The test is also applied per contract, not per ticker. One chain here carries two contracts for the same symbol, and merging them understates the settled figure by about a third.
The settled column is every qualifying mint. Some of those addresses hold what they receive rather than passing it on, and that share is identified separately in the analysis rather than removed here, so a reader who wants the strict payment reading can set it aside and one who does not is not shown a number that has already been cut for them.
Counts here are a floor for one more reason than usual. The class is defined by an absence, so an address that makes its first transfer tomorrow leaves it, and its mints move to the peer side. The split is stable in aggregate and is not stable per address.
Hours are read in Brazil's own time zone rather than UTC, because the only question a clock is being asked here is when people are awake.
This behaviour has been found on one token and one chain. The test runs over every Brazilian token in the database, so if a second one starts settling this way it appears here rather than going unnoticed.