Corrections, clarifications, and structural additions to the voting system design developed in deviant_voting-systems_FOR-sophisticated-readers-and-political-economic-analysts.html. Recorded from analytical conversation conducted 2026-06-05.
The voting system design has been refined through a sequence of analytical exchanges. Several initial readings of the design were corrected; several structural additions were made; several properties that were implicit became explicit. This document records what changed so the design's current state is captured in one place.
The base document (the Voting Systems sophisticated-readers reference) remains the authoritative source for the design. This document is the diff — what was clarified, what was added, what was corrected, what was made explicit. When the base document is next revised, this update's contents will be integrated.
Initial reading of the design treated the qualification machinery and the polls as if they were tightly coupled — as if the bicameral sortition's threshold tiers (52% / 71% / 33%) were a "ladder" applicable to different policy decisions. This was incorrect.
The design has two strictly separate layers:
Layer A — Qualification machinery (immutable, hardcoded). Sortition + vouching + bicameral confirmation + adaptive bootstrap schedule. Produces Citizens, Delegated Members, and Elders. This layer cannot be modified by any vote — not by Citizen majority, not by Elder unanimity, not by anyone. It is set at deployment and runs as deployed.
Layer B — Whatever the qualified electorate does with their right to vote. Anyone with qualified status can participate in polls constructed using the system's primitives (PollCovenant, TallyState, StakeVoteTote). Poll creators choose their own rules — free, fee-based, capital-weighted, 1p1v, supermajority-gated, simple-majority, whatever fits the question. These choices have no effect on the qualification machinery.
The crucial property: the voting architecture is not itself a votable thing. Layer B cannot be used to change Layer A. There is no constitutional-amendment pathway because there is no constitutional-amendment mechanism by design. The system is either adopted as built, or it is not adopted.
This is the same disciplinary principle as the MBA Standard's immutability. The contracts are not modifiable post-deployment; backing rules cannot be voted into different values; redemption mechanisms cannot be amended. The voting qualification machinery follows the same logic at a different layer.
The design's security model addresses three structurally independent failure modes that exist in every voting system:
Failure mode 1: Who can vote. Without verifiable qualification, illegitimate voters are admitted, double-voting happens, sybils participate, eligible voters are excluded. Modern democracies handle this through bureaucratic processes (voter rolls maintained by election officials). Token-weighted DAOs assume token-holder = voter. Both are vulnerable at this layer in different ways.
Failure mode 2: Who counts the votes. Even if every voter is legitimate, if the counting process is controlled by a trusted intermediary, that intermediary can miscount — by error, fraud, selective inclusion, stopping the count early, recounting until they get the desired result. Most contested elections actually break down at this layer.
Failure mode 3: Who displays the results. Even if every voter is legitimate and the count is correct, if the result is reported by a trusted intermediary, that intermediary can misreport. Media networks calling elections early, selective release of precinct-level data, results announced with delays that shape narrative formation — all are presentation-layer attacks.
The design addresses all three layers cryptographically:
| Layer | Mechanism | Property |
|---|---|---|
| Qualification | Bicameral sortition machinery with adaptive scaling | No bureaucratic discretion; verifiable on-chain |
| Counting | TallyState covenant — counts increment as vote transactions confirm | No counting authority; close() permissionless; no named oracle |
| Presentation | Closed tally outcome is on-chain covenant state; readOnly() path | No announcement layer; the chain state is the result |
Every layer of the system is verifiable independently of any trusted party. Who voted? Verifiable. How did they vote? Verifiable. What was the count? Verifiable. What was the result? Verifiable. No layer at which a trusted intermediary stands between voters and result.
This is qualitatively different from any deployed voting system at any scale. Token DAOs have on-chain counting and presentation but weak qualification. Modern democracies have qualification (with bureaucratic vulnerability) but trust-based counting and presentation. Sortitioned citizens' assemblies have legitimate qualification through random selection but trust-based counting and presentation. No deployed system has all three layers cryptographically integrated. The Deviant voting design does.
Previously the polls layer was "qualified electorate decides through whatever mechanism the poll specifies" — once the qualification machinery produced Citizens, what they voted on was external to the system. The Elder layer's role was limited to admissions/demotions.
New structure: significant poll results are subject to Elder confirmation. Delegated Members can raise concerns about a vote result; if substantiated, Elder review activates; Elders can veto, rule a re-vote, or extend the voting period to reach maximum attendance.
This addresses faction capture and minority-attacker coordination at the same time — extending the voting period removes the structural advantage of "we vote, you don't notice, decision passes."
Adaptive scaling for Elder confirmation:
| Cohort size (N) | Elder confirmation required | Note |
|---|---|---|
| 1000+ | 1 Elder confirmation | Initial Elder review power |
| 2000+ | 2 Elder confirmations | Phased increase |
| 15000+ | 15-of-29 sortitioned Elders | Mature standard at the bicameral threshold |
| 16000+ | 16-of-30 | Continues phasing without ceiling |
| 20000+ | 20-of-39 | Elder participation scales with network |
The scaling continues without ceiling. Elders become a top tier on top of the voting mechanism, with their own bicameral-sortition-style integrity, scaling with the cohort. The Elder layer itself can adapt similar mechanisms to make rules stricter as the network grows.
Elder confirmation uses sortition (option C from the design exploration): 15-of-29 random Elders drawn from the total Elder cohort. This mirrors the Citizen/Delegated chamber design at the Elder layer, applies the same anti-coordination property (random selection prevents pre-arranged Elder bribery), and uses the same 52% threshold pattern.
Elder action scope (combination of A and C): Elders can veto the result entirely, rule a new poll/re-vote, or extend the voting period to reach maximum participation. They do not impose their own substantive determination — they protect procedural integrity, with the substantive decision remaining with the electorate.
Raising a concern about a poll result requires a sortitioned Delegated investigation to confirm the concern is worth raising. The 15-of-29 pattern applies at this layer too. This prevents a captured Delegated minority from grinding the Elder review machinery on every poll.
Flow: Concern raised → sortitioned Delegated investigation (15-of-29) → if substantiated, escalates to sortitioned Elder review (15-of-29 at mature scale, adaptive per the schedule above) → Elder action (veto, re-vote, or extended voting).
The Delegated cohort itself scales similarly to the Citizen and Elder cohorts. As the network grows, the Delegated investigation participation scales with it.
Cost to raise a concern: moderate (not minimal — discourages frivolous grinding; not extreme — doesn't suppress legitimate concerns from poorer participants). If the concern is substantiated, the cost is refunded to the appliers. This punishes frivolous concerns while rewarding substantiated ones.
Elder recertification can also be triggered. If concerns escalate to Elder review and substantiated misconduct is found, recertification for the involved Elders may be triggered. This adds recursive accountability — Elders reviewing a tainted poll may themselves face recertification if their handling is flawed.
An attacker accumulating BCH to fund any attack vector — qualification machinery infiltration, per-vote bribery, MBA acquisition for voting weight — faces geometric rather than linear cost scaling. Their own accumulation moves the BCH market price up. The marginal cost of each additional BCH unit acquired rises as accumulation grows.
Bitcoin Cash has no native derivatives, no margin, no leverage layer. The attacker cannot use 10x leverage to acquire BCH exposure at 1x cost. They must hold the actual BCH. Their accumulation is visible on-chain. Their purchases signal the attack before it completes.
This composes with the BCH price defending the system bidirectionally:
— As attack-driven demand pushes BCH price up, defender stakes (denominated in BCH) become more valuable
— Bribing a Citizen at $5K-$50K dollar value requires bribing them at higher BCH-denominated value if BCH has appreciated
— The attacker's acquired BCH buys less defender-loyalty per dollar than the naïve calculation suggests
— A compounding pro-defender dynamic: BCH price rises → defender stakes rise → bribery costs rise → attacker needs more BCH → BCH price rises further
For attacks of meaningful scale, BCH acquisition cost can be 2-5x the naïve "current price × quantity" calculation. For attacks approaching meaningful percentages of BCH supply, acquisition cost can become functionally unbounded — there is not enough BCH at any reasonable price to fund the attack.
The Dynamic Rate Asset (DRA), originally designated as the premium-feature anchor in the business model, has a rate function set at genesis (function-immutability) that escalates according to a protocol-enforced schedule. If DRA serves as a voting credential or voting-weight component, this property provides anti-accumulation defense built into the protocol itself.
Unlike BCH market scarcity (which is market-discovered geometric cost — the attacker's demand moves the market), DRA's rate escalation is protocol-encoded geometric cost. Every actor faces the same rate schedule. The cost of the 100th DRA versus the 1st is determined by code, not by market depth.
The two geometric cost curves compose multiplicatively. To acquire the 100,000th DRA, an attacker must pay the escalated rate (protocol-encoded high cost in BCH per DRA) and market price for that BCH (market-discovered, also high because their accumulation has moved BCH price).
Why DRA specifically among the MBA classes:
— DEA: fixed rate, permissionless mint, unlimited supply. Cost per DEA is constant in BCH terms. No protocol-encoded anti-accumulation.
— PLA: fixed rate, limited supply. Supply cap exists but no escalating cost; first PLA and last PLA cost the same.
— MCA / MTA: managed minting; would require authorization, which is a separate gating layer.
— DRA: escalating rate function. Uniquely suited as voting credential because protocol mechanics produce anti-accumulation directly.
Trade-off worth flagging: the same property that prevents attacker accumulation also creates barriers to legitimate participation by later joiners. The rate function's calibration matters — too aggressive escalation locks out future participants; too gentle doesn't provide the security benefit. The structural property is elegant; the parameter tuning requires care.
DRA structural placement remains open — whether it is a fifth MBA class, a property modifier on existing classes, or a parallel quadrant. The voting-credential role surfaced in this conversation may inform that placement decision.
Several iterations on the ASM's properties were needed to reach the accurate framing. Recording the final form:
Small P2P transfers of existing MBA between addresses are possible (this is just CashTokens transfer functionality). What this does NOT do: create new MBA, reduce the cost of acquiring MBA, or provide a path to acquire more MBA than the ASM has issued.
The total quantity of MBA in existence equals the total BCH deposited into the ASM at the protocol-enforced rate, minus any MBA redeemed back through the ASM.
An attacker who wants 100,000 DEA must — directly or indirectly through prior holders — have caused 100,000 × (ASM rate) BCH to be deposited into the ASM. The total cost of bringing the attack-relevant MBA quantity into existence is determined by the ASM, not by any market.
What the ASM prevents structurally:
— Leveraged shorts to create cheap MBA. No MBA lending market exists. No derivatives layer permits synthetic shorts. No off-chain wrapped MBA on a chain that does have derivatives is recognized.
— Distressed-price acquisition. The ASM rate is the floor. No holder will sell below the ASM rate because they can always redeem at the ASM rate instead. Distress doesn't produce a discount because the protocol always offers a better exit.
— Above-rate accumulation through any mechanism. The only path to acquire MBA is depositing BCH into the ASM at the configured rate.
The MBA exchange is a new quality of exchange. Not "limited counterparty trading" or "discouraged speculation" — a structurally different exchange mechanism entirely. The exchange is the ASM. The ASM is the rate. The rate is fixed.
The voting system recognizes only Bitcoin Cash protocol participation as legitimate. This is not a project scoping choice — it is a structural consequence of the protocol's design philosophy, as documented in Vol. 13 and developed further in Vol. 14.
What the voting system does not recognize:
— Tokens on other chains (Ethereum-bridged BCH, wrapped BCH, synthetic BCH on derivatives platforms)
— Off-chain claims of MBA ownership (custodial holdings where the actual MBAs are held by a custodian)
— Off-chain governance tokens that claim to represent MBA voting rights
— Derivative positions that synthetically replicate MBA exposure
— Any layer-2 representation
The voting system runs on Bitcoin Cash, and Bitcoin Cash treats layer-2 activity as counterfeit at the protocol level (developed in the on-chain-only design philosophy document). The voting system inherits this property because it operates within the protocol.
Initial framings described off-chain activity as "invisible to the voting system" or "not recognized by the protocol." This made it sound like passive non-acknowledgment — as if the off-chain world existed but the protocol simply didn't look at it.
The accurate framing is active. The protocol actively verifies every transaction against its consensus rules. Transactions trying to use anything the protocol doesn't recognize as legitimate are rejected at validation. The chain is not blind — it is discerning.
An attacker cannot construct a clever cross-chain mechanism, a sufficiently-anchored layer-2 representation, or an elaborate wrapped-token scheme that achieves on-chain recognition. The verification machinery is inspecting every transaction. There is no clever construction that bypasses verification, because verification is the only path through. Either the asset is on-chain and the chain sees it directly, or it's off-chain and the chain rejects the transaction trying to use it.
This framing is developed in detail with the bank counterfeit analogy in the on-chain-only design philosophy document. The voting system's security inherits the property: every vote is a transaction; every transaction is verified; the protocol rejects votes that try to use anything not properly held on-chain.
Pulling all corrections and additions together, the full security model:
Layer 1 — Qualification machinery. Sortition + vouching + bicameral confirmation + adaptive bootstrap scaling. Hardcoded, immutable. Robust through multi-axis defense composition.
Layer 2 — Counting and presentation. On-chain via TallyState. No trusted intermediaries between votes and result.
Layer 3 — Elder confirmation for significant polls. Sortitioned Elder review with adaptive scaling. Triggered by sortitioned Delegated investigation. Recursive accountability through optional Elder recertification triggers.
Layer 4 — Economic substrate constraints:
— BCH market dynamics (geometric price increase from accumulation pressure)
— No derivatives or leverage on Bitcoin Cash
— ASM-locked rates for MBA acquisition (no counterparty markets at attack-relevant scale)
— DRA's protocol-encoded escalating rate (additional protocol-level anti-accumulation if DRA serves as voting credential)
— On-chain-only recognition (off-chain activity is structurally invalid)
— Active rejection of invalid transactions (the protocol verifies, not just observes)
Layer 5 — Detection and accountability. All on-chain accumulation observable; bidirectional accountability through demotion machinery; recursive accountability through Elder recertification.
The combinatorial property: an attacker must defeat every layer simultaneously. Defeating any single layer is insufficient; the others continue to defend. The attack costs combine multiplicatively across the layers — not additively. The composition produces qualitatively higher security than any single-layer defense, even one well-engineered.
Initial analytical framings positioned the design as a "better DAO governance mechanism." This was scope-too-narrow. The corrected scope:
The design competes structurally with the full voting-system stack used in every existing voting system at every scale. Not just crypto DAOs. Modern democracies. Sortitioned citizens' assemblies. Proof-of-personhood systems. Constitutional governance.
The closest historical analogs are not crypto systems — they are 2,500 years old (Athenian sortition, Roman bicameralism) or modern democratic experiments (citizens' assemblies in Ireland, BC, Iceland). Token-weighted DAOs are not the closest comparison; they are one of the systems being structurally improved upon, alongside modern electoral democracies and proof-of-personhood verification systems.
The design's ambition is to occupy a structural position that essentially no deployed voting system currently holds: cryptographic integrity at all three failure-mode layers (qualification, counting, presentation) simultaneously, with economic substrate constraints that make capture-attacks geometrically expensive, with bidirectional accountability throughout, and with no governance over the governance machinery itself.
Trigger threshold for "significant" polls. What classifies a poll as significant (subject to Elder confirmation pathway) versus routine (decided within the qualified electorate without Elder review) needs explicit specification. The boundary should be constitutional — written into the contracts at deployment, not adjustable later.
DRA structural placement. Whether DRA is a fifth MBA class, a property modifier on existing classes, or a parallel quadrant remains open. The voting-credential role surfaced in this update may inform the resolution.
Elder participation requirements at scale. The adaptive scaling assumes the Elder cohort grows proportionally with the overall cohort. If Elder admission lags behind Citizen/Delegated growth, the system may require Elder participation that exceeds available Elders. The Elder admission schedule should be cross-checked against the confirmation requirement schedule.
Specific DRA rate function calibration. If DRA serves as voting credential, the escalating rate function's curve matters — too aggressive locks out legitimate latecomers; too gentle doesn't provide security benefit. The calibration is a design parameter to specify.
Relationship between qualification credentials and MBA-based voting weight. Whether voting weight is binary (Citizen status = 1 vote) or quantitative (Citizen status × DRA holdings = vote weight, with MBA holdings supplementing) needs explicit specification per poll type.