WIP is not a replacement for national governments. It does not claim sovereignty over any territory, levy taxes, or command armies. It does not seek to abolish the nation-state system. Attempts to do so would be both impractical and dangerous -- the nation-state, for all its flaws, remains the primary guarantor of individual rights in most of the world.

WIP is not a blockchain voting gimmick. The cryptocurrency space has produced dozens of "voting on the blockchain" projects, most of which collapse under scrutiny because they solve the wrong problem. They make vote *recording* tamper-proof while ignoring the far harder problems of voter identity, vote privacy, informed participation, and resistance to coercion. Recording an uninformed, coerced, or fraudulent vote on an immutable ledger does not make it democratic -- it makes it permanently wrong.

WIP is not a techno-utopian fantasy that assumes technology alone can fix politics. Technology is a necessary condition for global-scale democracy, but it is not sufficient. The protocol's design reflects a deep skepticism of purely technical solutions. Every cryptographic mechanism in WIP exists to serve a human value -- dignity, privacy, equality, informed consent -- not the other way around.

WIP is a civic infrastructure protocol -- a set of rules, algorithms, and cryptographic guarantees that enable any human being on Earth to participate meaningfully in decisions that affect their life. It is designed around five non-negotiable principles:

1. Universal inclusion. If you are human, you can participate. Not "if you have a government ID." Not "if you have a bank account." Not "if you live in a country that permits it." If you are human. This principle, drawn directly from Article 34 of the Charter ("All human beings are born free and equal in dignity and rights"), drives every design decision in the identity layer.

1. Informed participation. A vote without understanding is not self-governance -- it is noise. WIP's deliberation layer ensures that every voter engages with the substance of an issue before casting their ballot. This is not a literacy test. It does not filter people out. It rewards engagement while preserving the inviolable base vote. The distinction matters enormously, and we will examine it in detail in the Voting Formula section.

1. Absolute privacy. Your vote is yours. No government, no corporation, no system operator, no fellow citizen can ever discover how you voted. This is not merely a preference -- it is a requirement derived from Article 41 (Privacy) and Article 55 (Freedom from Unlawful Surveillance) of the Charter. The zero-knowledge proof system, the commit-reveal protocol, and the mixnet all exist to make this guarantee mathematical rather than merely legal.

1. Verifiable integrity. Every participant can independently verify that every valid vote was counted and that the tally is correct, without being able to identify any individual voter. This is the central tension in voting system design -- privacy and verifiability seem to be in opposition. WIP resolves this tension through zero-knowledge proofs, which allow a statement ("this tally includes exactly N valid votes") to be proven true without revealing the underlying data.

1. Subsidiarity. Not every decision should be made at the global level. WIP's four-tier governance structure (Local, Regional, National, Global) ensures that decisions are made at the most appropriate level by the people most affected. A water management dispute in a specific watershed should be decided primarily by the people who drink that water. A global emissions target should be decided by all of humanity. The proximity weight in the voting formula encodes this principle mathematically.

Let us be candid about the scale of what we are attempting. No voting system in history has operated at the scale WIP envisions. The largest democratic exercises in the world -- India's general elections -- involve approximately 900 million eligible voters, but they occur over weeks, use paper ballots, and rely on a massive physical infrastructure of polling stations, security personnel, and election officials. WIP aims to enable billions of people to participate in decisions continuously, from their phones, with stronger privacy guarantees than any paper ballot system and stronger verifiability than any electronic voting system currently deployed.

This is hard. Parts of it may prove to be harder than we currently estimate. The protocol is designed to be deployed incrementally -- starting with small communities, scaling to regions, then nations, then the world. Each layer of the architecture has been designed to function independently so that the system delivers value even during partial deployment. A village in rural India can use the identity and voting layers for local governance decisions long before the global tally system is operational.

Three technological developments have made WIP possible in 2026 in ways that would have been impossible even five years ago:

• Zero-knowledge proof systems have matured from academic curiosities to production-ready cryptographic tools. The proving time for a ZK-SNARK circuit has dropped from minutes to milliseconds. This makes it practical to verify vote validity on a mobile device.

• Trusted Execution Environments are now standard in consumer smartphones. Apple's Secure Enclave and Android's StrongBox provide hardware-isolated computation that even a compromised operating system cannot access. This makes on-device biometric identity feasible without trusting any central server.

• Application-specific blockchains (particularly the Cosmos SDK ecosystem) allow us to build a sovereign chain optimized for voting rather than forcing voting transactions into a general-purpose blockchain designed for financial transfers. This gives us control over consensus parameters, transaction costs, and governance rules that would be impossible on Ethereum or Bitcoin.

The convergence of these technologies, combined with the political urgency of our moment -- a moment defined by climate deadlines, AI governance gaps, and declining trust in democratic institutions -- creates a window of opportunity. The World Intelligence Protocol is designed to fit through that window.

*"Every person is a citizen of the world as well as of their own community and nation. This global citizenship does not replace other identities but complements them."* -- Article 32, Universal Charter

The pages that follow describe how this vision translates into engineering. Every design decision traces back to the principles outlined above. Where we faced tradeoffs, we will explain what we chose and why. Where we considered alternatives, we will explain why they were rejected. The goal is not merely to describe a system, but to make you -- the skeptical, curious reader -- understand why this system, designed this way, is the best answer we have found to the question: How should humanity govern itself?

The voting formula is the single most consequential design decision in the World Intelligence Protocol. It determines whose voice counts, how much, and why. Get it wrong, and you have built either a plutocracy with extra steps or a system so flatly egalitarian that it cannot distinguish signal from noise. The formula we have chosen is:

**V = B x (1 + CW + PX)** Where B = 1.0 (base vote), CW = 0.0-0.25 (comprehension weight), PX = 0.0-0.25 (proximity weight) Minimum vote weight: 1.0 | Maximum vote weight: 1.5

Every element of this formula was debated extensively. What follows is an account of those debates.

The base vote of 1.0 is not a design parameter. It is a constitutional guarantee.

Article 39 of the Charter establishes "universal and equal suffrage." Article 34 states that "all human beings are born free and equal in dignity and rights." The base vote is the mathematical expression of these articles. Every verified human being -- regardless of education, wealth, location, age, or any other characteristic -- receives exactly 1.0. This value cannot be reduced. It cannot be suspended. It cannot be conditional.

Why is this important enough to state so emphatically? Because the history of weighted voting is, almost without exception, a history of exclusion disguised as meritocracy.

The United States Constitution originally counted enslaved people as three-fifths of a person for apportionment purposes. The British Parliament granted extra votes to university graduates and business property owners until 1948. Apartheid South Africa created elaborate racial classifications to determine voting eligibility. In each case, the architects of these systems produced sophisticated justifications for why some people's voices should count more than others. In each case, those justifications served the interests of the powerful at the expense of the vulnerable.

WIP's comprehension and proximity weights could, in the wrong hands, become instruments of the same kind of exclusion. This is why the base vote is inviolable. The weights are additive bonuses, not multiplicative factors that could reduce anyone's voice below 1.0. The worst possible outcome for any voter is that they cast a vote worth exactly 1.0 -- the same as every other human being on Earth. The best possible outcome is 1.5. The ratio between the most influential vote and the least influential vote is therefore 1.5:1. This is not an accident. It is a deliberately chosen constraint.

Why not 0.0 as a base? Some early designs considered a model where the base vote was 0.0 and all weight came from comprehension and proximity. This was rejected immediately and categorically. A system where uninformed voters have zero weight is not a democracy -- it is an epistocracy, rule by the knowledgeable. Epistocracy has well-documented failure modes: it concentrates power among those with access to education (which correlates with wealth), it assumes that knowledge produces wisdom (which it does not), and it creates perverse incentives to game the knowledge assessment rather than genuinely engage with the issues.

Why not a higher base, like 5.0 or 10.0? A higher base with the same additive weights (0.25 + 0.25) would make the weights negligible. With a base of 10.0, the maximum vote is 10.5, a ratio of 1.05:1. At that point, the comprehension incentive is so small that it has no practical effect on behavior. The base of 1.0 was chosen because it makes the maximum ratio (1.5:1) meaningful enough to incentivize engagement without being so large that it undermines equality.

The comprehension weight (CW) is the most philosophically novel element of the formula. It asks a question that traditional democracy does not ask: Did you understand the issue before you voted?

This is emphatically *not* a question about whether you reached the *right* answer. There is no "right" answer in a democratic vote. The comprehension check measures whether you can accurately describe the arguments on *all sides* of the issue -- not whether you agree with any of them.

Here is how it works in practice:

1. Before voting on a proposal, you enter the deliberation phase. You are presented with balanced perspectives on the issue, curated by diverse editorial panels -- not algorithms, not partisan media, not social media feeds. Every voter sees the same materials.

1. After reviewing the materials, you complete a brief assessment. The questions are designed to test comprehension, not opinion. For example, on a proposal about carbon pricing, a comprehension question might ask: "What is the primary argument made by opponents of this proposal?" The correct answer does not depend on whether you support or oppose carbon pricing -- it depends on whether you understood the opposition's argument.

1. Your comprehension score is translated to a weight between 0.0 and 0.25 using a continuous function. A perfect score gives 0.25. A score below the threshold gives 0.0. Intermediate scores give intermediate weights.

Why comprehension and not expertise? Expertise-based weighting was considered and rejected. The problem with expertise is that it is domain-specific and credentialist. A climate scientist's expertise is relevant to climate proposals but not to education policy. A system that weights expertise must define who counts as an expert, which inevitably becomes a gatekeeping exercise. Comprehension, by contrast, is issue-specific and universally accessible. A farmer who carefully reads the deliberation materials on agricultural trade policy can score as well as an economist. A teenager who studies the perspectives on digital privacy can score as well as a lawyer. Comprehension rewards the act of engagement, not the accident of credentialing.

Why is it capped at 0.25? The cap serves two functions. First, it limits the maximum influence of any single voter to 1.5x the minimum, preserving the equality principle. Second, it prevents the comprehension system from becoming the primary determinant of election outcomes. If comprehension weight were uncapped -- say, 0.0 to 5.0 -- then the people who scored highest on comprehension checks would dominate every vote, effectively creating an epistocracy. The 0.25 cap means that comprehension is a meaningful incentive but not a decisive advantage.

Who scores the comprehension checks? The assessments are scored by open-source AI models trained specifically for this purpose. The scoring algorithms are published, auditable, and subject to ongoing review by independent fairness panels. This is one of the most sensitive components of the system, and we treat it accordingly. The AI models are tested for bias across languages, cultures, and educational backgrounds. Human review panels adjudicate edge cases and disputed scores. The scoring criteria are published before each proposal's deliberation phase begins, so voters know exactly what is being assessed.

Can the comprehension check be gamed? Any assessment can be gamed. The question is whether the game-theoretic equilibrium incentivizes genuine learning or rote memorization. Because the comprehension check requires understanding arguments on all sides of an issue, gaming it requires actually engaging with those arguments -- which is the desired outcome. A voter who memorizes opposing arguments well enough to score 0.25 has, in the process, become a more informed voter. The gaming incentive is aligned with the system's goal.

The proximity weight (PX) encodes a principle that is intuitive but rarely formalized in democratic systems: the people most directly affected by a decision should have a somewhat greater say in that decision.

If a proposal concerns water management in a specific river basin, the farmers and residents who depend on that water have a legitimate claim to greater influence than someone living 3,000 kilometers away. If a proposal concerns global carbon emissions targets, everyone on Earth is affected, and proximity differences are negligible.

Proximity is calculated along multiple dimensions:

• Geographic proximity. How close are you to the physical impact of the proposal? This is calculated from the voter's registered location (which is self-declared and privacy-protected) relative to the proposal's declared impact zone.

• Economic proximity. Does the proposal directly affect your livelihood? A tariff on agricultural imports is more proximate to farmers than to software developers.

• Demographic proximity. Does the proposal specifically concern your demographic group? A proposal about maternal healthcare is more proximate to people who can become pregnant.

The proximity calculation is transparent -- voters can see why they received a particular proximity weight and can appeal if they believe it was calculated incorrectly.

Why not let proximity go higher? The same argument that caps comprehension at 0.25 applies here. Higher proximity weights would mean that local majorities could dominate global decisions. A coal-mining community might receive very high proximity on an emissions proposal and vote to block it, overriding the interests of billions of people affected by climate change. The 0.25 cap ensures that proximity provides a meaningful voice amplification without creating local vetoes over global issues.

Why not use proximity alone, without comprehension? A system with only proximity weight would amplify the voices of affected parties without ensuring they understood the issue. A person with high proximity but low comprehension might vote against their own interests due to misinformation. The combination of both weights creates a system where the ideal voter is both affected and informed.

The maximum vote weight ratio of 1.5:1 was not chosen arbitrarily. It is the result of a deliberate analysis of the tradeoff between incentivizing engagement and preserving equality.

Why not 2.0:1? A 2:1 ratio means that one informed, proximate voter has the same influence as two uninformed, distant voters. This begins to feel undemocratic. In a close election, it could mean that a minority of highly engaged voters overrides a majority of less engaged ones. Historical analysis of close elections suggests that ratios above 1.5 significantly increase the probability of minority-rule outcomes.

Why not 3.0:1 or higher? At 3:1, the system ceases to be meaningfully democratic. Three highly engaged voters could outvote nine less engaged ones. The incentive to game the comprehension system would become overwhelming, and the legitimacy of outcomes would be questioned by anyone who received the minimum weight.

Why not 1.0:1 (no weighting at all)? Pure equality has its own failure mode: it provides no incentive for voters to engage with the substance of issues. Empirical evidence from deliberative democracy experiments shows that even small incentives for comprehension significantly improve the quality of collective decisions without undermining perceived legitimacy. The 1.5:1 ratio is the sweet spot -- large enough to matter, small enough to preserve the democratic character of the system.

The formula V = B x (1 + CW + PX) is, ultimately, a mathematical expression of a moral claim: every person's voice is equal in dignity, but a society benefits when its members make the effort to understand each other. The formula rewards that effort without punishing those who do not or cannot make it.

The identity problem is the hardest problem in digital democracy. Every other technical challenge -- privacy, verifiability, scalability -- becomes trivial if you cannot first solve the question: How do you ensure that each vote comes from a unique, real human being, without creating a surveillance infrastructure that undermines the democracy you are trying to build?

This section describes WIP's answer: a layered identity system that combines on-device biometrics, hardware-isolated computation, social trust networks, and zero-knowledge proofs to achieve a property we call sybil-resistant pseudonymity -- the guarantee that each human has exactly one vote, without any central authority knowing which human cast which vote.

The Humanity Key is a unique cryptographic identifier that proves you are a real, unique human being. It is not a username, not an email address, not a government-issued ID number. It is a value derived from your biometric data through a one-way process that makes it computationally impossible to reconstruct the original biometrics from the key.

Think of it as a fingerprint of a fingerprint -- a mathematical abstraction so far removed from the original that it tells the system nothing about you except that you are you, and that you have not registered before.

The Humanity Key is generated entirely on your device. No server ever sees it during creation. No database stores the biometric data from which it was derived. The key exists in a Trusted Execution Environment (TEE) on your phone -- a hardware-isolated area that even a compromised operating system cannot access. Once generated, the Humanity Key is registered on the Cosmos blockchain as a leaf in a Merkle tree. This registration proves that a verified human exists without revealing any information about that human.

How does it differ from existing digital identity systems? Fundamentally. Consider the alternatives:

• Government ID systems (passports, national ID cards) are issued by a sovereign authority, which can revoke them, refuse to issue them, or use them for surveillance. They exclude stateless people, refugees, and anyone whose government has collapsed or is hostile to them.

• Corporate identity systems (Google accounts, Apple IDs, Meta accounts) are controlled by private companies whose incentives are misaligned with democratic participation. They require personal data, track behavior, and can terminate access at will.

• Self-sovereign identity systems (most blockchain-based identity projects) solve the centralization problem but typically rely on government-issued credentials as their root of trust, inheriting all the exclusion problems of government ID.

The Humanity Key is rooted in biology, not bureaucracy. You prove your humanity through your body -- your face, your voice -- processed in a way that produces a unique identifier without storing or transmitting the biometric data itself. This design choice has a single overriding justification: no human being should need permission from any institution to participate in democracy.

When you enroll in WIP, your phone's camera captures your face and your microphone captures your voice. These raw biometric inputs are immediately processed inside the device's Trusted Execution Environment through a multi-step pipeline:

1. Feature extraction. The raw image and audio are converted into numerical feature vectors -- compact mathematical representations that capture the unique characteristics of your face and voice. This is the same type of processing used by FaceID and fingerprint sensors, but applied for identity derivation rather than access control.

1. Hashing. The feature vectors are combined and passed through a cryptographic hash function (SHA-256). The output is a 256-bit digest -- the Humanity Key. This hash is one-way: given the hash, it is computationally infeasible to reconstruct the feature vectors, let alone the original biometric data. Even if someone intercepted the hash, they could not recreate your face or voice from it.

1. Uniqueness check. The Humanity Key is compared against all existing keys in the on-chain Merkle tree using a zero-knowledge proof. This proof demonstrates that the new key does not match any existing key without revealing either the new key or the existing keys to any third party.

Why biometrics? Because they are the only characteristic that is simultaneously universal (every human has a face and a voice), unique (no two humans share the same biometric signature), and non-transferable (you cannot give your face to someone else). Government IDs can be forged, shared, or denied. Passwords can be stolen. Private keys can be sold. But your face is yours, permanently and inalienably.

Why on-device? Because any system that transmits biometric data to a server creates a honeypot -- a centralized store of the most sensitive possible personal information. History provides abundant examples of what happens when such databases are compromised. The U.S. Office of Personnel Management breach in 2015 exposed 5.6 million fingerprint records. India's Aadhaar system has faced repeated security concerns about its centralized biometric database. By ensuring that biometric data never leaves the device, WIP eliminates the honeypot entirely. There is no database to breach because the database does not exist.

Why hashing? Because hashing provides an irreversible transformation. The raw biometric data is destroyed after the Humanity Key is generated. The phone retains only the hash. Even if the phone is seized, the hash cannot be reversed to produce usable biometric information. This is the same principle that protects passwords in well-designed systems -- the system never stores your password, only a hash of it.

A Trusted Execution Environment (TEE) is a secure area within a processor that runs code in isolation from the main operating system. Even if the phone's OS is compromised by malware, the TEE remains secure. Code running inside the TEE cannot be observed, modified, or interfered with by code running outside it.

On Apple devices, the TEE is called the Secure Enclave -- a dedicated processor with its own encrypted memory, separate from the main A-series or M-series chip. On Android devices, the equivalent is StrongBox -- a tamper-resistant hardware security module that meets the same isolation requirements.

WIP uses the TEE for the entire biometric processing pipeline: feature extraction, hashing, key generation, and proof computation all occur within this hardware-isolated environment. This provides several critical guarantees:

• The operating system cannot access the biometric data. Even if a malicious app has root access to the phone, it cannot read the data being processed inside the TEE.

• The computation is tamper-proof. The TEE guarantees that the code running inside it has not been modified. This means the hashing algorithm is provably correct -- no one has substituted a backdoored version.

• The output is attestable. The TEE can produce a signed attestation that a particular computation was performed correctly inside a genuine TEE. This attestation is verified on-chain, providing a hardware-backed guarantee that the Humanity Key was generated through the correct process.

Why is this better than server-side processing? Server-side processing requires trusting the server operator. In a global democratic system, "the server operator" might be a government, a corporation, or an international organization -- all of which have interests that could conflict with voter privacy. TEE-based processing eliminates the need to trust anyone except the hardware manufacturer, and even that trust is bounded by the attestation mechanism.

Biometric enrollment is the primary path to identity verification in WIP, but it is not the only path. The social vouching system provides an alternative for people who cannot complete biometric enrollment -- whether due to disability, lack of a compatible device, cultural objections to facial recognition, or any other reason.

Social vouching works as follows:

1. Three already-verified humans (holders of valid Humanity Keys) vouch for the new participant's identity.
2. Each voucher stakes a small amount of reputation -- if the person they vouch for is later found to be a duplicate or a bot, the vouchers' reputation scores are penalized.
3. The new participant receives a Humanity Key derived from the vouching transaction rather than from biometrics.

Why three vouchers? The number three was chosen based on analysis of social network resilience. Two vouchers can be trivially corrupted -- a bad actor and one accomplice. Four or more creates an unnecessarily high barrier to entry that would exclude isolated individuals. Three provides a meaningful trust threshold while remaining accessible. Historical precedent also supports this number: many legal systems require two or three witnesses for significant acts, and informal trust networks typically converge on similar thresholds.

What prevents abuse? The reputation staking mechanism creates skin in the game. Vouching for a fraudulent participant imposes real costs on the vouchers. Additionally, the system monitors vouching networks for suspicious patterns -- a single person who vouches for hundreds of accounts, or tight clusters of accounts that only vouch for each other, are flagged for review.

Is social vouching less secure than biometrics? Yes, somewhat. Biometric verification provides a hardware-attested guarantee of uniqueness; social vouching provides a socially-attested one. The tradeoff is intentional. WIP prioritizes inclusion over security purity. A system that achieves perfect sybil resistance but excludes 10% of humanity has failed at its core mission. Social vouching is the safety valve that ensures no one is left out.

*"All human beings are born free and equal in dignity and rights. Every person, without distinction of any kind -- including race, color, sex, language, religion, political opinion, national or social origin, property, birth, or other status -- is entitled to the full protection of this Charter."* -- Article 34, Universal Charter

This is the question we receive most often, and it deserves a thorough answer. Government-issued identity documents are the standard root of trust for most systems that require identity verification. Why does WIP not simply require a passport or national ID?

The answer has four dimensions:

1. Exclusion. Approximately 850 million people worldwide lack any form of government-issued identification. This includes refugees who have fled without documents, indigenous peoples in remote regions, people in failed states where civil registries have been destroyed, and populations living under governments that deliberately deny identity documents to marginalized groups. A voting system that requires government ID is, by definition, a voting system that excludes hundreds of millions of the world's most vulnerable people. This is not an acceptable tradeoff for a system whose founding document declares that "every person" has the right to participate.

2. Surveillance. Government IDs are surveillance tools. They link your identity to your activities -- where you travel, what you buy, how you vote. In many countries, voting is already compromised by the government's ability to correlate voter registration data with voting patterns. WIP's entire privacy architecture would be undermined by relying on government ID as the root of trust, because the government that issued the ID could always link the ID to the vote.

3. Sovereignty. Requiring government ID means giving governments veto power over democratic participation. A government that does not want its citizens participating in WIP can simply refuse to issue or validate IDs for that purpose. This has historical precedent: voter ID laws in the United States have been repeatedly shown to disproportionately disenfranchise minority communities. A global democratic system cannot be subject to the gatekeeping of individual governments.

4. Statelessness. The Rohingya, the Palestinians in certain jurisdictions, the Bidoon of the Gulf states, the hill tribes of Thailand -- millions of people exist in a legal limbo where no government claims them. These are precisely the people who most need a voice in global governance, and they are precisely the people a government-ID-based system would exclude.

The Humanity Key is designed to route around all four of these failure modes. Your identity is rooted in your biology, verified by hardware on your own device, and registered on a blockchain that no single government controls. This is not a rejection of government identity -- people who have government IDs can certainly use them as supplementary verification. It is a refusal to make government identity a prerequisite for the fundamental human right of participation.

*"All peoples have the right to determine their own destiny, to choose their political status, and to pursue their economic, social, and cultural development. No people shall be deprived of their own means of subsistence or their right to shape their future."* -- Article 44, Universal Charter

In a traditional election, voters cast their ballots in private booths and the results are announced after all polls close. This two-phase structure -- secret ballot followed by simultaneous reveal -- is so deeply embedded in democratic practice that most people never question why it exists.

The reason is simple and profound: if voters could see how others voted before casting their own ballots, the election would cease to be a genuine expression of individual will. It would become a strategic game where the last voter always wins, where early voters are punished for honesty, and where the outcome reflects social pressure rather than private judgment.

The commit-reveal protocol is the cryptographic equivalent of the sealed ballot box. It ensures that in a digital voting system -- where there is no physical booth, no paper ballot, no sealed container -- the same guarantees hold. But it does so using mathematics rather than physical security, which makes the guarantees stronger, not weaker.

Consider what happens in a single-phase digital voting system. Votes are submitted and recorded on a blockchain. Even if the votes are encrypted, the *fact* that a vote was submitted is visible. An observer can see the timing, the transaction size, and potentially the source address. In a close election, these metadata alone can reveal the trajectory of the vote and allow strategic behavior.

The game theory is straightforward. In a single-phase system:

• The last-voter advantage. If voting happens over a period of time and running tallies are visible (even approximately), the last voters have perfect information and can vote strategically. This creates an incentive to delay voting, which in turn creates an incentive for everyone to delay voting, which collapses participation.

• Coercion and vote-buying. If votes are visible as they are cast, a coercer can verify that the victim voted as instructed. A vote-buyer can confirm the transaction. Even if the votes are encrypted, the timing and metadata of submission can be used as a coercion channel ("submit your vote at exactly 3:47 PM and I will know it was you").

• Bandwagon and underdog effects. Visible voting momentum creates psychological pressure. If one option is clearly winning, some voters switch to it (bandwagon) while others switch away from it (underdog). Both effects distort the honest aggregation of preferences.

The commit-reveal protocol eliminates all three problems by separating the act of committing to a choice from the act of revealing that choice.

During the commit phase, each voter constructs a commitment by concatenating three values and hashing them together:

**commitment = SHA-256(vote || weight || nonce)**

Let us examine each component:

• vote: The voter's choice (e.g., "yes," "no," or a candidate identifier), encoded as a standard byte sequence.

• weight: The voter's calculated vote weight (an integer between 1000 and 1500, representing 1.000 to 1.500 scaled by 1000 for integer arithmetic). The weight is included in the commitment to prevent post-hoc weight manipulation -- once committed, neither the vote nor the weight can be changed.

• nonce: A cryptographically random 256-bit value generated on the voter's device. The nonce serves a critical function: it makes the commitment unpredictable. Without the nonce, an attacker who knows the set of possible votes (often just "yes" or "no") could hash each option and compare against the commitment to determine the vote. The nonce makes this impossible -- even if the vote is binary, the nonce adds 2^256 possible commitment values for each option, making brute-force reversal computationally infeasible.

Why SHA-256? SHA-256 is the most widely deployed and thoroughly analyzed cryptographic hash function in the world. It has been the subject of two decades of cryptanalysis with no practical attacks found. It is standardized by NIST, implemented in hardware on most modern processors, and understood by every cryptography library in every programming language. We considered newer hash functions (SHA-3, BLAKE3) but chose SHA-256 for its maturity, universality, and the confidence that comes from extensive public scrutiny.

Why concatenation and not a Merkle construction? The commitment is a single hash of a flat concatenation because the structure is simple: three fixed-length fields (vote, weight, nonce) produce a single commitment. A Merkle construction would add complexity without security benefit. The concatenation order is specified in the protocol to prevent ambiguity -- vote first, then weight, then nonce, with each field length-prefixed to prevent boundary confusion.

The commitment is submitted to the Cosmos blockchain as a transaction. Once the transaction is confirmed, the commitment is immutably recorded. The voter retains the original vote, weight, and nonce locally (encrypted in the TEE) for later reveal.

The reveal phase begins after the commit window closes. During the reveal phase, every voter who submitted a commitment must submit a reveal transaction containing their original vote, weight, and nonce. The on-chain smart contract recomputes SHA-256(vote || weight || nonce) and verifies that it matches the previously submitted commitment. If it matches, the vote is counted. If it does not match, the vote is discarded.

The critical design decision is that all reveals happen within a single, bounded window, and no results are calculated or published until the window closes. This means:

• No voter can see any other voter's revealed vote before revealing their own.
• No observer can compute partial tallies during the reveal phase.
• The tally is calculated from the complete set of valid reveals, atomically.

Why not reveal instantly after commit? Because instant reveal recreates the single-phase problem. If the first voter's reveal is visible before the last voter reveals, the last voter can adjust their behavior (even though they cannot change their committed vote, they could choose not to reveal -- a form of strategic abstention). The bounded reveal window with atomic tally calculation prevents this.

What happens if someone does not reveal? A committed vote that is not revealed during the reveal window is treated as an abstention. The commitment remains on-chain as a record that the voter participated in the commit phase, but the unrevealed vote is not counted. This creates a minor strategic concern -- a voter could commit and then withhold their reveal if they learn (through side channels) that the result is already going their way. To mitigate this, WIP publishes no intermediate results during the reveal phase and incentivizes reveal through reputation penalties for consistent non-revelation.

How long is the reveal window? The duration depends on the governance tier and the significance of the proposal. Local proposals might have a reveal window of 24 hours. Global proposals might have a window of 72 hours. The window must be long enough for all committed voters to submit their reveals, accounting for timezone differences, network connectivity issues, and the reality that not everyone checks their phone every day. The window must be short enough that the period of uncertainty does not create instability.

Once a commitment is submitted to the blockchain, it cannot be altered. This finality is a deliberate design choice, not a limitation.

The case for finality:

1. Coercion resistance. If votes could be changed after commitment, a coercer could force a voter to change their vote after the fact. Finality means that once you have committed, no one -- not even you -- can alter the record. This protects voters who are under pressure by giving them a truthful statement: "I cannot change it, even if I wanted to."

1. Protocol integrity. The commit-reveal protocol's security depends on the binding nature of commitments. If commitments could be revised, the protocol degenerates into a single-phase system with extra steps. The mathematical guarantees -- that the reveal must match the commitment, that the commitment was made without knowledge of other commitments -- require finality.

1. Deliberative incentive. Finality encourages voters to take the commitment seriously. If you can always change your vote later, the incentive to carefully consider your position before committing is weakened. Finality is a forcing function for deliberation.

The case against finality (and why we rejected it):

Critics argue that people sometimes change their minds for legitimate reasons -- new information emerges, a persuasive argument is encountered, or the voter simply makes an error. In traditional elections, early voting and absentee ballots sometimes allow change (by voiding the early ballot), and some argue WIP should do the same.

We considered and rejected this for two reasons. First, the deliberation phase *precedes* the commitment phase precisely to address this concern. The system is designed so that voters encounter all relevant information and arguments before they commit, not after. Second, allowing vote changes fundamentally undermines the commit-reveal protocol's security guarantees. You cannot have both changeability and coercion resistance -- they are in direct tension.

The protocol's answer to "what if I change my mind?" is: you had the deliberation period to form your judgment, and the commitment period to finalize it. The reveal is merely the mechanical execution of a decision already made. This mirrors the physical ballot: once you drop it in the box, it is done. WIP simply makes this finality explicit and mathematically enforced.

*"No one shall be subjected to arbitrary surveillance or interference with their private affairs."* -- Article 41, Universal Charter

The commit-reveal protocol ensures that your vote is a private act, committed with finality and revealed only alongside millions of others, in a moment of collective transparency that no individual actor can manipulate.

Zero-knowledge proofs are the cryptographic heart of the World Intelligence Protocol. They solve a problem that seems impossible on its face: how can you prove that a statement is true without revealing any information beyond the truth of that statement? In the context of WIP, zero-knowledge proofs enable two critical properties simultaneously -- you can prove that your vote is valid (you are a real, unique, verified human with a correctly calculated weight) while revealing absolutely nothing about who you are, what you voted, or what your exact weight is.

This section explains what zero-knowledge proofs are, why WIP uses them, and how the specific proof circuits are designed.

Imagine you are colorblind and your friend claims to be able to distinguish a red ball from a green ball. You are skeptical. Your friend wants to prove they can tell the difference without revealing *how* they do it (perhaps their method is a secret).

Here is the protocol: you hold both balls behind your back, one in each hand. You either swap them or do not swap them (you choose randomly, and your friend cannot see what you do). Then you show them both balls and ask: "Did I swap them?" If your friend can really distinguish the colors, they will always answer correctly. If they are guessing, they will be right only 50% of the time.

After 100 rounds of this game, if your friend has answered correctly every time, you can be overwhelmingly confident that they can distinguish the balls -- the probability of guessing correctly 100 times in a row is 1 in 2^100, which is vanishingly small. And yet, at no point in this process did your friend reveal anything about *how* they distinguish the colors. They proved knowledge (of the difference) without transferring knowledge (of the method).

This is the essence of a zero-knowledge proof: the *prover* convinces the *verifier* that a statement is true, and the verifier learns nothing except that the statement is true.

In WIP, the proofs are not interactive (we do not play 100 rounds of a game). Instead, we use ZK-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge), which compress the entire proof into a single, compact mathematical object that can be verified in milliseconds. The "non-interactive" property is essential for a blockchain system -- the proof is submitted once and verified by anyone, without requiring back-and-forth communication between prover and verifier.

The first ZK circuit in WIP is the weight proof circuit. Its purpose is simple to state and subtle to implement: it proves that a voter's weight is a valid value in the range [1000, 1500] (representing 1.000 to 1.500) without revealing the exact value.

Why is this necessary? Because the vote commitment includes the weight, and the tally depends on weights. The system must verify that every vote uses a correctly calculated weight -- no one should be able to claim a weight of 10.0 or 0.0. But if the exact weight were revealed, it would leak information about the voter's comprehension score and proximity, which could be used to narrow down their identity.

The circuit works as follows:

1. Private inputs (known only to the prover/voter):

• The exact weight value (e.g., 1237)
• The comprehension score and proximity score that produced this weight
• The nonce used in the commitment

1. Public inputs (visible to everyone):

• The vote commitment hash (already on-chain)
• The Merkle root of the identity tree (proving the voter exists in the set of verified humans)

1. The circuit proves three statements simultaneously:

• The weight was correctly computed from valid comprehension and proximity scores using the formula V = B x (1 + CW + PX)
• The weight falls within [1000, 1500]
• The commitment hash matches SHA-256(vote || weight || nonce) for the claimed vote and weight

The verifier (the on-chain smart contract) checks the proof and confirms all three statements are true. At no point does the verifier learn the exact weight, the comprehension score, the proximity score, or the vote. The verifier learns only: "this is a valid vote from a verified human with a correctly calculated weight in the legal range."

Why a range proof and not an exact value? Because the exact value is a privacy leak. If your weight is 1.437, and the system knows that only 12 voters in your geographic area received comprehension and proximity scores that produce that exact weight, your anonymity set shrinks dramatically. A range proof says only "your weight is between 1.0 and 1.5," which is true of every voter and reveals nothing distinguishing.

How is the circuit implemented? WIP uses Circom for circuit definition and Groth16 for proof generation and verification. Circom is a domain-specific language for defining arithmetic circuits (the mathematical structure that underlies ZK-SNARKs). Groth16 is a proof system that produces very small proofs (approximately 128 bytes) with fast verification time (approximately 1-2 milliseconds), making it suitable for on-chain verification where storage and computation are expensive.

The tradeoff of Groth16 is that it requires a trusted setup -- a one-time ceremony that generates proving and verification keys. If the toxic waste from this ceremony is not properly destroyed, a party with access to it could forge proofs. WIP mitigates this risk through a multi-party ceremony where each participant contributes randomness, and the setup is secure as long as at least one participant was honest. The ceremony will be public, auditable, and involve hundreds of independent participants.

The second ZK circuit is the identity proof circuit. It proves that the voter is a member of the set of verified humans (i.e., their Humanity Key is a leaf in the on-chain Merkle tree) without revealing which leaf.

This is a classic Merkle proof in zero knowledge. In a standard Merkle proof, you prove membership by revealing the leaf and the path of hashes from the leaf to the root. In a ZK Merkle proof, you prove the same statement without revealing the leaf or the path.

1. Private inputs:

• The voter's Humanity Key (the Merkle leaf)
• The authentication path (the sequence of sibling hashes from the leaf to the root)

1. Public inputs:

• The Merkle root (published on-chain, representing the current set of verified humans)

1. The circuit proves:

• There exists a leaf in the Merkle tree, and a valid authentication path from that leaf to the published root
• The prover knows the leaf value (i.e., they possess the Humanity Key)

The verifier confirms that the prover is a verified human without learning which one. The anonymity set is the entire set of verified humans -- potentially billions of people.

Why a Merkle tree? Because Merkle trees provide efficient membership proofs with logarithmic complexity. For a tree with 8 billion leaves (one per human), the authentication path is only 33 hashes long. This makes the ZK circuit feasible on a mobile device. Alternative set membership structures (bloom filters, accumulators) were considered but rejected for various reasons: bloom filters have false positive rates that are unacceptable for voting, and cryptographic accumulators, while theoretically elegant, have higher computational costs for proof generation.

Homomorphic encryption (HE) is the other major cryptographic approach to private computation. HE allows computation on encrypted data -- you can add encrypted votes together without decrypting them, producing an encrypted tally that, when decrypted, reveals the correct total.

WIP chose zero-knowledge proofs over homomorphic encryption for four reasons:

1. Performance. Fully homomorphic encryption is orders of magnitude slower than ZK proof generation and verification. A single HE addition can take milliseconds, which seems fast until you consider that a global election might involve billions of votes. The tally computation under HE would take hours or days. ZK proofs, by contrast, are verified independently per vote, and the tally is a simple sum of revealed (and proven-valid) votes.

2. Verifiability. ZK proofs produce a verifiable artifact -- anyone can check the proof and confirm the statement is true. HE produces an encrypted result that must be decrypted by a key holder. This introduces a trust requirement: someone must hold the decryption key, and you must trust them to decrypt honestly and not collude. ZK proofs eliminate this trusted third party.

3. On-chain constraints. The Cosmos blockchain has limited computational resources per block. ZK proof verification (especially Groth16) is extremely efficient on-chain -- a single elliptic curve pairing operation. HE operations are far more expensive and would quickly exceed block gas limits. The entire WIP architecture depends on on-chain verifiability, which HE cannot provide at scale.

4. Composability. WIP needs to prove multiple statements simultaneously -- identity membership, weight validity, commitment consistency. ZK circuits can be composed: the identity proof and the weight proof can be combined into a single circuit that proves everything at once. HE does not provide this composability -- each operation is independent, and combining guarantees requires additional protocol design.

The decision was not close. Homomorphic encryption is the right tool for certain private computation problems (secure multi-party computation, private machine learning), but it is the wrong tool for a voting system that requires on-chain verifiability, global scale, and zero trusted third parties.

*"Every person has the right to protection of their personal data. Collection and use of personal information shall be transparent, limited to legitimate purposes, and subject to meaningful consent."* -- Article 54, Universal Charter

Zero-knowledge proofs are the mathematical realization of this right. They allow the system to verify everything it needs to verify -- identity, eligibility, weight validity -- while collecting no personal information whatsoever. The voter's data stays on their device. The blockchain sees only proofs: mathematical objects that reveal nothing except truth.

Imagine you have built a voting system with perfect cryptography. Every vote is committed via a hash, revealed simultaneously, proven valid by zero-knowledge proofs, and cast by a verified-unique human. Is the voter's privacy guaranteed?

No. It is not.

The reason is metadata. Even when the content of a vote is encrypted and the identity of a voter is hidden behind a ZK proof, the *act of submitting a transaction* produces observable information: the IP address from which it was submitted, the time of submission, the order in which transactions appear in a block, the gas fee paid, and even the size of the transaction. A sophisticated adversary -- a government agency, a well-resourced corporation, or a determined activist group -- can use this metadata to correlate voters with their votes through traffic analysis, even without breaking any cryptographic primitive.

The mixnet is WIP's answer to the metadata problem. It is a network of servers that cryptographically shuffle votes before they are tallied, severing the last possible link between a voter's identity and their cast ballot.

To understand why the mixnet is necessary, consider three specific attack vectors that it defends against:

1. Traffic analysis. An adversary who monitors network traffic can observe when a voter submits their reveal transaction. If the adversary also knows when the voter submitted their commitment (by monitoring the commit phase), they can correlate the two transactions. If the adversary can additionally observe the voter's behavior (e.g., through surveillance of their device or network), they can link the commitment/reveal pair to a specific individual. The mixnet breaks this correlation by routing all reveal transactions through multiple intermediate nodes that strip metadata and reorder the outputs.

2. Ordering attacks. On a blockchain, transactions within a block are ordered. A validator (or an adversary who controls a validator) can observe the order in which reveal transactions arrive and potentially correlate them with commit transactions. Even in a system where commits and reveals are separate transactions, the ordering within each block can leak information. If Alice's reveal is always in the same relative position as her commitment (e.g., both are the 47th transaction in their respective blocks), an adversary can link them. The mixnet randomizes the order of reveals independently of the order of commitments.

3. Volume analysis. In a close election, an adversary might monitor the volume of reveal transactions over time. If reveals for a particular option arrive in bursts, and the adversary can correlate those bursts with activity from a specific geographic region or demographic group, they can infer how that group voted without identifying individual voters. The mixnet temporally decorrelates reveals from their submission times.

These are not hypothetical attacks. Traffic analysis has been used by intelligence agencies to de-anonymize Tor users. Ordering attacks have been demonstrated against various blockchain privacy systems. Volume analysis is a standard technique in network surveillance. WIP's threat model assumes a powerful adversary with the ability to monitor network traffic, control blockchain validators, and observe voter behavior -- because in a global democratic system, such adversaries exist.

At its core, a mixnet performs a cryptographic shuffle: it takes a set of inputs, randomizes their order, and produces a set of outputs that are provably the same items in a provably random order. The shuffle must be:

• Uniformly random. Every possible permutation of the inputs must be equally likely. A biased shuffle could cluster certain votes together, enabling statistical analysis.

• Verifiable. It must be possible to prove that the outputs are a permutation of the inputs (no votes were added, removed, or modified) without revealing the permutation itself.

• Unlinkable. Given the inputs and outputs, it must be computationally infeasible to determine which input corresponds to which output.

The shuffling algorithm used in WIP's development implementation is the Fisher-Yates shuffle (also known as the Knuth shuffle), seeded with cryptographically secure randomness.

The Fisher-Yates algorithm works by iterating through the array from the last element to the first, swapping each element with a randomly chosen element from the remaining unprocessed portion. The elegance of Fisher-Yates is that it is provably uniform: if the random number generator produces truly random values, every permutation of the array is equally likely. This is a stronger guarantee than most people realize -- many "obvious" shuffling algorithms (such as sorting with a random comparator) produce biased distributions that a statistical test can detect.

Why is Fisher-Yates sufficient for development? In the development and testing phase, WIP uses a single-server mixnet with Fisher-Yates seeded by the Node.js crypto.randomBytes() function, which draws from the operating system's cryptographic random number generator (/dev/urandom on Linux, CryptGenRandom on Windows). This provides sufficient randomness for testing and small-scale deployments.

What changes for production? In production, the single-server shuffle is replaced by a multi-party mixing protocol (described in the next section) where the randomness is distributed across multiple independent nodes. The Fisher-Yates algorithm remains the core shuffle at each node, but the security guarantee changes from "trust the single server" to "trust that at least one node is honest" -- a much stronger assumption.

The production mixnet uses a cascade architecture: votes pass through a sequence of independent mixing nodes, each operated by a different party. Each node performs its own shuffle and re-encryption of the votes. The output of one node becomes the input of the next.

Here is how it works:

1. Input. The set of all valid reveal transactions (vote + weight, with commitment verified) is collected after the reveal window closes.

1. First mix node. The first node receives the set of votes, strips all metadata (IP addresses, timestamps, transaction IDs), shuffles the votes using Fisher-Yates with its own cryptographic randomness, and re-encrypts each vote under the next node's public key. The re-encryption ensures that even if the first node's randomness is compromised, the votes cannot be linked across nodes by comparing ciphertexts.

1. Subsequent mix nodes. Each subsequent node receives the shuffled, re-encrypted set from the previous node, decrypts with its private key, shuffles again with its own randomness, and re-encrypts under the next node's key. This process repeats for all nodes in the cascade.

1. Final output. The last node in the cascade outputs the final shuffled set of votes in plaintext (since the votes themselves are valid reveal data, not encrypted content). This final set is used for tallying.

The trust model. The cascade architecture provides a critical security property: the mixing is secure as long as at least one node in the cascade is honest. Even if all other nodes are compromised -- controlled by the same adversary, colluding, or running malicious code -- a single honest node that properly shuffles and destroys its intermediate state makes the overall permutation unlinkable.

This is a much stronger guarantee than a single-server model, which requires trusting the single server completely. In WIP's production deployment, the mix nodes are operated by diverse, independent organizations: civil society groups, academic institutions, and independent technical organizations from different jurisdictions. The incentive structure of the cascade means that an adversary must compromise *all* nodes to break voter privacy -- and the nodes are deliberately chosen to be politically, geographically, and institutionally diverse to make total compromise as difficult as possible.

What happens if one node is compromised? If one node in a cascade of N nodes is compromised, the adversary learns the permutation applied by that node. But they do not know the permutations applied by the other N-1 nodes. The composition of an unknown permutation with a known permutation is still an unknown permutation. Therefore, the adversary gains no ability to link inputs to outputs of the overall cascade. This is the fundamental reason cascades work: they convert a trust requirement of "trust everyone" into a trust requirement of "trust at least one."

What if a node modifies votes? Each mix node produces a zero-knowledge proof of correct shuffle -- a proof that the output is a permutation of the input, with no votes added, removed, or modified. This proof is verified before the output is passed to the next node. A malicious node that attempts to alter votes will produce an invalid proof and be detected and replaced. The ZK shuffle proof is computationally expensive (it is one of the most demanding ZK circuits in the system), but it is performed only once per election per node, not once per vote.

How many nodes? The cascade length is configurable per election. For local proposals with lower security requirements, three nodes may suffice. For global proposals with high stakes, five to seven nodes provide an extremely high security margin. The tradeoff is latency: more nodes means more time to complete the mixing. For a global election with millions of votes and five mix nodes, the mixing process is expected to take 30-60 minutes -- a small price for mathematical privacy.

The mixnet is the final layer of WIP's privacy architecture. It operates in concert with the other layers:

• The identity layer ensures you are human without revealing who you are.
• The commit-reveal protocol ensures you committed before seeing others' votes.
• The zero-knowledge proofs ensure your vote is valid without revealing its contents.
• The mixnet ensures that even the metadata of vote submission cannot be used to link you to your ballot.

Each layer addresses a different attack vector. The identity layer prevents sybil attacks. The commit-reveal protocol prevents strategic voting. The ZK proofs prevent identity leakage. The mixnet prevents traffic analysis. Together, they provide end-to-end verifiable, universally private voting -- a property that no existing voting system, paper or electronic, achieves.

*"No person shall be subjected to arbitrary or unlawful surveillance. Monitoring of communications or activities must be authorized by law, necessary, proportionate, and subject to independent oversight. The right to private communication shall be protected."* -- Article 55, Universal Charter

The mixnet is the engineering expression of this right. It ensures that even in a fully digital, fully transparent, fully verifiable voting system, the act of voting remains what democracy requires it to be: a private expression of individual judgment, free from observation, pressure, or consequence.

Democracy has a well-documented failure mode: uninformed populism. When complex questions are put to a vote without structured exposure to the relevant arguments, the result reflects not the collective intelligence of the population but its collective impulse. The World Intelligence Protocol addresses this through a deliberation system that is neither optional window-dressing nor a gatekeeping mechanism, but a structural prerequisite for meaningful participation.

The goal is not to create better voters. It is to create better-informed votes.

The case for deliberation before voting rests on decades of research in democratic theory and practical experimentation. Citizens' assemblies -- from Ireland's Constitutional Convention to the French Convention Citoyenne pour le Climat -- have demonstrated that ordinary citizens, when given structured access to expert testimony and opposing viewpoints, make decisions that are more nuanced, more broadly supported, and more durable than those produced by conventional referendums or legislative bodies.

The key insight from this research is not that citizens are incapable of making good decisions, but that the information environment in which decisions are made fundamentally shapes their quality. A voter who has been exposed to only one side of an argument is not exercising democratic choice -- they are confirming a bias. A voter who has encountered the strongest version of the opposing position and still chooses their original stance is exercising genuine judgment.

The alternative -- uninformed populism -- is not a hypothetical risk. The Brexit referendum, the California ballot initiative system, and numerous national referendums have demonstrated what happens when complex policy questions meet an underprepared electorate. The issue is not that voters are stupid; it is that the system does not give them what they need to make decisions they would endorse upon reflection.

WIP's deliberation system addresses this by requiring a structured exposure period before every vote. This is not a lecture or an exam -- it is a curated collection of the strongest arguments from both sides, surfaced by the community itself.

The deliberation system works as follows. During the deliberation period (which precedes the voting window), any verified human can submit a perspective on the proposal -- an argument of up to 500 words or 3 minutes of audio or video, taking either a FOR or AGAINST stance. Each verified human receives 3 upvotes to allocate across perspectives for each proposal. Self-upvoting is prohibited. After the deliberation period closes, the top 5-10 perspectives by upvote count are compiled into a deliberation package that all voters engage with before casting their vote.

This is a community-curated system, not an editorially curated one. No committee selects which arguments voters see. No algorithm optimizes for engagement. The community itself decides which perspectives are most worth hearing, through a simple, transparent upvoting mechanism with hard limits that prevent any single person from dominating the selection.

But upvote-based ranking has a well-known failure mode: majority amplification. If 70% of participants support a proposal, the top perspectives by upvote count will disproportionately be FOR perspectives. This creates a feedback loop where voters only see majority arguments, making the deliberation package a confirmation machine rather than an exposure tool.

WIP addresses this with an automatic balance check. When the deliberation package is assembled, the system checks whether it includes at least one FOR and one AGAINST perspective. If all top perspectives lean the same direction, the highest-upvoted perspective from the underrepresented side is automatically included, replacing the lowest-ranked perspective in the package. If no opposing perspective was submitted at all, a notice is displayed to voters explaining the gap.

This intervention is minimal by design. It affects at most one slot in the package. The remaining perspectives are ranked purely by upvotes. The algorithm is deterministic, transparent, and auditable -- voters can see exactly why an opposing perspective was included. The alternative approaches that were considered and rejected include: allocating exactly 50% of slots to each side (rejected because it forces artificial balance even when one side has genuinely stronger arguments), weighted ranking formulas (rejected because they are opaque and difficult for voters to understand), and editorial curation by human moderators (rejected because it introduces subjective judgment and does not scale).

After engaging with the deliberation package, voters who wish to earn a comprehension bonus are presented with a single prompt: "What is the main concern of people who disagree with your position?"

This question tests one thing and one thing only: whether the voter can articulate the opposing viewpoint. It does not test whether they agree with it. It does not test whether they can refute it. It does not test spelling, grammar, rhetorical skill, or intellectual sophistication. It tests relevance -- is the voter's response topically related to the arguments they were shown?

The voter can respond in any language, via text or voice. Voice responses are transcribed using OpenAI's Whisper model. The response is then scored on a three-level scale:

• Level 0 (CW = 0.000): The response is irrelevant, off-topic, or empty. The voter either did not engage or submitted noise.
• Level 1 (CW = 0.125): The response is topically related to at least one opposing argument. The voter demonstrated basic awareness.
• Level 2 (CW = 0.250): The response is closely related to the opposing arguments. The voter demonstrated substantive engagement.

Critically, the comprehension check is entirely optional. A voter who skips it receives their full base vote of 1.0. The maximum comprehension bonus is 0.25, which combines with the base vote through the formula V = B x (1 + CW + PX). The comprehension check can never reduce a vote below 1.0, and it can never increase it beyond the 1.5 maximum. This is a constitutional constraint enforced at the smart contract level.

Scoring at scale -- potentially hundreds of thousands of responses per proposal, in over 100 languages -- requires automation. The AI scoring service uses the multilingual-e5-large model, a sentence transformer that produces 1024-dimensional embedding vectors for text in over 100 languages. The scoring pipeline works as follows:

1. The voter's response is embedded into a vector representation.
2. Each opposing argument from the deliberation package is embedded into a vector.
3. The cosine similarity between the response vector and each argument vector is computed.
4. The maximum similarity score is taken (because the voter only needs to engage with one argument).
5. The similarity score is mapped to a comprehension level using configurable thresholds: below 0.30 maps to Level 0, 0.30 to 0.60 maps to Level 1, above 0.60 maps to Level 2.

Semantic similarity was chosen over other approaches because it measures topical relatedness without judging quality. A response in Swahili that references the same concepts as one in English will produce comparable embeddings. A response with grammatical errors but correct topical content will score the same as a polished essay on the same topic.

To guard against model errors and drift, 5% of all scored responses are randomly sampled for human audit. These audit samples contain only the response text, the opposing arguments, and the computed score -- no voter identity information is included. If systematic bias is detected (for example, if responses in a particular language consistently score lower than human reviewers would rate them), the model is recalibrated. Voters who believe their score was unfair can request a one-time human review through an appeals process.

The AI scoring service operates within strict trust boundaries. It never receives voter identity information. Response text is discarded immediately after scoring (except for the 5% audit sample, which is stored without identity linkage). The service runs in an isolated container with no access to the database, blockchain, or vote data. It is advisory, never authoritative -- the base vote of 1.0 is mathematically inviolable regardless of what the AI produces.

This is perhaps the most important philosophical decision in the entire deliberation system, and it deserves a thorough defense.

The temptation to score response *quality* is strong. It seems intuitive that a voter who writes a nuanced, detailed analysis of the opposing position has demonstrated deeper engagement than one who writes a single relevant sentence. And that is probably true. But scoring quality introduces problems that are, in our assessment, fatal to the system's legitimacy.

First, quality judgment is inherently subjective. What counts as a "good" engagement with an opposing argument depends on cultural norms, educational conventions, and rhetorical traditions that vary enormously across the world's populations. A direct, assertion-based communication style common in some cultures might be scored lower than the discursive, qualification-heavy style common in others -- not because it reflects less understanding, but because the scoring model was trained on data that privileges one style over the other.

Second, quality scoring is discriminatory by construction. It systematically advantages voters with higher formal education, greater fluency in the dominant language of the training data, and more practice with the kind of analytical writing that AI models are trained to recognize as "high quality." A subsistence farmer who understands perfectly well why industrial agriculture proponents disagree with their position, but expresses that understanding in a single colloquial sentence, would score lower than a university graduate who produces a polished paragraph saying essentially the same thing.

Third, quality scoring falls victim to Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. If voters know that response quality affects their vote weight, they will optimize for the scoring model. They will learn to write responses that sound analytical rather than responses that reflect genuine engagement. The comprehension check would become a performance, not a reflection -- defeating its entire purpose.

Fourth, and most fundamentally, using an AI model to judge the quality of human reasoning on political topics is ethically fraught. Language models have biases. They have political leanings embedded in their training data. They perform differently across languages, dialects, and registers. Giving such a model the power to judge whether a human's engagement with a political argument is "good enough" is a power we do not believe any AI system should wield.

By contrast, semantic relevance is narrow, mechanical, and auditable. It asks only: did the voter mention the topic? This is the kind of question an embedding model can answer reliably across languages, education levels, and cultural contexts. It does not judge. It does not rank. It simply checks for topical presence. The difference between understanding and agreement is preserved: a voter can demonstrate perfect relevance by accurately describing the opposing position and then rejecting it entirely. The system rewards exposure, not capitulation.

Not all decisions are created equal. A neighborhood's decision about a community garden has a fundamentally different character from a continental decision about carbon emissions policy. These decisions differ not just in scale but in kind -- in the number of people affected, the complexity of trade-offs involved, the reversibility of consequences, and the time required for thoughtful deliberation. A voting system that treats all decisions identically is a voting system that has not thought carefully about what it means to govern.

The World Intelligence Protocol organizes decision-making into five governance tiers, each with distinct thresholds, deliberation periods, and approval requirements calibrated to the scope and gravity of the decision at hand.

Subsidiarity is the principle that decisions should be made at the lowest level of governance competent to address them. We encode this not as a recommendation but as a structural constraint.

The five tiers are Local, Regional, National, Continental, and Global. Each tier defines a geographic scope that determines who is eligible to vote, how many cosigners are needed to advance a proposal, and how long the deliberation period lasts.

The choice of five tiers was itself a design decision that required justification. Three tiers (local, national, global) were considered but rejected because they create too-large jumps in scale. The gap between a city-level decision and a national one is enormous, and regional governance -- the level of states, provinces, or administrative regions -- is where much of the world's practical policy-making occurs. Skipping it would leave a governance vacuum. Seven tiers were considered (adding sub-local and sub-continental levels) but rejected because the additional granularity adds complexity without meaningful benefit. Most real-world governance maps cleanly onto five levels, and additional tiers would create classification ambiguity.

Tier classification follows the subsidiarity principle: issues default to the most local applicable tier. A proposal about water quality in a specific river basin starts as a Regional issue, not a National one. If the decision has verified externalities -- if downstream populations in another region are affected -- affected parties can petition for reclassification to a higher tier. This requires 1,000 signatures from the affected tier, ensuring that escalation reflects genuine concern rather than political maneuvering.

Tier classification is proposed by the submitter, verified by AI analysis (which examines the proposal text for geographic scope indicators), and challengeable by any verified human. The AI classification is advisory, not authoritative -- it provides a recommendation that the community can override through the challenge process.

The Global tier is reserved for issues with no geographic boundary: artificial intelligence governance, space policy, ocean stewardship, pandemic preparedness. These are questions that affect humanity as a whole and cannot be meaningfully localized.

Before a proposal enters the deliberation phase, it must collect a minimum number of cosignatures from verified humans. This is the first filter against frivolous, spam, or poorly conceived proposals.

The thresholds increase with tier scope:

• Local: 5 cosigners
• Regional: 10 cosigners
• National: 25 cosigners
• Continental: 50 cosigners
• Global: 100 cosigners

These numbers were chosen to balance two competing concerns. Too low, and the system is flooded with proposals that waste collective attention -- a scarce resource in any democracy. Too high, and the system becomes exclusionary, favoring well-connected proposers who can mobilize networks.

The thresholds represent a meaningful commitment of social capital. Cosigning a proposal is not a low-cost action -- it attaches your verified identity (albeit anonymized through the Humanity Key system) to a statement that this proposal deserves collective deliberation. It is, in economic terms, skin in the game: cosigners are investing their limited cosigning capacity in proposals they believe are worth the community's time.

Three alternative approaches were considered and rejected. Flat thresholds (the same number for all tiers) were rejected because a global proposal affecting billions should require broader initial support than a local issue. Exponentially increasing thresholds (e.g., 10/100/1000/10000/100000) were rejected because they make higher-tier proposals effectively impossible to pass -- the Global tier would require more cosigners than most advocacy organizations have members. Dynamic thresholds that adjust based on participation rates were rejected because they create a moving target that confuses proposers and is gameable (artificially suppressing participation to lower the threshold).

Some decisions, regardless of their geographic tier, carry concentrated or irreversible impact on specific populations. A regional water diversion project might devastate a downstream community. A national energy policy might eliminate an entire industry in a specific region. These decisions demand additional scrutiny.

The Significant Impact flag can be triggered in two ways. Any verified human can flag a proposal as having significant concentrated impact on a specific population. Alternatively, an AI impact analysis can identify proposals with asymmetric consequences. When a flag is raised, it is validated through a meta-vote: a simple majority of 1,000 randomly selected verified humans determines whether the flag is legitimate.

If validated, four consequences follow:

1. The deliberation period doubles, giving affected populations more time to organize their perspectives.
2. Perspectives from the affected population are auto-elevated in the deliberation package.
3. A formal "impact statement" is solicited from the affected community.
4. The voting threshold increases from simple majority (>50%) to a supermajority: 60% for local through national tiers, and 66% for continental and global tiers.

The 60% threshold (rather than 50%) was chosen because simple majority rule has a well-known weakness: it allows a bare majority to impose concentrated costs on a minority. The classic example is two wolves and a sheep voting on what to eat for dinner. The 60% threshold ensures that proposals with significant impact require not just majority support but broad consensus -- the kind of support that suggests the proposal has addressed the concerns of affected populations, not merely outvoted them.

Critically, the trigger is impact, not identity. The system does not classify groups as "minorities" or "privileged." It does not maintain a registry of protected categories. It evaluates proposals, not people. A proposal that concentrates impact on wealthy industrial firms receives the same scrutiny as one that concentrates impact on subsistence communities. This avoids the political toxicity of identity-based classification systems while achieving the protective function they are intended to serve.

Real-world governance rarely involves isolated decisions. A transportation policy is connected to environmental policy, which is connected to energy policy, which is connected to economic development. The World Intelligence Protocol supports linked proposals -- formal relationships between proposals that signal alternatives or dependencies.

Two types of links are supported:

• Alternatives: Proposals that address the same issue with different approaches. If Proposal A proposes wind energy investment and Proposal B proposes solar energy investment for the same region, they can be linked as alternatives. Voters see both proposals and their relationship.
• Dependencies: Proposals where one depends on the outcome of another. If Proposal C (building a new hospital) depends on Proposal D (allocating healthcare funding), they can be linked as dependencies.

Linked proposals matter because they prevent a subtle but corrosive failure mode: contradictory decisions. Without linking, a community could simultaneously vote to reduce taxes and increase public services, to build new roads and protect rural land, to expand industry and reduce emissions. Each decision might win majority support in isolation while being collectively incoherent. Linked proposals force voters to confront trade-offs explicitly.

Any verified human can propose a link between proposals. Links can be challenged and removed through the same governance process. The linked proposals page shows all related proposals with their current status, enabling voters to make decisions in context rather than in isolation.

The deliberation period -- the window during which perspectives can be submitted and upvoted before voting opens -- varies by tier:

• Local: 3 days
• Regional: 5 days
• National: 7 days
• Continental: 10 days
• Global: 14 days

These durations reflect a fundamental truth about democratic deliberation: time is not a luxury; it is a prerequisite. Rushing a decision does not make it faster -- it makes it worse. The history of legislative disasters is littered with bills passed under artificial time pressure, where inadequate deliberation produced unintended consequences that took years to repair.

The durations increase with tier scope for three reasons. First, higher-tier decisions involve more diverse populations spread across more time zones, and equitable participation requires that people in different geographies have adequate time to learn about, discuss, and respond to proposals. Second, higher-tier decisions tend to involve greater complexity and more numerous trade-offs, requiring more time for the community to surface and debate the relevant considerations. Third, higher-tier decisions have broader and more durable consequences, justifying a longer period of reflection before irreversible commitments are made.

These durations are for the standard deliberation period. If a proposal is flagged for Significant Impact, the deliberation period doubles (e.g., a National proposal goes from 7 to 14 days). Fast-track voting (48 hours) is available only through a specific governance approval process and is intended for genuinely urgent matters, not for convenience.

The cost of rushing is not abstract. In WIP's framework, the deliberation period is when the comprehension check material is generated. If the period is too short, fewer perspectives are submitted, the deliberation package is thinner, and the comprehension check has less material to work with. The system's integrity depends on giving the community enough time to do its work.

A voting system is only as trustworthy as its verifiability. If voters must simply trust that their vote was counted correctly, then the system is no different from a black box -- and the history of black-box voting is a history of suspicion, conspiracy, and legitimate grievance. The World Intelligence Protocol uses Merkle trees to solve this problem: giving every voter a mathematical proof that their vote was included in the final tally, while allowing anyone to verify that the tally itself is correct, without compromising the privacy of any individual voter.

Trust, but verify. Or better yet: design the system so that trust is unnecessary because verification is trivial.

A Merkle tree is a data structure that allows efficient and secure verification of large data sets. To understand it, imagine building a pyramid from the bottom up.

At the bottom layer, you have all the individual pieces of data -- in WIP's case, all the votes cast on a particular proposal. Each vote is run through a cryptographic hash function (a mathematical blender that produces a fixed-size fingerprint from any input). These hashes form the leaves of the tree.

At the next layer up, you take pairs of adjacent leaf hashes and hash them together, producing a new hash that represents both of its children. You continue this process -- pairing and hashing, pairing and hashing -- until you reach a single hash at the very top. This is the Merkle root: a single, compact fingerprint that uniquely represents the entire data set below it.

The Merkle root has a remarkable property: if any single piece of data at the bottom of the tree changes -- even by one bit -- the change cascades upward through every layer, producing a completely different root. The root is, in effect, a tamper-evident seal on the entire data set. You cannot change a vote without changing the root, and you cannot produce the same root from a different set of votes.

WIP uses Merkle trees in three places:

• Identity registry: All Humanity Key hashes are leaves in a Merkle tree. The root is stored on-chain and serves as a public input for ZK identity proofs.
• Vote tally: All mixed votes (after mixnet shuffling) are leaves in a Merkle tree. The root is published on-chain as the tamper-evident seal on the election result.
• Proposal registry: All proposal hashes are leaves in a Merkle tree, ensuring the integrity of the proposal record.

After voting concludes -- after the commit phase, the reveal phase, and the mixnet shuffling -- the tally service builds a Merkle tree from all the mixed votes. The Merkle root is submitted to the vote-tally smart contract on the Cosmos appchain, where it is stored on-chain permanently.

Now comes the critical capability: individual vote verification. Any voter can request a Merkle inclusion proof for their vote. This proof is a small set of hashes -- specifically, the sibling hashes along the path from their vote's leaf to the root. With this proof, the voter can perform a simple computation:

1. Start with the hash of their own vote.
2. At each level of the tree, combine their hash with the sibling hash provided in the proof.
3. If the computation reaches the Merkle root stored on-chain, the vote is proven to be included in the tally.

This verification requires no special software, no trust in any server, and no access to any other voter's data. The voter only sees their own vote and the sibling hashes along their path -- which reveal nothing about other votes. The on-chain Merkle root is public and immutable. The verification is a pure mathematical computation that anyone can perform.

The proof is compact: for a tree with 100,000 votes, the Merkle proof is approximately 1KB -- a chain of about 17 hashes (log2 of 100,000). This is small enough to transmit over a 2G connection and verify on a low-end smartphone in under a second.

This design means that a voter does not need to trust WIP's servers, infrastructure, or operators. They do not need to trust the blockchain validators. They need only trust the mathematics of cryptographic hash functions -- the same mathematics that secures every bank transaction, every HTTPS connection, and every digital signature on the internet.

Individual verification is powerful, but it answers only one question: "Was my vote included?" A broader question matters just as much: "Is the tally correct?"

WIP answers this through public auditability. After the tally is published, anyone -- not just voters, but independent auditors, journalists, civil society organizations, academic researchers -- can:

1. Download the complete set of mixed votes from the tally service. These are the post-mixnet votes: {vote_value, weight} tuples with no link to voter identity.
2. Recompute the Merkle root from the downloaded vote set using the same tree construction algorithm.
3. Compare their computed root to the root stored on-chain.

If the roots match, the published tally is mathematically proven to be correct -- the tally was computed from exactly the set of votes represented by the on-chain root, with no additions, deletions, or modifications. If the roots do not match, the discrepancy is proof of tampering, and anyone can demonstrate this publicly by publishing both roots.

The on-chain Merkle root is the anchor. It is stored on a blockchain with CometBFT consensus, which provides deterministic finality in approximately 6 seconds. Once the root is on-chain, it cannot be altered without corrupting the blockchain itself -- an attack that requires compromising more than one-third of the validator set. The root is not stored on a server controlled by WIP. It is stored on a decentralized ledger that WIP's operators cannot unilaterally modify.

This architecture creates a system where the correctness of the tally is not a matter of trust but a matter of mathematics. The phrase "trust us" is replaced with "verify us." Anyone who doubts the result can check it themselves. Anyone who wants to prove fraud can demonstrate it mathematically. And anyone who wants to confirm that the system is working can do so without asking anyone's permission.

The Merkle tree is not the only integrity mechanism in WIP -- it works alongside the commit-reveal protocol, the mixnet shuffling, and the ZK proofs -- but it is the mechanism that makes the entire system auditable. Without it, verification would require either trusting the operators or accessing private data. With it, verification is a public, permissionless, mathematical operation. This is the standard that democratic infrastructure demands.

The World Intelligence Protocol is built on a dedicated blockchain -- not deployed as a smart contract on someone else's chain, but operated as a sovereign appchain with its own validator set, its own consensus rules, and its own governance parameters. This is not a technical convenience; it is a philosophical commitment. A voting system that depends on another platform's governance, fee market, or upgrade schedule is a voting system that has outsourced its sovereignty. For infrastructure that aspires to serve global democratic deliberation, this dependency is unacceptable.

Three blockchain platforms were seriously evaluated for WIP: Cosmos SDK (custom appchain), Ethereum L2 (Optimism/Arbitrum or a custom OP Stack rollup), and Solana (Anchor framework programs). Each was assessed against five non-negotiable requirements: sovereign control, fast finality, zero-fee voting, deterministic smart contract execution, and future interoperability.

Ethereum L2 was rejected for several reasons. Optimistic rollups have a 7-day challenge window for finality -- voters cannot wait a week to know their vote was recorded. Even ZK rollups add minutes to hours of delay for proof generation and batching. The fee structure on any L2 is partially influenced by L1 gas prices, making it impossible to guarantee zero-fee voting. Most fundamentally, deploying on an L2 means WIP's governance would be subject to the L2 framework's upgrade schedule and the L1's governance decisions. WIP would be a tenant, not a sovereign.

Additionally, Solidity -- Ethereum's dominant smart contract language -- lacks the type safety guarantees of Rust. Memory safety bugs and reentrancy vulnerabilities remain persistent concerns in the Solidity ecosystem. For contracts that handle cryptographic vote data and enforce constitutional weight bounds, the Rust type system's compile-time guarantees are not a nice-to-have; they are a security requirement.

Solana was rejected primarily for runtime instability. Solana has experienced multiple network outages, some lasting hours. For a voting platform, downtime during a commit or reveal phase would be catastrophic -- votes could be lost, deadlines could pass, and the integrity of the entire process would be compromised. Solana's account-based programming model also adds friction for the contract patterns WIP requires (iterating over vote commitments, managing proposal state machines). Finally, Solana lacks a standardized cross-chain communication protocol comparable to IBC.

Cosmos SDK satisfied all five requirements:

• Sovereignty: A Cosmos appchain has full control over block structure, gas policy, transaction ordering, and upgrade schedule. There is no dependency on a shared chain's congestion, governance, or fee market. WIP sets its own rules.
• CometBFT finality: Cosmos uses CometBFT (formerly Tendermint) consensus, which provides deterministic finality in approximately 6 seconds. When a voter submits a vote commitment, they know within seconds that it is permanently recorded. There is no probabilistic finality, no challenge window, no waiting.
• IBC interoperability: The Inter-Blockchain Communication protocol enables future cross-chain identity verification and multi-chain governance without bridges or wrapped tokens. IBC is available but not activated in v2.1 -- it adds no overhead when unused and is ready when needed.
• CosmWasm: Rust-based smart contracts with deterministic execution, memory safety, and the full power of the Rust type system.
• Zero-fee voting: Full control over the fee market means WIP can subsidize vote commits from the protocol treasury, removing the economic barrier to participation.

The WIP appchain runs with 21 initial validators, a 5-second block time, and a 4MB maximum block size. CometBFT's BFT consensus requires 2/3+1 honest validators, meaning the chain tolerates up to 6 malicious validators out of 21 without compromising safety. This validator set is curated initially and will be progressively decentralized as the platform matures.

WIP's on-chain logic is implemented in four CosmWasm smart contracts written in Rust:

• humanity-key-registry: Identity registration, social vouching, key lifecycle management, and Merkle root updates for the identity tree.
• vote-commitment: The commit-reveal vote lifecycle (four phases: Commit, Reveal, Mixing, Complete), ZK weight proof verification, and double-vote prevention.
• vote-tally: Accepts mixed votes from the mixnet, computes weighted tallies, and publishes the Merkle root on-chain.
• proposal-registry: Proposal creation, cosigning, lifecycle transitions (Draft through Complete), tier management, and significant impact flagging.

Rust was chosen for smart contracts because of three properties that are critical for voting infrastructure.

First, memory safety. Rust's ownership model eliminates entire classes of bugs -- buffer overflows, use-after-free, data races -- at compile time. In a system where a single vulnerability could compromise vote integrity for millions of people, compile-time safety guarantees are not optional.

Second, WebAssembly compilation. CosmWasm contracts compile to WASM, which provides deterministic execution: the same contract with the same inputs produces the same outputs on every validator, every time. This is essential for consensus -- if different validators computed different results from the same transaction, the chain would fork.

Third, gas metering. WASM execution is gas-metered, preventing infinite loops and resource exhaustion attacks. Every operation has a deterministic cost, and transactions that exceed their gas budget are reverted cleanly.

All smart contracts require 100% branch coverage in tests before deployment. This is not a guideline; it is a gate. The voting formula's constitutional constraints -- minimum weight 1.0, maximum weight 1.5 -- are enforced at the contract level with explicit range checks. The weight is validated against the range [1000, 1500] in fixed-point integer arithmetic, and the ZK WeightRangeProof circuit enforces the same constraint cryptographically.

A blockchain is a powerful tool for integrity, but it is a terrible tool for privacy. Everything stored on-chain is public, permanent, and immutable. This creates a fundamental tension for a voting system that must be simultaneously auditable and private.

WIP resolves this tension by being precise about what goes on-chain and what stays off-chain.

On-chain (public, permanent, verifiable by anyone):

• Vote commitments: The SHA-256 hash of each vote. This reveals nothing about the vote content (the hash is hiding) but proves the vote was locked at a specific time.
• ZK weight proofs: Mathematical proofs that each vote weight is in the valid range [1000, 1500] without revealing the exact weight.
• Merkle roots: The tamper-evident seals on the identity registry and the vote tally. These enable anyone to verify inclusion and integrity.
• Tally results: The final weighted count of yes/no/abstain votes. This is public information -- the whole point of voting is to produce a result.
• Proposal metadata: Titles, descriptions, tier classifications, cosigner counts, lifecycle status. These are public by nature.

Off-chain (private, ephemeral, or access-controlled):

• Deliberation content: Perspectives are stored on IPFS, which is content-addressed and decentralized but not on the blockchain. The blockchain stores only the IPFS content identifier (CID), not the content itself.
• AI comprehension scores: The scoring pipeline runs off-chain. Only the resulting comprehension level (0, 1, or 2) affects the on-chain vote weight.
• Response text: Voter responses to the comprehension check are discarded immediately after scoring. They never touch the blockchain.
• User profile data: Names, email addresses, device information -- none of this belongs on-chain.
• Raw biometric data: Never stored anywhere outside the device's Trusted Execution Environment. Only a one-way hash is transmitted, and even that hash is not stored on-chain in raw form -- it is committed through the Humanity Key registry with ZK proof verification.

The principle is simple: on-chain for integrity, off-chain for everything else. The blockchain is a notary, not a database. It certifies that commitments were made, that proofs were valid, that roots were published, and that tallies were recorded. It does not store the underlying data, the deliberation content, the AI analysis, or any user information. This division is not an implementation detail; it is a privacy architecture. On-chain data is the minimum set of cryptographic commitments required for public verifiability. Everything else is kept where it belongs: in systems that can enforce access control, data retention policies, and privacy regulations.

A global voting platform is, by definition, a high-value target. It concentrates political power in a digital system, making it attractive to every adversary from nation-state intelligence agencies to partisan hacktivists to criminal organizations seeking to monetize influence. The security model for the World Intelligence Protocol is not designed for a benign world. It is designed for a world where sophisticated, well-resourced, and persistent adversaries will attempt to compromise the system -- and where the consequences of failure include undermining democratic legitimacy itself.

Security is non-negotiable. Performance is optimizable. Features are deferrable.

The system's security architecture begins with an honest enumeration of adversaries and their capabilities.

Nation-state actors represent the most capable threat. They possess the resources to compromise hardware supply chains, infiltrate validator sets, operate sophisticated surveillance programs, and exert legal pressure on any entity within their jurisdiction. A nation-state that opposes a WIP vote outcome could attempt to deanonymize voters, manipulate tallies, or simply shut down infrastructure within its borders.

Insider threats are perhaps the most insidious. A developer with commit access, an operator with server credentials, or a validator with signing keys could attempt to manipulate the system from within. The security model must assume that any individual participant in the system might be compromised, coerced, or corrupt.

Mass surveillance threatens voter privacy. If a government or corporation can determine how individuals voted, voters in authoritarian contexts face retaliation, and voters everywhere face social pressure that distorts genuine preference expression. The secret ballot exists for a reason, and digital voting must preserve it.

Voter coercion is the flip side of surveillance. If a coercer can verify how a voter voted -- by demanding to see their screen, checking their vote receipt, or monitoring their network traffic -- the secret ballot is meaningless. The system must ensure that voters cannot prove how they voted, even if they want to.

Sybil attacks -- the creation of fake identities to cast multiple votes -- strike at the heart of "one person, one vote." At internet scale, creating fake accounts is trivial. A Sybil attacker could manufacture thousands of identities, each casting a vote, overwhelming legitimate participation.

Each threat in the model maps to specific defensive mechanisms.

Against deanonymization and surveillance, the system deploys zero-knowledge proofs. The HumanityProof ZK circuit allows a voter to prove "I am a registered, verified human" without revealing *which* human. The proof is verified against the on-chain Merkle root of the identity registry, but the specific leaf (the voter's Humanity Key hash) remains hidden. Even if an adversary observes the proof being submitted, they learn only that *some* registered human voted, not which one.

The mixnet provides a second layer of unlinkability. After the reveal phase, votes are encrypted in three layers (onion encryption) and processed through a cascade of three independent mix nodes. Each node decrypts one layer and shuffles the entire batch using a cryptographically secure Fisher-Yates shuffle. Even if two of the three nodes are compromised, the single remaining honest node ensures that the mapping between voters and votes is destroyed. The output is a shuffled array of {vote, weight} tuples with no link to any identity.

Against voter coercion, the commit-reveal protocol is the primary defense. During the commit phase, the voter submits only a SHA-256 hash of their vote -- not the vote itself. A coercer observing the commitment learns nothing about the vote content. During the reveal phase, all commitments are revealed simultaneously (within a 24-hour window) and immediately fed into the mixnet. The voter cannot produce a verifiable receipt of their vote to show a coercer, because by the time the vote is visible, it has been mixed with thousands of others and is unlinkable to any individual.

Against Sybil attacks, the system uses a multi-layered identity verification system. Biometric hashing in the device's Trusted Execution Environment (TEE) ensures that each physical human produces a unique identifier. The raw biometric data (face and voice) never leaves the TEE -- only a one-way SHA-256 hash is transmitted. Device attestation verifies that the TEE is genuine hardware, not a software emulator. Social vouching requires three already-verified humans to attest to each new user's existence, creating a web of trust that is expensive to fake at scale. Collision detection using Hamming distance checks between biometric hashes prevents duplicate registrations. Together, these mechanisms make it prohibitively costly to create fake identities: each one requires a unique physical human, a genuine hardware device, and three existing verified humans willing to vouch.

Against data breaches and server compromise, the system applies the principle of minimum data exposure. The API gateway never sees plaintext votes -- only commitment hashes. The AI scoring service never receives voter identity. Response text is discarded after scoring. Vote content exists in memory only during the brief tally computation, and is deleted afterward. All data at rest is encrypted with AES-256-GCM. All data in transit uses TLS 1.3 with certificate pinning on mobile. Log redaction strips authorization headers, biometric hashes, ZK proofs, nonces, votes, and commitment hashes from all logs. Even a complete database breach reveals no vote content and no linkage between voters and their votes.

Against smart contract exploitation, every contract undergoes testing with 100% branch coverage -- a requirement, not a guideline. The Rust type system eliminates memory safety vulnerabilities at compile time. CosmWasm's single-threaded execution model prevents reentrancy by design. The constitutional weight range [1000, 1500] is enforced at the contract level as an explicit bounds check, and separately by the ZK WeightRangeProof circuit -- defense in depth where a bug in one layer is caught by another.

The design decisions that were *rejected* reveal as much about the system's values as the ones that were adopted. Several features that appear in earlier versions of the protocol or in competing systems were intentionally excluded from v2.1 after careful analysis revealed unacceptable risks.

Goodwill Weight was a proposed mechanism to reward users who contributed positively to the community -- moderating content, helping new users, submitting well-received perspectives. The weight bonus would increase with accumulated "goodwill points." This was removed because it falls directly into Goodhart's Law: when a measure becomes a target, it ceases to be a good measure. The moment goodwill points affect vote weight, users will optimize for points rather than genuine contribution. Moderation becomes performative. Helping becomes transactional. The metric that was supposed to measure community spirit would instead measure skill at gaming the system. More fundamentally, any system that rewards past behavior with increased voting power creates a de facto aristocracy of early and active users -- precisely the power concentration that WIP exists to prevent.

Temporal Wisdom Score was a proposed mechanism to reward users whose past votes aligned with eventual outcomes -- a "track record" bonus. Users who consistently voted with the winning side (or whose predictions about consequences proved accurate) would receive increased weight. This was removed because the concept is self-reinforcing: accurate predictions increase your score, which increases your vote weight, which shapes outcomes toward your predictions. The score does not measure wisdom; it measures influence. It would create a feedback loop where early participants accumulate disproportionate power, and would punish principled minority positions that might be correct but unpopular.

Emergency Delegation was a proposed protocol allowing voters to temporarily delegate their voting power to a trusted representative during emergencies (natural disasters, communication blackouts). This was removed because of dictatorship risk: any mechanism that concentrates voting power in emergencies can be exploited to manufacture emergencies. History is replete with examples of leaders who declared emergencies to consolidate power. A system that allows emergency delegation provides the technical infrastructure for exactly this kind of abuse. The correct response to an emergency that prevents voters from participating is to extend the voting period, not to concentrate their power in fewer hands.

Community Nodes -- physical locations where citizens could vote in person, attend deliberation sessions, and receive identity verification -- were proposed as a way to serve populations without smartphones. This was deferred (not removed) because it requires physical infrastructure that does not yet exist and cannot be built in parallel with the digital system. Premature deployment of physical nodes would create geographic inequality (areas with nodes would have different access than those without), operational complexity (staffing, security, maintenance), and potential for coercion (voting in a public location undermines ballot secrecy). The digital-first system must be proven before physical extensions are added.

Civic Lottery was a proposed system where random groups of verified humans would be selected (like jury duty) to review and decide on specific proposals, rather than opening all proposals to all voters. This was removed because it creates a legitimacy crisis: random selection of decision-makers undermines the core principle that every human deserves a direct voice on issues that affect them. A voter who is excluded from a decision by lottery -- especially a decision with direct personal impact -- has legitimate grounds to reject the outcome. The system would also face the practical problem of non-participation: unlike jury duty, WIP has no legal authority to compel service, and opt-out rates would introduce systematic bias.

Each of these exclusions follows the same logic: if a feature creates a pathway to power concentration, gaming, or exclusion, it is removed regardless of its theoretical appeal. The security model protects not only against external attackers but against the system's own potential for self-corruption.

The most important line in any security claim is the one that says: "Don't take our word for it. Check for yourself."

Every system that asks for trust must answer a prior question: why should anyone trust it? Traditional institutions answer with authority -- trust us because we are the government, the bank, the established institution. The World Intelligence Protocol answers differently. WIP's trust model is built not on authority but on verifiability: the entire system is open source, independently auditable, and designed so that its guarantees are enforced by code, not by policy.

The difference between "trust us" and "verify us" is the difference between faith and evidence.

A closed-source voting system asks voters to trust that the code does what the documentation says it does. This is, on its face, an unreasonable request. The history of proprietary voting systems is a history of documented failures: the Diebold AccuVote machines that could be reprogrammed with a $15 memory card, the ES&S ExpressPoll systems with hardcoded passwords, the numerous proprietary systems whose security-through-obscurity model was shattered by the first competent audit.

Open source eliminates this failure mode. When the source code is public, every claim about the system's behavior is verifiable. When WIP states that the base vote of 1.0 is inviolable, anyone can read the `calculateWeight()` function in the shared type library and confirm that the safety clamp enforces `Math.max(MIN_WEIGHT, Math.min(MAX_WEIGHT, weight))` where `MIN_WEIGHT = 1000`. When WIP states that biometric data never leaves the device, anyone can read the enrollment code and confirm that only a SHA-256 hash is transmitted. When WIP states that vote content is never logged, anyone can read the log redaction configuration and confirm that `vote`, `nonce`, `commitmentHash`, and `biometricHash` are explicitly redacted.

This is not transparency as a virtue. It is transparency as an engineering requirement. A democratic voting system that cannot be independently verified is not a democratic voting system -- it is a black box with democratic aspirations. The legitimacy of WIP's results depends not on the reputation of its operators but on the demonstrable correctness of its code.

Open source also provides a structural defense against insider threats. A developer who introduces a backdoor must do so in code that is visible to the entire world. A maintainer who weakens a security guarantee must do so in a public commit. The social pressure of public scrutiny -- the knowledge that cryptographers, security researchers, and concerned citizens are reading every line -- is itself a security mechanism. It does not replace technical controls, but it complements them.

WIP uses reproducible builds for all components. This means that anyone can take the published source code, compile it using the documented build process, and verify that the resulting binary matches the one running in production. Reproducible builds close the gap between "the source code is secure" and "the deployed software is secure" -- a gap that has been exploited in supply chain attacks against other systems.

Open source is necessary but not sufficient. Code that is available for review but never actually reviewed provides false confidence. WIP's approach to auditing is systematic, multi-layered, and public.

Smart contract audits are the highest priority. The four CosmWasm contracts (humanity-key-registry, vote-commitment, vote-tally, proposal-registry) collectively enforce the constitutional guarantees of the voting system: the inviolability of the base vote, the integrity of the commit-reveal protocol, the correctness of the weighted tally, and the validity of the proposal lifecycle. These contracts undergo formal security audits by independent firms specializing in Cosmos/CosmWasm security, with all findings published in full -- not redacted summaries, not executive overviews, but the complete audit report with every finding, severity rating, and remediation status.

Publishing full audit findings is a deliberate choice that invites scrutiny. Many organizations publish only summaries, highlighting resolved issues and downplaying or omitting unresolved ones. WIP publishes everything because the purpose of the audit is not to generate a marketing document but to demonstrate that the system has been examined by competent adversaries and that its weaknesses are known, documented, and addressed.

API penetration testing is conducted by independent security firms against the production API gateway. The test scope covers all REST endpoints, authentication flows, rate limiting, input validation, and the full OWASP Top 10 attack surface. The penetration test is not a one-time event; it is a recurring engagement that runs against each major release.

The scope of the pen test includes: SQL injection (verifying parameterized queries), authentication bypass (JWT manipulation, algorithm confusion, token reuse), rate-limit bypass (header spoofing, distributed requests), privilege escalation (horizontal and vertical), IDOR (accessing other users' data through manipulated identifiers), timing attacks on authentication, and replay attacks on voting (resubmitting captured commit/reveal payloads). Findings are published in the same format as smart contract audits.

Dependency audits run quarterly across all package ecosystems (npm audit, cargo audit, pip-audit). The results are integrated into CI/CD: any dependency with a known critical vulnerability blocks the build pipeline until resolved. This is an automated defense against supply chain attacks -- the kind of attack where a compromised upstream dependency introduces a vulnerability that is invisible to manual code review.

Beyond formal audits, WIP operates a bug bounty program with payouts up to $1 million for critical voting or identity vulnerabilities. The bug bounty extends the audit surface from professional firms to the global security research community. The economics are simple: paying a researcher who finds a vulnerability before an attacker exploits it is always cheaper than recovering from an exploited vulnerability.

Most organizations govern themselves through policy documents: terms of service, privacy policies, bylaws, codes of conduct. These documents state intentions but do not enforce them. A privacy policy that says "we do not store your data" can be violated by a rogue employee, a misconfigured server, or a management decision to change the policy. The enforcement mechanism for policy documents is legal action -- slow, expensive, jurisdictionally limited, and available only after the violation has occurred.

WIP takes a different approach for its core guarantees. The most important rules of the system are enforced not by policy documents but by immutable smart contracts deployed on the Cosmos appchain.

The base vote of 1.0 is not a policy -- it is a `MIN_WEIGHT = 1000` constant in the vote-commitment smart contract, enforced by a range check that rejects any weight below this floor. The maximum vote weight of 1.5 is not a guideline -- it is a `MAX_WEIGHT = 1500` constant enforced by the same range check. The commit-reveal protocol is not an aspiration -- it is a phase state machine in the smart contract that physically prevents vote submission outside the commit phase and prevents revelation outside the reveal phase. Double voting is not discouraged -- it is prevented by a uniqueness constraint on (proposal_id, voter_key_hash) that the contract checks before accepting any commitment.

These guarantees cannot be violated by a WIP employee, a WIP board member, or even the entire WIP organization acting in concert. They are enforced by code running on a decentralized blockchain that no single entity controls. Modifying these guarantees would require deploying a new contract -- an act that is visible on-chain to everyone and would be immediately detected by any monitoring system.

This is what it means for the code to be the constitution. The guarantees are not promises; they are mathematical facts. The base vote of 1.0 is not protected by good intentions; it is protected by the same cryptographic and computational mechanisms that protect bank accounts and state secrets. A voter does not need to trust that WIP will honor its commitments. They can verify that the smart contract makes violating those commitments computationally infeasible.

The implications extend beyond security. When the code is the constitution, the governance of the system itself becomes transparent and verifiable. Any proposed change to the system's rules -- a modification to the voting formula, a change to the cosigning threshold, an update to the deliberation period -- requires deploying new contract code. This deployment is visible on-chain, auditable by anyone, and subject to the same governance process as any other proposal. The rules that govern voting are themselves subject to voting, and the enforcement of those rules is not delegable to any individual or institution.

This is the deepest commitment WIP makes: not just that the system is open, but that it is self-enforcing. The guarantees do not depend on the good faith of the operators. They do not depend on the legal system. They do not depend on the vigilance of users. They are properties of the code itself, running on infrastructure that no single party controls, verifiable by anyone with a computer and an internet connection. This is the standard that democratic infrastructure in the digital age must meet.