One verified human. One token. One vote.
Most voting products ask you to trust an operator. This one is built so you do not have to: identity is gated before a ballot exists, the token is the unit of integrity, and every cast is written twice so either record can check the other.
The invariant
Everything below exists to hold one line true, from the first enrolment to the published result:
A million eligible voters means a million tokens — never more. Votes can be fewer, because turnout is never total, but they can never exceed the tokens, and a token can never be spent twice. That is not a policy we enforce with staff. It is a property of the contract, and you can check it without asking us.
1 · Verify
Before a ballot exists for you, the poll must be satisfied you are a unique human eligible for it. How hard that check is depends on what is at stake — a neighbourhood sentiment poll and a binding association election should not have the same door.
What the chain stores is deliberately thin: a personhood nullifier — a stable identifier that proves "one human, already counted" without carrying who you are. Your attributes live off-chain, and what goes on-chain alongside the nullifier is a commitment to them: a hash that lets anyone verify the attributes were not changed after the fact, while revealing nothing about their contents.
Why a nullifier rather than an address. Addresses are cheap — one person can hold a thousand. A nullifier is issued once per verified human, so re-registering on a new address does not buy a second vote. It also survives a rebind: lose your keys, move to a new address, and you are still the same person to the system, with the same single vote.
2 · Issue
Enrolling in a poll spends exactly one voting credit, which is minted and immediately retired. That credit is the anti-Sybil unit: it is non-transferable, so there is no market in votes to corner, and per-method weight — an approval set, a quadratic budget — lives in poll state rather than as anything tradeable.
Unused tokens expire on a schedule set when the poll is created. Dormant inventory is exactly what a fraudster wants to harvest, so it is not left lying around.
3 · Cast
Casting writes the vote to our database and to the chain in the same operation. Two records, independently checkable, is the point: if our database ever disagreed with the chain, the disagreement itself would be visible rather than quietly resolved in our favour.
Double-voting is not blocked by a rule that an administrator could waive — the contract refuses a second ballot from a participant who has already voted. The refusal is a property of the code path, not a permission someone holds.
4 · Tally
The count runs on-chain, through the voting method the poll was created with. The method is pinned at creation, so changing the registry later cannot alter how a live poll is counted.
- Single choice — one option, highest count wins.
- Approval — approve any number; the most approvals wins.
- Quadratic — a budget spent across options, where intensity costs more than breadth.
- Ranked choice — full instant-runoff, eliminated round by round, on-chain. It is differentially fuzz-tested against an independent reference tabulator, because a tabulation bug is indistinguishable from fraud to everyone outside the code.
5 · Audit it yourself
A result you have to take our word for is not a transparent result. Three things are open to you:
- The ballot-set commitment. When a poll closes it publishes a hash that commits to exactly the set of ballots counted. Nothing can be added or dropped afterwards without changing it.
- The event log. Every lifecycle step — created, enrolled, cast, closed, tallied — is an on-chain event. Our transparency explorer rebuilds each poll by folding those events and shows the block it stopped at, so you can reconcile our view against the chain rather than trusting the page.
- The aggregate releases. Every published cross-tab carries the parameters that produced it — the suppression floor, the privacy budget spent, the attestation hash. How those rules work →
What a poll reveals about you
Every poll carries an explicit disclosure policy, chosen before anyone enrols and frozen once the first person joins — so the terms you enrolled under cannot move under you.
AggregateOnly— the default. Participation is public, and your choice is not returned by any view or API. Read the limits below before treating that as privacy.Public— per-address choice is published. A deliberate opt-in for polls where open voting is the point, never the default, and never available to an official election.Sealed— participation is withheld too, until the poll closes.
The full posture page sets out, per mode, exactly who can see what — including the parts that do not flatter us.
What we do not claim
An aggregate-only poll is not a secret ballot. It is access control, not privacy. Withholding choice from the contract's public views stops integrators, dashboards and casual readers. It does not stop a determined observer: a poll's ballots sit in contract storage, and contract storage is readable by anyone — no function call, no permission, no cooperation from us required. Transaction calldata gives the same answer a second way. We know this because we tested it: a review in September 2026 read every ballot and every voter out of storage while the public getter was correctly refusing. That test is kept green on purpose, as a standing reminder of what the default does and does not buy you.
Real ballot secrecy means never putting a plaintext ballot on a public chain, which is what our commit–reveal module is for. It is a separate module, it is not what runs on a standard poll, and we will not describe a standard poll as secret until it is. We would rather lose the sentence than let the word "blockchain" imply a guarantee we have not built.
A very small poll reveals its voters no matter what we do. If three people vote and the result is published, the result is close to the ballots. At one voter it is the ballot. No gate, and no cryptography, changes that — it is arithmetic. Committees, boards and small HOA votes should assume their choices are inferable from the published outcome.
Binding government elections are not near-term viable. That is a legal constraint, not a product opinion, and no amount of cryptography changes it in the near term. Our beachheads are non-binding verified polling at any scale, and binding votes for HOAs, associations, boards and member organisations — where the law already permits what we are good at.
Enterprise KYC is on the path, not shipped. Document upload, liveness, webcam imaging and voter-roll integration are designed and specified. Until they run in production we describe them as planned, and verification today is a back-office review.
Read the rest, then hold us to it.
The verification tiers, the disclosure rules, and the surfaces a ballot can be cast on.