@misc{engineering2026sovereign,
  author = {System9 Engineering},
  title = {SOVEREIGN: A Distributed Cryptographic Voting System},
  year = {2026},
  url = {https://system9.ai/research/sovereign-paper},
  howpublished = {\\url\{https://system9.ai/research/sovereign-paper\}},
  note = {Draft, in preparation}
}

SOVEREIGN: A Distributed Cryptographic Voting System with Entity Contracts and Multi-Cell Consensus

---

Metadata

Authors: System9 Engineering Date: 2026-03-30 Version: 1.0.0 (Draft)

Submission Targets

• E-Vote-ID (International Conference on Electronic Voting) -- Primary target
• USENIX Security -- Top-tier security venue
• Financial Cryptography (FC) -- Relevant for contract governance aspect
• WPES (ACM Workshop on Privacy in the Electronic Society) -- Workshop paper
• JETS (USENIX Journal of Election Technology and Systems) -- Journal paper

---

Abstract

We present SOVEREIGN, a distributed end-to-end verifiable voting system built on the System9 platform. Unlike existing E2E-V systems (ElectionGuard, Helios, Belenios) which operate on centralized servers, SOVEREIGN distributes trust across independent cryptographic cells -- each representing a sovereign jurisdiction such as a state, county, or precinct. Votes are encrypted using Paillier homomorphic encryption, tallied without decryption via homomorphic addition, and decrypted through threshold ceremonies where the private key is never assembled. Voter anonymity is achieved through RSA blind signatures that break the voter-ballot linkage while preserving eligibility guarantees. Ballot validity is proven via zero-knowledge disjunctive Sigma protocols compiled through the Fiat-Shamir heuristic. Elections are governed by formal entity contracts following the AAMAS 2026 seven-tuple model (I, O, S, R, T, Phi, Psi), providing machine-enforced rules for ballot format, tally structure, temporal bounds, and success criteria rather than procedural compliance. SOVEREIGN supports seven election types (simple majority, super majority, ranked choice, approval, weighted, consensus, referendum), operates in disconnected environments via delay-tolerant networking with eventual consistency, and provides coercion resistance through JCJ-style fake credentials implemented with HMAC-SHA-256. We implement and evaluate the system in Python with 122 passing tests across 17 test files, demonstrating correct end-to-end operation including key generation, blind token issuance, encrypted ballot casting with zero-knowledge proofs, homomorphic tallying across distributed cells, and threshold decryption with partial shares using the Damgard-Jurik Delta scheme.

---

1. Introduction

Electronic voting occupies a unique position in the landscape of distributed systems: it simultaneously demands mutually antagonistic properties. Voters must be certain their votes are counted (integrity), while no observer -- not even the election administrator -- should be able to determine how any individual voted (privacy). The system must allow anyone to verify correctness (transparency) while preventing vote buying and coercion (receipt-freeness). These requirements are in fundamental tension, and satisfying them simultaneously is one of the hardest problems in applied cryptography.

1.1 The State of the Art

The past two decades have produced several landmark E2E-V systems. Helios [1] demonstrated that web-based voting could be made verifiable using homomorphic tallying. ElectionGuard [2] brought E2E-V concepts to mainstream election hardware through Microsoft's partnership with VotingWorks. Belenios [3] added a distributed trust model with threshold trustees. Each system advanced the field significantly, but all share structural limitations:

Centralized trust. All three systems operate under the assumption of a unified administrative domain. The server, the key holders, and the bulletin board are all 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.

Single election type. ElectionGuard and Helios support plurality voting. Belenios supports plurality and majority judgment. None natively support ranked-choice, approval, weighted, or consensus voting -- types used in corporate governance, parliamentary procedures, and increasingly in public elections.

Procedural governance. Election rules are documented in human-readable policy documents and enforced through procedural compliance. There is no machine-readable specification of what constitutes a valid ballot, when the election opens and closes, what quorum is required, or how violations are handled.

Network dependency. All three systems require persistent network connectivity. Military, humanitarian, and disaster-response contexts frequently operate in disconnected environments where network access is intermittent or absent.

1.2 Contribution

SOVEREIGN addresses these limitations through four innovations:

Distributed multi-cell trust. SOVEREIGN leverages the System9 platform's cell architecture -- a three-level hierarchy of nodes (logical jurisdictions), service groups (administrative districts), and cells (physical deployment units). Key shares are distributed across cells so that no single cell or service group holds enough shares to decrypt. Encrypted ballots are collected locally and synchronized to a shared bulletin board, enabling both local autonomy and global verification.

Seven election types. SOVEREIGN implements simple majority, super majority, ranked choice, approval, weighted, consensus, and referendum voting through a unified cryptographic framework. All types use Paillier encryption and homomorphic tallying; the differences are in the tallying algorithm and threshold conditions, which are specified in the election contract.

Formal entity contracts. SOVEREIGN governs elections through entity contracts following the AAMAS 2026 seven-tuple model. The contract formally specifies ballot format (I), tally structure (O), required tallying skills (S), resource constraints (R), temporal bounds (T), success criteria (Phi), and termination conditions (Psi). Contract compliance is verified automatically and attested cryptographically.

Disconnected operation. All per-ballot cryptographic operations (encryption, ZK proof generation, blind token verification) are local. Only tallying and threshold decryption require multi-cell coordination. Cells can operate disconnected for the voting phase and synchronize later, enabling deployment in austere environments.

1.3 Paper Organization

Section 2 reviews related work. Section 3 describes the system architecture. Section 4 presents the cryptographic protocols. Section 5 details the election protocol lifecycle. Section 6 provides security analysis. Section 7 reports implementation and evaluation. Section 8 discusses comparison, limitations, and deployment considerations. Section 9 concludes.

---

2. Related Work

2.1 ElectionGuard

ElectionGuard [2] is Microsoft's open-source E2E-V toolkit, designed for use with existing election hardware (ballot marking devices and scanners). It uses the ElGamal encryption scheme over an elliptic curve group, with additive homomorphic tallying and threshold key management via Shamir secret sharing with Lagrange interpolation.

ElectionGuard's primary contribution is its deployment model: it integrates with existing voting machines as an add-on verification layer, allowing jurisdictions to adopt E2E-V without replacing their hardware. Ballot proofs use the Chaum-Pedersen protocol for zero-knowledge demonstrations that encrypted values are valid.

SOVEREIGN differs from ElectionGuard in several respects. First, SOVEREIGN uses Paillier rather than ElGamal. Paillier's additive homomorphism over Z_n is natural for vote counting (the sum of encrypted 0/1 values gives the count directly), whereas ElGamal's multiplicative homomorphism requires encoding votes as exponents. Second, SOVEREIGN distributes trust across independent cells rather than assuming a single administrative domain. Third, SOVEREIGN provides coercion resistance through the JCJ protocol, which ElectionGuard does not address. Fourth, SOVEREIGN governs elections through formal contracts rather than procedural compliance.

2.2 Helios

Helios [1] is a web-based voting system that pioneered the concept of open-audit elections. Voters encrypt their ballots in the browser using JavaScript, submit them to a server, and can verify their encrypted ballots on a public bulletin board. Helios uses ElGamal encryption with homomorphic tallying and provides individual and universal verifiability.

Helios demonstrated that E2E-V could be made accessible to non-expert users through a web interface. However, Helios has known limitations: it does not provide ballot secrecy against the server (which knows the encryption randomness if the browser is compromised), it does not support threshold decryption (a single party holds the decryption key), and it does not address coercion resistance.

SOVEREIGN addresses all three limitations: threshold decryption ensures no single party can decrypt, the JCJ protocol provides coercion resistance, and the distributed cell architecture reduces the trust placed in any single server.

2.3 Belenios

Belenios [3] extends the Helios model with a more rigorous security analysis and a distributed trust model. It uses threshold ElGamal encryption with multiple trustees, provides a formal security proof in the Universal Composability (UC) framework, and supports a "Belenios-RF" variant that provides partial receipt-freeness through re-encryption.

Belenios is the closest system to SOVEREIGN in terms of security ambition. SOVEREIGN differs primarily in its use of Paillier rather than ElGamal, its distribution across independent cells rather than cooperative trustees, its support for multiple election types, and its formal contract governance. Belenios's UC security proof is more rigorous than SOVEREIGN's game-based arguments; achieving UC security for SOVEREIGN is future work.

2.4 Blockchain-Based Approaches

Several proposals have applied blockchain technology to voting, including systems built on Ethereum [4], Hyperledger, and custom blockchains. The appeal is the blockchain's append-only ledger, which provides a natural bulletin board with tamper-evident properties.

However, blockchain-based voting systems face fundamental challenges. Public blockchains expose encrypted ballots to all participants, making ballot secrecy dependent on the encryption scheme's security for the lifetime of the blockchain (which may be indefinitely long). As quantum computing advances, encrypted ballots stored permanently on a blockchain could eventually be decrypted (the "harvest now, decrypt later" threat). The computational cost of blockchain consensus is high and poorly suited to the bursty access patterns of elections. Smart contract bugs have caused catastrophic failures in financial applications and the consequences of such bugs in elections are unacceptable. Gas fees on public blockchains create accessibility barriers. And the immutability that makes blockchains appealing for audit also makes error correction impossible -- a ballot submitted with a software bug cannot be corrected.

SOVEREIGN does not use blockchain. Its bulletin board is an append-only log maintained by the System9 platform's replication layer, with tamper-evidence provided by HMAC hash chains rather than distributed consensus. This gives SOVEREIGN the tamper-evident properties of a blockchain without the computational overhead, smart contract risk, or permanent data exposure. The System9 replication layer provides the same availability guarantees through multi-cell replication without the energy cost of proof-of-work or the stake concentration risks of proof-of-stake.

2.5 Entity Contracts for AI Agents (AAMAS 2026)

The AAMAS 2026 seven-tuple contract model [5] provides a formal framework for specifying and enforcing agreements between autonomous agents. A contract C = (I, O, S, R, T, Phi, Psi) specifies:

• I: Input specification (what the agent receives)
• O: Output specification (what the agent must produce)
• S: Required skills (capabilities the agent must possess)
• R: Resource constraints (budgets, rate limits)
• T: Temporal constraints (validity window)
• Phi: Success criteria (quality metrics)
• Psi: Termination conditions (what happens on failure)

SOVEREIGN applies this model to elections: the election authority proposes a contract, the tallying agent accepts it, and both parties are bound by its terms. This provides formal, auditable governance that goes beyond the procedural compliance model used by all existing E2E-V systems.

---

3. System Architecture

3.1 Topology: States as Nodes, Counties as Service Groups, Precincts as Cells

SOVEREIGN maps the hierarchical structure of jurisdictions to the System9 platform's three-level topology:

Nodes represent sovereign jurisdictions -- for example, states in a federal election, countries in an international organization, or divisions in a corporate governance context. A node is a logical construct that spans physical infrastructure. A single node may operate cells across multiple cloud providers or data centers, or entirely on-premises.

Service groups represent administrative districts within a jurisdiction -- for example, counties within a state, or departments within a division. Service groups define replication boundaries and fault domains. Cells within a group share data through the System9 replication layer.

Cells are the physical deployment units -- for example, precinct servers, mobile voting terminals, or cloud instances. Each cell runs its own instance of the SOVEREIGN voting services, maintains its own database, and performs all cryptographic operations locally. A cell is the fundamental unit of trust: compromising one cell does not compromise others.

This mapping is not rigid. A small election (e.g., a board vote) may use a single node with one service group and one cell. A national election may use 50+ nodes, hundreds of service groups, and thousands of cells.

3.2 Entity Model: Voters, Officials, Agents as Cryptographic Entities

SOVEREIGN models all participants as System9 entities with cryptographic identities:

Voters are entities with eligibility credentials. In anonymous elections, voters hold blind-signed tokens and (optionally) JCJ coercion-resistant credentials. A voter's identity is decoupled from their ballot through the blind signature protocol.

Election officials are entities with key share custodianship. Each official holds one share of the Paillier private key and participates in the threshold decryption ceremony. Officials are authenticated through the System9 entity system and governed by the election contract.

Tallying agents are entities (potentially automated) that perform the homomorphic tally computation. The tallying agent operates on encrypted data and never sees individual votes. Its behavior is governed by the election contract, which specifies the tallying algorithm, resource constraints, and success criteria.

Verifiers are entities (potentially anonymous) that read the bulletin board and verify election correctness. Verifiers need no credentials -- the bulletin board is public.

3.3 Election Contracts: AAMAS 2026 Seven-Tuple Governance

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

I (Input Specification). Defines the ballot format, including required fields (ballot_id, election_id, voter_entity_id, selections), field types, and the schema of races and choices. For anonymous elections, the input specification also requires the encrypted ballot selections and ZK proofs.

O (Output Specification). Defines the tally format, including guaranteed output fields (election_id, race_tallies, total_voted, certified_at), field types, and minimum completeness (1.0, meaning all valid ballots must be counted).

S (Required Skills). Specifies the tallying algorithm that the executing agent must implement. For example, "tally:ranked_choice" requires the agent to implement instant-runoff tallying. This ensures that the correct algorithm is applied.

R (Resource Constraints). Sets the maximum number of ballot processing operations equal to the number of eligible voters. This contract-level constraint prevents ballot stuffing even if other checks are bypassed.

T (Temporal Constraints). Defines when the election opens (valid_from) and closes (valid_until). Ballots submitted outside this window are rejected by the contract enforcement layer, not just by application logic.

Phi (Success Criteria). Requires 100% ballot inclusion rate (every valid ballot must appear in the tally) and quorum satisfaction (if configured). The evaluation method is "exact_count" -- partial compliance is not acceptable for election integrity.

Psi (Termination Conditions). Specifies what happens on exceptional conditions: timeout extends the election period, violations are escalated to human administrators, and budget exhaustion (more ballots than eligible voters) terminates the election for investigation.

The contract is created during the setup phase and published to the bulletin board. Contract compliance is verified during the attestation phase and recorded in the cryptographic attestation.

---

4. Cryptographic Protocol

4.1 Paillier Homomorphic Encryption

SOVEREIGN uses the Paillier cryptosystem [6] for ballot encryption. Paillier is additively homomorphic: the product of two ciphertexts decrypts to the sum of the plaintexts. We chose Paillier over the more common ElGamal for three reasons: (1) Paillier's additive homomorphism maps directly to vote counting (the sum of 0/1 encryptions yields the count), whereas ElGamal requires encoding votes as exponents; (2) Paillier decryption is deterministic, which simplifies threshold combination; and (3) Paillier's security rests on the Decisional Composite Residuosity (DCR) assumption, which is well-studied and considered at least as hard as factoring.

Key generation. Generate two large primes p, q of equal bit-length (1024 bits each for 2048-bit security). Compute n = pq and g = n + 1. The private key is lambda = lcm(p-1, q-1) and mu = L(g^lambda mod n^2)^{-1} mod n, where L(x) = (x-1)/n. Primes are generated using Python's secrets module with 20-round Miller-Rabin primality testing, providing error probability at most 4^{-20} = 2^{-40} per candidate.

Encryption. To encrypt plaintext m in Z_n with randomness r in Z*_n:

c = (1 + n*m) * r^n mod n^2

The simplification g^m = 1 + nm mod n^2 (valid because g = n+1 and higher binomial terms vanish mod n^2) avoids an expensive modular exponentiation. The randomness r ensures semantic security: the same plaintext encrypted twice produces different ciphertexts.

Decryption. To decrypt ciphertext c:

m = L(c^lambda mod n^2) * mu mod n

Correctness. We verify the round-trip. Starting from c = (1+nm)r^n mod n^2, raising to the power lambda gives c^lambda = (1+nm)^lambda * r^{nlambda} mod n^2. By Carmichael's theorem, r^{lambda} = 1 mod n, so r^{nlambda} = 1 mod n^2 (by a Hensel lifting argument). Then (1+nm)^lambda = 1 + nmlambda mod n^2 (binomial theorem, higher terms vanish mod n^2). Applying L gives m*lambda, and multiplying by mu = lambda^{-1} mod n recovers m.

Homomorphic tallying. For encrypted votes c_1 = E(v_1), ..., c_K = E(v_K):

product(c_i) mod n^2 = E(v_1 + v_2 + ... + v_K)

This is the key property enabling vote tallying without decryption. The homomorphic tally engine (HomomorphicTallyEngine) exploits this by multiplying all valid encrypted ballots for each choice. The add_many_encrypted function initializes with E(0) as the identity element and iteratively applies add_encrypted (which is simply modular multiplication in Z_{n^2}).

The engine also performs two verification steps before including a ballot in the tally: (1) verifying the ZK ballot proof to ensure the ciphertext encrypts 0 or 1, and (2) verifying the anonymous token to ensure the voter is authorized. Ballots failing either check are rejected and counted separately for audit reporting.

Security. Paillier is IND-CPA secure under the Decisional Composite Residuosity (DCR) assumption [6]. Informally, DCR states that given n, it is hard to determine whether a random element of Z*_{n^2} is an n-th residue. This directly implies that E(0) and E(1) are computationally indistinguishable, so individual encrypted ballots reveal no information about the underlying vote.

Algorithm: Paillier Encrypt-Tally-Decrypt

Encrypt(pk, v):
  Input:  Public key pk = (n, n^2, g), vote v in {0, 1}
  Output: Ciphertext c in Z*_{n^2}, randomness r
   1.  r <- RandomCoprime(n)
   2.  c <- (1 + n*v) * r^n mod n^2
   3.  return (c, r)

HomomorphicTally(pk, {c_1, ..., c_K}):
  Input:  Public key pk, K encrypted votes
  Output: Encrypted tally T = E(sum(v_i))
   1.  T <- E(0) = (1 + n*0) * r_0^n mod n^2   // identity element
   2.  for i = 1 to K:
   3.    T <- T * c_i mod n^2
   4.  return T

ThresholdDecrypt(T, {share_1, ..., share_M}, pk):
  Input:  Encrypted tally T, M key shares, public key pk
  Output: Plaintext count m
   1.  Delta <- N!
   2.  for each share i:
   3.    partial_i <- T^{2 * Delta * s_i} mod n^2
   4.  for each share i, compute Lagrange coefficient:
   5.    mu_i <- Delta * product_{j != i} (0 - x_j) / (x_i - x_j)
   6.  combined <- product_i (partial_i ^ mu_i) mod n^2
   7.  l_val <- (combined - 1) / n
   8.  scale <- 2 * Delta^2 mod n
   9.  m <- l_val * scale^{-1} * mu mod n
  10.  return m

4.2 RSA Blind Signatures for Anonymous Tokens

Blind signatures [7] enable the election authority to certify a voter's eligibility without learning their ballot identity.

Token generation. The voter generates a random 256-bit token.

Blinding. The voter computes:

h = SHA-256(token) mod n
blinded = h * r^e mod n

where r is a random blinding factor coprime to n and (n, e) is the authority's RSA public key.

Signing. The authority signs the blinded value:

blinded_sig = blinded^d mod n

The authority never sees the original token.

Unblinding. The voter computes:

sig = blinded_sig * r^{-1} mod n = h^d mod n

This is a standard RSA signature on h = SHA-256(token).

Verification. Anyone can verify: sig^e mod n = SHA-256(token) mod n.

Unlinkability. The blinding factor r makes the blinded value uniformly random over Z*_n for any fixed token. The authority cannot correlate the signing session with the final (token, sig) pair.

4.3 Zero-Knowledge Ballot Proofs

The voter must prove that their encrypted ballot contains a valid vote (0 or 1) without revealing which. This prevents ballot stuffing (encrypting a value > 1) and ensures the homomorphic tally is meaningful.

SOVEREIGN uses a disjunctive Sigma protocol (OR-proof) made non-interactive via the Fiat-Shamir heuristic [8].

Intuition. Define c_0 = c (hypothesis: c encrypts 0) and c_1 = c * g^{-1} mod n^2 (hypothesis: c encrypts 1). If c encrypts b, then c_b = r^n mod n^2 and the prover knows the n-th root r. The prover generates a real proof for the true branch and simulates the false branch. The verifier cannot distinguish which is which.

Proof structure. The proof consists of (a_0, a_1, e_0, e_1, z_0, z_1) satisfying:

1. Challenge partition: e_0 + e_1 = H(n, g, c, a_0, a_1) mod 2^{256}
2. Branch 0 verification: z_0^n = a_0 * c_0^{e_0} mod n^2
3. Branch 1 verification: z_1^n = a_1 * c_1^{e_1} mod n^2

The hash input is domain-separated with "SOVEREIGN-ZK-v1" to prevent cross-protocol attacks.

Security. The protocol is zero-knowledge (a simulator exists that produces indistinguishable transcripts without the witness) and sound (extracting the witness from two accepting transcripts with different challenges). Non-interactive soundness follows from the Fiat-Shamir heuristic in the random oracle model [9].

4.4 Threshold Key Management and Partial Decryption

The Paillier private key is split into N shares using Shamir's Secret Sharing [10] over the integers. Any M shares can reconstruct the key, but SOVEREIGN uses partial decryption so the full key is never assembled. This is critical: if the full key were reconstructed on any machine, that machine would become a single point of compromise.

Why sharing over the integers? Standard Shamir sharing operates over a finite field F_p, where Lagrange interpolation is exact because inverses are well-defined. However, for threshold Paillier decryption, the Lagrange combination happens in the exponent of c^{s_i} mod n^2. Computing modular inverses in the exponent requires knowing the group order phi(n^2) = n*phi(n), which is secret (knowing phi(n) is equivalent to factoring n). The Damgard-Jurik Delta trick [11] solves this: by multiplying all Lagrange denominators by Delta = N!, all divisions become exact integer divisions, and the extra factor of Delta is canceled at the end using a known quantity.

Sharing polynomial. f(x) = lambda_val + a_1x + a_2x^2 + ... + a_{M-1}x^{M-1}, where each a_i is drawn uniformly from [0, n2^{128}). The large coefficient bound (n*2^{128}) provides 128-bit statistical security: regardless of the value of lambda_val, the distribution of M-1 or fewer shares is statistically indistinguishable (within 2^{-128}) from uniform. Share i is f(i), evaluated without modular reduction.

Partial decryption. Each share holder computes locally:

partial_i = c^{2 * Delta * s_i} mod n^2

where Delta = N! and s_i = f(i) is the share value. The factor of 2*Delta is a key insight from Damgard-Jurik: it ensures that the Lagrange coefficients mu_i = Delta * product_{j != i} (0-x_j)/(x_i-x_j) are always exact integers (since all denominators divide N!). The factor of 2 provides a further algebraic convenience in the recovery step.

The share holder also computes a SHA-256 commitment hash over (share_id, partial_value, ciphertext) for audit logging. The raw share value s_i never leaves the holder's machine; only partial_i and the commitment hash are transmitted.

Combination. The combiner computes integer Lagrange coefficients mu_i = Delta * L_i(0) and combines:

combined = product(partial_i^{mu_i}) mod n^2
         = c^{2 * Delta^2 * lambda_val} mod n^2

Then applies the L function:

l_val = (combined - 1) / n

And recovers the plaintext:

scale = 2 * Delta^2 mod n
plaintext = l_val * scale^{-1} * mu mod n

The modular inverse of scale is computable because scale is a known quantity (Delta = N! is public, and mu is part of the public key). The full private key lambda_val is never computed during this process.

Correctness sketch. The combination yields c^{2Delta^2lambda} because the exponent sum is 2Delta * sum(s_i * mu_i) = 2Delta * Delta * f(0) = 2Delta^2lambda_val (by the correctness of Lagrange interpolation). Applying L gives 2Delta^2mlambda (by the standard Paillier decryption derivation). Dividing by 2Delta^2 and multiplying by mu = lambda^{-1} recovers m.

Security. M-1 or fewer shares reveal no information about the secret (information-theoretic security of Shamir sharing, extended to integers via the large coefficient bound). The partial decryptions partial_i = c^{2Deltas_i} are deterministic functions of the shares and carry no additional information. Extracting s_i from partial_i would require solving the discrete logarithm in Z*_{n^2}, which is at least as hard as factoring n.

4.5 Coercion-Resistant Credentials

SOVEREIGN implements a simplified variant of the JCJ protocol [12] using HMAC-SHA-256 rather than public-key encryption.

Real credential. The election authority computes:

mac = HMAC-SHA-256(authority_key, credential_id || ":" || token)

Fake credential. The voter computes:

mac = HMAC-SHA-256(random_key, credential_id || ":" || token)

Both produce 256-bit hex strings with identical format. Without the authority's key, the HMAC output is computationally indistinguishable from random (PRF security of HMAC-SHA-256). A fake credential's HMAC (computed with a random key) is also indistinguishable from random. Therefore, no PPT adversary can distinguish real from fake.

Tally-phase filtering. During tallying, the authority validates each credential by recomputing the HMAC with the authority key. Real credentials match; fakes are silently discarded. The count of discarded credentials is not revealed.

Trade-offs. This HMAC-based approach is simpler than the original public-key JCJ but provides computational rather than information- theoretic hiding. It also requires a single authority key rather than a distributed validation threshold. These are acceptable trade-offs for the deployment scenarios SOVEREIGN targets.

---

5. Election Protocol

5.1 Setup Phase

The election lifecycle begins with setup:

1. Election creation. The authority creates an Election object specifying type, privacy level, races, choices, eligible voters, temporal bounds, and threshold requirements.

2. Key generation (anonymous elections). Generate Paillier keypair (pk, sk) at 2048-bit security. Split sk into N shares with threshold M. Distribute shares to key share holders on separate cells. Generate RSA keypair for blind signatures. Destroy sk.

3. Contract creation. Build the AAMAS 2026 entity contract governing the election (Section 3.3). The contract is stored via the ContractManager or as an ephemeral contract for standalone elections.

4. Bulletin board publication. Publish the election definition (name, type, privacy, race count, temporal bounds, contract_id) to the bulletin board.

5. Status transition. DRAFT -> OPEN.

5.2 Registration Phase

For each eligible voter:

1. Eligibility verification. The EligibilityChecker applies four filters in sequence: duplicate ballot guard, entity type restriction, explicit entity allow-list, and live entity lookup. All four must pass.

2. Credential issuance (coercion-resistant elections). The authority issues a real credential. The voter optionally generates fake credentials for use under coercion.

3. Blind token issuance (anonymous elections). The voter generates a random token, blinds it, sends the blinded value to the authority, receives a blind signature, and unblinds to obtain a valid signed token. The authority cannot link the token to the voter.

5.3 Voting Phase

For each ballot:

1. Encryption. For each race and choice, the voter encrypts their selection (0 or 1) using Paillier with fresh randomness. The encrypt_with_randomness function returns both the ciphertext and the randomness needed for ZK proof generation.

2. Proof generation. For each encrypted selection, the voter generates a ZK proof demonstrating the ciphertext encrypts 0 or 1 using the disjunctive Sigma protocol (Section 4.3).

3. Ballot assembly. The encrypted selections, ZK proofs, anonymous token, and token signature are assembled into an EncryptedBallotSelection.

4. Submission. The ballot recorder writes the ballot to the append-only journal with an HMAC integrity signature.

5. Receipt issuance. The voter receives a VoterReceipt containing (receipt_id, ballot_id, election_id, SHA-256(encrypted_payload), timestamp). The receipt does not reveal the voter's choice.

6. Bulletin board publication. The encrypted ballot is published with the ZK proof, anonymous token, and commitment hash. No voter identity is published.

5.4 Tallying Phase

After the election closes:

1. Credential filtering (if coercion-resistant). The authority validates all credentials, silently discarding fakes.

2. Proof verification. The HomomorphicTallyEngine verifies each ballot's ZK proof (verify_ballot_proof) and anonymous token (verify_token). Invalid ballots are rejected with logged warnings.

3. Homomorphic summation. For each race and choice, the engine multiplies all valid ciphertexts: T_j = product(c_i) mod n^2. This produces E(count_j) -- an encryption of the vote count for choice j. The add_many_encrypted function initializes with E(0) and iteratively applies add_encrypted (modular multiplication).

4. Publication. EncryptedTally objects are published to the bulletin board with metadata (ballot_count, valid_proofs, invalid_proofs).

5. Status transition. CLOSED -> TALLYING.

5.5 Decryption and Verification Phase

The threshold decryption ceremony reveals the tally:

1. Partial decryption. Each of M key share holders computes their partial decryption on their own machine using compute_partial_decryption. The share value never leaves the holder's machine; only the partial result (c^{2Deltas_i} mod n^2) and a commitment hash are transmitted.

2. Combination. The DecryptionCeremony combiner collects M partial decryptions and calls combine_partial_decryptions to recover the plaintext count using Lagrange interpolation in the exponent.

3. Decryption proof. A SHA-256 hash binding the encrypted tally, plaintext result, ballot count, and share count is generated as an audit proof.

4. Result publication. DecryptionResult objects are published to the bulletin board.

5. Individual verification. Voters verify their receipts against the bulletin board using bulletin_board.verify_receipt(receipt).

6. Universal verification. Observers verify all ZK proofs, recompute the homomorphic sum, and check decryption proofs using the bulletin board's verify_ballot_count and export_for_audit methods.

7. Attestation. The ResultAttestationGenerator creates a signed ElectionAttestation containing result_hash, journal_hash (hash chain over all ballot entries), contract_id, and an HMAC signature. The attestation is published to the bulletin board.

8. Status transitions. TALLYING -> CERTIFIED -> ARCHIVED.

---

6. Security Analysis

We analyze SOVEREIGN's security properties through reduction-based arguments. The full formal treatment appears in the companion SOVEREIGN Security Specification [13].

6.1 Ballot Secrecy

Theorem 1. If the DCR assumption holds for the Paillier cryptosystem with security parameter lambda, then SOVEREIGN provides ballot secrecy (IND-CPA-style, Definition in Section 3 of [13]) against any PPT adversary A corrupting at most M-1 key share holders.

Proof. We proceed by reduction. Assume A breaks ballot secrecy with non-negligible advantage epsilon. We construct an algorithm B that breaks the DCR assumption.

Construction. B receives a DCR challenge (n, y) where y is either a random n-th residue (y = r^n mod n^2 for random r) or a random element of Z*_{n^2}.

B simulates the SOVEREIGN election for A:

1. B sets pk = (n, n^2, n+1, .) and gives pk to A. (B does not know the factorization of n, so it cannot create sk.)

2. When A requests ballot encryptions, B returns E(m) = (1+nm) * r^n mod n^2 using fresh random r for each query. These are valid Paillier ciphertexts.

3. When A submits challenge (b_0, b_1), B: a. If y is an n-th residue (y = r^n), B computes c* = (1 + nb_0) * y mod n^2. This equals E(b_0, r) -- a valid encryption of b_0. b. If y is random, c is a random element of Z*_{n^2}, which is computationally indistinguishable from E(b_1, r') for random r'.

4. B generates a ZK proof pi* for c* using the simulator (which exists by the zero-knowledge property of the Sigma protocol).

5. B returns (c*, pi*) to A.

6. When A outputs beta', B outputs:

   • 1 if beta' = 0 (A thinks c* encrypts b_0, consistent with y being an n-th residue)
   • 0 if beta' = 1

Analysis. If y is an n-th residue, B perfectly simulates the beta = 0 case. If y is random, B simulates neither case correctly, so A's advantage is 0. Therefore:

Adv^DCR_B = |Pr[B(n-th residue) = 1] - Pr[B(random) = 1]|
          = |Pr[A wins | beta=0] - 1/2|
          = Adv^BS_A / 2

Since Adv^DCR_B is negligible (by assumption), Adv^BS_A is also negligible.

Composition with threshold. The M-1 corrupted share holders gain no additional advantage: M-1 shares reveal no information about the secret lambda_val (information-theoretic security of Shamir sharing over integers, Section 4.4 of [13]), and the partial decryptions are deterministic functions of the shares. Therefore the reduction applies even when M-1 shares are known.

Composition with ZK proofs. The ZK proofs do not leak information: the simulated branch of the OR-proof is identically distributed to the real branch. In the random oracle model, the Fiat-Shamir transform preserves this property.

Composition with blind signatures. The blinding factor makes the signed message uniformly distributed during registration, breaking the voter-ballot linkage (Section 4.2).

The overall advantage is bounded by:

Adv^BS_A <= 2 * Adv^DCR + Adv^ZK_sim + negl(lambda)

All terms are negligible, completing the proof. []

6.2 Individual Verifiability

Claim. SOVEREIGN provides individual verifiability under the collision resistance of SHA-256.

Argument. After casting a ballot, the voter receives a receipt R containing SHA-256(encrypted_payload). The same encrypted ballot is published to the bulletin board. The voter checks that the published ballot's hash matches their receipt.

If an adversary replaces the ballot on the bulletin board with a different encrypted payload p', the hashes will differ unless SHA-256(p') = SHA-256(encrypted_payload), which requires finding a collision. If the adversary deletes the ballot entirely, the voter's receipt verification fails (no matching ballot_id exists).

Implementation. The BallotRecorder.record_ballot_with_receipt method generates the receipt at recording time, and the ElectionBulletinBoard.verify_receipt method checks inclusion.

6.3 Universal Verifiability

Claim. SOVEREIGN provides universal verifiability under the soundness of the ZK ballot proof, the homomorphic property of Paillier, and the correctness of threshold decryption.

Argument. Any observer can verify the election by reading the bulletin board and performing four checks:

1. Ballot validity. Verify each ballot's ZK proof. By soundness (Section 4.3), a ballot with a valid proof encrypts 0 or 1 with overwhelming probability. Invalid ballots are detected and rejected.

2. Token validity. Verify each ballot's anonymous token against the authority's public RSA key. By RSA unforgeability, only tokens signed by the authority pass verification.

3. Tally correctness. Recompute the homomorphic sum by multiplying all valid ciphertexts and comparing with the published encrypted tally. By the determinism of modular arithmetic, any discrepancy indicates tampering.

4. Decryption correctness. Verify the decryption proof. The current implementation uses a SHA-256 binding; a Chaum-Pedersen proof (planned for Phase 3) would provide stronger guarantees.

5. Ballot count consistency. Count the ballot entries on the bulletin board and compare with the tally metadata.

6.4 Eligibility Verifiability

Claim. SOVEREIGN provides eligibility verifiability under the unforgeability of RSA and the honest registration assumption.

Argument. Every counted ballot must contain a valid anonymous token (RSA blind signature from the authority). By RSA unforgeability, tokens cannot be forged without access to the authority's signing key. The authority issues at most one token per eligible voter (trust assumption). Duplicate token detection prevents double-voting.

The eligibility checker applies four-layer filtering (duplicate guard, type restriction, allow-list, live lookup) before token issuance, ensuring only eligible entities receive tokens.

6.5 Coercion Resistance

Claim. SOVEREIGN provides coercion resistance under the PRF security of HMAC-SHA-256.

Argument. A coerced voter uses a fake credential (HMAC computed with a random key). Without the authority's secret key, the HMAC output is indistinguishable from random by the PRF property. A real credential's HMAC is also indistinguishable from random (by the PRF property -- the output of a PRF on a random input looks random even to someone who knows it was produced by a PRF). Therefore, no PPT adversary can distinguish real from fake credentials.

During tallying, the authority validates credentials using the authority key. Only real credentials pass, so the tally reflects only genuine votes. The count of discarded fake credentials is not revealed.

Reduction. An adversary distinguishing real from fake credentials can be transformed into a PRF distinguisher for HMAC-SHA-256. The reduction queries its oracle (either HMAC with authority key or a random function) and uses the response as the credential MAC. The adversary's advantage in the coercion game equals the distinguisher's advantage in the PRF game, which is negligible by assumption.

---

7. Implementation and Evaluation

7.1 Implementation

SOVEREIGN is implemented in Python as part of the System9 platform. The implementation consists of two layers:

Cryptographic layer (app/core/security/crypto/voting/):

Module	Lines	Responsibility
paillier.py	224	Key generation, encryption, decryption, homomorphic ops
blind_signature.py	127	Token generation, blinding, signing, verification
zk_ballot_proof.py	182	Disjunctive Sigma protocol, Fiat-Shamir
threshold_keys.py	334	Shamir sharing, partial decryption, Lagrange combination
homomorphic_tally.py	123	Tally engine with proof and token verification
decryption_ceremony.py	133	Ceremony orchestration, proof generation
coercion_resistance.py	190	JCJ credential management and validation

Election layer (app/services/compute/intelligence/workflow/voting/):

Module	Lines	Responsibility
voting_types.py	205	Types: Election, Race, Choice, Ballot, Tally
election_manager.py	~500	Full lifecycle: create, open, cast, tally, certify
election_contract.py	164	AAMAS 2026 contract building
eligibility_checker.py	129	Four-layer eligibility verification
ballot_recorder.py	227	Journal recording, HMAC integrity, receipts
bulletin_board.py	321	Public board: publish, query, verify, export
result_attestation.py	129	Signed attestation generation
voting_node_executor.py	--	Workflow node integration

Design decisions. The cryptographic layer is implemented in pure Python using built-in arbitrary-precision integers. This eliminates external cryptographic dependencies for the core voting protocols, reducing the attack surface and simplifying auditing. The one exception is RSA key generation for blind signatures, which uses the cryptography library for constant-time operations and side-channel resistance.

All cryptographic values use frozen dataclasses with __slots__ for immutability and memory efficiency. Credential comparisons use hmac.compare_digest for constant-time equality to prevent timing attacks.

7.2 Test Coverage

The implementation has 122 passing tests across 17 test files:

Cryptographic tests (7 files):

• test_paillier.py: Key generation, encrypt/decrypt round-trip, homomorphic addition (single and batch), key size validation, plaintext range validation.
• test_threshold_keys.py: Key splitting, threshold reconstruction, insufficient shares rejection, partial decryption, partial combination, full round-trip with 3-of-5.
• test_blind_signature.py: Token generation, blind/sign/unblind round-trip, verification, wrong-key rejection, multiple tokens unlinkability.
• test_zk_ballot_proof.py: Proof generation for 0, proof generation for 1, verification of valid proofs, rejection of invalid proofs (wrong ciphertext, tampered proof), Fiat-Shamir challenge binding.
• test_homomorphic_tally.py: Tally engine with valid ballots, tally with invalid proofs (rejected), tally with invalid tokens (rejected), empty ballot set.
• test_decryption_ceremony.py: Full ceremony, partial decryption generation, partial combination, audit proof verification.
• test_coercion_resistance.py: Real credential issuance, fake credential generation, validation (real passes, fake fails), indistinguishability (structural identity), batch filtering.

Election tests (8 files):

• test_voting_types.py: All enum values, dataclass construction, frozen immutability.
• test_eligibility_checker.py: All four eligibility rules, edge cases (empty lists, missing manager).
• test_election_contract.py: Contract building, seven-tuple field mapping, ephemeral vs. managed contracts.
• test_election_manager.py: Full lifecycle for all 7 election types, status transitions, quorum enforcement, anonymous ballot casting.
• test_ballot_recorder.py: Journal recording, HMAC integrity verification, receipt generation, receipt verification.
• test_bulletin_board.py: Election publishing, ballot publishing, tally publishing, receipt verification, ballot count verification, audit export.
• test_result_attestation.py: Attestation generation, signing, hash chain, unsigned attestation.
• test_voting_node_executor.py: Workflow node execution, integration with the compute intelligence pipeline.

End-to-end integration tests (2 files):

• test_e2e_anonymous_election.py: Complete cryptographic flow from key generation through threshold decryption. Generates a 1024-bit Paillier keypair, splits into 5 shares with threshold 3, generates RSA authority keys, simulates 5 voters (3 voting for candidate A, 2 for candidate B), issues blind tokens, encrypts ballots, generates ZK proofs, verifies all proofs and tokens, performs homomorphic tallying, and decrypts via threshold ceremony. Verifies final counts: 3 for A, 2 for B.

• test_e2e_manager_anonymous.py: Complete manager-level flow. Creates an anonymous election via ElectionManager, sets authority keys, opens the election, casts 5 anonymous ballots through the manager API (with blind tokens, encrypted selections, and ZK proofs), closes the election, tallies via tally_anonymous(), and verifies the result matches expected counts.

7.3 Performance

Performance measurements were taken using 1024-bit Paillier keys on a standard development machine (single core, CPython). Production deployments should use 2048-bit keys (approximately 8x slower).

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

Operation	Time (ms)	Notes
KeyGen	583	One-time setup per election
Encrypt	26	Per-vote encryption
Decrypt	73	Used only in threshold ceremony
Homomorphic Add	0.02	Per-ballot accumulation
ZK Prove	102	Per-vote proof generation
ZK Verify	103	Per-ballot verification
Threshold Split (5,3)	0.9	One-time setup
Partial Decrypt	50	Per-share-holder
Combine Partials (3)	2.5	Per-race
Blind Token	0.6	Per-voter registration
Sign Blinded	85	Authority per-voter

Election simulation (1024-bit, single core):

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

Analysis. Three key observations emerge from the benchmarks:

First, encryption dominates total election time (>99%), but this is a client-side operation that is embarrassingly parallel across voters and cells. In a deployment with 100 cells, a 10,000-voter election completes the encryption phase in approximately 3 seconds per cell.

Second, homomorphic tallying is near-instant: 20ms for 1,000 ballots. This confirms that the O(K) tallying cost has a negligible constant factor (modular multiplication in Z_{n^2}).

Third, threshold decryption is O(M) and independent of K: 21-33ms for 3-of-5 regardless of voter count. This means decryption latency does not increase with election size.

Scalability analysis. For an election with K voters:

• Voting phase: O(K) encryptions and proof generations, each independent and parallelizable across cells.
• Tallying phase: O(K) proof verifications and O(K) homomorphic additions. Proof verification dominates; tallying is embarrassingly parallel across cells.
• Decryption phase: O(M) partial decryptions and one combination. Independent of K.

For K = 10,000 voters at 2048-bit security (estimated 8x overhead):

• Per-voter encrypt + prove: ~1s (client-side, parallel)
• Tallying: ~1.6s (sequential) or ~16ms (100x parallelism)
• Decryption: ~170ms for 3-of-5 threshold

7.4 Recommended Parameters

Parameter	Development	Production	High Security
Paillier key	1024 bits	2048 bits	3072 bits
RSA blind sig	2048 bits	2048 bits	4096 bits
Threshold (M,N)	(2,3)	(3,5)	(5,9)
Miller-Rabin rounds	20	40	64
SHA-256 (Fiat-Shamir)	256 bits	256 bits	256 bits
HMAC-SHA-256 (JCJ)	256 bits	256 bits	256 bits

The 1024-bit Paillier key provides approximately 80-bit security and is suitable only for development and testing. The 2048-bit key provides 128-bit security, aligned with NIST recommendations through approximately 2030. The 3072-bit key provides 128+ bit security with additional margin and is recommended for elections whose secrecy must be preserved beyond 2030.

The (3,5) threshold configuration balances availability (any 3 of 5 holders can decrypt) against security (compromising 2 holders is insufficient). The (5,9) configuration is appropriate for elections where key holders are distributed across mutually distrustful jurisdictions.

7.5 Test Vectors

The following test vectors were generated from the reference implementation with 1024-bit Paillier keys and can be used to verify alternative implementations.

Paillier (1024-bit):

• E(0): ciphertext is 2045 bits
• E(1): ciphertext is 2047 bits (approximately 2n bits, as expected)
• D(E(42)) = 42 (encryption/decryption round-trip)
• D(E(17) * E(25) mod n^2) = 42 (homomorphic addition: 17 + 25 = 42)

Zero-knowledge proof:

• Proof components: a_0, a_1 in Z*_{n^2} (2047 bits), e_0 in Z_n (255 bits), z_0 in Z_n (1022 bits)
• Verify(pi, E(1), pk) = accept (correct proof for correct ciphertext)
• Verify(pi, E(0), pk) = reject (proof for E(1) fails against different ciphertext)

Threshold (5,3):

• D_{partial}(E(77), {share_1, share_2, share_3}) = 77
• D_{partial}(E(77), {share_1, share_3, share_5}) = 77 (any 3-of-5 subset works)

Blind signature:

• Verify(Unblind(Sign_d(Blind_e(token, r)), r), token, e) = accept

---

8. Discussion

8.1 Comparison with Existing Systems

SOVEREIGN occupies a unique position in the E2E-V landscape:

Feature	SOVEREIGN	ElectionGuard	Helios	Belenios
Encryption	Paillier	ElGamal (EC)	ElGamal	ElGamal
Homomorphic tallying	Yes	Yes	Yes	Partial
Threshold decryption	Damgard-Jurik	Lagrange	No	Threshold ElGamal
Key never reconstructed	Yes	No	N/A	Yes
Blind signatures	RSA	No	No	No
Coercion resistance	HMAC-JCJ	No	No	Partial
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
Formal security proofs	Game-based	Game-based	Game-based	UC
Open source	Yes (System9)	Yes	Yes	Yes

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 requiring the jurisdictions to share infrastructure or administrative authority. Its primary disadvantage relative to Belenios is the lack of UC security proofs, and relative to ElectionGuard is the lack of deployment experience with real election hardware.

8.2 Limitations

Formal proofs. SOVEREIGN's security arguments are reduction-based game-hops, not full formal proofs. A UC-framework proof [14] would provide stronger composability guarantees. This is significant because SOVEREIGN composes multiple cryptographic primitives (Paillier, RSA blind signatures, Sigma protocols, Shamir sharing), and composition security is not guaranteed by individual primitive security.

Trusted device problem. Like all electronic voting systems, SOVEREIGN assumes the voter's device correctly implements the protocol. A compromised device could encrypt a different vote than intended. This is a fundamental limitation that requires complementary measures (voter-verifiable paper audit trails, split-path verification) for high-stakes elections.

Decryption proof strength. The current decryption proof is a SHA-256 binding hash, not a zero-knowledge proof of correct partial decryption. A malicious share holder could submit an incorrect partial decryption without detection. Adding Chaum-Pedersen DLOG equality proofs (planned for Phase 3) would address this.

Single authority key for JCJ. The HMAC-based coercion resistance relies on a single authority key. Compromising this key breaks coercion resistance. A threshold HMAC construction or reverting to public-key JCJ would distribute this trust.

No mix-net. SOVEREIGN does not use a re-encryption mix-net, so encrypted ballots appear on the bulletin board in arrival order. This could leak timing information. A mix-net would randomize ballot order at the cost of additional complexity and a different trust model.

Integer Shamir leakage. Shamir sharing over integers can leak information about secret magnitude through share magnitudes. The large random coefficients (drawn from [0, n*2^{128})) provide 128-bit statistical security, but this is a weaker guarantee than information-theoretic security over a finite field.

8.3 Deployment Considerations

Key ceremony. The threshold key ceremony is the most security- critical phase. Each share holder should operate from a separate machine, ideally air-gapped. The ceremony software should be audited independently. SOVEREIGN's DecryptionCeremony.compute_single_partial method is designed for this: it runs on the share holder's machine and only the partial result (never the share value) is transmitted. The ceremony coordinator never sees key shares and cannot reconstruct the private key.

In a production deployment with N = 5 key share holders and threshold M = 3, the ceremony proceeds as follows: (1) the coordinator generates the Paillier keypair and immediately splits the private key into 5 shares; (2) each share is encrypted for its designated holder using the holder's public key; (3) the original private key is securely erased; (4) shares are distributed through authenticated channels; (5) each holder verifies their share by computing a test partial decryption on a known ciphertext. This verification step ensures that all shares are valid before the election begins.

Bulletin board integrity. The bulletin board must be replicated across multiple cells to prevent single-point-of-failure attacks. The HMAC hash chain provides tamper detection: each ballot entry's integrity signature incorporates the previous entry, creating a chain where modifying or deleting any entry is detectable by recomputing the chain from the beginning. The System9 replication layer ensures that all cells maintain consistent copies of the bulletin board data.

For the highest level of assurance, the bulletin board can be published to multiple independent locations (e.g., different cloud providers, university archives, media organizations). Any discrepancy between copies triggers an investigation.

Voter client security. The voter's device must be trusted to correctly implement encryption, proof generation, and token handling. For high-stakes elections, the voter client should be open-source, reproducibly built, and independently audited. A split-verification model (where two independent devices verify each other) would provide additional assurance: the voter casts their ballot on one device and verifies the encrypted ballot's ZK proof on a second device.

SOVEREIGN's architecture makes this split-verification model natural: the voter can encrypt on their primary device and verify the proof on a secondary device (or a public verification terminal) by providing only the ciphertext and proof -- no secrets are needed for verification.

Key size selection. The 2048-bit Paillier key provides 128-bit security, which is considered adequate through approximately 2030 by NIST guidelines. For elections whose results must remain secret for longer periods, 3072-bit or 4096-bit keys should be considered, though the performance cost increases significantly (key generation time grows cubically with key size, and per-ballot operations grow quadratically).

Disconnected deployment model. For military, humanitarian, or disaster-response deployments, SOVEREIGN cells can operate entirely disconnected during the voting phase. All cryptographic operations (Paillier encryption, ZK proof generation, blind token verification) are performed locally using only the public key and the voter's randomness. No network access is required until tallying.

When connectivity is restored, encrypted ballots are synchronized to the bulletin board through the System9 replication layer. The tallying phase (proof verification, homomorphic summation) and decryption ceremony proceed as normal. This delay-tolerant design makes SOVEREIGN suitable for forward-deployed military units, remote humanitarian operations, and elections conducted during infrastructure disruptions.

Audit trail. SOVEREIGN produces a comprehensive audit trail: the bulletin board records all encrypted ballots, ZK proofs, tallies, decryption proofs, and attestations. The result attestation includes a hash chain over all ballot journal entries, creating a tamper-evident binding between the raw ballot data and the certified result. This trail is sufficient for independent audit by any party with access to the bulletin board data, and the cryptographic properties ensure that the audit can be performed years after the election without trusting any participant's claims about what happened.

---

9. Conclusion

We have presented SOVEREIGN, a distributed end-to-end verifiable voting system that addresses four key limitations of existing E2E-V systems: centralized trust, single election types, procedural governance, and network dependency.

SOVEREIGN distributes trust across independent System9 cells, supports seven election types through a unified Paillier-based cryptographic framework, governs elections through formal AAMAS 2026 entity contracts, and enables disconnected operation through local cryptographic processing with eventual synchronization.

Our implementation demonstrates the feasibility of the approach with 122 passing tests including two comprehensive end-to-end integration tests. The cryptographic primitives are implemented in pure Python with no external dependencies beyond the standard library (except RSA key generation), making the code auditable and portable.

Several areas remain for future work. Formal UC security proofs would strengthen the theoretical foundation. Chaum-Pedersen proofs for partial decryptions would enable detection of malicious share holders. A threshold HMAC construction would distribute the coercion-resistance authority key. Range proofs would enable weighted voting with encrypted weights. Re-encryption mix-nets would provide ballot-order privacy. And deployment experience with real election hardware and real voters would validate the usability and performance characteristics in practice.

SOVEREIGN represents a step toward voting systems that are both cryptographically rigorous and operationally realistic -- systems that can serve the diverse voting needs of jurisdictions, organizations, and missions without requiring shared infrastructure, persistent connectivity, or centralized trust.

---

References

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

[2] J. Benaloh, M. Byrne, P. Kortum, N. McBurnett, O. Pereira, T. Stark, D. Wallach. "STAR-Vote: A Secure, Transparent, Auditable, and Reliable Voting System." USENIX Journal of Election Technology and Systems, 2019. See also: ElectionGuard Specification v2.0, https://www.electionguard.vote/spec/

[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, Springer, 2015. See also: Belenios specification, https://www.belenios.org/

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

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

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

[7] D. Chaum. "Blind Signatures for Untraceable Payments." In Advances in Cryptology -- CRYPTO '82, pp. 199-203, Plenum Press, 1983.

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

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

[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, Springer, 2001.

[12] A. Juels, D. Catalano, M. Jakobsson. "Coercion-Resistant Electronic Elections." In Proceedings of the 2005 ACM Workshop on Privacy in the Electronic Society (WPES), pp. 61-70, ACM, 2005.

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

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

---

Appendix A: Supported Election Types

SOVEREIGN supports seven election types through its unified cryptographic framework. The cryptographic layer (Paillier encryption, ZK proofs, threshold decryption) is shared across all types; only the tallying algorithm and threshold conditions vary.

A.1 Simple Majority

Each voter selects one choice per race. The choice with the most votes wins. This is the most common election type and the simplest to tally homomorphically: one encrypted 0/1 per choice, summed independently. The winner is the choice with the highest decrypted count.

A.2 Super Majority

Requires a configurable threshold percentage (default 66.7%) for a choice to be declared the winner. The threshold is specified in the election definition and enforced by the election contract's success criteria (Phi). If no choice meets the threshold, the election result indicates no winner. The cryptographic protocol is identical to simple majority; the threshold is a post-decryption check.

A.3 Ranked Choice (Instant Runoff)

Voters rank choices in order of preference. Tallying proceeds in rounds: in each round, the choice with the fewest first-preference votes is eliminated, and its votes are redistributed to the next-ranked choice on each ballot. This continues until one choice has a majority.

For anonymous elections, ranked-choice introduces a complication: pure homomorphic tallying cannot determine rankings because it only reveals per-choice sums. SOVEREIGN handles this by encrypting each rank position separately (choice X is ranked 1st, 2nd, etc.) and performing multiple rounds of threshold decryption. Each round reveals the aggregate rank distribution, not individual rankings.

A.4 Approval Voting

Voters can approve (vote 1 for) any number of choices. Each choice's approval count is tallied independently. This maps perfectly to the homomorphic framework: one encrypted 0/1 per choice, no constraint that selections sum to 1. The ZK proof per selection ensures each encrypted value is 0 or 1, preventing a voter from approving a choice with a weight greater than 1.

A.5 Weighted Voting

Each voter's vote carries a weight (e.g., proportional to shares in a corporate governance context). SOVEREIGN handles this by encrypting the weight rather than 1 for selected choices. The homomorphic sum then produces the weighted total. The ZK proof must be adapted to prove the encrypted value is in a valid range [0, max_weight] rather than {0, 1}. Range proofs based on Paillier are more complex than disjunctive proofs and are planned for a future enhancement.

A.6 Consensus Voting

Requires unanimous or near-unanimous agreement for a choice to pass. The quorum threshold is set to 100% (or near 100%) in the election contract. The protocol is identical to simple majority with a high passage threshold.

A.7 Referendum Voting

A binary yes/no vote with a configurable passage threshold. This is a specialization of simple majority with exactly two choices. The passage threshold is specified in the election contract and may differ from a simple majority (e.g., a constitutional amendment requiring 60% approval).

---

Appendix B: Multi-Cell Deployment Scenarios

B.1 Federal Election (Large Scale)

Topology: 50 nodes (states), 3000+ service groups (counties), 100,000+ cells (precincts).

• Key shares distributed: 7 shares (one per judicial circuit), threshold 4.
• Each precinct cell collects encrypted ballots locally.
• County service groups aggregate subtallies homomorphically.
• State nodes coordinate threshold decryption.
• National bulletin board aggregates all state boards.

B.2 Corporate Board Vote (Small Scale)

Topology: 1 node, 1 service group, 1 cell.

• Key shares: 3 shares (board chair, corporate secretary, external auditor), threshold 2.
• All voters interact with a single cell.
• Tally and decryption are local operations.
• Bulletin board is the cell's local board.

B.3 Military Field Election (Disconnected)

Topology: 1 node (theater command), 3 service groups (brigade areas), 9 cells (battalion positions).

• Key shares: 5 shares (1 per battalion commander + 2 at brigade), threshold 3.
• Cells operate disconnected for days or weeks.
• Votes are encrypted and stored locally.
• When tactical network is available, encrypted ballots synchronize.
• Threshold decryption occurs at theater command when sufficient cells are connected.

B.4 International Organization (Cross-Border)

Topology: 27 nodes (member states), 27 service groups (national delegations), 54 cells (primary + backup per delegation).

• Key shares: 9 shares (3 per geographic region), threshold 5.
• Each delegation operates its own cell.
• Bulletin board is replicated across all delegations.
• Threshold decryption requires participation from at least 5 key holders spanning at least 2 geographic regions.

---

Appendix C: Contract-Governed Election Example

The following illustrates the concrete entity contract for a simple majority election with 100 eligible voters, opening on January 1 and closing on January 31:

Contract = (I, O, S, R, T, Phi, Psi)

I = InputSpec(
  required_fields = (ballot_id, election_id, voter_entity_id, selections),
  field_types = {
    ballot_id: str,
    election_id: str,
    voter_entity_id: str,
    selections: list[BallotSelection]
  },
  schema_json = {
    race_ids: ["race-001"],
    choice_map: {"race-001": ["choice-A", "choice-B", "choice-C"]}
  }
)

O = OutputSpec(
  guaranteed_fields = (election_id, race_tallies, total_voted, certified_at),
  field_types = {race_tallies: list[RaceTally], total_voted: int},
  min_completeness = 1.0
)

S = ("tally:simple_majority",)

R = ResourceConstraints(max_api_calls = 100)

T = TemporalConstraints(
  valid_from = "2026-01-01T00:00:00Z",
  valid_until = "2026-01-31T23:59:59Z"
)

Phi = SuccessCriteria(
  min_completeness = 1.0,
  custom_metrics = {quorum_pct: 0.5, ballot_inclusion_rate: 1.0},
  evaluation_method = "exact_count"
)

Psi = TerminationConditions(
  timeout_action = "extend",
  violation_action = "escalate",
  budget_exhaustion_action = "terminate"
)

This contract is machine-readable and machine-enforceable. The tallying agent must satisfy all terms, and compliance is verified during the attestation phase. Any deviation (missing ballots, incorrect tally, temporal violation) is detected and recorded.

---

Appendix D: Notation Summary

Symbol	Meaning
lambda	Security parameter (key size in bits)
n	Paillier modulus (n = pq)
n^2	Paillier ciphertext space modulus
g	Paillier generator (g = n + 1)
E(m, r)	Paillier encryption of m with randomness r
lambda_val	lcm(p-1, q-1) (Paillier private key)
mu	L(g^{lambda_val} mod n^2)^{-1} mod n
L(x)	(x - 1) / n
M	Threshold (minimum shares for decryption)
N	Total number of key shares
Delta	N! (factorial of total shares)
s_i	Share i (evaluation of sharing polynomial at point i)
H(.)	SHA-256 hash function (random oracle)
HMAC_k(.)	HMAC-SHA-256 with key k
Z_n	Integers modulo n
Z*_n	Integers coprime to n in Z_n
negl(lambda)	Negligible function of lambda
PPT	Probabilistic polynomial-time
DCR	Decisional Composite Residuosity assumption
(auth_n, auth_e, auth_d)	Authority RSA key triple
pi	Zero-knowledge proof
B	Bulletin board
CR, CF	Real and fake credentials
K	Number of voters

---

End of paper draft.