Something about crypto felt off. I couldn't quite articulate what. So I used a structured reasoning tool to think it through — and ended up learning what blockchain actually is in the process.
I'm building infrastructure for structured public deliberation — tools where people can make claims, support them with evidence, raise objections, and have the whole process recorded transparently. (If you want the full picture, Working Note 001 walks through it.)
The project has connections to decentralized knowledge graph technology, and in that world, blockchain and cryptocurrency are everywhere. I'd been treating them as roughly synonymous — blockchain, crypto, decentralization, all part of the same package. But something about the whole thing nagged. It seemed like cryptocurrency is based on the assumption that the only way for people to coordinate is by fighting over something — that trust comes from making cheating expensive. Burn electricity. Stake money you'd lose. The system doesn't care who you are, only whether you've committed enough resources to make dishonesty unprofitable.
That felt like a waste of energy — literally — for a project whose whole point is helping people reason together. But I wasn't sure whether my discomfort was with something real or whether I was just not understanding the technology well enough.
So I tested the question using the Epistemic Workbench — a structured reasoning tool I've been developing. And the first thing the analysis forced me to do was actually understand what these technologies are.
It turns out that "blockchain" and "cryptocurrency" are not the same thing, though they're more intertwined than I initially realized.
At the most basic level, a hash chain is a list of records where each record contains a cryptographic fingerprint of the previous one. If you alter any record, the fingerprint breaks, and every record after it becomes invalid. This is the core idea that makes tampering detectable.
Here's the thing: lots of technologies use hash chains. Git — the version control system that software developers use to track changes to code — is built on hash chains. Every change you save contains a fingerprint of the previous change. The Epistemic Workbench already uses git to track the history of argument graphs. Certificate Transparency logs — the system that records every security certificate issued on the web — also use hash chains. They've been running at global scale since 2013.
So what makes "blockchain" different from these other hash chain systems? The answer is decentralized consensus — the mechanism by which strangers who don't trust each other can agree on which records are valid, without any central authority making the call.
And here's where cryptocurrency enters the picture. It's not just an application "built on top of" blockchain. In most public blockchain systems, the cryptocurrency is the incentive mechanism that makes decentralized consensus work. You need some way to reward the people who maintain the shared record and punish the ones who try to cheat. Proof of work pays miners in coins for burning electricity. Proof of stake lets people earn rewards for locking up tokens they'd lose if they misbehave. The currency and the consensus mechanism are deeply intertwined — not cleanly separable layers.
Once I understood this, the question sharpened. It wasn't "blockchain vs. not-blockchain" — it was: does this project need decentralized, trustless consensus?
Decentralized consensus solves a specific problem: how do you maintain a shared record when nobody trusts anyone and there's no authority to appeal to? That's a real problem in some contexts. If you're building a currency for people who don't trust governments, or a record system that needs to survive hostile state actors, you need strangers to agree without trusting anyone. Cryptocurrency-style incentives are how you achieve that.
But is that the problem I actually have?
I fed the strongest version of the blockchain case into the Workbench: "Deliberation infrastructure requires blockchain to ensure records can't be tampered with."
The tool generated the thesis at only 45% confidence. When it decomposed the argument, the structure was clear. The case rests on three legs:
The thesis needs all three to stand. Green = strong, red = weak.
The first two legs are solid. I do need tamper-proof records, and blockchain does provide them. But the thesis doesn't just need blockchain to work. It needs there to be no alternative that also works.
And now that I understood what blockchain actually is, I could see why that leg is weak. The tamper-detection part of blockchain is the hash chain — and hash chains exist in lots of things that aren't blockchains. The part that's unique to blockchain is the decentralized consensus, and that's the part that requires the adversarial incentive model I was uncomfortable with. So the question becomes: can I get the hash chain part without the decentralized consensus part?
The reason you need decentralized consensus is that there's no one in charge — no authority everyone trusts. But this project operates under Osmio's governance. Osmio is a digital municipality chartered at the ITU in Geneva, with enrolled citizens and a legal structure. It's a Certificate Authority — it already issues digital certificates and operates within the web's existing trust infrastructure.
That's a trust anchor. It means I don't need strangers to agree without trusting anyone. I have a governed institution — accountable to its enrolled citizens, operating under Swiss jurisdiction — that can serve as the authority for maintaining records.
And Osmio, as a Certificate Authority, already operates within the Certificate Transparency ecosystem — the very hash-chain-based, tamper-evident log system that has been running at global scale since 2013. The tamper-detection infrastructure and the identity verification infrastructure are already part of the same world.
On top of that, the Workbench already uses git — another hash chain system — to track the history of every argument graph. Git records every change, who made it, and when. If each change is signed with an Osmio-issued digital certificate, that's tamper detection and verified authorship and a complete audit trail.
These aren't alternatives to blockchain in the sense of being completely different technologies. They're cousins — they use the same underlying cryptographic ideas. The difference is that they work with a trust anchor instead of requiring trustless consensus. And since this project has a trust anchor, that's the right fit.
The analysis also surfaced a second problem — not just "you don't need this" but "it would actively conflict with what you're building."
In proof-of-work systems, who gets to maintain the record is determined by who can afford the most computing power. In proof-of-stake systems, influence is proportional to how many tokens you hold. Both concentrate governance power according to wealth. If you're building a system for democratic deliberation — where the point is equal voice — and the infrastructure underneath it gives more power to whoever has more money, there's a mismatch.
You could use a permissioned blockchain — one where a governed authority controls who participates — and avoid this problem. But at that point, you've reintroduced the trust anchor that trustless consensus was designed to eliminate. And if you have a trust anchor anyway, you might as well use simpler infrastructure — like signed git and certificate transparency logs — that does the same job with less complexity.
Before concluding, I deliberately tried to construct the strongest possible case for needing decentralized, trustless consensus — a practice sometimes called "steelmanning."
The best argument is censorship resistance. Git repositories need hosting. Certificate transparency logs depend on identifiable operators. A government could, in theory, compel all of these operators to censor or remove records. Trustless consensus, because it's permissionless, resists that kind of coercion.
This is a real property. But it doesn't match the actual threat model. The threat I'm designing against isn't "a hostile government censors all copies of a deliberation." It's "a platform operator quietly edits the record because it's politically convenient." For that threat, multiple independent log operators provide more than enough protection.
And even the censorship resistance argument has limits in practice. China blocks blockchain nodes. The U.S. Treasury sanctions Bitcoin addresses. Validators increasingly comply with regulatory demands. If state-level censorship ever became a genuine threat, the real protection would be legal and political — Osmio's institutional structure and Swiss jurisdiction — not technological.
The first two legs held. The third did not.
The analysis pointed toward infrastructure that uses the same underlying cryptography as blockchain — hash chains, signed records, append-only logs — but relies on Osmio as a trust anchor instead of cryptocurrency-style consensus.
This isn't "blockchain vs. not-blockchain." It's the same family of cryptographic tools, used with a different trust model — one based on a governed institution rather than adversarial economic incentives.
I started this exploration skeptical of cryptocurrency but without a clear understanding of why. What I found was that my discomfort was well-placed but poorly aimed. The thing that felt wrong wasn't hash chains or cryptographic tamper detection — those are genuinely useful, and this project will use them. The thing that felt wrong was the adversarial trust model: the assumption that coordination requires making cheating expensive because no one can be trusted.
That model exists for a reason. In a truly trustless environment — anonymous participants, no governing authority, no legal recourse — you need economic incentives to keep people honest. Cryptocurrency solves that problem, and it's a real engineering achievement.
But this project isn't a trustless environment. It has Osmio — a governed institution with enrolled, verified citizens. It doesn't need to make cheating expensive because it can make reasoning visible and participants accountable. Different problem, different tools.
The deeper distinction isn't "centralized vs. decentralized" or "blockchain vs. no blockchain." It's about what kind of trust you're building on. Adversarial trust says: assume the worst about everyone and make the math protect you. Governed trust says: build institutions that are transparent, accountable, and designed to resist capture — and let them serve as the foundation.
Both are responses to institutional failure. The adversarial approach says: institutions can't be trusted, so replace them with economic incentives. This project says: institutions can't be trusted as currently designed, so build better ones.
A note on what I learned about the tool: During this analysis, the Workbench revealed a limitation in itself. When I raised an objection against a thesis and then agreed with the objection rather than arguing against it, the tool treated this the same as successfully rebutting the objection — both counted as "answered." But agreeing with an objection to your own thesis should weaken the thesis, not resolve it neutrally. A future version needs to distinguish "I've countered this objection" from "this objection is valid and I accept it." I'm documenting this publicly because the whole point of the project is transparency about reasoning — including the tool's own shortcomings.