Shadow-vote system
Teller
A voluntary, non-binding parallel vote for annual conference sessions — cast on delegates’ phones, alongside the official count, then reconciled against it.
The idea
Annual conferences vote by voice, by a show of hands, or with rented electronic clickers — each with trade-offs in speed, accuracy, and cost. Teller is a way to try a phone-based alternative under real session conditions, without putting anything at stake.
During a session, recruited delegates cast a parallel ballot on their phones while the official vote happens as usual. Afterward the two counts are set side by side. The point is not to decide the question — it is to learn whether the process, the identity checks, and the tally hold up.
Non-binding by design
Teller’s results never reach the chair. They exist only to be compared with the official count.
This is deliberate. Because Teller decides nothing, it is not an election method — it is a research exercise delegates choose to join. That keeps it clear of the conference’s Standing Rules and free to be tested with zero stakes.
How it works
- 1A teller loads the delegate roster and sends each recruited delegate a personal link.
- 2At the session, delegates check in — with that link, by entering a short code, or by scanning a QR code shown in the room.
- 3The teller opens a question, and it appears on every checked-in delegate's phone.
- 4Delegates tap a choice and see exactly what was recorded — and can change it while the question stays open.
- 5The teller closes the question; the tally freezes, shown with turnout and a lay/clergy split.
- 6At the end, the whole run exports — ready to set beside the official count.
How it’s kept honest
Teller v1 is identified — the system knows who cast which ballot. That is on purpose: an identified vote is debuggable and fully auditable. v1 is a test of process, not a secret ballot.
- One person, one vote — enforced in the database. A delegate may change their ballot while a question is open, but a second vote updates that ballot rather than adding one. The rule lives in the data, not only on the screen.
- Votes are gated by the server clock. A ballot is accepted only while its question is open. Taps that land early or late are rejected — and recorded.
- An append-only audit log. Every roster load, every question opened or closed, every ballot cast or changed, and every rejected attempt is written down and never altered.
- Controlled access. Delegates check in against a pre-loaded roster; the teller dashboard is limited to named addresses.
- Reconciliation, not just a tally. Every run ends with an export built to be set, line by line, against the official result.
What’s next
Today — v1. The roster, check-in, voting, the teller dashboard, and live results are built and running. Export and reconciliation tooling completes v1.
Next — v2, anonymity. The property worth reaching for is the one the clicker vendors sell: verifiable turnout with unlinkable ballots — proving that a known number of eligible delegates voted, while no stored data ties any ballot to a person. Two directions are under consideration:
- Tokenized separation. Check-in issues each delegate one anonymous voting token and keeps no record linking token to delegate. Ballots are cast by token, against a table with no delegate column at all.
- Blind signatures. A more trust-minimizing approach, where the server signs a delegate’s voting token without ever seeing it.
These are directions, not commitments — the details are still open, and v2 would run behind a feature flag with v1 as the default.
An honest limit. Teller is built for a zero-stakes process test. Were it ever to move toward real, binding, contested votes, the right step would not be home-grown cryptography — it would be adopting a proven, end-to-end-verifiable system, or building on a vetted toolkit. The anonymity work is for understanding the problem well, not for protecting a contested result.