One human, one token, one vote — and why the token is the hard part

Ask anyone what makes a vote legitimate and you will hear some version of "one person, one vote." Ask how a given system guarantees that, and the answer is almost always a description of an organisation: a registrar, a roll, an auditor, a process. Those are promises. They can be excellent promises. They are still promises, and you either trust the organisation making them or you do not.

The interesting question is which parts of that guarantee can be moved out of the organisation and into the mechanism, where trusting them is not required.

Why "one address, one vote" fails immediately

The obvious blockchain answer is to count addresses. It does not survive contact with reality for a single afternoon: addresses are free and unlimited, so the rule counts wallets, not people. Anyone can be a thousand voters before lunch.

The less obvious failure is the one that actually matters. Most systems patch this by adding a role that marks addresses as verified. Now re-read the threat model: whoever holds that role can verify as many addresses as they like. You have not eliminated the trusted operator, you have concentrated them — and given them a much quieter way to be dishonest than stuffing a ballot box.

The nullifier

What we bind personhood to is not an address but a nullifier: an identifier derived once per verified human. Register a second time from a different address and the nullifier already on record collides, and the registration is refused. The address you use becomes an implementation detail rather than the unit of accounting.

This buys two properties that matter in practice. Losing your keys does not lose your franchise — a rebind moves a live personhood to a new address atomically, without ever producing two live accounts sharing one nullifier. And revocation frees the nullifier so a real person can re-enrol, which a naive one-shot scheme cannot do without opening a Sybil hole.

The token is the unit of integrity

Verification gets you to "this is a unique human." It does not get you to "this human voted once." For that, enrolling in a poll mints exactly one voting credit, which is immediately retired.

The credit is deliberately non-transferable. This is the design decision we argue about most, and it is not negotiable: the moment a vote credit can be sold, the system has a market price for a vote, and everything else you built is decoration. Per-method weight — an approval set, a quadratic budget — lives in poll state rather than as anything tradeable, for the same reason.

Unused tokens expire on a schedule set at poll creation. Dormant inventory is precisely what a fraudster wants to harvest, and leaving it around indefinitely is an unforced error.

What "protocol-impossible" means, precisely

We say double-voting is protocol-impossible rather than prevented. The distinction is worth being pedantic about. "Prevented" describes a control someone operates and could therefore waive. "Protocol-impossible" means the contract refuses a second ballot from a participant who has already voted, and there is no role that can make it accept one.

You do not have to believe us about that. The code path is public, the refusal is testable, and the entire lifecycle is emitted as on-chain events that our explorer folds back into a poll view — showing the block it stopped at, so you can reconcile our reconstruction against the chain yourself.

The invariant, stated once

A million verified people means a million tokens, never more. Votes may be fewer, because turnout is never total. They cannot be more, and no token is spendable twice. That single line is what all of the above exists to hold true — and unlike a promise, you can check it.