Skip to main content

​
GET /polls//confirm

Returns the current confirmed receipt count for a poll. Response 
{ "confirmed_count": 1731 }

​
Submitting a receipt confirmation (TxType = 5)

Voters submit a TxTypeConfirmReceipt transaction after poll close to acknowledge that their identity_hash appears in the voter registry (List 2). 
{
  "type": 5,
  "signature": "<voter-device-sig>",
  "data": {
    "poll_id": "referendum-2026-1",
    "identity_hash": "<MiMC(person_secret, poll_id)>"
  }
}

​
Why this mechanism matters

The receipt confirmation mechanism is structurally present in the two-list protocol — it requires no new oracle, no biometrics, and no ZK. The voter simply checks that their ZK nullifier (identity_hash) exists in the public voter registry. What the gap signals: 
confirmed_count K  ←  voters who acknowledged their participation
total_votes N      ←  records in voterRegistry (List 2)

Sybil gap = N - K
A large gap suggests fabricated participation: Sybil identities cannot confirm receipts because their person_secret was never held by a real voter. A small gap indicates that most participation was genuine — voters confirmed what they expected to see.

​
Information disclosure

Receipt confirmation reveals zero new information per voter:
  • identity_hash is already public in List 2 (participation in a poll is a ToS disclosure)
  • Confirming that your own nullifier is present tells no one anything they didn’t already know
The aggregate K/N ratio is the useful signal — not any individual confirmation.