# Streembit Vote Protocol Working Draft — Version 0.1 ## 1. Purpose, Scope and Participants ### 1.1 Purpose The Streembit Vote Protocol is a general protocol for creating ballots, establishing voting entitlement, recording votes and producing verifiable results. It covers community, educational, gaming, corporate and political voting: a street deciding on a playground upgrade, a school class choosing a trip destination, a gaming community voting on game features, shareholders voting on governance matters, an association or party electing officers or adopting positions. National elections are a later application (Section 1.7). These cases differ in who is eligible, how eligibility is established and how much a vote may reveal. They share the same core: a ballot, an electorate, at most one counted submission per entitlement, a deterministic count and an immutable result. The protocol therefore defines one ballot model whose policy selects the eligibility, privacy and counting rules appropriate to each case. ### 1.2 Scope The protocol covers ballot policy, the eligible electorate and its weights, vote submission, counting, result publication and the preserved history of each ballot. A ballot comprises its policy, its electorate, the votes accepted and its result. Each ballot MUST bind the result to the exact policy and electorate under which it was conducted. The protocol distinguishes: - What the organizer defined (the policy). - What the eligibility authority confirmed (the electorate and its weights). - What each voter submitted. - What the blockchain counted and recorded. The protocol records decisions; it does not execute them. Whether a result is binding, and how it is acted upon, is determined outside the protocol by the organization that conducted the ballot. Ballotee and other applications provide the user interface: ballot design, voter invitation, vote preparation and result presentation. The protocol defines what such applications submit and what the blockchain guarantees about it. ### 1.3 Participants **Organizers** define the ballot and its rules by publishing its policy. **Eligibility authorities**, named in the policy, confirm who may vote and with what weight. A teacher confirms the pupils of a class, an association its members, a company its holders of record. The eligibility authority may be the organizer or a separate party. The eligibility authority is accountable for the electorate; the protocol records what it confirmed and does not verify real-world entitlement itself. **Voters** are the members of a ballot's electorate. Each entitlement binds one voting key to one voter and, where the policy provides, to a voting weight. Voters submit their choices with the confirmed key. **Accountable Nodes** provide specified identity attestations where a policy requires identity assurance beyond the eligibility authority's own confirmation, and provide confidentiality services for sealed ballots: holding the ballot's key confidential while voting is in progress and disclosing it after the ballot closes. Identity attestation and key custody are distinct roles. **Verifiers** are anyone. They check the recorded policy, electorate, votes and result against the protocol's rules and recompute the count. **Consensus participants** retain their ordinary system duties. The protocol assigns them no voting-specific role. ### 1.4 Ballot Policy A ballot's policy defines: the question and its options; the voting method (single choice, multiple choice with a maximum number of selections, or ranked choice); eligibility requirements and the named eligibility authority; whether and how entitlements are weighted; opening and closing times; quorum; approval thresholds; tie treatment; whether abstention is recorded; whether a voter may replace a submitted vote before close; the privacy profile (Section 1.6); the treatment of a ballot that cannot be counted (Section 1.7); and the cancellation rule. Every rule that affects voting or counting MUST be fixed before voting opens. A ballot whose rules must change MUST be cancelled and a new ballot created. **Cancellation.** The policy MUST fix who may cancel the ballot, under what conditions and until when. Cancellation MUST NOT be possible after the ballot closes, and a policy MAY exclude it once voting has opened. A cancellation is recorded with the ballot, naming the cancelling party and the stated reason; the votes already accepted remain in the ballot's history. The electorate MUST be complete and confirmed before voting opens. A vote from a key not in the electorate MUST be rejected. ### 1.5 Foundational Requirements - Only confirmed members of the electorate may vote. - Each entitlement contributes at most one counted submission, weighted no more than its permitted weight. - An accepted vote cannot be silently altered or removed. Where the policy permits replacement, a voter may replace their own vote before close; only the applicable vote counts, and the replaced vote remains in the ballot's history. - Counting follows the published policy and is deterministic: given the policy, the electorate and the accepted votes, any party MUST obtain the same result. - A recorded outcome is final. The protocol never reverses an outcome; a disputed ballot is addressed by conducting a new one. - Results remain independently verifiable from the on-chain record alone. ### 1.6 Privacy and Verification The protocol supports privacy profiles. Each profile explicitly states who can see individual choices, when choices and results become visible, and what evidence permits verification at each stage. Version 1 defines two: **Public ballot.** Each vote is recorded in clear. Individual choices are visible to anyone, the count is observable while the ballot is in progress, and verification is by direct reading of the record. **Sealed ballot.** Each vote is recorded encrypted to the ballot's key, held by the assigned Accountable Nodes. Choices and partial counts remain hidden from the public while voting is in progress, for as long as the custodians keep the key confidential; the custodians themselves are able to decrypt at any time. After close, the Accountable Nodes disclose the key on-chain, the votes become readable and the count is performed on the recorded votes. Key custody follows the Accountable Node key-custody model of the Streembit Deed Protocol. A sealed ballot provides delayed public visibility, not lasting secrecy. After key disclosure every choice is permanently linked to the voting key that cast it; the eligibility authority knows the persons behind the keys, and a key MAY be identifiable to others through the account that submitted it, its funding or its reuse. The on-chain electorate binds voting keys, not persons, and the mapping between keys and persons is held by the eligibility authority off-chain; this limits, but does not prevent, public linkage. A profile that conceals the link between voter and choice after disclosure requires a mechanism this version does not provide (Section 1.7). The fact that a key has voted is public in both profiles. In every profile, a voter can verify that their own vote was recorded as submitted. In a public ballot any verifier can recompute the count at any time. In a sealed ballot the count can be recomputed only once the key is disclosed; before that, verifiers can check the policy, the electorate and the acceptance of votes, but not the tally. ### 1.7 Outcomes A ballot ends in exactly one recorded outcome. A **finalized result** is produced when the ballot closed and the count was performed under its policy; it states the winning option or options, or that the quorum or threshold was not met. A **ballot that could not be counted** is recorded as such when the count cannot be performed: the key of a sealed ballot was not disclosed within the recovery time fixed by the policy, or the ballot was cancelled under its cancellation rule. The two are distinct records; a ballot that could not be counted has no result. The treatment of votes that cannot be counted individually — an encrypted vote that does not decrypt to a valid choice, or a choice invalid under the policy — MUST be predetermined by the protocol and applied uniformly; such votes are recorded as rejected at counting and are excluded from the tally. Later sections define these rules. ### 1.8 Out of Scope - General identity-verification procedures; the eligibility authority confirms entitlement, and Accountable Node identity attestation is specified by the system's attestation rules. - Consensus, transaction processing and Accountable Node lifecycle. - Application concerns: authentication of application users, voter invitation and notification, billing. - Legal recognition of results, electoral disputes and enforcement of decisions. - Lasting ballot secrecy: unlinkability of a choice from its voting key, and of a voting key from its voter, by cryptographic means (mixing, blind credentials). Version 1 offers delayed visibility only (Section 1.6). - Coercion resistance and vote-buying countermeasures beyond what vote replacement provides. - Delegation and proxy voting. - Self-registration of voters; the electorate is confirmed by the eligibility authority. - Multi-question ballots; a ballot has one question, and several questions are several ballots. - National elections. Their requirements — universal identity assurance, anonymity, scale — need a dedicated profile before support is claimed. The key boundary: the contract enforces the ballot's recorded rules; the named eligibility authority establishes real-world entitlement. ## 2. Definitions and Identifiers ### 2.1 Definitions _To be specified._ ### 2.2 Identifiers _To be specified._ ### 2.3 Signed Messages _To be specified._ ## 3. Ballot Policy ### 3.1 Policy Content _To be specified._ ### 3.2 Voting Methods and Counting Rules _To be specified._ ### 3.3 Privacy Profiles _To be specified._ ### 3.4 Consistency Requirements _To be specified._ ## 4. Electorate ### 4.1 Entitlement Confirmation _To be specified._ ### 4.2 Voting Keys Voting keys are generated outside the protocol. The protocol requires only that the key confirmed in the electorate is the key that signs the vote. How an application generates a key pair for a voter, and whether the voter or the application holds the private key, is an application concern bounded by the ballot's eligibility requirements. ### 4.3 Electorate Freeze and Limits _To be specified._ ## 5. Voting, Counting and Outcomes ### 5.1 Vote Submission and Fees A vote is a message signed by the voter's confirmed voting key. The voter needs no SBRIT account. The signed vote binds the chain, the voting contract, the ballot, the entitlement, the choice — or, in a sealed ballot, the encrypted choice — and a revision number. Any account may submit a signed vote to the chain; the submitting account conveys the vote and gains no voting entitlement. The protocol supports two routes with identical acceptance rules: - **Sponsored submission.** An application such as Ballotee submits the voter's signed vote from its own funded account and pays the normal transaction fee. This is the expected default: voters never hold funds, and the application covers the cost through its own allowances or organizer plans. Pricing and payment collection are outside the protocol. - **Direct submission.** A voter, or anyone else carrying a valid signed vote, submits it from a funded account. No application is a required route to participation. The contract verifies the voter's signature and entitlement independently of the submitting account, and uses the submitting account for nothing but the transaction fee. A submitter cannot alter a signed choice. The same signed vote carried by two submitters is accepted once; the later inclusion is reported as a duplicate and does not fail the call. A submission MAY carry several signed votes for one ballot. Each vote is accepted or rejected individually with a reported status; one rejected vote does not fail the others. The revision number orders a voter's submissions. Where the policy permits replacement, a vote with a higher revision replaces the voter's earlier vote and a vote with a lower or equal revision is rejected as stale, regardless of inclusion order. Where replacement is not permitted, the revision MUST be zero and any second vote from the same entitlement is rejected. In a sealed ballot the revision is outside the encrypted content, so ordering is enforced without decryption. A vote is **accepted** when it is included on-chain with an accepted status. An application MUST NOT present a vote as accepted before that. ### 5.2 Acceptance Rules _To be specified._ ### 5.3 Sealed Votes and Key Disclosure Version 1 uses a single ballot key held in full by every assigned Accountable Node, following the Streembit Deed Protocol's key-custody model. Threshold-shared keys, under which no single custodian can decrypt before disclosure, are a later upgrade. ### 5.4 Counting Counting is performed on-chain after close. The policy's electorate size is bounded so that a count completes within one contract call; the limit is fixed in Section 3. ### 5.5 Rejected Votes _To be specified._ ### 5.6 Outcomes and Ballot States _To be specified._ ### 5.7 Cancellation _To be specified._ ## 6. Contract Interface ### 6.1 Contract and Methods _To be specified._ ### 6.2 Storage Layout _To be specified._ ### 6.3 Fund Flows _To be specified._ ## 7. Implementation Notes ### 7.1 Execution Dependencies _To be specified._ ### 7.2 Encoding _To be specified._ ### 7.3 Accountable Node Records _To be specified._ ### 7.4 Implementation Requirements _To be specified._ ### 7.5 Security Notes _To be specified._ ## References _To be specified._