I shipped a burn mechanism. Then I built the thing that tells me if it works.

In March 2026, zkVerify activated a fee mechanism: 70% of every paid fee is burned, and the remaining 30% goes to the block author. It went live at block #2,805,170.

The sentence everyone writes next is “this makes the network deflationary.” I wrote a version of that sentence myself. It isn’t true yet, and whether it ever becomes true is an empirical question with a specific answer that changes every day.

So I built the thing that answers it.

The claim has a threshold, and the threshold is checkable

Deflation isn’t a vibe. The protocol emits about 2.5% annually. Burn is a function of how much fee revenue the network actually collects, which is a function of how many proofs people actually submit. The network turns deflationary at exactly one condition:

annualized burn rate > 2.5% emission

That’s it. Either the trailing burn run-rate clears the emission rate or it doesn’t. There is no interpretation layer, no narrative, no “directionally.” It’s a comparison between two numbers, and both numbers are on-chain.

Once you write the condition down that plainly, not measuring it starts to look like a choice.

What I built

A dashboard that reads the public zkVerify Subsquid indexer and chain RPC, and publishes four things:

• Total fees collected, all-time, from Extrinsic.fee
• Fees burned since the 31 Mar 2026 activation
• Net inflation rate — 2.5% emission minus the annualized burn rate, taking the trailing 30 days as the current run-rate
• Progress to the deflation threshold, as a bar, because a percentage of the way to a threshold is easier to act on than two numbers you have to subtract in your head

It refreshes daily on a GitHub Actions cron. Methodology is written on the page, including the trailing-30-day choice, because a metric whose definition is hidden is a metric you can quietly redefine later.

Live dashboard →

The outcome, including the part I don’t love

As of 7 August 2026, the threshold has not been crossed. Net inflation over the trailing 30 days is 2.31%, and the burn run-rate is at 7.6% of the way to flipping the network deflationary. The mechanism works exactly as designed. The network is not deflationary — because throughput isn’t there yet.

That is the honest state, and it’s on a public URL with my name attached to it.

I want to be precise about why that matters, because “be transparent” is the kind of advice that sounds good and means nothing. Here’s the concrete version:

Before the dashboard, the deflation claim was a forward-looking statement in a blog post. It had no owner and no expiry. Anyone could repeat it indefinitely, and nobody would be wrong, because nobody was checking.

After the dashboard, the claim has a number attached. If throughput grows, the bar moves and the claim gets stronger on its own. If throughput stalls, the bar sits there, and I have to look at it. That asymmetry is the entire point. The instrument isn’t there to prove I was right. It’s there to make it expensive for me to keep saying something after it stops being true.

Two things I got wrong first

I built it after, not before. The mechanism shipped on 31 March. The dashboard came later. That ordering meant there was a window where the claim was in circulation with nothing behind it, and I had to reconstruct the early burn history from the indexer rather than watching it accumulate live. If I ran it again, the measurement ships in the same release as the mechanism. The metric is part of the feature, not a follow-up ticket.

I nearly made it internal. The first version was going to be a Grafana panel for the team. Internal dashboards have a failure mode I’ve watched happen more than once: when the number goes the wrong way, the panel stops being opened. Nobody decides to stop looking. It just gradually stops being part of the weekly rhythm, and six months later somebody asks “wait, what is that at now?” and nobody knows. A public URL doesn’t fix your character, but it does remove the option of quietly looking away.

The general version

Most product teams ship the mechanism. Fewer ship the measurement. Almost nobody ships the measurement publicly, because a public measurement can embarrass you.

But the mechanism and the measurement aren’t the same deliverable, and shipping only the first one means the claim you made at launch is the last word anyone ever has on it. If you’ve written “this will make X happen,” you have already committed to a testable statement. Building the test is not extra credit. It’s finishing the sentence.

The version of this I’d defend in any room: if you can write the success condition as an inequality, you can build the thing that evaluates it, and you should — before you need it to say something flattering.