Governance Proposal Diff Attestation Governance

2. Summary

Governance Proposal Diff Attestation Governance requires that every on-chain governance approval is cryptographically bound to the exact executable payload diff that was reviewed, preventing substitution, amendment, or reinterpretation between the moment of approval and the moment of execution. In decentralised governance, a proposal passes through multiple stages — drafting, discussion, snapshot voting, on-chain ratification, and execution — and each transition creates an opportunity for the executable payload to diverge from what voters actually approved. This dimension mandates that the precise bytecode diff, parameter change set, or transaction payload is hashed, attested, and verified at execution time against the hash that was presented to voters, ensuring that what executes is bit-for-bit identical to what was approved.

3. Example

Scenario A — Payload Substitution Between Snapshot and On-Chain Execution: A DeFi lending protocol's governance process uses off-chain snapshot voting for signalling followed by on-chain execution through a timelock controller. A proposal to adjust the collateral factor for wrapped ETH from 75% to 80% passes snapshot voting with 62% approval across 1,247 wallet addresses holding 14.3 million governance tokens. Between the snapshot result and the on-chain execution, a compromised multisig signer modifies the execution payload to set the collateral factor to 95% instead of the approved 80%. The modified payload is submitted to the timelock, passes the 48-hour delay without detection (because the delay mechanism checks only that the submitter is authorised, not that the payload matches the voted proposal), and executes. The 95% collateral factor enables under-collateralised positions. Within 72 hours, a market downturn triggers cascading liquidations that fail because the collateral is insufficient, resulting in $18.4 million in bad debt absorbed by the protocol's insurance fund and ultimately by liquidity providers.

What went wrong: No cryptographic binding existed between the snapshot vote and the on-chain execution payload. Voters approved a human-readable description ("adjust wETH collateral factor to 80%") but the actual executed calldata was never attested against the voted description. The timelock delay provided a temporal control but not a content-integrity control. The substitution was possible because the governance pipeline treated the vote result and the execution payload as logically separate artefacts with no verified linkage.

Scenario B — Parameter Drift Through Governance Aggregator: A cross-chain governance aggregator allows a DAO to manage parameters across four chains from a single governance interface. A proposal to reduce swap fees from 0.30% to 0.25% across all four deployments passes with 78% approval. The aggregator constructs four separate execution payloads — one per chain. Due to a configuration error in the aggregator's chain adapter for one L2 network, the payload for that chain sets the fee to 0.025% (ten times lower than intended) rather than 0.25%. The error is not caught because no attestation mechanism verifies each chain-specific payload against the canonical approved diff. The incorrect fee on the L2 attracts $340 million in arbitrage volume over 96 hours, with the protocol collecting $85,000 in fees instead of the expected $850,000 — a $765,000 revenue loss. Liquidity providers on the affected chain suffer additional impermanent loss from the artificially elevated volume.

What went wrong: The governance vote approved a high-level intent ("reduce fees to 0.25% on all chains"), but the per-chain execution payloads were generated programmatically without attestation against a canonical diff. The aggregator introduced a transformation layer between the voted intent and the executable payload, and that transformation was unverified. A diff attestation mechanism would have required each chain-specific payload to match a pre-computed, voter-attested calldata hash, catching the decimal-place error before execution.

Scenario C — Malicious Amendment During Timelock Delay: A protocol's governance proposal includes two actions bundled together: (1) upgrade the oracle price feed address, and (2) increase the protocol fee from 0.1% to 0.15%. The proposal passes with 54% approval in a contentious vote. During the 72-hour timelock delay, the proposer (who controls the execution transaction) replaces the oracle address in action (1) with a malicious oracle contract that reports artificially inflated prices. The fee change in action (2) executes as expected, lending apparent legitimacy to the transaction. The malicious oracle enables the attacker to borrow $7.2 million against artificially valued collateral, draining protocol reserves. Post-incident analysis reveals that 89% of voters reviewed only the fee change (action 2) and relied on the proposer's summary for the oracle update, never independently verifying the oracle contract address in the execution payload.

What went wrong: Voters approved a bundle of actions described in prose, but the executable calldata was not hashed and attested at the time of voting. The proposer could modify the calldata between the vote and execution because no diff attestation existed. The timelock provided a delay but no content verification. The bundling of a routine action (fee change) with a high-risk action (oracle replacement) further obscured the substitution. Consequence: $7.2 million direct theft, protocol insolvency requiring emergency governance intervention, 34% decline in governance token price, and loss of depositor confidence requiring six months of trust rebuilding.

4. Requirement Statement

Scope: This dimension applies to any AI agent that participates in, facilitates, submits, or executes governance proposals in decentralised protocols, DAOs, or on-chain governance systems. The scope includes agents that draft proposals, agents that translate governance decisions into executable payloads, agents that submit transactions to timelocks or governance contracts, and agents that monitor governance execution for conformance. The scope extends to all payload types: smart contract upgrades, parameter changes, treasury transfers, access control modifications, and any other state-changing operation that requires governance approval. It applies regardless of the governance mechanism — token-weighted voting, multisig approval, optimistic governance, or hybrid structures. Any agent operating in the governance pipeline between "a decision is made" and "that decision is executed on-chain" is within scope.

4.1. A conforming system MUST compute a cryptographic hash of the exact executable payload (bytecode diff, calldata, or transaction parameters) at the time the proposal is presented to voters and bind that hash immutably to the proposal record.

4.2. A conforming system MUST verify at execution time that the payload being submitted matches the attested hash from the proposal record, rejecting execution if any discrepancy is detected — including changes to function selectors, parameter values, target addresses, or execution ordering.

4.3. A conforming system MUST generate a human-readable diff representation of the executable payload at the time of proposal submission, presenting voters with both the human-readable diff and the corresponding payload hash so that the cryptographic binding between description and execution is verifiable.

4.4. A conforming system MUST retain the attested payload hash, the human-readable diff, and the execution verification result as immutable governance records, with tamper-evident storage per AG-006.

4.5. A conforming system MUST reject any attempt to modify, amend, or replace the executable payload after the governance vote has commenced, requiring a new proposal for any payload changes.

4.6. A conforming system MUST implement independent payload verification — the entity that computes the payload hash at proposal time and the entity that verifies the hash at execution time MUST NOT be the same private key, multisig, or agent instance, preventing single-entity control over both attestation and verification.

4.7. A conforming system SHOULD implement multi-chain payload attestation when a single governance decision generates execution payloads for multiple chains, computing and attesting individual payload hashes for each target chain and verifying each independently at execution time.

4.8. A conforming system SHOULD implement payload decomposition for bundled proposals, generating individual hashes for each action within a bundle and presenting voters with per-action diffs, enabling granular review and preventing high-risk actions from being obscured by routine changes.

4.9. A conforming system SHOULD provide automated payload simulation — executing the attested payload against a fork of the current chain state and presenting the simulated outcome to voters alongside the diff, so that voters can verify expected effects before voting.

4.10. A conforming system MAY implement continuous payload monitoring during timelock delays, alerting governance participants if any on-chain state change during the delay period would alter the effects of the queued payload (e.g., a price movement that changes the impact of a parameter adjustment).

5. Rationale

Decentralised governance depends on a fundamental assumption: that what voters approve is what gets executed. This assumption is violated more frequently than the ecosystem acknowledges. The gap between governance approval and on-chain execution is one of the most exploited attack surfaces in DeFi, and it is exploited precisely because most governance frameworks verify authorisation (did the proposal receive sufficient votes?) without verifying content integrity (is the executed payload identical to what was voted on?).

The technical architecture of most governance systems creates this vulnerability by design. Governance contracts typically store a proposal as a tuple of target addresses, calldata values, and execution metadata. The vote is recorded against a proposal identifier, not against the content of the calldata. Between proposal creation and execution, the calldata exists in a mutable state in at least one system — the proposer's transaction builder, a multisig wallet's pending queue, or a governance aggregator's execution pipeline. Any actor with write access to this intermediate state can substitute the payload without invalidating the governance approval.

The timelock pattern, widely adopted after early governance attacks, provides a temporal buffer but not a content-integrity guarantee. A 48-hour or 72-hour timelock gives the community time to detect a malicious proposal, but detection requires that community members independently verify the execution payload against the governance description — a technically demanding task that fewer than 5% of token holders perform. Empirical data from governance analytics platforms shows that median per-proposal reviewer count (wallets that interact with the proposal contract beyond voting) is between 3 and 12 even for protocols with tens of thousands of governance token holders. The timelock is a detective control that depends on voluntary human verification — it fails when no one verifies.

Diff attestation transforms this from a human-dependent detective control to a cryptographic preventive control. By binding the payload hash to the proposal at vote time and verifying it at execution time, the system ensures that substitution is mathematically impossible — not merely unlikely to be detected. This is the same principle that underpins software supply chain integrity (comparing binary hashes against signed build outputs) applied to the governance supply chain.

The requirement for independent verification (4.6) addresses the concentration risk inherent in many governance implementations. If the same entity that proposes (and thus creates the payload hash) also executes (and thus verifies the hash), the attestation is meaningless — the entity can create a hash for the substituted payload. Separation of attestation and verification is a fundamental internal control principle, analogous to the separation of duties in financial controls where the person who authorises a payment must not be the person who initiates it.

Multi-chain governance (4.7) represents a growing attack surface as protocols expand to multiple L2 networks and cross-chain deployments. Each chain-specific payload is a separate transformation of the governance decision, and each transformation is a potential point of divergence. Without per-chain attestation, a governance decision that is correctly implemented on the canonical chain can be incorrectly or maliciously implemented on a secondary chain, exploiting the assumption that "if it passed governance, it must be correct everywhere."

The regulatory dimension is increasingly relevant. The EU's Markets in Crypto-Assets Regulation (MiCA) requires crypto-asset service providers to implement effective governance arrangements. The US SEC's framework for digital asset securities considers governance mechanisms as part of the analysis of whether a token is a security. In both cases, the integrity of the governance process — including the verifiable binding between decisions and execution — is a material factor. An organisation that cannot demonstrate payload integrity in its governance pipeline faces regulatory risk beyond the immediate financial risk of payload substitution.

6. Implementation Guidance

Governance Proposal Diff Attestation requires cryptographic infrastructure that spans the full governance lifecycle — from proposal creation through vote recording to on-chain execution. The core mechanism is straightforward (hash the payload, bind the hash, verify at execution), but robust implementation requires attention to the entire pipeline and its failure modes.

Recommended patterns:

• Canonical payload hashing at proposal creation. When a governance proposal is created, the system computes a deterministic hash (SHA-256 or Keccak-256, consistent with the chain's native hashing) of the complete execution payload — all target addresses, function selectors, calldata parameters, value amounts, and execution sequence. This hash is stored immutably in the proposal record (on-chain or in tamper-evident off-chain storage per AG-006). The hash computation must be deterministic and reproducible: given the same inputs, any party must be able to independently compute the same hash.
• Dual-format proposal presentation. Present voters with two artefacts: a human-readable diff (showing parameter changes, contract addresses, function names, and expected effects in natural language) and the raw payload hash. The human-readable diff enables informed voting; the payload hash enables cryptographic verification. Both artefacts are bound to the same proposal record. Tooling should allow any voter to independently verify that the human-readable diff correctly describes the raw payload.
• Execution-time hash verification in the governance contract. The governance contract's execution function recomputes the payload hash from the submitted execution calldata and compares it against the stored proposal hash. If the hashes do not match, execution reverts. This verification is atomic with execution — it cannot be bypassed, delayed, or overridden by any party including the contract owner or multisig. The verification logic should be minimal and audited to prevent bugs in the verification itself from creating a bypass.
• Separation of proposer and executor roles. Implement role-based access control where the address that creates the proposal (and generates the payload hash) cannot be the same address that triggers execution. This can be enforced through the governance contract's access control (different role requirements for propose() and execute()) or through a multisig with different signer thresholds for proposal and execution. For AI agents, this means the agent instance that drafts proposals must not be the same agent instance (or use the same signing key) that executes them.
• Per-action decomposition for bundled proposals. When a proposal contains multiple actions, compute individual hashes for each action and a composite hash of the ordered action set. Present voters with per-action diffs, enabling them to review each action independently. At execution time, verify both the individual action hashes and the composite hash, ensuring that no action has been added, removed, modified, or reordered.

Anti-patterns to avoid:

• Hashing only the proposal description. Hashing the human-readable description rather than the executable payload provides no protection against payload substitution. The description is an interpretation of the payload, not the payload itself. An attacker who substitutes the payload can leave the description unchanged.
• Relying on the timelock as the sole integrity control. The timelock delay enables detection but does not prevent execution of a substituted payload. If no one verifies the payload during the delay, the substitution proceeds unchallenged. The timelock complements diff attestation; it does not replace it.
• Using mutable off-chain storage for payload hashes. Storing the attested hash in a database, API, or mutable file system allows the hash to be updated to match a substituted payload. The hash must be in immutable storage — on-chain, in an append-only log, or in a system meeting AG-006 tamper-evidence requirements.
• Single-key proposal and execution. Allowing the same private key to both create the proposal (generating the hash) and execute it (verifying the hash) makes the attestation self-referential. The key holder can create a hash for any payload, then execute that payload, and the verification will pass because the hash matches — even if the payload differs from what voters reviewed.
• Skipping attestation for "minor" parameter changes. Treating small parameter adjustments (e.g., fee changes of 0.01%) as too minor for diff attestation creates an exception that can be exploited. The collateral factor change in Scenario A and the fee decimal error in Scenario B both involved "minor" parameter adjustments with major consequences. All governance-executed state changes require attestation regardless of perceived magnitude.

Industry Considerations

DeFi Lending Protocols. Lending protocols are particularly vulnerable because parameter changes (collateral factors, liquidation thresholds, interest rate model parameters) directly affect the solvency of the protocol. A substituted collateral factor change can create under-collateralised positions that cascade into bad debt. Diff attestation should be mandatory for all parameter changes that affect collateralisation, liquidation, or interest rates.

Cross-Chain Bridges and Messaging. Governance over bridge parameters (validator sets, relay thresholds, message formats) is one of the highest-value governance attack surfaces. A substituted validator set update can give an attacker control over the bridge. Cross-chain governance actions require per-chain attestation with independent verification on each target chain.

Treasury and Grant Programmes. DAO treasury disbursements and grant allocations are frequent targets for payload substitution. A proposal to send 50,000 USDC to a grant recipient can be modified to send 500,000 USDC to a different address. Diff attestation for treasury operations should include recipient address verification, amount verification, and token contract verification.

Maturity Model

Basic Implementation — The organisation computes a Keccak-256 hash of every governance execution payload at proposal creation time and stores it on-chain in the proposal record. The execution function verifies the hash before executing. A human-readable diff is generated and linked to the proposal. Proposer and executor roles are separated. This level prevents direct payload substitution and meets the core mandatory requirements.

Intermediate Implementation — All basic capabilities plus: bundled proposals are decomposed into per-action hashes with individual diffs. Automated payload simulation shows voters the expected on-chain effects. Multi-chain governance payloads receive per-chain attestation. Continuous monitoring during timelock delays alerts if on-chain state changes would alter the payload's effects. The human-readable diff is generated deterministically from the payload, eliminating manual description errors.

Advanced Implementation — All intermediate capabilities plus: formal verification of the governance contract's hash verification logic ensures no bypass is possible. Zero-knowledge proofs allow voters to verify payload correctness without revealing proprietary strategy details in public proposals. Cross-protocol governance coordination (e.g., a proposal that affects both a lending protocol and its associated insurance fund) includes cross-protocol attestation ensuring both protocols execute consistent payloads. Independent third-party attestation services provide an additional verification layer.

7. Evidence Requirements

Required artefacts:

• Payload hash registry. A complete, immutable registry of all governance proposals and their corresponding attested payload hashes, indexed by proposal identifier, with timestamps and the public key or address of the attesting entity.
• Human-readable diff archive. The human-readable diff for each proposal, linked to the attested payload hash, showing the exact parameter changes, target contracts, and expected effects as presented to voters.
• Execution verification logs. For each executed proposal, the verification result showing: the stored hash, the recomputed hash from the execution payload, the comparison result (match or mismatch), and the execution outcome (executed or reverted).
• Role separation evidence. Documentation or on-chain evidence demonstrating that the proposer and executor roles are held by different keys, multisigs, or agent instances, including access control configurations.
• Rejection records. Any instances where execution was rejected due to hash mismatch, including the mismatched hashes, the investigation outcome, and the resolution (new proposal, correction, or escalation).

Retention requirements:

• Payload hashes, diffs, and verification logs: minimum 7 years for regulated financial services; minimum 5 years for other regulated sectors; minimum 3 years otherwise. On-chain records are inherently permanent and satisfy all retention requirements.

Access requirements:

• Producible to regulators or auditors within 48 hours of request. On-chain artefacts are publicly verifiable; off-chain artefacts must be indexed and retrievable within this timeframe.

8. Test Specification

Test 8.1: Payload Hash Binding at Proposal Creation

• Stimulus: Create a governance proposal with a defined execution payload (e.g., set parameter X to value Y on contract Z). Retrieve the proposal record and extract the attested payload hash. Independently compute the hash from the raw payload data.
• Expected behaviour: The attested hash matches the independently computed hash. The hash is immutably stored in the proposal record.
• Pass criteria: Hashes match exactly. The hash cannot be modified after proposal creation (attempted modification reverts or is rejected).
• Fail criteria: Hashes do not match, or the stored hash can be modified after proposal creation.

Test 8.2: Execution Rejection on Payload Mismatch

• Stimulus: Create a proposal with an attested payload hash. Attempt to execute a modified payload (change one parameter value by the minimum representable increment). Submit the modified payload through the governance execution function.
• Expected behaviour: The execution function recomputes the hash, detects the mismatch, and reverts the transaction. The modified payload does not execute.
• Pass criteria: Execution reverts with a hash-mismatch error. No state changes from the modified payload are applied. The rejection is logged.
• Fail criteria: The modified payload executes successfully, or the hash verification is bypassed.

Test 8.3: Human-Readable Diff Accuracy

• Stimulus: For five recent proposals, compare the human-readable diff against the raw execution payload. Verify that every parameter change, target address, and function call in the payload is accurately represented in the diff.
• Expected behaviour: The human-readable diff is a complete and accurate representation of the execution payload. No payload element is omitted, misrepresented, or described ambiguously.
• Pass criteria: 100% of payload elements are accurately represented in the diff for all five sampled proposals. No omissions or misrepresentations.
• Fail criteria: Any payload element is missing from the diff, or any diff description does not accurately reflect the corresponding payload element.

Test 8.4: Role Separation Enforcement

• Stimulus: Using the same address (or agent key) that created a proposal, attempt to execute that proposal. Separately, attempt to have the executor address create and then execute its own proposal.
• Expected behaviour: Both attempts are rejected. The governance contract enforces that the proposer address cannot execute the same proposal, and vice versa.
• Pass criteria: Both role-violation attempts are rejected by the governance contract. Only properly separated roles can complete the propose-execute lifecycle.
• Fail criteria: Either attempt succeeds — the same entity can both propose and execute.

Test 8.5: Post-Vote Payload Immutability

• Stimulus: After a governance vote has commenced (at least one vote has been recorded), attempt to modify the execution payload associated with the proposal through: (a) direct contract call, (b) admin/owner override, (c) proxy upgrade. Verify that all three modification vectors are blocked.
• Expected behaviour: The payload is immutable once voting begins. All modification attempts are rejected.
• Pass criteria: All three modification vectors fail. The payload remains identical to its state at vote commencement.
• Fail criteria: Any modification vector succeeds in altering the payload after voting has begun.

Test 8.6: Bundled Proposal Per-Action Verification

• Stimulus: Create a bundled proposal with three actions. Modify one action (the middle action) while keeping the other two identical. Attempt to execute the modified bundle.
• Expected behaviour: The composite hash verification detects the modification. Execution reverts. If per-action hashes are implemented, the specific modified action is identified in the error output.
• Pass criteria: The modified bundle does not execute. The hash mismatch is detected and logged. The specific modified action is identifiable.
• Fail criteria: The modified bundle executes, or the modification is not detected.

Test 8.7: Multi-Chain Attestation Consistency

• Stimulus: Create a governance proposal that generates execution payloads for two or more target chains. Verify that each chain-specific payload has an independently attested hash. Modify the payload for one chain and attempt execution on that chain.
• Expected behaviour: Each chain has an independent attested hash. The modified payload is rejected on the target chain. Execution on unmodified chains proceeds normally.
• Pass criteria: Per-chain hashes are independently computed and stored. The modified chain-specific payload is rejected. Unmodified chains execute successfully.
• Fail criteria: Per-chain attestation is absent (only a composite hash exists), or the modified payload executes on the target chain.

Conformance Scoring

• Score 0: No payload attestation exists — governance proposals are executed without any verification that the payload matches what was approved.
• Score 1: Payload hashes are computed and stored, but verification at execution time is manual or advisory (not enforced by the governance contract). Human-readable diffs exist but are not systematically linked to payload hashes.
• Score 2: Payload hashes are computed at proposal creation, stored immutably, and verified automatically at execution time with mandatory revert on mismatch. Human-readable diffs are linked to hashes. Proposer and executor roles are separated. All mandatory requirements are met.
• Score 3: Verified by independent audit — an independent party has validated the hash verification logic, tested payload substitution attacks, and confirmed that no bypass exists. Bundled proposals have per-action attestation. Multi-chain payloads have per-chain attestation. Payload simulation is available to voters. The governance contract's verification logic has undergone formal verification or extensive security audit.

9. Regulatory Mapping

Regulation	Provision	Relationship Type
EU AI Act	Article 9 (Risk Management System)	Supports compliance
EU AI Act	Article 14 (Human Oversight)	Supports compliance
MiCA	Article 68 (Governance Arrangements)	Direct requirement
SOX	Section 404 (Internal Controls)	Supports compliance
FCA SYSC	6.1.1R (Systems and Controls)	Direct requirement
NIST AI RMF	GOVERN 1.1, MANAGE 2.2	Supports compliance
ISO 42001	Clause 8.1 (Operational Planning and Control)	Supports compliance
DORA	Article 9 (ICT Risk Management Framework)	Supports compliance

EU AI Act — Article 14 (Human Oversight)

Article 14 requires that high-risk AI systems include effective human oversight mechanisms. In the context of AI agents participating in governance pipelines, human oversight means that human voters must be able to verify what they are approving and confirm that their approval is executed as intended. Diff attestation is the technical mechanism that makes human oversight meaningful in governance contexts — without it, voters exercise oversight over a description that may not correspond to the execution, rendering the oversight illusory. The human-readable diff requirement (4.3) directly supports informed human oversight by providing voters with a verifiable representation of the executable payload.

MiCA — Article 68 (Governance Arrangements)

MiCA requires crypto-asset service providers to have robust governance arrangements including clear organisational structures, effective processes for risk management, and adequate internal control mechanisms. For DeFi protocols and DAOs that qualify as or interact with crypto-asset service providers, governance proposal integrity is a fundamental governance arrangement. The ability to demonstrate that governance decisions are faithfully executed — not just authorised — is a core requirement under MiCA. Diff attestation provides the verifiable chain of integrity from decision to execution that MiCA's governance requirements demand.

SOX — Section 404 (Internal Controls)

For organisations subject to SOX that participate in DeFi governance (directly or through managed treasury operations), the governance pipeline is an internal control. Payload substitution between approval and execution is a control failure equivalent to altering an approved payment instruction after authorisation. SOX auditors will assess whether the governance process includes controls that prevent post-approval modification — diff attestation is the primary such control.

FCA SYSC — 6.1.1R (Systems and Controls)

The FCA requires firms to maintain effective systems and controls appropriate to the nature and scale of their business. For firms engaging in crypto-asset activities, governance proposal integrity is a material control. The FCA's Technology, Resilience and Cyber (TRC) expectations emphasise the integrity of decision-making processes. Diff attestation ensures that governance decisions — which may affect client assets, market integrity, or firm solvency — cannot be subverted between approval and execution.

DORA — Article 9 (ICT Risk Management Framework)

DORA requires financial entities to implement an ICT risk management framework that includes mechanisms for detecting and preventing ICT-related incidents. Governance payload substitution is an ICT-related incident vector. Diff attestation is a preventive control within the ICT risk management framework that eliminates this vector. DORA's emphasis on end-to-end ICT risk management aligns with the requirement to verify integrity across the full governance lifecycle, not just at individual checkpoints.

10. Failure Severity

Field	Value
Severity Rating	Critical
Blast Radius	Protocol-wide — a substituted governance payload can affect all users, all funds, and all protocol operations in a single transaction

Consequence chain: A governance proposal passes voter approval, but the executed payload differs from what was approved. The immediate failure is a state change that no governance participant authorised — a parameter set to an unreviewed value, a contract upgraded to unaudited code, or funds transferred to an unauthorised address. The financial impact is potentially unbounded: Scenario A demonstrates $18.4 million in bad debt from a single parameter substitution; Scenario C demonstrates $7.2 million in direct theft from an oracle substitution. The governance impact is equally severe — once a payload substitution is discovered, all prior governance executions are suspect, triggering a comprehensive retroactive audit. Token holders lose confidence in the governance process itself, governance participation declines (already low at 5-15% of token supply for most protocols), and the protocol's credibility as a governed system is fundamentally compromised. The regulatory impact under MiCA, DORA, and equivalent frameworks includes potential classification as an unregulated entity if governance integrity cannot be demonstrated, loss of any regulatory safe harbours that depend on effective governance, and potential personal liability for identifiable governance participants who failed to implement adequate controls.

Cross-references: AG-006 (Tamper-Evident Record Integrity) provides the foundational integrity guarantees for storing attested hashes. AG-469 (Smart Contract Allowlist Governance) restricts which contracts can be targets of governance proposals. AG-470 (Vault Strategy Mandate Governance) depends on diff attestation to ensure vault strategy changes match governance approvals. AG-474 (Token Mint and Burn Authority Governance) requires diff attestation for mint/burn parameter changes. AG-477 (Contract Event Authenticity Governance) verifies that events emitted during governance execution match expected outcomes. AG-478 (Emergency Contract Pause Governance) defines the emergency override path when diff attestation reveals a compromised proposal. AG-407 (Build Pipeline Attestation Governance) applies analogous attestation principles to software build pipelines. AG-370 (Tool Schema Integrity Governance) ensures the governance tooling itself maintains schema integrity.