Petitions, repository governance ballots, and employee organising lists fail the same way: the host platform retains a signer database that outlives the campaign, and that database becomes the compelled-disclosure surface. The Resilient Civic Participation Protocol checks eligibility against a stated credential, keeps signer participation unlinkable across petitions, and lets a future verifier reconstruct the outcome from L1 state after the platform shuts down. The committee escrows a bounty; Resolvers compete for it by computing the resolution SNARK, which emits the outcome bit and per-class component bits as public inputs. The deploying institution holds no signer roster and no compelled-disclosure surface. Cost moves from per-signer operator overhead to amortised batch publication plus a one-time bounty. Operator-mediated platforms apply where no credential layer is available or the deployment cannot accept the EIP-4844 retention boundary.
The engineering work splits across five surfaces: the signer client with its forward-secure tree, the signer SNARK with credential-membership and predicate gadgets, the batch SNARK with cross-field decomposition between the proving curve and the blob field, the Registry contract holding roots and the bounty escrow, and the resolution SNARK over the full leaf set. The proving stack is Noir over UltraHonk, the same toolchain Aztec and several institutional pilots already build against; the blob path and dispute precompile are stock EIP-4844.
This is a perspective for legal review by the deploying institution, not legal advice. Legal exposure sits with the credential issuer (a separate use case, Resilient Identity Continuity) and the Organizer's predicate-selection policy, which determines what attribute predicates the signer SNARK enforces. The on-chain footprint is the Registry's per-signature nullifier, identity tag, and class tag carried over an EIP-4844 blob whose retention is finite; the durable record is the resolution SNARK and its public inputs. Whether the resolution SNARK satisfies admissibility or auditability for a specific regulatory regime is a per-jurisdiction question; the document does not claim sufficiency for any specific regime. Compelled disclosure of any non-Signer role (Organizer, Relayer, Resolver, Disputant) yields only public on-chain state.
Requirements
- Each signature proves eligibility under an issuer-pinned credential root with no operator in the verification path
- Signer-level participation is unlinkable across petitions and to any L1 / blob-archive observer
- The petition's outcome bit and per-class component bits are re-verifiable from L1 state alone after the host platform shuts down
- Past per-slot signer state is unrecoverable from any future device snapshot under one-way PRG security
- Mandatory class-binding partitions the threshold check by jurisdiction or group (member states for ECI, teams for repository governance, shifts for workplace organising)
Constraints
- The signing window must close inside the EIP-4844 default blob retention (4096 epochs, about 18 days) for the dispute path to operate against every published batch without voluntary-archiver dependency
- The signer's device must honour overwrite-in-place semantics for forward secrecy; copy-on-write filesystems and SSDs without TRIM degrade the bound
- Sybil resistance is delegated to the credential layer (Resilient Identity Continuity or compatible) and not redesigned per petition
- Network-layer anonymity for signer-to-relayer submissions is delegated to Tor or an equivalent anonymity network
Architectural options
Recommended
For petitions whose threat model includes compelled disclosure, successor-regime inheritance, or operator breach, default to the Resilient Civic Participation Protocol. Durability and dispute coverage come from the bounty-funded Resolver and the on-chain Registry; the deploying institution carries no signer roster after the petition closes.
Side-by-side
| Axis | Resilient Civic Participation Protocol |
|---|---|
| Maturity | concept |
| Context | both |
| Trust model | Credential issuer + L1 + blob availability |
| Privacy scope | Signer unlinkability within credential class; forward secrecy past slot |
| Performance | Batched signature aggregation; one resolution SNARK per petition |
| Operator req. | No (permissionless Organizer / Relayer / Resolver) |
| Cost class | Low (amortised per-signature; bounty pays resolution) |
| Regulatory fit | Strong for outcomes-only audit; credential-layer audit lives at the issuer |
| Failure modes | Dispute-window margin under-sizing; FSRT seed backup defeats forward secrecy |
Decision factors
- If the deployment lacks a credential layer compatible with attribute commitments, the protocol is not deployable; use an operator-mediated platform until a credential layer is in place.
- If the signing window exceeds the EIP-4844 retention margin and voluntary archival is not in scope, the dispute path loses coverage on late batches; shorten the window or use a per-signature on-chain alternative.
- If signer devices cannot honour overwrite-in-place storage (copy-on-write filesystems, SSDs without TRIM), forward secrecy degrades against forensic adversaries.
Open questions
- Predicate-match-count estimation without surveying the credential tree. Organizers must size predicates so the match count, intersected with the class partition, meets the deployment's privacy floor. What is the analytical or sampling tool for this estimate that does not itself expose credential-tree structure?
- Slot exhaustion redeployment cadence. The 24-bit global slot counter bounds protocol lifetime. What is the deployment-policy schedule for redeployment under a fresh contract instance, and how is signer-side re-enrollment cost amortised (issuer-side coordination, batched re-enrollment windows)?
- Anti-coercion under predicate disclosure. Signers in adversarial-employer or adversarial-jurisdiction settings may be compelled to sign or to abstain. Coercion-resistant resolution (MACI-style key-change) is out of scope in this protocol's reference design. What is the integration point: pre-signing key registration, in-circuit coercion-resistance gadget, or a deployment-policy layer that selects a coercion-resistant variant?
Referenced by
approaches
use cases
Last reviewed