Impact Ledger Specification
This article specifies the engineering detail underlying the Chapter 2 statement that Impact uses some of the same plumbing as crypto, but the design choices are the opposite. Three deliberate departures from cryptocurrency architecture are the point. The Chapter 2 paragraph is the executive summary; this article is the spec the AI-fluent reader can argue about.
The lineage
The closest formal predecessor in the public literature is Vitalik Buterin, Glen Weyl, and Puja Ohlhaver, Decentralized Society: Finding Web3’s Soul (2022), which introduced the soulbound-token (SBT) mechanic. Impact inherits the structural family resemblance: a non-transferable token recorded on a public ledger, verifiable across many independent computers, decoupled from speculation. Soulbound tokens have evolved since the paper; Impact extends and inverts the model.
BFT consensus across MOSAIC validator nodes
The Impact ledger runs on a Byzantine fault tolerant (BFT) consensus mechanism. Practical-BFT (Castro and Liskov, 1999) is the underlying algorithm class. The validator set is constructed not from economic stake but from the Diversity Guard’s structural selection.
Canonical Phase Zero validator set: seven validators, each drawn from a distinct slot in the five-dimension Diversity Guard matrix (cultural, economic, geographic, cognitive, generational). This is the same selection that produces the 0.032 percent capture-probability ceiling described in Chapter 3 (the math: 0.2 raised to the fifth power, assuming roughly independent diversity dimensions).
BFT parameterisation: 3f + 1 with f = 2 for n = 7. The panel tolerates two actively malicious validators before consensus can be subverted. For constitutional changes (rules-about-rules), the panel scales to 21. For the rarest writes (mandate-of-heaven-class revocations), 49.
Rotation cadence: quarterly. Validators rotate off after each three-month cycle; a separately rotating committee audits the independence assumption (the diversity dimensions are not perfectly independent in practice, so the audit measures real correlation drift and adjusts panel size upward when correlation creeps above threshold).
Slashing: civic, not economic. There is no stake to burn (consensus pays no rewards in Impact; it is a civic obligation, not a job). Correction conditions are audit-log replay, public dissent record, and removal from the eligibility pool after independence-test failure. Validators who fail audits are not punished financially; they lose standing to validate.
Statistical skeleton: the diversity arithmetic uses Cramer’s V as the correlation measure across diversity dimensions, consistent with the Chapter 3 prose and Patrick’s independence-of-streams construction at Teradata.
Soulbound-token mechanics: non-transferability at the smart-contract layer
Impact tokens are non-transferable by design. The smart-contract layer enforces this constraint at write time: a transfer instruction (a transferFrom call in the conventional crypto idiom) reverts with an explicit non-transferability error. The token’s identity binding is to the consciousness-attested holder, not to the holder’s wallet, which means key-rotation events do not require token-transfer events; the holder authenticates with a new key and the binding persists.
Why this matters at the architectural level: transferable tokens become speculative, and non-transferable ones become reputation. The two categories cannot meaningfully share an exchange surface, so Impact does not have one. There is no decentralized exchange for Impact tokens, no over-the-counter market, no liquidity provider. The constraint is enforced in code rather than promised in a whitepaper.
Decay in the smart-contract layer
Impact decays at 3.4 percent annually, which is a 20-year half-life on accumulated balance. The decay function applies at the smart-contract layer, not at the application layer. The ledger guarantees the decay; the user interface only reports it. Time is sampled in epochs (one Earth-year), and each epoch the smart-contract applies the decay multiplier to all outstanding balances atomically across the validator set. This is why the decay is non-evadable: no application can choose to display old totals; the on-chain balance has already been reduced.
Founder Credits, the EXIT Protocol’s mechanism for legacy elites who transition into the Commons, decay at 5 percent annually, deliberately faster than standard Impact. The asymmetry is the ratchet against legacy entrenchment: legacy wealth converted to Founder Credits washes out across generations faster than ordinary earned Impact, ensuring multi-generational soft landings do not become multi-generational holdouts.
ZK identity attestation
Impact holders need to be verifiably distinct human consciousnesses (one human, one identity binding) without exposing personally identifying information. Zero-knowledge proofs handle this. The validator pool sees that diversity was satisfied across the five dimensions without seeing which validator carries which dimension.
The state-of-the-art examples cited in the article corpus: Aleo (privacy-preserving L1, mainnet September 2024), Aztec Ignition (privacy-preserving Ethereum L2, mainnet November 2025), Aztec Alpha Network (March 31, 2026). The Impact reference implementation borrows from this lineage rather than building its own cryptographic primitives.
The attestation flow: a Spark-Assessed consciousness (per the Chapter 4 protocol) receives a non-transferable identity binding, which then permits one and only one Impact ledger entry per individual. The ZK proof attests to the binding without revealing the underlying consciousness signature.
The three deliberate departures
Restating the inversions made explicit in the Chapter 2 paragraph:
- Non-transferable by design. No exchange, no exit liquidity, no speculative market. Reputation, not wealth.
- Decaying so accumulated influence cannot become permanent. 3.4 percent standard, 5 percent Founder Credits. No dynasty lasts forever, by construction.
- Federated consensus across MOSAIC validator nodes rather than economic incentives. No proof-of-work, no proof-of-stake, no token-weighted voting. Diversity is the security parameter; civic obligation is the participation mechanism; correctness is audited, not bought.
What prevents the tampering, in the book’s plain-language summary: every change is recorded simultaneously on enough independent computers that no single party can alter the record without others catching it.
What this article is not
This is a specification, not a deployment. Implementation details (the specific blockchain layer, the cryptographic primitives chosen for the production rollout, the gas-equivalent costs, the validator hardware requirements, the API surface for application developers) are deferred to a separate implementation document. The Chapter 2 paragraph and this article together are sufficient for the book’s argument; the engineering choices that follow can be settled later.
The Chapter 2 paragraph carries the executive summary, this article carries the spec, and the implementation document will carry the deployment when it exists.
Related reading: Impact · Impact vs Soulbound Tokens · Impact Decay Curves · Proof of Diversity · Foundational Principles · Zero-Knowledge Proofs
