@misc{engineering2026sovereign,
  author = {System9 Engineering},
  title = {SOVEREIGN: Distributing Trust in E2E-V Elections},
  year = {2026},
  url = {https://system9.ai/research/sovereign-workshop-paper},
  howpublished = {\\url\{https://system9.ai/research/sovereign-workshop-paper\}},
  note = {Draft, in preparation}
}

SOVEREIGN: Distributing Trust in E2E-V Elections Across Independent Cryptographic Cells

Abstract

End-to-end verifiable (E2E-V) voting systems provide ballot secrecy, verifiability, and eligibility enforcement, but all deployed systems -- ElectionGuard, Helios, Belenios -- assume centralized trust within a single administrative domain. This architectural limitation excludes federal elections spanning sovereign jurisdictions, military operations on disconnected networks, and international organizations crossing legal boundaries. We present SOVEREIGN, a distributed E2E-V system that partitions trust across independent cryptographic cells organized in a three-level hierarchy (nodes, service groups, cells). Each cell operates autonomously during voting, collecting Paillier-encrypted ballots and verifying zero-knowledge proofs without contacting other cells. Elections are governed by formal entity contracts following the AAMAS 2026 seven-tuple model, replacing procedural checklists with machine-enforced, cryptographically attested governance. Homomorphic tallies are accumulated per-cell and verified across cells through a consensus protocol, with threshold decryption ensuring no single cell holds sufficient key material. We evaluate SOVEREIGN with 122 tests across 17 files and demonstrate sub-second per-voter cryptographic cost with tallying latency independent of election size. SOVEREIGN is the first E2E-V system to combine distributed multi-jurisdictional trust, formal contract governance, and disconnected operation.

1. Introduction

Democratic decision-making -- from national elections to corporate governance to military field votes -- requires systems that simultaneously guarantee ballot secrecy, verifiable integrity, and eligibility enforcement. The past two decades have produced landmark E2E-V systems: Helios [1] demonstrated web-based open-audit voting, ElectionGuard [2] integrated E2E-V with existing election hardware, and Belenios [3] added threshold trustees with UC-framework proofs. Each system advanced the field significantly.

Yet all three share a fundamental architectural constraint: they assume a unified administrative domain. The server infrastructure, key holders, and bulletin board are operated by a single organization or a small set of cooperating organizations. There is no mechanism for distributing trust across mutually distrustful jurisdictions -- a requirement for federal elections where states do not share infrastructure, international organizations where member states operate under different legal frameworks, and military operations where tactical networks are intermittent.

This constraint is not incidental. Centralized architectures simplify key management, bulletin board consistency, and tally verification. Distributing these functions across independent, potentially disconnected nodes introduces challenges that existing E2E-V protocols were not designed to address: How are key shares distributed across jurisdictions that do not trust each other? How are encrypted ballots collected and tallied when cells cannot communicate during voting? How are election rules enforced consistently across independent systems?

SOVEREIGN addresses these challenges through two innovations. First, it maps jurisdictional hierarchy to a three-level cell topology where each cell is an autonomous trust boundary running its own cryptographic services. Key shares are distributed across cells via Shamir sharing over the integers with the Damgard-Jurik Delta scheme, ensuring no single cell or service group holds sufficient material to decrypt. Cells collect encrypted ballots independently and synchronize asynchronously via delay-tolerant networking.

Second, SOVEREIGN governs elections through formal entity contracts following the AAMAS 2026 seven-tuple model [4]. Each election is bound by a machine-readable contract specifying ballot format (I), tally structure (O), tallying algorithm (S), resource constraints (R), temporal bounds (T), success criteria (Phi), and termination conditions (Psi). Contract compliance is verified automatically and attested cryptographically, replacing the procedural compliance model -- human-enforced checklists that are unverifiable after the fact -- used by all existing E2E-V systems.

Our contributions are:

1. Distributed E2E-V architecture with independent cells operating as sovereign trust boundaries, supporting disconnected operation during voting and asynchronous synchronization for tallying.
2. Entity contract governance that makes election rules machine-enforced, auditable, and consistent across jurisdictions.
3. Per-cell homomorphic accumulation with cross-cell consensus verification, enabling distributed tallying without revealing per-cell subtallies.
4. Implementation and evaluation demonstrating feasibility with 122 tests and benchmarks showing tallying latency independent of election size.

2. Background

2.1 End-to-End Verifiable Voting

An E2E-V system provides three guarantees: individual verifiability (each voter confirms their ballot was recorded as cast), universal verifiability (any observer confirms the tally reflects recorded ballots), and ballot secrecy (no observer determines any individual vote). The tension between verifiability and secrecy is resolved through homomorphic encryption: ballots are encrypted so individual votes are hidden, but the homomorphic property allows computing the tally over ciphertexts. The result is decrypted through threshold ceremonies where the private key is never assembled.

2.2 Existing Systems

ElectionGuard [2] uses ElGamal encryption over elliptic curves with threshold key management via Shamir sharing and Lagrange interpolation. It integrates with existing election hardware as an add-on verification layer. It supports only plurality voting, operates within a single administrative domain, and does not address coercion resistance or disconnected operation.

Helios [1] pioneered web-based open-audit elections with browser-side encryption. It provides individual and universal verifiability but lacks threshold decryption (a single party holds the key), does not address coercion, and trusts the server with encryption randomness if the browser is compromised.

Belenios [3] extends Helios with threshold ElGamal and UC-framework proofs. It supports plurality and majority judgment. Its UC proofs are stronger than game-based arguments, and it has Coq-verified implementations. However, it operates on centralized infrastructure and does not support disconnected operation or multiple election types beyond two.

2.3 Entity Contracts

The AAMAS 2026 seven-tuple contract model [4] specifies agreements between autonomous agents: C = (I, O, S, R, T, Phi, Psi). SOVEREIGN applies this model to elections, binding the election authority and tallying agent to formally specified, machine-enforceable terms. This provides auditable governance that goes beyond procedural compliance -- an auditor can cryptographically verify that the declared rules were applied to the declared inputs to produce the declared output.

3. Architecture

3.1 Multi-Cell Topology

SOVEREIGN maps jurisdictional hierarchy to the System9 platform's three-level topology:

Level	Example (Federal)	Example (Corporate)	Role
Node	State	Division	Sovereign jurisdiction; logical, spans physical infrastructure
Service Group	County	Department	Administrative district; replication boundary
Cell	Precinct	Office	Physical deployment unit; fundamental trust boundary

Each cell runs its own SOVEREIGN services, databases, and cryptographic operations. Compromising one cell does not compromise others. The mapping is flexible: a board vote uses a single cell; a national election uses thousands of cells across hundreds of service groups.

Sovereignty invariant. Each cell operates autonomously during the voting phase: it collects encrypted ballots, verifies ZK proofs, and records entries to its local bulletin board segment without contacting other cells. This invariant is critical for disconnected operation -- a cell in a forward-deployed military unit continues accepting votes when connectivity is lost. Synchronization occurs asynchronously when connectivity is restored.

Bulletin board. The bulletin board is an append-only public log replicated across cells. Each entry is protected by an HMAC hash chain: entry_i.hmac incorporates entry_{i-1}.hmac, creating a tamper-evident chain. Any party can read the board and independently verify the election.

3.2 Entity Contracts for Election Governance

Each election is governed by a formal entity contract mapping election parameters to the AAMAS 2026 seven-tuple:

Tuple	Election Meaning	Enforcement
I (Input)	Ballot format, field types, race/choice schema	Ballot recorder rejects non-conforming ballots
O (Output)	Tally format, minimum completeness = 1.0	Attestation verifies completeness
S (Skills)	Tallying algorithm (e.g., tally:ranked_choice)	Agent selection validates capability
R (Resources)	Max operations = eligible voter count	Contract layer enforces ceiling
T (Temporal)	Election open/close window	Contract rejects out-of-window ballots
Phi (Success)	100% inclusion, quorum satisfaction	Attestation verifies criteria
Psi (Termination)	Timeout extends, violation escalates	Exception handler executes policy

The contract is published to the bulletin board during setup. During attestation, compliance is verified and cryptographically bound to the result. This shifts governance from "trust that procedures were followed" to "verify that the contract was satisfied."

Multi-jurisdictional consistency. In a distributed election, each node operates under the same contract (published on the shared bulletin board). Any observer can compare the contract used by each node against the published version. Discrepancies trigger investigation via Psi termination conditions.

3.3 Threat Model

We consider a computationally bounded adversary A with network observation (A sees all traffic and the bulletin board), threshold corruption (A corrupts up to M-1 of N key share holders), cell compromise (A compromises individual cells but not M or more total share holders), voter coercion (A demands specific votes), and registration observation (A observes registration but cannot compromise signing keys).

Trust assumptions: honest registration authority (one credential per voter), honest threshold (M of N holders honest), random oracle model (SHA-256 for Fiat-Shamir), append-only bulletin board (HMAC chain), and voter device integrity (correct encryption).

4. Protocol Overview

SOVEREIGN proceeds in five phases. We summarize the protocol here; the full cryptographic details (Paillier key generation, ZK proof construction, Lagrange combination) appear in the companion paper [5].

Setup. The election authority generates a Paillier keypair at the configured security level (2048-bit for production). The private key is immediately split into N shares with threshold M via Shamir sharing over the integers. Each share is distributed to a designated holder on a separate cell. The original private key is securely erased. The authority generates an RSA keypair for blind signatures, creates the election contract, and publishes the election definition to the bulletin board.

Registration. For each eligible voter, the eligibility checker applies four filters: duplicate ballot guard, entity type restriction, explicit allow-list, and live entity lookup. For anonymous elections, the voter generates a random token, blinds it, obtains a blind RSA signature from the authority, and unblinds to get a valid signed token. The authority never sees the original token. For coercion-resistant elections, the authority additionally issues a real HMAC-based JCJ credential; the voter may generate indistinguishable fake credentials for use under duress.

Voting. The voter encrypts each selection (0 or 1) using Paillier with fresh randomness, generates a disjunctive Sigma protocol ZK proof for each ciphertext (proving it encrypts 0 or 1 without revealing which), assembles the ballot with the anonymous token, and submits to the local cell's ballot recorder. The recorder writes to the append-only journal with an HMAC integrity signature. The voter receives a receipt containing (ballot_id, SHA-256(encrypted_payload), timestamp) that reveals nothing about the vote.

Tallying. After the election closes, the homomorphic tally engine verifies each ballot's ZK proof and anonymous token, rejecting invalid entries. For each race and choice, it multiplies all valid ciphertexts modulo n^2, producing an encryption of the count without decryption. Encrypted tallies are published to the bulletin board.

Decryption and verification. Each of M share holders computes a partial decryption on their own machine using the Damgard-Jurik Delta scheme -- the share value never leaves the holder's machine. The combiner collects M partial decryptions and recovers the plaintext via Lagrange interpolation in the exponent. Voters verify receipts; observers verify all ZK proofs, recompute the homomorphic sum, and check decryption proofs. A signed attestation binds the result hash, journal hash chain, and contract_id.

5. Distributed Tallying

The distributed tallying protocol is SOVEREIGN's core architectural contribution, enabling trust distribution across independent cells while maintaining the homomorphic tallying guarantees of centralized systems.

5.1 Per-Cell Homomorphic Accumulation

Each cell independently accumulates its local encrypted ballots:

CellTally(cell_k, pk):
  T_k = E(0)                           // identity element
  for each valid ballot b_i in cell_k:
    verify ZK_proof(b_i)               // reject if invalid
    verify token(b_i)                  // reject if unauthorized
    T_k = T_k * c_i mod n^2           // homomorphic add
  publish (cell_id, T_k, count_k, proof_hash) to bulletin board
  return T_k

This per-cell accumulation is the key to disconnected operation: each cell computes its subtally using only local data. No inter-cell communication is required during the voting or per-cell tallying phases. The subtally T_k = E(sum of votes in cell k) is an encryption of the local count, revealing nothing about individual votes or the count itself.

The per-cell subtally is published to the bulletin board with the count of included ballots, allowing observers to verify that the number of tallied ballots matches the number of recorded ballots for that cell.

5.2 Cross-Cell Consensus Verification

After all cells have published their subtallies, a global tally is computed:

GlobalTally({T_1, ..., T_C}, pk):
  T_global = product(T_k) mod n^2      // homomorphic sum of subtallies
  // Verify: sum(count_k) matches total ballot count on bulletin board
  // Verify: each T_k was computed from the correct set of ballots
  publish T_global to bulletin board
  return T_global

The homomorphic property guarantees correctness: product(E(sum_k)) = E(sum(sum_k)) = E(total_count). Any observer can independently verify the global tally by:

1. Reading each cell's subtally from the bulletin board.
2. Multiplying all subtallies modulo n^2.
3. Comparing with the published global tally.
4. Verifying that the sum of per-cell ballot counts matches the total.

Discrepancies indicate either a compromised cell or a replication error. Because the bulletin board is an HMAC hash chain, tampering with any entry is detectable.

Subtally privacy. Individual per-cell subtallies are encrypted. They are never decrypted separately -- only the global tally undergoes threshold decryption. This prevents the adversary from learning vote distributions within individual cells, which could enable demographic inference attacks (e.g., learning how a particular precinct voted). If per-cell results are desired (as in some jurisdictions), the threshold decryption ceremony can be applied to subtallies individually, but this is a policy decision governed by the election contract.

5.3 Disconnected Operation via DTN

SOVEREIGN's delay-tolerant networking model operates in three phases:

Phase 1: Disconnected voting. Each cell collects encrypted ballots locally. All per-ballot cryptographic operations (Paillier encryption, ZK proof generation, blind token verification) use only the public key and local randomness. No network access is required.

Phase 2: Asynchronous synchronization. When connectivity is restored, cells replicate their bulletin board segments to the shared board. The HMAC hash chain ensures integrity: each entry's HMAC incorporates the previous entry, so any modification or deletion during transit is detectable. The System9 replication layer handles conflict resolution for concurrent bulletin board updates across cells.

Phase 3: Coordinated tallying. Once all cells (or a sufficient subset) have synchronized, the global tally is computed and threshold decryption proceeds. The threshold property means that not all cells need to be reachable -- only M of N share holders must participate.

This three-phase model makes SOVEREIGN suitable for military operations where forward-deployed units are disconnected for days, humanitarian missions in disaster zones with intermittent connectivity, and elections during infrastructure disruptions where some precincts lose network access.

Eventual consistency guarantees. The bulletin board's append-only, hash-chained structure ensures that once a cell synchronizes its entries, the entries are permanent and verifiable. Late-arriving entries from disconnected cells are appended to the board, and the global tally is recomputed. The election contract's temporal bounds (T) define when the election closes; entries arriving after the deadline are timestamped at their original recording time (per the cell's local clock, attested in the HMAC chain) and included if within bounds.

6. Evaluation

6.1 Performance

Benchmarks use 1024-bit Paillier keys on a single-core CPython runtime. Production deployments use 2048-bit keys (estimated 8x overhead).

Per-operation latency (1024-bit, single core):

Operation	Time	Notes
KeyGen	583 ms	One-time per election
Encrypt	26 ms	Per-vote, client-side
ZK Prove	102 ms	Per-vote, client-side
ZK Verify	103 ms	Per-ballot, server-side
Homomorphic Add	0.02 ms	Per-ballot accumulation
Partial Decrypt	50 ms	Per-share-holder
Combine (3-of-5)	2.5 ms	Per-race
Blind Token	0.6 ms	Per-voter registration

Election-scale benchmarks (1024-bit, single core):

Voters	Encrypt+Prove	Tally	Decrypt	Total
100	4.5 s	3 ms	33 ms	~4.5 s
1,000	30 s	20 ms	21 ms	~30 s
10,000	~5 min	~200 ms	~21 ms	~5 min

Three key observations emerge. First, encryption and proof generation dominate total time (>99%) but are client-side and embarrassingly parallel across voters and cells. With 100 cells, 10,000 voters complete encryption in approximately 3 seconds per cell. Second, homomorphic tallying is near-instant: 20ms for 1,000 ballots, confirming the O(K) cost has negligible constant factor. Third, threshold decryption is O(M) and independent of voter count: 21-33ms for 3-of-5 regardless of election size.

Distributed scalability. For K voters across C cells with M-of-N threshold:

• Voting phase: O(K/C) operations per cell, each independent
• Per-cell tallying: O(K/C) per cell, parallel
• Global aggregation: O(C) multiplications (trivial)
• Decryption: O(M), independent of K and C

At 2048-bit security with K = 10,000 and C = 100: per-cell tally ~16ms, global aggregation ~0.2ms, decryption ~170ms. The distributed architecture provides near-linear scalability with the number of cells.

Communication cost. During the voting phase, inter-cell communication is zero -- each cell operates independently. During tallying, each cell publishes one encrypted subtally per race per choice to the bulletin board. For an election with R races and J choices per race, the per-cell publication is R * J ciphertexts (each ~256 bytes at 1024-bit, ~512 bytes at 2048-bit). For a typical election with 5 races and 3 choices each, this is ~7.5 KB per cell at 2048-bit -- negligible bandwidth even over constrained tactical networks. The global aggregation step reads C subtallies and performs C-1 multiplications per race per choice, publishing one global tally. Threshold decryption requires M partial decryptions per tally entry, each approximately 256 bytes. The total decryption communication for 5 races, 3 choices, 3-of-5 threshold is ~11 KB. This low communication cost makes SOVEREIGN practical for bandwidth-constrained environments where other distributed protocols (blockchain consensus, multi-round MPC) would be prohibitive.

6.2 Deployment Scenarios

The multi-cell architecture maps to diverse deployment contexts:

Federal election (large scale). 50 nodes (states), 3,000+ service groups (counties), 100,000+ cells (precincts). Key shares: 7 (one per judicial circuit), threshold 4. Precincts collect encrypted ballots locally; counties aggregate subtallies homomorphically; states coordinate threshold decryption. The contract ensures uniform ballot format and tallying algorithm across all 50 states despite independent operation.

Military field election (disconnected). 1 node (theater command), 3 service groups (brigade areas), 9 cells (battalion positions). Key shares: 5 (1 per battalion commander + 2 at brigade), threshold 3. Cells operate disconnected for days or weeks; encrypted ballots synchronize when the tactical network is available. The DTN model ensures no votes are lost during disconnection, and the threshold property means that only 3 of 5 key holders need to be reachable for decryption.

Corporate board vote (small scale). 1 node, 1 service group, 1 cell. Key shares: 3 (board chair, corporate secretary, external auditor), threshold 2. All operations local. The contract specifies weighted voting (proportional to share ownership) and super-majority threshold for certain motions.

International organization (cross-border). 27 nodes (member states), 27 service groups (national delegations), 54 cells (primary + backup per delegation). Key shares: 9 (3 per geographic region), threshold 5. Threshold decryption requires participation from at least 5 key holders spanning at least 2 geographic regions, preventing any single region from controlling the outcome.

6.3 Comparison with Centralized Systems

Feature	SOVEREIGN	ElectionGuard	Helios	Belenios
Encryption	Paillier	ElGamal (EC)	ElGamal	ElGamal
Homomorphic tallying	Yes	Yes	Yes	Partial
Threshold decryption	Damgard-Jurik	Lagrange	No (single key)	Threshold ElGamal
Key never assembled	Yes	No	N/A	Yes
Blind signatures	RSA	No	No	No
Coercion resistance	HMAC-JCJ	No	No	Partial (RF)
Formal contracts	AAMAS 2026	No	No	No
Multi-cell distribution	Yes	No	No	No
Disconnected operation	Yes	No	No	No
Election types	7	1	1	2

SOVEREIGN's primary advantage is its distributed trust model. By distributing key shares and ballot collection across independent cells, it enables multi-jurisdictional elections without shared infrastructure. Its primary disadvantage relative to Belenios is the lack of UC security proofs, and relative to ElectionGuard the lack of deployment experience with real election hardware.

6.4 Security Properties

SOVEREIGN provides five security properties, each reduced to standard cryptographic assumptions. We summarize the arguments; full reduction proofs appear in the security specification [6].

Ballot secrecy (IND-CPA under DCR). An adversary breaking ballot secrecy can be transformed into a DCR distinguisher. The threshold property ensures M-1 corrupted shares leak no information (statistical security of integer Shamir sharing within 2^{-128} of uniform). ZK proof simulation and blind signature blinding preserve the reduction.

Individual verifiability (collision resistance of SHA-256). The voter's receipt contains SHA-256(encrypted_payload). Replacing the ballot on the bulletin board requires a hash collision.

Universal verifiability (ZK soundness + homomorphic determinism). Observers verify all ZK proofs, recompute the homomorphic sum, and check decryption proofs. Soundness ensures each ballot encrypts 0 or 1; deterministic modular arithmetic ensures tally correctness.

Eligibility (RSA unforgeability + honest registration). Every counted ballot must contain a valid blind RSA signature. Tokens cannot be forged; the authority issues at most one per eligible voter.

Coercion resistance (PRF security of HMAC-SHA-256). Real and fake credentials are computationally indistinguishable without the authority key. During tallying, only real credentials pass HMAC verification; fakes are silently discarded.

7. Discussion and Future Work

Entity contracts as governance primitive. The contract model extends beyond elections. Any multi-agent distributed computation requiring formal governance -- budget votes, policy decisions, resource allocation -- can use the same seven-tuple framework. The combination of machine-enforceable rules and cryptographic attestation provides a governance primitive that is both flexible and verifiable. In the election context, the contract replaces an entire class of procedural vulnerabilities: temporal manipulation (accepting votes outside the declared window), algorithmic substitution (applying a different tallying method than announced), and selective inclusion (counting only a subset of valid ballots) all become detectable through contract verification. The attestation cryptographically binds the input ballots, applied algorithm, and output tally to the published contract, creating an unforgeable audit chain.

Comparison with blockchain governance. Blockchain-based voting systems [16] use smart contracts for election governance -- superficially similar to SOVEREIGN's entity contracts. However, the approaches differ fundamentally. Smart contracts execute on a distributed ledger, inheriting the blockchain's limitations: permanent data exposure, consensus overhead, and the risk of smart contract bugs that cannot be corrected after deployment. SOVEREIGN's entity contracts are declarative specifications verified at attestation time, not imperative programs executed during tallying. A bug in a smart contract may silently corrupt the tally; a deviation from a SOVEREIGN contract is detected at attestation and triggers the Psi termination conditions. Furthermore, SOVEREIGN's contracts operate over encrypted data -- the contract specifies what must be computed without exposing the underlying votes -- whereas smart contracts on public blockchains operate over publicly visible state.

Limitations. SOVEREIGN's security arguments are game-based, not UC-framework proofs. Achieving UC security would provide composability guarantees important for a system that combines Paillier, RSA blind signatures, Sigma protocols, and Shamir sharing. The HMAC-based JCJ relies on a single authority key; a threshold HMAC construction would distribute this trust. The current decryption proof is a SHA-256 binding, not a zero-knowledge proof of correct partial decryption; Chaum-Pedersen proofs would detect malicious share holders. The pure-Python implementation prioritizes auditability over performance; a C or Rust implementation would provide 10-100x speedup. Encrypted ballots appear on the bulletin board in arrival order, potentially leaking timing information; a re-encryption mix-net would randomize ballot order at additional complexity cost.

Deployment path. SOVEREIGN is best suited initially for organizational voting (corporate boards, professional associations) where the threat model is less severe. These deployments provide real-world validation before scaling to political elections, which require additional infrastructure: voter-verifiable paper audit trails, hardware security modules for key shares, and formal certification. The multi-cell architecture maps naturally to existing election administration boundaries (states, counties, precincts), and the disconnected operation capability addresses disaster-response and military deployment scenarios that no existing E2E-V system supports.

Future work. Key directions include UC-framework security proofs for formal composability guarantees, Chaum-Pedersen proofs for partial decryption verification (detecting malicious share holders), threshold HMAC for distributing the coercion-resistance authority key across multiple parties, range proofs for encrypted weighted voting (proving encrypted values lie in valid ranges without revealing them), re-encryption mix-nets for ballot-order privacy, and pilot deployments with organizational voting conducted in parallel with traditional paper-based methods to validate usability and operational robustness.

8. Conclusion

We have presented SOVEREIGN, a distributed E2E-V voting system that addresses the centralized trust assumption shared by all deployed E2E-V systems. By distributing cryptographic operations across independent cells and governing elections through formal entity contracts, SOVEREIGN enables multi-jurisdictional elections without shared infrastructure, machine-enforced governance with cryptographic attestation, and disconnected operation for tactical and disaster-response environments.

Our evaluation demonstrates feasibility: sub-second per-voter cost, tallying latency independent of election size, and near-linear scalability with the number of cells. The combination of distributed trust, formal contracts, and disconnected operation opens deployment contexts -- federal elections, military operations, international organizations -- beyond the reach of existing E2E-V systems.

SOVEREIGN demonstrates that distributing trust in E2E-V elections is both cryptographically sound and practically achievable within a unified framework built on independent cryptographic cells and formal contract governance.

References

[1] B. Adida. "Helios: Web-based Open-Audit Voting." In Proc. 17th USENIX Security Symposium, pp. 335-348, 2008.

[2] J. Benaloh et al. "STAR-Vote: A Secure, Transparent, Auditable, and Reliable Voting System." USENIX JETS, 2019. See also: ElectionGuard Specification v2.0.

[3] V. Cortier, P. Galindo, S. Glondu, M. Izabachene. "Election Verifiability for Helios under Weaker Trust Assumptions." In ESORICS 2014, LNCS 8713, pp. 327-344, 2015. See also: https://www.belenios.org/

[4] System9 Engineering. "Formal Entity Contracts for Autonomous Agent Governance." Submitted to AAMAS 2026.

[5] System9 Engineering. "SOVEREIGN: A Distributed Cryptographic Voting System with Entity Contracts and Multi-Cell Consensus." Technical report, 2026.

[6] System9 Engineering. "SOVEREIGN Security Specification v1.0.0." Technical report, 2026.

[7] P. Paillier. "Public-Key Cryptosystems Based on Composite Degree Residuosity Classes." In EUROCRYPT '99, LNCS 1592, pp. 223-238, 1999.

[8] D. Chaum. "Blind Signatures for Untraceable Payments." In CRYPTO '82, pp. 199-203, 1983.

[9] A. Fiat, A. Shamir. "How To Prove Yourself: Practical Solutions to Identification and Signature Problems." In CRYPTO '86, LNCS 263, pp. 186-194, 1986.

[10] A. Shamir. "How to Share a Secret." Communications of the ACM, 22(11):612-613, 1979.

[11] I. Damgard, M. Jurik. "A Generalisation, a Simplification and Some Applications of Paillier's Probabilistic Public-Key System." In PKC 2001, LNCS 1992, pp. 119-136, 2001.

[12] A. Juels, D. Catalano, M. Jakobsson. "Coercion-Resistant Electronic Elections." In Proc. WPES, pp. 61-70, ACM, 2005.

[13] R. Cramer, R. Gennaro, B. Schoenmakers. "A Secure and Optimally Efficient Multi-Authority Election Scheme." In EUROCRYPT '97, LNCS 1233, pp. 103-118, 1997.

[14] D. Pointcheval, J. Stern. "Security Arguments for Digital Signatures and Blind Signatures." Journal of Cryptology, 13(3):361-396, 2000.

[15] R. Canetti. "Universally Composable Security: A New Paradigm for Cryptographic Protocols." In 42nd FOCS, pp. 136-145, IEEE, 2001.

[16] F. Shaikhli, R. Zulkurnain, M. Chuprat. "Blockchain-Based E-Voting Systems: A Technology Review." Electronics, 10(19), 2021.

---

End of workshop paper draft.