Sortition Proof Layer
What
A cryptographically verifiable layer that wraps around existing sortition systems, to generate publicly auditable proofs that participant selection was both random and representative, without revealing participant identities. Works as middleware between participant databases and any selection algorithm.
Why
Build trust in deliberative processes ↑, enable independent verification of fairness ↑, reduce accusations of selection manipulation ↓ and demonstrate methodological rigor ↑, strengthening legitimacy of deliberative process ↑.
Problem Definition
Selection happens behind closed doors. Even well-intentioned practitioners can’t prove they didn’t manipulate results. The commissioning authority and wider public must trust that organizers conducted selection fairly. Current solutions are cumbersome and require trusted human verifiers.
Definition of Success
Having this layer be compatible with the major sortition tools/platforms and having 50+ processes using this verification layer within 2 years. Practitioners keep existing workflows, it just adds a verification step. Prevents process delegitimization that could waste $100K-$1M+ in assembly costs.
Requirements
- Accepts data from any source (CRM export, spreadsheet), outputs to any selection tool.
- Easy integration with existing tools (e.g., Lottery Lab/Panelot) with a plugin/API model.
- User-friendly verification interface (non-technical users can check proofs) and open-source implementation for community audit.
- Having a ‘selection transparency report’ generator as a default artifact.
- Zero-knowledge proofs for stratification verification without revealing individual demographics.
- Ideally establish field-wide agreement on what constitutes ‘sufficient proof’.
- Challenges: protecting participants’ data privacy; supporting various selection algorithms without requiring tool rewrites; making cryptographic proofs comprehensible to non-technical commissioners and publics; and convincing process organizers/practitioners to add verification step to existing workflows.
Existing Limitations
Currently, the public, process organizers and commissioning authorities must trust the sortition software and the organization conducting sortition. Current tools are open source but most actors are not able to verify integrity for themselves. Practitioners invest time learning existing tools, and asking them to switch platforms could create adoption barriers. The verification layer approach could let them keep familiar workflows while gaining cryptographic guarantees.
Milestones
- Build verification layer with proof generation, basic verification interface
- Build connectors for existing sortition tools with standardized data formats
- Build the public verification portal with report materials for non-technical audiences and documentation for process organizers/commissioning authorities.
- Run 5-7 real processes with verification layer across different existing tools, gather feedback, and iterate.
Starting Points
- Document 8-10 most common sortition approaches (Sortition Foundation tools, Excel-based, custom scripts) and their data formats.
- Interview/workshop with process organizers for agreement on what constitutes ‘sufficient proof’.
- Design middleware that’s tool-agnostic (input: eligible pool + stratification targets; output: verifiable randomness seed + proofs).