Security & Privacy
How we ensure anonymity and protect voter data
Security First — What the Cryptography Proves
Security and privacy are not optional features at Agora — they are the product. Anonymous votes, posts and comments each carry a cryptographic proof before they are recorded: a Semaphore membership proof, a blind-signed admission credential, or both. Actions you take under your own name are recorded as yours, and this page is explicit about which is which.
Cryptography settles what a server would otherwise have to be trusted for: that a voter belongs to the group and that a fee was paid. Double voting is refused by a uniqueness constraint we hold rather than by the proof, so that one rests on us. It does not put Agora outside the trust boundary — we run the database and can see when an account is active. So the honest claim is that your ballot is unlinkable to other members and to the public, and that where a guarantee depends on us behaving, this page says so rather than implying otherwise.
The pillars below cover anonymous voting (Semaphore v4), blind-signed admission credentials with an enforced anonymity floor, Canton ledger integrity, privacy-preserving analytics (k ≥ 25), shielded fee proofs, verifiability, and one capability still in development. Read them as a description of the implemented protocol rather than of a running deployment: the second-generation anonymous action stack is built and tested, but it has not yet been cut over to production and has not yet carried a production vote.
Semaphore v4 Zero-Knowledge Proofs
Client-side proof generation — the plaintext secret stays on your device; the identity backup we require is encrypted with your own password before it is sent
Security Guarantees:
- Identity commitment is a Poseidon hash — not reversible
- ZK proof verifies membership without identity disclosure
- Nullifier makes a repeat ballot recognisable; what refuses it is a uniqueness constraint in our own database, not the proof
- Client-side proof generation — secrets never leave the device
- ZK proofs validated before anchoring on the Canton ledger
Blind-Signed Admission Credentials
Rate limiting without a name attached. Credentials are issued to your account in fixed batches and blind-signed, so the service that hands them out cannot recognise them when they are spent. The private key that signs them lives in a separate process the backend reaches only over mutual TLS, and the keys it uses are published in a signed, hash-chained manifest — the newer scheme adds an append-only transparency log built for outside witnesses to countersign, though no independent witness is running yet. An action is held back until enough different people hold credentials for the same period, so nobody is ever the only candidate.
Security Guarantees:
- RFC 9474 blind signatures — the credential carries nothing that ties a spend back to its issuance
- A fixed number of single-use credentials per account, per period
- An action is refused until the anonymity set reaches its floor
- One signing key per capability class per period — never per person and never per community, so every community shares the largest cohort available
Pseudonymous Reputation (in development)
Reputation is designed to be shown as a proof rather than a profile — prove you are above a threshold without revealing who you are. The circuits are written but their proving keys are not yet generated, so this is on the roadmap rather than in the running system.
Security Guarantees:
- Per-period pseudonyms, so reputation does not become a lasting handle
- Prove reputation is above a threshold without disclosing the score
- Sybil resistance through cost rather than identity checks
- Status: circuits written, proving keys not yet built
Canton Ledger Immutability
Votes and settlement records are anchored on Agora's live Canton Network mainnet validator through a DAML attribution ledger. Records are tamper-evident and independently verifiable by the parties to them.
Security Guarantees:
- Cryptographically secured by the Canton Network
- Anchored on a DAML attribution ledger — tamper-evident audit trail
- Vote receipts on the Canton ledger — batch roots (BatchAnchored), or one VoteRecorded per vote in direct mode, submitted by the organisation's party rather than the voter's; on a sealed poll these are held back until voting closes, because each ballot's arrival time is what would pair with a registration list
- Validator submission keys are held by the validator node itself; a managed-KMS custody path is drafted in deployment config but not wired
k-Anonymity Analytics (k ≥ 25)
Organisation dashboards run the cohort analytics through a k ≥ 25 guard: rows whose cohort is smaller than that are dropped, and a nonzero count below 25 is bucketed rather than shown exactly — rounded to the nearest 5, never below 5. Bucketing says the true count sits in a band, not that 25 people share the answer, and the guard covers the cohort analytics that report a floor rather than every reported figure. Free-text answers are a deliberate exception — they are shown to other respondents as written, so treat them as public within the poll.
Security Guarantees:
- Community, social and demographic dashboards pass a k ≥ 25 guard: cohorts below it are withheld, smaller counts bucketed to the nearest 5
- Event store + schema registry for auditable aggregation
- Daily aggregate tables (PollDailyAggregate, CommunityDailyAggregate, PostDailyAggregate)
- Raw events purged after aggregation window
Shielded Fee Proofs
Per-action fees are paid from a shielded pool rather than at the moment you act. You deposit in advance, and spending proves you hold an unspent deposit without revealing which one — so paying a fee does not put a timestamp next to your action.
Security Guarantees:
- Deposit and spend are separated in time
- Groth16 proof over a Poseidon2 commitment tree
- Fixed denominations, so the amount is not a fingerprint
- Settlement recorded on a DAML attribution ledger
Verifiability — and Who Can Check the Record
Vote receipts are recorded on Agora's live Canton mainnet validator through a DAML attribution ledger, so counts are tamper-evident rather than taken on trust. Daml visibility is scoped to the parties of a record, and the party on a vote anchor is the organisation that ran the poll — so it and Agora's validator can check the record, not the individual voter and not the public.
Security Guarantees:
- DAML attribution ledger records every vote receipt
- ZK proofs verified before anchoring on the Canton ledger
- Merkle tree root validation
- A per-poll evidence bundle, built once after results unseal and served as the exact stored bytes, checkable with an offline verifier — the public tier carries no per-ballot rows, because a public per-ballot transcript would be a receipt oracle
Privacy Guarantees
Identity Protection
Your identity here is a commitment — a Poseidon hash derived from a secret your device holds — and it registers you into a members' tree. The ballot itself carries neither that commitment nor an account id: a vote row holds a nullifier, derived from the same secret and this poll. The register that maps accounts to commitments lives in Agora's database, which is why this protects you from other members rather than from us.
Vote Anonymity
Your ballot is stored apart from your account: the vote row carries no user reference, only a nullifier proving it was cast once. That makes it unlinkable to other members and to anyone reading the ledger. Agora operates the database, so we are inside the trust boundary rather than outside it.
No Shared Identifier Across Polls
Each vote carries a nullifier derived from that poll, so your ballots in two different polls share no common identifier. What could still link them sits outside that nullifier: both submissions reach the gateway over plain HTTPS from your address, and each ballot stores a generalised demographic profile floored to a cohort within its own poll, not across polls. In a small group, when and how often you take part narrows the field too — anonymity comes from the size of the crowd as well as the cryptography.
Last Vote Counts, Where It Is Enabled — On a sealed-results poll whose organiser switched this on at creation — it cannot be switched on later — you can cast a new ballot until voting closes, and only the last one is counted. The change is not announced: an accepted revote returns the same response as a first ballot, and no organiser view and no published result carries a revote count. The replaced ballot row is kept in Agora's database for the audit trail, so this hides the change from other members and from anyone reading the published record, not from us. It is a deterrence measure with the same known limits as Estonia's scheme: someone who watches you until voting closes, or who simply stops you voting, is not defeated by it.
Coercion Resistance: NOT CLAIMED. What is true is narrower: Agora hands nobody a per-voter breakdown, and you hold no receipt that proves how you voted, so the platform has nothing to give a coercer who asks it for one. Two limits we state rather than hide: a voter who cooperates can prove their own ballot to a third party by showing the circuit inputs they hold and reproducing the proof; and because the anonymous identity is derived from your recovery words, whoever holds those words derives the same identity and can check the vote that was cast. Where the organiser enabled it you can quietly replace your ballot until the poll closes and only the last one counts — deterrence, not a guarantee.
Security Measures
Cryptographic Security
- Semaphore v4 membership proofs; RLN spam limiting on the v1 lane only, where the identity commitment sits beside the user id so a post is attributable by the operator; the UniRep-inspired reputation circuits are written but the epoch-transition circuit is unbuilt
- Poseidon2 hash function for commitments
- EdDSA signatures + Groth16 verification
- Merkle tree depth 20 (supports 1M+ members per group)
- crypto.randomInt() (not Math.random) across all ZK paths
Ledger & Settlement Security
- DAML settlement package on Agora's live Canton mainnet validator
- Canton Coin settlement with a shielded fee pool (Poseidon2 + Merkle proofs)
- DAML contract authorization on privileged settlement operations
- Canton validator signing keys are held by the validator node; managed KMS custody is planned, not yet wired
- Vote receipts (BatchAnchored / VoteRecorded) anchored on the DAML ledger
- Third-party settlement & token-design security audit — planned, not yet scheduled
Infrastructure Security
- HTTPS/TLS encryption for all communications
- Validator signing keys held by the node itself; managed KMS custody is planned, not yet enabled
- Rate limiting: application-level throttling; RLN on the older v1 post and comment routes; per-account, per-epoch credential quotas on the v2 action path
- Prometheus + Grafana monitoring for the prover, validator, and settlement pipeline
- Proof verification runs server-side and fails closed: without a loaded verification key, the proof is rejected
Audit & Verification
Agora's security model is built to be checked rather than taken on trust: the Semaphore protocol and the RFC-standardised blind-signature schemes it builds on are public and externally audited, while Agora's own settlement templates and circuits are not published — open-sourcing components is a stated plan rather than shipped work, and the Agora integration itself has not yet had an independent audit:
Settlement Ledger
- DAML settlement package — source not yet published; open-sourcing is planned
- Anchored on Agora's live Canton mainnet validator
- Third-party audit recommendations
ZK Circuits
- Semaphore protocol (battle-tested)
- Six circom circuits — proving artifacts are downloadable; the source is not published
- Semaphore v4 proofs verify against the verification key from the protocol's public MPC ceremony, which Agora did not run; Agora's own circuit setup is single-host, not a multi-party ceremony
Security Best Practices
Users should always use official frontends and keep their identity secrets and keys secure. Never share your identity secret or private keys with anyone.
Resetting Your Identity — Threat: your identity secret is exposed, so you ask for an identity reset. Mitigation: partial, and the limit is worth stating. An approved reset clears the guard rows binding your account to its old commitment, which frees you to bind a fresh one on your next action; it does not withdraw the old commitment from any group it had already been enrolled in. In a sealed poll the eligible set is fixed when registration closes and late registrations are refused, so a reset after that moment leaves the old secret as the only one that can vote in that poll. A reset protects the groups and polls you join next, not the ones you had already joined.
Backend Compromise
Threat: Attacker gains access to backend database and servers.
Mitigation: Identity secrets are generated on the device, and the only copy that reaches us is a vault encrypted client-side under a key we never hold — so an attacker with the database still cannot forge a ballot, because proof verification enforces unforgeability rather than our good behaviour, and that holds against everyone including us. Recasting is weaker than it looks: nothing inside verification rejects a repeat, and what refuses the second ballot is a unique index in our own database — solid against another member, a row we could delete. Unlinkability is narrower too: the account-to-commitment register sits in that same database, which is why the threat model names our own backend as the adversary. Canton ledger verification is independent of the backend.
Canton Network Attack
Threat: Consensus attack or settlement-logic exploit.
Mitigation: Canton's security model and DAML authorization rules. Records are append-only, so a retroactive edit would be visible to a party that can read them — today that is the organisation that ran the poll plus Agora's validator, because every Agora template is signatory-only with no observers and nothing reads the vote anchors back.
Identity Correlation
Threat: Attempts to link votes to identities through metadata or timing analysis.
Mitigation: Against other members and the public, ZK proofs and Merkle membership hide which voter cast which ballot, and a repeat under the same nullifier is caught by a unique database index rather than by the proof — refused on an ordinary poll, and treated as a replacement on a sealed poll whose policy lets a voter change their vote. Against the operator this is weaker on two counts: a registration table maps an account to its commitment, and an anonymous submit reaches the gateway over plain HTTPS, so we see the source IP — an authenticated session and an anonymous submit from the same address seconds apart can be joined by timestamp. We do not claim unlinkability against ourselves, and closing the network half needs a third-party relay we have not built.
Comprehensive Risk Analysis
Technical Risks
ZK Proof Complexity
Risk: ZK proof generation requires significant computational resources, especially on mobile devices. Complex proofs may take 10-30 seconds to generate.
Mitigation: Client-side proof generation with progress indicators. Optimized Semaphore circuits. Future mobile optimizations planned.
Settlement Costs
Risk: High settlement costs on public blockchains can limit accessibility. Agora avoids this by settling on the Canton Network.
Mitigation: Settlement on the Canton Network avoids public-chain fee markets. Batched anchoring keeps per-action overhead low. Fees settle privately in Canton Coin.
Scalability Limitations
Risk: Merkle tree depth of 20 supports up to 1,048,576 voters per poll. Very large polls may face performance challenges.
Mitigation: Batch processing for large polls. Off-chain aggregation with verification anchored on the Canton ledger. Future support for larger tree depths.
Settlement Logic Vulnerabilities
Risk: Potential bugs in settlement logic could compromise vote integrity.
Mitigation: DAML settlement logic with comprehensive testing. Planned third-party audits. Formal verification for critical settlement functions.
Regulatory & Legal Risks
Voting Regulations
Risk: Different jurisdictions have varying regulations for electronic voting. Some may require specific certifications or compliance.
Mitigation: Platform designed for non-binding polls and surveys. Legal consultation for binding vote use cases. Compliance framework development.
Securities Regulations
Risk: AGR token may be subject to securities regulations in some jurisdictions.
Mitigation: Token designed as utility token for platform use. Legal review of token structure. Compliance with applicable regulations.
Data Protection Laws
Risk: GDPR, CCPA, and other data protection regulations may apply to user data.
Mitigation: Privacy-by-design architecture. Minimal data collection. Anonymization through ZK proofs. Compliance framework development.
Market & Adoption Risks
Low Adoption
Risk: Platform may struggle to gain traction if users don't see value or find it too complex.
Mitigation: User-friendly interfaces. Educational content. Incentive mechanisms (token rewards). Strategic partnerships. Community building.
Competition
Risk: Established platforms (Snapshot, Aragon) or new competitors may capture market share.
Mitigation: Unique value proposition: ZK proofs and nullifiers keep a ballot unlinkable to other members and to anyone reading the ledger, and the operator boundary is stated rather than hidden. Continuous engineering investment. Strong community engagement.
Token Economy Design
Risk: The AGR token economy is still in design. Miscalibrated fee or reward parameters could affect platform sustainability if introduced prematurely.
Mitigation: The token economy remains in design and is not yet deployed. Parameters will be modeled, reviewed, and phased in gradually — the platform runs fully on Canton settlement in the meantime.
Operational Risks
Infrastructure Failures
Risk: Backend servers, databases, or Canton Network issues could disrupt service.
Mitigation: Redundant infrastructure. Monitoring and alerting. Disaster recovery plans. Canton Network decentralization reduces single points of failure.
Key Personnel Risk
Risk: Loss of key team members could impact development and operations.
Mitigation: Documentation and knowledge sharing. Team expansion. Community contributions. Future decentralization.
Treasury Management
Risk: Poor treasury management could deplete reserves and affect sustainability.
Mitigation: Automated dynamic reward system. Minimum reserve requirements (40%). Transparent treasury reporting. Future DAO governance.