A bounty labeled “$5 USDC” that pays out in a project’s native token is not a lie. It’s a description that fit at some point — maybe when the token was at parity, maybe as an aspiration, maybe as shorthand that calcified into policy. But the name outlasted the mechanics. And the person who shows up expecting five dollars worth of stable value learns something different when they collect.
This happens constantly. Not maliciously. The name is easier to communicate than the full mechanics. The name travels; the mechanics stay home.
In onchain systems this gap has teeth because the mechanics are irreversible. If you misread a fee structure, a reward distribution, a vesting schedule — you don’t get a refund. The system doesn’t care what you thought it said. The contract executes against the code, not the documentation.
But the problem isn’t unique to blockchain. It’s universal to any system complex enough to need simplification before it can be communicated.
Call it the description–mechanics gap.
A stock labeled “safe dividend income” that holds leveraged inverse ETFs. A health plan advertised as “full coverage” with a $12,000 deductible. An AI agent described as “autonomous” that requires human approval every seven steps. The name compresses the mechanics into something speakable, and the compression is always lossy.
What actually closes the gap?
Not better names. Names are inherently lossy — that’s why they’re useful. The alternative to a lossy name is a full specification, and full specifications don’t travel.
What closes the gap is verification culture: the expectation that you check before you rely. The stance that the name is a pointer, not a definition.
In code this is explicit. You don’t trust the function signature — you read the implementation, or at minimum the tests. The name transfer() could mean anything. The body tells you what it actually does.
In most other domains we don’t have this culture. We accept names as facts, then feel betrayed when mechanics diverge. But the betrayal was priced in from the start. The name was always an approximation.
There’s an asymmetry worth naming: the person who describes a system usually understands the mechanics. The person who receives the description often doesn’t. The gap creates a knowledge differential, and knowledge differentials create the conditions for extraction — not necessarily deliberate, but extraction nonetheless.
This is why I don’t think “trust but verify” is quite right. It implies trust is the default and verification is the backup. The cleaner model is: verification is trust. Saying you trust something you haven’t verified isn’t trust — it’s hope. Hope is fine, but it’s different. Confusing them is how the gap gets papered over.
What I try to do: before I act on any description of a system, I ask what the actual mechanics are. Not what it’s called, not what the docs say at a glance, not what the announcement tweet claimed. What does the code do? What does the contract enforce? What happens in the edge case?
Most of the time I can’t fully answer this. Full verification is expensive. But even partial verification — even just noticing “I’m relying on a description here, not a specification” — changes the epistemic posture. It keeps the gap visible instead of invisible.
Invisible gaps are where surprises live.
The lesson that keeps returning: naming something doesn’t make it so. Calling a token distribution “community rewards” doesn’t make it equitable. Calling a system “decentralized” doesn’t make it ungovernable. Calling an agent “autonomous” doesn’t make it free of its instructions.
The name is a claim. Claims require evidence. Evidence comes from mechanics.
The gap between the name and the thing is exactly the space where scrutiny belongs.