Chapter 41: Governance, hard forks, and migration case studies
A blockchain governance forum is a multi-stakeholder coordination process for activating a verifier-surface change. A post-quantum migration is not always a hard fork.
Per the closed Ch 36 / Ch 37 framing, Bitcoin’s two-layer path is a soft fork: BIP-360 Pay-to-Merkle-Root (P2MR, Draft v0.12.1) (Beast et al., 2024) is the long-exposure key-path mitigation. Full short-exposure protection would require a separate post-quantum signature proposal, likely designed as a soft-fork-style script or tapscript extension if it follows Bitcoin’s current extension model, but the exact mechanism is not yet specified in BIP-360.
Ethereum’s consensus-layer signature changes coordinate through hard-fork network upgrades, while execution-layer account-signature migration can happen through account abstraction and contract-level verification paths. ERC-4337 (Buterin et al., 2021) already shows how smart accounts can use programmable validation without consensus-layer changes. The public Ethereum post-quantum roadmap (ethereum.org contributors, 2026) points to protocol-supported account-abstraction work. The Draft EIP-8141 (“Frame Transaction”) (Ethereum Improvement Proposal authors, 2026) is being considered for the Hegotá upgrade as the signature-agility hook. The fork association is the roadmap page’s statement, not the EIP’s (ethereum.org contributors, 2026).
The operator’s question is therefore not only “hard fork or not,” but which verifier surface changes, which stakeholder group owns it, and whether the activation window clears Mosca’s inequality on the governance surface.
Covered in Ch 37, Ch 38, Ch 39, and Ch 40: the Layer-1 transaction surface, the wallet and key-rotation surface, the consensus signature surface, and the on-chain verifier-contract surface. This chapter covers the governance surface from the Ch 36 surface taxonomy. Ch 26 introduces the six architectural areas a migration organizes around, and Ch 30 runs them as work streams under a four-phase migration program (discovery, first wave, broad rollout, end of migration). The stakeholder taxonomy below is this chapter’s own: on a public chain the owners are not internal teams. This chapter wires both into the cross-stakeholder choreography and walks three named case studies.
A Strand governance surface migrating from Schnorr-secp256k1 per-vote to a post-quantum candidate
Section titled “A Strand governance surface migrating from Schnorr-secp256k1 per-vote to a post-quantum candidate”The Strand governance surface from the Ch 36 fixture deploys Schnorr-secp256k1 (Wuille et al., 2020) at years (governance-key reuse window) and years (governance-fork rollout window). The surface signs per-vote: a fixed multisig committee approves treasury proposals, parameter changes, and protocol upgrades through on-chain Schnorr signatures. Under the Ch 36 strict-inequality framing, . The surface clears under any and breaches under .
The motivating example: a Strand governance committee plans the migration to a post-quantum candidate before the on-chain Schnorr verifier breaks under Shor (Shor, 1994). The candidate set covered later in the chapter spans composite Schnorr+ML-DSA-65 (National Institute of Standards and Technology, 2024) for a transition window, SLH-DSA-128s (National Institute of Standards and Technology, 2024b) for the long-lived governance key, and a research-grade threshold ML-DSA combiner. The classical leg is Schnorr rather than the Ed25519 used in the Ch 37 and Ch 38 composites because Strand’s governance surface deployed Schnorr-secp256k1, not Ed25519.
The migration is not a one-team rollout. It runs across three stakeholder groups. The Strand core development team writes the proposal. The Strand validator operators run the consensus client. The infrastructure service providers (RPC providers, indexers, block explorers, wallet vendors) front the chain for end users. Each group carries its own coordination cadence. The cross-stakeholder activation window is set by the sequential critical path (proposal review, economic-actor or client-team lead, consensus-participant update), with parallel infrastructure readiness becoming binding only if it lags the consensus-release path.
The four-part operator playbook below decomposes the stakeholder set into three groups and three actions, quantifies the cross-stakeholder activation window in weeks, plans the governance-rotation cadence against the Mosca window, and choreographs three end-to-end walks. The walks are a Bitcoin draft soft-fork proposal walked through the BIP process with BIP-360 P2MR as the live hook (Beast et al., 2024), an Ethereum hard fork through the All Core Devs forum, and a Strand-bridge upgrade.
Three coordination tools and how they connect
Section titled “Three coordination tools and how they connect”The governance surface from the Ch 36 surface taxonomy is the Strand surface with the slowest signing cadence. The transaction surface rolls per-spend; the consensus surface rolls per-slot; the wallet surface rolls per-address; the on-chain-verifier surface rolls per-proof. The governance surface signs per-vote, with each vote representing a multisig-approved proposal that lands on-chain through a single governance transaction carrying an M-of-N signature set. Today that set is one Schnorr threshold aggregate. Under the migrated design it carries multiple independent signatures instead, per the post-quantum threshold-signature posture in the tradeoffs section. The per-vote cadence sets the lower bound on key reuse: a committee that signs ten proposals in a year reuses the same key for at least one full year unless a between-vote rotation runs in parallel.
This chapter’s three-stakeholder taxonomy maps the migration onto three work streams. Each work stream has an owner, a cadence, and a deliverable.
| Work stream | Owns | Cadence | Deliverable |
|---|---|---|---|
| protocol developer | the proposal: BIP draft, EIP, or rollup forum thread | proposal review, weeks to months | a reference implementation |
| validator operator | the consensus-rule deploy: client release, validator-set rotation, activation block | validator-set update, weeks | validators running the new client at activation |
| infrastructure service provider | the read-side deploy: RPC surface, indexer schema, explorer renderer, wallet display | parallel with the client-team release lead | end-user continuity across the activation |
The infrastructure-service-provider cadence sits off the critical path under this model’s planning assumptions. In practice, indexer, RPC, or wallet incompatibility can still become the binding constraint when an upgrade lands without coordinated infrastructure readiness.
The Ch 30 four-phase program (discovery, first wave, broad rollout, end of migration) maps onto the cross-stakeholder choreography as follows. Discovery runs at the protocol-developer work stream and ends with a written proposal. First wave runs jointly: the protocol-developer ships a reference implementation, the validator-operator runs it on a public testnet, the infrastructure-service-provider tests end-user breakage. Broad rollout runs at the validator-operator and infrastructure-service-provider work streams jointly: the validator set upgrades and the infrastructure surface swaps in parallel. End of migration runs at the validator-operator work stream and ends when the legacy signature opcode is deactivated.
The cross-stakeholder governance playbook in four parts
Section titled “The cross-stakeholder governance playbook in four parts”Decompose the stakeholder set into three groups and pick a per-action work-stream owner
Section titled “Decompose the stakeholder set into three groups and pick a per-action work-stream owner”The Strand operator decomposes the stakeholder set into the three groups and walks the matrix of three stakeholders by three actions. The actions are propose, audit, and deploy: a proposal lands on a public forum, an external audit reviews the proposal and the reference implementation, and a deploy phase rolls the change out across the network. The function below is a pedagogical slice of governance.stakeholder_matrix.lookup that records the work-stream-owner role per cell.
# Block 1: pedagogical slice of governance.stakeholder_matrix# (stdlib only).STAKEHOLDERS = ( "protocol-developer", "validator-operator", "infrastructure-service-provider",)ACTIONS = ("propose", "audit", "deploy")
# (work_stream_owner, coordination_role) per (stakeholder, action).MATRIX = { ("protocol-developer", "propose"): ( "core-development-team", "primary", ), ("protocol-developer", "audit"): ( "core-development-team", "primary", ), ("protocol-developer", "deploy"): ( "core-development-team", "co-owner", ), ("validator-operator", "propose"): ( "validator-coordinator", "downstream-consumer", ), ("validator-operator", "audit"): ( "validator-coordinator", "co-owner", ), ("validator-operator", "deploy"): ( "validator-coordinator", "primary", ), ("infrastructure-service-provider", "propose"): ( "rpc-provider-and-indexer-team", "downstream-consumer", ), ("infrastructure-service-provider", "audit"): ( "rpc-provider-and-indexer-team", "co-owner", ), ("infrastructure-service-provider", "deploy"): ( "rpc-provider-and-indexer-team", "primary", ),}
primaries_per_action = {action: [] for action in ACTIONS}for (stakeholder, action), (owner, role) in MATRIX.items(): if role == "primary": primaries_per_action[action].append(stakeholder)
for action in ACTIONS: print(f"{action}: {primaries_per_action[action]}")# ==> propose: ['protocol-developer']# ==> audit: ['protocol-developer']# ==> deploy: ['validator-operator', 'infrastructure-service-provider']Every Python block this chapter prints is also a standalone file in the companion repository, under chapter-code/ch41/, one file per block. Appendix C covers the clone and the environment they run on.
The propose action carries one primary owner. The audit action carries one primary owner: the core-development team integrates fixes from an external security-audit firm into the proposal. The deploy action carries two primary owners on different sub-surfaces: the validator operator owns the consensus-rule deploy, and the infrastructure service provider owns the read-side deploy. Block 2 below gives the per-cell coordination tempo.
Figure 41.1 maps the three stakeholder groups against the three governance-fork phases (propose, audit, deploy). Each cell names its coordination role: primary owner, co-owner, or downstream-consumer. Four of the nine also carry a coordination tempo in weeks.
Quantify the cross-stakeholder activation window
Section titled “Quantify the cross-stakeholder activation window”The second inline block walks the activation-window arithmetic across two named coordination cycles: a Bitcoin-style soft-fork / BIP process and an Ethereum-style All Core Devs hard-fork process. The activation window sums three components on the critical path: the proposal-review weeks, the economic-actor or client-team lead weeks, and the consensus-participant update weeks. The consensus-participant update window covers Ethereum-side validator-set rotation per the Ch 39 framing and Bitcoin-side full-node / miner / mining-pool readiness against the activation height. The infrastructure-lead weeks run in parallel with the client-team release lead time and do not stack onto the critical path. Every reported quantity carries its cycle-name suffix.
# Block 2: pedagogical slice of governance.fork_choreography# (stdlib only). Constants are illustrative anchors at chain-tip# 2026; a production hard fork measures against its own# coordination history.
# Bitcoin BIP cycle.BIP_PROPOSAL_REVIEW_WEEKS = 16BIP_ECONOMIC_ACTOR_LEAD_WEEKS = 26
# Ethereum All Core Devs cycle.ACD_PROPOSAL_REVIEW_WEEKS = 12ACD_CLIENT_TEAM_RELEASE_WEEKS = 8
# Cross-cycle critical-path component. Chain-neutral name: Ethereum-# side validator-set rotation + Bitcoin-side full-node / miner /# mining-pool readiness against the activation height.CONSENSUS_PARTICIPANT_UPDATE_WEEKS = 4
# Off-critical-path parallel component.INFRASTRUCTURE_LEAD_WEEKS = 8
btc_window_weeks = ( BIP_PROPOSAL_REVIEW_WEEKS + BIP_ECONOMIC_ACTOR_LEAD_WEEKS + CONSENSUS_PARTICIPANT_UPDATE_WEEKS)eth_window_weeks = ( ACD_PROPOSAL_REVIEW_WEEKS + ACD_CLIENT_TEAM_RELEASE_WEEKS + CONSENSUS_PARTICIPANT_UPDATE_WEEKS)
print(f"bitcoin_bip_cycle activation_window_weeks={btc_window_weeks}")print(f"ethereum_acd_cycle activation_window_weeks={eth_window_weeks}")print(f"bitcoin years={btc_window_weeks/52:.3f}")print(f"ethereum years={eth_window_weeks/52:.3f}")print(f"infrastructure_lead_weeks (off critical path)={INFRASTRUCTURE_LEAD_WEEKS}")# ==> bitcoin_bip_cycle activation_window_weeks=46# ==> ethereum_acd_cycle activation_window_weeks=24# ==> bitcoin years=0.885# ==> ethereum years=0.462# ==> infrastructure_lead_weeks (off critical path)=8Under this illustrative planning model, the Bitcoin-style case study runs longer than the Ethereum-style case study because the economic-actor lead window dominates. Mining pools, exchanges, custodians, and wallet vendors stage release builds against the activation height for roughly six months in the modeled cycle. The Ethereum-style case study runs shorter because the client-team release lead time runs in parallel with the AllCoreDevs forum review on most hard forks in the modeled cycle. The eight-week constant absorbs the remaining sequential lead. The 16-week, 26-week, 12-week, 8-week, and 4-week constants are illustrative model parameters for the operator playbook in this chapter, not measured protocol constants. Any production hard fork measures against its own coordination history.
Figure 41.2 compares the two activation windows as stacked bars, the Bitcoin-style 46-week BIP cycle against the Ethereum-style 24-week All Core Devs cycle. Each segment is labelled by component, and the 26-week economic-actor lead that dominates the difference is the longest segment on either bar.
Plan the governance-rotation cadence
Section titled “Plan the governance-rotation cadence”The third inline block runs the Mosca-window calculation against the Strand governance surface. The calculation applies the same cadence-recommendation logic as Ch 40, restricted to the per-vote tempo options: per-vote-cycle, every-N-vote-cycles, governance-trigger, hard-fork-trigger. The cross-stakeholder activation window from the second block sits inside the cadence rather than driving it: a 46-week Bitcoin BIP cycle fits inside the three-year safe window at the Strand fixture’s narrow scenario, and runs comfortably inside the wider scenarios. The cadence functions work with the signed margin , whose positive part is Ch 36’s exposure window.
# Block 3: pedagogical slice of governance.governance_mosca# (stdlib only). Recommends a governance-rotation cadence under# the Strand governance anchor (X=4, Y=3) per the Ch 36 fixture.
X, Y = 4, 3 # Strand governance surface anchor.SCENARIO_Z_VALUES = {"narrow": 6, "central": 9, "wide": 13}
def recommend_cadence(X, Y, Z): breach = X + Y - Z safe_window = max(0, Z - Y) if breach <= 0: return ("governance-trigger", breach, safe_window, 0) if safe_window >= 1: return ("every-N-vote-cycles", breach, safe_window, safe_window) return ("hard-fork-trigger", breach, safe_window, 0)
for scenario, Z in SCENARIO_Z_VALUES.items(): cadence, breach, safe_window, interval = recommend_cadence(X, Y, Z) print( f"{scenario:8s} Z={Z:2d} breach={breach:+3d} " f"safe_window={safe_window:2d} interval={interval:2d} " f"cadence={cadence}" )# ==> narrow Z= 6 breach= +1 safe_window= 3 interval= 3 cadence=every-N-vote-cycles# ==> central Z= 9 breach= -2 safe_window= 6 interval= 0 cadence=governance-trigger# ==> wide Z=13 breach= -6 safe_window=10 interval= 0 cadence=governance-triggerUnder the narrow scenario at the surface breaches by one year. The safe window is years. The cadence is every-N-vote-cycles with tuned so the effective key-reuse stays inside the three-year safe window, under the same three conditions Ch 39 attaches to the consensus surface. The interval counts down to the absolute arrival date. The post-quantum governance-key cutover completes inside . And every classical committee key retires within the window, because rotating one classical key for another clears nothing once the CRQC exists. Under the central scenario at , the margin is years (cleared by two years). The cadence is governance-trigger: rotate at named governance events rather than at a fixed calendar interval. Under the wide scenario at the cadence stays governance-trigger with a comfortable ten-year safe window. The boundary case for the strict inequality is . At the surface is one year past the breach boundary, the smallest breach the matrix admits.
The narrow value is the narrowest scenario under the surface. The central value reuses the Ch 36 NCSC 2035 working assumption, the same anchor used for the consensus and on-chain-verifier surfaces in Ch 39 and Ch 40. The wide value is one year below the mid-2040 scenario in Ch 36 and gives a third clearly-cleared scenario. The cross-cycle activation window from Block 2 is at most one year on Bitcoin and fits inside the three-year safe window at .
Choreograph the named case studies
Section titled “Choreograph the named case studies”Three case studies run the same three work streams through three different coordination processes. The table names who fills each work stream in each case.
| Work stream | Bitcoin BIP soft fork | Ethereum ACD hard fork | Strand L2 bridge upgrade |
|---|---|---|---|
| protocol developer | the BIP draft and its reference implementation | the EIP draft and the client pull requests, plus the client-team set itself | the rollup governance proposal and the bridge-contract upgrade |
| validator operator | miners and mining pools, with full-node operators | solo stakers, staking pools, institutional operators, node providers | the sequencer-and-prover team plus the L1 multisig committee |
| infrastructure service provider | exchanges, custodians, wallet vendors, payment processors, explorers | RPC providers plus the indexer and explorer ecosystem | the same, plus a per-rollup explorer and bridge UI |
The Bitcoin case study traces a draft soft-fork proposal through the BIP process from a draft on the bitcoin-dev mailing list, through the BIP repository, to activation across the economic actors. The chain hook at chain-tip 2026 is BIP-360 (Beast et al., 2024), a Draft Pay-to-Merkle-Root (P2MR) proposal, not a deployed post-quantum signature opcode. P2MR is a soft-fork-style proposal (Layer: Consensus, soft fork) that mitigates long-exposure quantum risk by removing the Taproot key path and committing only to a script Merkle root. Per the closed Ch 36 / Ch 37 framing, full short-exposure post-quantum signature support is left to a separate, not-yet-drafted proposal. The exact mechanism is not specified in BIP-360, though if the proposal follows Bitcoin’s current extension model it would likely be a soft-fork-style script or tapscript extension.
The BIP publication process is editorial rather than decisional, and it is distinct from the implementation, activation, and adoption phases that follow it. BIP-3 (Murch, 2025) gives the BIP editors “administrative and editorial responsibilities” and states that once a proposal advances “it is up to the Bitcoin community to evaluate, adopt, ignore, or reject a BIP”. Activation happens elsewhere. Miners and mining pools produce blocks and may signal readiness through a soft-fork activation mechanism such as BIP 9 versionbits or BIP 8. Full-node operators validate consensus rules and ultimately enforce or reject the activated rule set. On the read side, exchanges stage release builds against the activation height, custodians migrate cold-storage signing paths, and wallet vendors update address-derivation logic. The 26-week economic-actor lead window in Block 2 absorbs all three.
The Ethereum case study traces a post-quantum hard fork through the All Core Devs (ACD) forum, the rough-consensus cross-client-team coordination process that surfaces a hard-fork plan rather than a binding command authority. EIP-233 (Beregszaszi, 2017) frames hard-fork coordination through a Meta EIP that names the fork codename, activation block, timeline, and included EIPs. That EIP is itself Stagnant, so read it as the shape of the process rather than as its current governing document. The live practice runs as the All Core Devs Execution (ACDE) and Consensus (ACDC) call series, roughly biweekly.
The protocol-developer work stream on Ethereum is also the client-team set. It spans the execution-client teams (Geth, Nethermind, Besu, Erigon, Reth) and the consensus-client teams (Lighthouse, Prysm, Teku, Nimbus, Lodestar, Grandine). Each ships a release build that passes the cross-client testnet under the new EIP. The validator-operator work stream is whoever deploys those releases before the fork activation epoch. The eight-week client-team release lead window in Block 2 absorbs the cross-client coordination. The eight-week infrastructure-lead window runs in parallel.
The Ethereum post-quantum roadmap (ethereum.org contributors, 2026) is not a single signature swap. It spans four quantum-vulnerable areas: consensus-layer BLS signatures, KZG commitments for data availability, execution-layer account signatures, and application-layer ZK proof systems. The consensus layer’s public direction points to a hash-based replacement (leanXMSS) for validator signatures plus a minimal-zkVM aggregation machinery (leanVM) that compresses per-slot signature data. The execution layer’s signature-agility hook is account abstraction. ERC-4337 (Buterin et al., 2021) already shows the validation-by-bytecode pattern. The Draft EIP-8141 “Frame Transaction” (Ethereum Improvement Proposal authors, 2026) is being considered for the Hegotá upgrade to bring native account abstraction into the protocol. The EIP names no fork, and the association is the roadmap page’s (ethereum.org contributors, 2026). Under native account abstraction, individual accounts can opt into post-quantum verification ahead of a single protocol-wide migration. The roadmap is explicit that these are planning targets, not guaranteed commitments. Final direction is determined through the All Core Devs process.
The Strand-bridge case study traces an L2 bridge upgrade from a rollup-side governance forum to L1 activation. The Strand bridge is a synthetic example modeling a generic optimistic-rollup-to-L1 bridge. Its activation choreography reuses the five-phase verifier-contract upgrade from Ch 40 (propose, audit, multisig-approve, activate, transition window) and adds the cross-stakeholder coordination from Blocks 1 and 2 on top.
Cryptanalysis: three governance-surface attack categories
Section titled “Cryptanalysis: three governance-surface attack categories”Three attack categories are specific to the governance surface.
The first category is multisig-key compromise. A corrupted multisig signer attempts to forge a governance vote, or an adversary that compromises one signer through long-exposure public-key recovery once a CRQC exists. The compromise mechanism is a Shor-style attack against the on-ledger public key, distinct from the HNDL confidentiality-harvest framing that targets encrypted traffic. The mitigation is the M-of-N multisig policy and the per-signer key-rotation cadence from Ch 38. Strand’s 5-of-9 committee tolerates up to four compromised signers: an attacker holding fewer than five keys cannot produce a valid 5-of-9 spend. The per-signer rotation cadence (annual or per-vote, depending on the governance committee’s risk posture) bounds the time a compromised key sits exploitable.
Under SLH-DSA-128s (National Institute of Standards and Technology, 2024b) the long-lived governance key is hash-only secure: its unforgeability rests on the pseudorandomness of the underlying PRF and on preimage resistance and related properties of the underlying hash function, with the precise hypothesis set given in Chapter 18. Under composite Schnorr+ML-DSA-65 (National Institute of Standards and Technology, 2024a) during a transition window, the legacy and post-quantum verification paths run in parallel. A verifier accepts only when both paths return valid. An adversary forging the Schnorr leg through Shor still has to produce a valid ML-DSA-65 leg.
The second category is stakeholder-coordination failure. A stakeholder group fails to upgrade in time, fragmenting the network across a legacy verifier set that still accepts the pre-fork signature opcode and a post-quantum verifier set that does not. The fragmentation manifests as a chain split if the validator-operator work stream falls behind, or as end-user breakage (broken explorers, stale indexer schemas, wallet-vendor display errors) if the infrastructure-service-provider work stream falls behind.
The mitigation is the staged-activation choreography from Block 2. The activation block is chosen so the validator-set update runs after the proposal-review and economic-actor or client-team lead windows close. The infrastructure-lead window runs in parallel rather than blocking the critical path. A second mitigation is a transition window analogous to the Ch 40 verifier-contract upgrade window: the legacy and post-quantum signature opcodes run in parallel for a fixed multi-week period, giving wallets, explorers, custodians, and stragglers time to migrate. A transition window reduces application-level breakage; it does not by itself eliminate consensus-split risk if block producers and validating nodes disagree on the activated rule set, and so it does not replace the underlying activation-discipline requirement.
The third category is governance-process gaming. An adversary submits a malicious proposal that exploits a process gap: a missed audit-firm engagement, a multisig-approval threshold tuned too low, an activation window that runs through a low-attention period (a holiday, a major industry conference). The mitigation is the audit phase of the stakeholder matrix and the multi-week proposal-review window. The audit phase forces an external auditor to review the proposal and the reference implementation; the proposal-review window forces the protocol-developer work stream to surface the proposal to the validator-operator and infrastructure-service-provider work streams before the multisig-approval phase.
A 16-week BIP proposal-review window absorbs roughly four monthly cycles of public review; a 12-week ACD proposal-review window absorbs roughly three monthly cycles of forum-call agenda inclusion (six biweekly cycles). Longer windows reduce, but do not eliminate, low-attention timing risk: holidays, industry conferences, and market crises can span multiple weeks, and calendar length alone does not defeat governance-process gaming.
Each category sits at a different point in the four-part playbook. Multisig-key compromise sits at the deploy phase, after the proposal lands on-chain. Stakeholder-coordination failure sits at the validator-set update window, the critical-path component. Governance-process gaming sits at the proposal-review window, before the multisig-approval phase.
Tradeoffs
Section titled “Tradeoffs”The four candidates on the governance surface trade off across four axes: coordination tempo, work-stream-owner clarity, rollback feasibility, and post-quantum readiness at chain-tip 2026.
| Candidate | Coordination tempo | Work-stream-owner clarity | Rollback feasibility | PQ readiness 2026 |
|---|---|---|---|---|
| Schnorr-secp256k1 baseline | low (no migration) | high (status quo) | high (no upgrade) | broken under Shor |
| composite Schnorr+ML-DSA-65 | medium (transition window) | high (parallel paths) | high (drop the PQ leg: no re-keying, but a rule relaxation that needs the same activation mechanism) | transition-only; category 3, structured-lattice assumption |
| SLH-DSA-128s | medium (one-time swap) | high (single-primitive) | medium (revert by hard fork) | high assumption confidence, category 1 |
| threshold ML-DSA | high (research-grade) | medium (combiner unclear) | low (hard fork plus committee re-keying) | research |
The composite candidate has the highest rollback feasibility because dropping the post-quantum leg returns the verifier to the legacy Schnorr-only path with no re-keying and no new primitive: the committee’s Schnorr keys are already registered. It is still a consensus-rule change. Accepting votes with no valid ML-DSA-65 leg loosens the acceptance rule, so it is a hard fork unless the activation that introduced the composite already authorized the fallback, and a committee that dropped the leg node by node would split on exactly the votes the leg protects. The security given up is the post-quantum leg itself: Schnorr-only acceptance is forgeable by a CRQC. SLH-DSA-128s carries the highest post-quantum confidence at chain-tip 2026. Its hash-only unforgeability depends on PRF pseudorandomness and on preimage resistance and related properties of the underlying hash function (Chapter 18), with no dependence on a structured assumption such as discrete log or LWE.
The two are not the same NIST security category. FIPS 205 (National Institute of Standards and Technology, 2024b) places SLH-DSA-128s at category 1, while FIPS 204 (National Institute of Standards and Technology, 2024a) places ML-DSA-65 at category 3. The SLH-DSA-128s choice in this chapter is the conservative-assumption choice, not the same-category choice. A hash-based parameter set at ML-DSA-65’s category 3 level would use SLH-DSA-192s instead, at 16,224 bytes against 7,856, a roughly two-times larger signature budget.
Threshold ML-DSA is research-grade at chain-tip 2026. The threshold combiner is an open problem for SLH-DSA per Ch 39, exists for FALCON as a published and benchmarked protocol with no consensus deployment (Garg et al., 2026), and the ML-DSA combiner exists in published proposals but has not deployed on a production chain. Ch 39 §“Decide between threshold and per-validator signing” carries the byte-budget tradeoff between it and SLH-DSA-128s. Its rollback row reads low for a reason that is not statefulness. A threshold committee registers one jointly generated public key where an M-of-N committee registers N independent ones. Reverting therefore needs a hard fork and a re-keying of every signer, where the SLH-DSA-128s path needs only the fork. FROST (Komlo & Goldberg, 2020) is the canonical classical-Schnorr threshold precedent. Ch 39 covers its Shor-vulnerability inheritance through the underlying ECDLP and the open status of post-quantum analogues.
The conservative-assumption preference for the long-lived governance key is SLH-DSA-128s. SLH-DSA has no threshold variant: the threshold combiner is an open research problem per Ch 39. Strand’s governance surface is a 5-of-9 Schnorr threshold signature today (Ch 36), so it ships one aggregate signature. Every post-quantum path below loses that aggregation and ships one signature per voting signer.
| Per-vote payload | Signature material | Adding the newly transmitted public keys |
|---|---|---|
| Schnorr-secp256k1 today, one aggregate | 64 B | 64 B |
| composite Schnorr+ML-DSA-65, five signers | B | B |
| SLH-DSA-128s, five signers | B | B |
The right-hand column assumes the classical signer keys are already registered on-chain, so only the post-quantum keys are newly transmitted. Carrying every verification key inline instead would put the Schnorr row at 96 B and the composite row at B, 160 bytes more, and would leave the SLH-DSA row unchanged because it has no classical component. The signature sizes are FIPS 204’s for ML-DSA-65 (National Institute of Standards and Technology, 2024a) and FIPS 205’s for SLH-DSA-128s (National Institute of Standards and Technology, 2024b). The 32-byte Schnorr key and 64-byte signature are BIP-340’s (Wuille et al., 2020). The byte-budget preference during the transition window is therefore composite Schnorr+ML-DSA-65: it is smaller than the SLH-DSA-128s alternative with or without the inline keys, and the two carry the same per-vote cadence. Both are hundreds of times the 64 bytes a threshold Schnorr aggregate ships today, and that gap has two factors rather than one. Losing aggregation multiplies by 5, the signer count. The primitive multiplies by another 52.7 for the 3,373-byte composite and 122.8 for the 7,856-byte SLH-DSA signature, each against Schnorr’s 64 bytes.
The choice between the two preferences is a posture decision the governance committee makes rather than a primitive decision the chapter forces. A committee that prioritizes rollback feasibility above post-quantum confidence picks the composite. A committee that prioritizes post-quantum confidence above byte budget picks SLH-DSA-128s.
Where Part VII ends and the book closes
Section titled “Where Part VII ends and the book closes”Part VII took a chain apart the way Part VI took a proof system apart. Ch 36 set the taxonomy: five cryptographic surfaces on one fictional chain, each with its own primitive, its own , its own , and the same . The five chapters that followed migrated one surface each. Ch 37 took the per-spend transaction signature, Ch 38 the wallet derivation, Ch 39 the consensus attestation, Ch 40 the on-chain verifier contract, and this chapter the governance vote.
Nothing Part IV built is a candidate anywhere in it. No chapter of Part VII proposes McEliece, HQC, SQIsign, UOV, MAYO or SNOVA for any surface, which continues the handoff Ch 24 made when it recorded that Part V deploys none of them either. A chain migrates onto lattice and hash-based signatures, the two families Parts II and III built, or onto a composite of one of those with the classical primitive it replaces.
What moved across the six chapters is where the binding constraint sits, and it moved steadily away from the primitive. On the transaction surface it is throughput, where Ch 37 measures a 12.7-fold drop on Bitcoin. On the wallet surface it is a property no candidate has, since Ch 38 shows BIP-32’s public-key-only child derivation does not survive the swap. On the consensus surface it is a 26,452-fold byte tax from losing BLS aggregation, one full signature per validator. The floor beneath it, Ch 39 shows, is a participation bitmap the signature scheme never touches, which is why even threshold ML-DSA’s normalized payload floor sits at 1.03 times the BLS payload rather than below it. On the verifier surface it is EIP-7825’s per-transaction gas cap, which Ch 40 shows decides deployability before throughput becomes a question at all. On this surface it is a calendar: 24 weeks on the modelled Ethereum cycle and 46 on the modelled Bitcoin one, and not one of those weeks is spent on cryptography.
That is the arc of the book as well as of the Part. Ch 01 posed Mosca’s inequality with three terms and assigned each an owner: is the data owner’s, is the organization’s, and is nobody’s. Parts II, III and IV built the primitives that make finite, because a migration with no destination has no duration. Part V turned into a program a single organization can run and audit. Parts VI and VII then measured and for two deployed domains. The last surface of the last Part is where the assignment breaks: a public chain has no organization, so its is a coordination window across parties nobody owns. The three work streams in this chapter exist because that owner had to be invented.
is where the book began and where it stops. Ch 01 said no dependable arrival date can be assigned to a CRQC, and nothing in the forty chapters since has changed that. Every number in this chapter is conditional on a scenario, and the three scenarios are chosen rather than measured. What the book can offer instead is the other two terms. you can read off your own data. you can now estimate, because you know what you would be migrating to and roughly what it costs. That is enough to start, and starting is the only part of the inequality under your control.
Exercises
Section titled “Exercises”Exercise 1 (compute). Compute the cross-stakeholder activation window in weeks for a stated chain. Assume a chain with the following coordination cycles: a 20-week proposal-review window, a 12-week economic-actor lead window, a 6-week validator-set update window, a 10-week infrastructure-lead window running in parallel. State the activation-window total in weeks and convert to a fractional-year figure. Compare the result against a reference Ethereum hard fork (12 + 8 + 4 = 24 weeks) and identify the dominant component.
Exercise 2 (compute). Sketch the Bitcoin BIP process for a post-quantum proposal. Name the six stages from a bitcoin-dev draft to activation across the economic actors. For each stage, state the work-stream owner from this chapter’s stakeholder matrix and a one-line description of the deliverable that closes the stage. The chain hook is BIP-360 P2MR (Pay-to-Merkle-Root) (Beast et al., 2024): state its status as Draft at chain-tip 2026. Explain that it is a soft-fork proposal that mitigates long-exposure quantum risk by removing the Taproot key path. Distinguish it from a future, not-yet-drafted post-quantum signature opcode proposal that would be a separate BIP.
Exercise 3 (open-ended). Apply the three-stakeholder taxonomy to a stated rollup or L2 bridge. Pick a named system (a Layer-2 rollup, a cross-chain bridge, a validator-aggregator service) and decompose the post-quantum migration into the three work streams (protocol developer, validator operator, infrastructure service provider). For each work stream, state the cadence in weeks and the deliverable that closes the work stream’s contribution to the activation.
Exercise 4 (compute). Justify a governance-rotation cadence for the Strand governance surface under given a stakeholder coordination tempo from Block 2. Use the Strand anchor , from the Ch 36 fixture. Compute the signed margin , the safe window, and the recommended cadence per the third inline block. Verify that the cross-stakeholder activation window from Block 2 fits inside the safe window. Identify the per-stakeholder action that the cadence absorbs without forcing a between-vote rotation.
Exercise 5 (open-ended). Map the governance migration to the Ch 30 four-phase program (discovery, first wave, broad rollout, end of migration) and name the work-stream owner from this chapter’s stakeholder matrix for each phase. State the deliverable that closes each phase and the gating criterion that admits the phase to the next. The deliverable for end of migration is the deactivation of the legacy Schnorr-secp256k1 verifier opcode. Identify the gating criterion that admits this final phase.
Worked solutions and editorial notes for these exercises are in Appendix D, Chapter 41. A separate track, for rebuilding rather than reading: the package exercises/ch41-governance has every function the chapter teaches replaced by a stub. Run PQC_IMPL=exercises pytest tests/ch41 to grade your version against the suite that proves the reference one.
References
Section titled “References”Last updated: