What if we ran a national election on Nostr?

Run real elections on Nostr: private ballots, public proof, zero new infrastructure.

ABH3PO

29. Oktober 2026October 29, 2026 · 4 Min. Lesezeit4 min read

3

Not a Twitter poll.
Not a Discord reaction.

An actual election — with real voters, sealed ballots, and results that anyone can verify.

NIP-88 already gives us the tools. We just need two small upgrades.

The problem with normal Nostr polls#

NIP-88 is beautiful in its simplicity:

But if you try to run something serious with it, two things break immediately:

  1. Everyone can see the votes arrive in real time (bandwagon effect + timing attacks)

  2. The voting keys are usually just throwaway npubs that someone handed out — meaning there’s still a human who knows who got which key

That’s fine for “pineapple on pizza?”
It’s not fine for choosing a government.

The fix: Blinded IDs + Sealed Ballot Box#

Here’s how you actually run an election on Nostr.

1. The Blinded ID Issuer

Instead of asking people to make their own throwaway keys (or having some admin hand them out), you run a disposable program:

What remains is just a list of anonymous voting credentials.
No one — not even the issuer — can link a key back to a real identity after the program is gone.

To make this verifiable, the issuer can run inside a Trusted Execution Environment (TEE). The TEE can produce an attestation proving that the correct open-source code ran, that it generated the keys, published only the public keys, and then wiped the private material. Anyone can check the attestation instead of just trusting the operator.

2. Relays that keep the box closed

The poll still uses normal NIP-88.
But the relays you point it at agree to one extra rule:

> Do not serve any vote events until the official endsAt timestamp.

Until the deadline hits, the ballot box is sealed.
No intermediate results. No last-minute swings. No real-time surveillance of who is voting.

After the deadline, the relays open the box. Anyone can download every vote, filter by the published list of allowed public keys, apply the normal one-vote-per-pubkey rule, and get the exact same result.

The full process looks like this:#

  1. Finalize the voter roll

  2. Run the blinded issuer (ideally inside a TEE) → get a clean list of public keys

  3. Publish that list

  4. Create a normal NIP-88 poll pointing at the sealed relays

  5. People vote with the private keys they received

  6. After the deadline, the results become public and fully verifiable

That’s it.

No new event kinds.
No special cryptography beyond what Nostr already has.
Just better key hygiene and better relay policy.

Why would anyone actually want this?#

Because it gives you properties that almost no current election system has at the same time:

In short: you get cryptographic auditability and real privacy and resistance to interference, without inventing a new blockchain or forcing citizens to install experimental apps.

Is this perfect?#

You tell us?

coercion/vote-selling is still a human problem, not a protocol problem.

But compared to every other “blockchain voting” scheme that requires new tokens, zero-knowledge circuits, or trusted hardware… this is almost offensively simple.

And it already works with the clients people use today.

So yeah.
What if we actually ran a national election on Nostr?

The tools are already here.
We just have to use them properly.

Written by

Comments3

AU9913

Actually I had an idea where the whole govt should be ran on nostr and anyone in government actually has a 100 yard restraining order on anyone else in govt and they can only communicate digitally over nostr. Any violation would be life ruining. Couple it with moving the capital to St Louis, Missouri (but since all politicians are remote, not important). Each state runs their own relay (or cluster of them) funded by federal tax dollars, but executed by the state.
Open in a Nostr client

codonaft

> physical letter ECDH using paper letters? 😅 This is awesome. The bandwagon effect is a big concern for me in particular. I remember I asked for something similar on security dot stackexchange but received no satisfying response. I'm not sure if I got it right: a sealed relay just doesn't allow REQ until a deadline? Or it's something more complex, something similar to NIP-59? A relay operator (or somebody malicious that gets access to it) still could leak intermediate results if they are available there. Did you possibly mean running the entire relay in the TEE?
Open in a Nostr client