DigiDollar on mainnet: the chain record

Every mint commits to a lock tier on-chain, and the maturity height is carried in the transaction itself. This is not a survey or an estimate — it is what 137 minters actually chose, recovered from the payload of every mint since activation.

Counting every mint: 72 (53%) carry terms of a year or longer, 59 (43%) two years or longer, 49 (36%) five years or longer, and 37 (27%) ten years. The ten-year tier is the single most-chosen term on the ladder.

The 22 one-hour mints are the protocol's shortest tier and read as people testing the mechanism rather than locking value: they are 16% of mints but only 11.5% of the dollars minted, and ten of them have already been redeemed. We count them separately throughout rather than folding them into the lockup totals.

Thirteen redemptions occurred in the first eight days. Tracing each one back through the DigiDollar output it consumed, to the mint that created it, shows what was actually unwound:

So of 115 real lockups opened in week one, one has been closed, with two redemptions still unattributed. This is a structural property, not a behavioural one: DigiDollar collateral cannot be released before its timelock expires — there is no early exit and no liquidation — and 72 of these positions do not mature for at least a year.

Twenty-nine transfers in eight days is real movement, but thin — DigiDollar's first week was overwhelmingly about opening positions. Excluding the test cohort entirely, the mix is 79% mints, 20% transfers, 1% redemptions.

Scale, for context: $41,461 of DigiDollar minted against roughly 39.5M DGB of collateral across 124 open positions. A week earlier, on 18 July, that was 35 positions and 6.28M DGB.

A census is only worth as much as its error bars, so here are ours, checked against getdigidollarstats on a DigiByte node at the same height.

Position count is exact. 137 mints minus 13 redemptions is 124, which is what the node reports.

Supply is 1.05% high, and we know why. Redemptions do not always state a burn amount on-chain, so we value them by tracing the consumed output back to its mint. But DigiDollar's recovery mechanism can require burning more DD than a position originally minted, so mint-amount valuation undercounts burns and leaves supply overstated by $420. Treat every dollar figure here as an upper bound.

Collateral totals are upper bounds too. An earlier version of this census counted ordinary change outputs as collateral. Reading the consensus code corrected it: collateral outputs use a provably-unspendable internal key so they can only be released through the timelocked script path, which gives a definitive test we have not yet applied to the value totals.

This census was corrected four times before publication — a first pass overstated supply by 4.08%, misread redemptions as transfers, and misclassified change as collateral. The numbers above are what survived.

• Not agent activity. Whether a human, a script, or an autonomous agent signed a transaction is not observable on-chain. This measures DigiDollar volume — never agent-to-agent volume.
• Not a price or demand signal. Eight days of a new asset is not a trend, and nothing here forecasts anything.
• Not causally linked to anything off-chain. Agent-payment demos run by this site's operator during this period were on testnet and have no relationship to the mainnet activity above.
• Not final. Dollar figures are upper bounds; the reconciliation above states the gap.

Every figure comes from scanning mainnet blocks 23,869,440 through 23,915,757 on a DigiByte Core full node and decoding the DigiDollar OP_RETURN in each transaction. Anyone with a synced node can reproduce it. Transaction classification comes from the consensus type byte carried in each payload — not from inferring intent — and the lock terms are read directly from the maturity height each mint commits to. If your numbers disagree with ours, we would like to know: treat the discrepancy as our error until shown otherwise, exactly as our methodology commits to for the live tracker.

Live figures update every five minutes on the dashboard, and the underlying feeds are documented in the API.