Blockchain-based smart contracts are immutable once deployed: the code, not a court or administrator, determines on-chain outcomes. Legal systems, however, require that erroneous, void, or unlawful transactions be correctable or reversible. A 2020 survey by Drummer and Neumann identified the lack of contract mutability and the inability to reverse void contracts among the principal causes of slow smart-contract adoption, proposed neutralizable or blockchain-editable contracts as remedies, and flagged the resulting tension between controlled mutability and decentralization as unresolved. Later work has made the engineering of mutability routine (proxy-based upgradeable contracts, timelocks, pause mechanisms, redactable blockchains in permissioned settings) and has quantified its costs: upgrade mechanisms introduce security vulnerabilities, and the governance processes that would exercise emergency powers are themselves centralized and capturable. No validated legal-technical-governance design reconciles emergency neutralization with decentralization; recent regulatory instruments such as the EU Data Act now make the question urgent rather than academic.

Background

A smart contract is a program stored on a blockchain that automatically executes agreed transactions when its conditions are met; on Ethereum the most widely used platform, deployed code runs on the Ethereum Virtual Machine (EVM) and cannot be altered after deployment. This immutability is deliberate: it removes any trusted operator who could unilaterally rewrite the deal. In the 'code is law' view, the deployed code is the final arbiter of what the parties agreed to. The legal world presumes the opposite: contracts concluded by mistake, in breach of consumer-protection rules, or for unlawful purposes can be voided, rescinded, or reversed by courts, and payment systems can be halted in emergencies. Drummer and Neumann (2020), combining a structured literature synthesis with 30 expert interviews, located a key cause of slow smart-contract adoption precisely in this mismatch: among twenty catalogued shortcomings they list the inability to reverse void contracts (a6) and the lack of contract mutability (b7), and propose as remedies 'blockchain-editing or neutralizable contracts' — while noting that every such remedy carries the tradeoff of centralizing authority versus decentralization. The historical precedent is the 2016 exploit of The DAO (a decentralized investment fund built as a smart contract), where the Ethereum community reversed the theft only by a contested hard fork (a permanent change to the protocol's rules that split the network into two separate chains).

The engineering landscape since then has three strands. First, upgradeable smart contracts: the standard proxy pattern keeps a stable address that delegates execution to a replaceable implementation contract, so maintainers can patch or upgrade logic after deployment; large empirical studies of Ethereum (Liu et al. 2024; Li et al. 2024; Qasse et al. 2024) show these are widespread but introduce storage collisions, breaking changes, and hijackable upgrade paths. Second, redactable blockchains: cryptographic constructions, mostly built on chameleon hashes (hash functions whose holders of a secret trapdoor key can find collisions), permit controlled and auditable edits to stored data — but overwhelmingly in permissioned or private settings (Calandra et al. 2025). Third, on-chain governance: decentralized autonomous organizations (DAOs) — entities whose rules are encoded in smart contracts and changed by token-weighted voting — can in principle authorize emergency actions, typically mediated by timelocks (enforced delays between a vote and its execution) or guardian keys that can pause a protocol. This governance layer is itself fragile: Gudgeon et al. (2020) demonstrated flash-loan-driven governance attacks (borrowing voting power momentarily to seize control of a protocol), Barbereau et al. (2022) measured that voting rights in major decentralized-finance (DeFi) protocols are highly concentrated, and Pahari et al. (2026) documented trust and transparency tradeoffs in the governance contracts of 48 Ethereum DAOs. In parallel, regulation has moved from debate to obligation: the EU Data Act imposes essential requirements on smart contracts for data sharing, including safe termination and interruption — a de facto 'kill switch' mandate — and Seneviratne (2024) surveyed how termination mechanisms across nine major platforms do and do not satisfy such requirements, concluding that designing neutralization mechanisms compatible with the decentralized ethos remains the open challenge.

Problem Statement

The unresolved question from Drummer and Neumann (2020), still open per the later literature: can deployed smart contracts be made safely mutable — permitting controlled modification, emergency neutralization (halting), and reversal of erroneous, void, or unlawful outcomes — without reintroducing the centralized, trusted control that blockchain execution was designed to eliminate? A coherent legal-technical-governance design that makes deployed contracts safely mutable and neutralizable must specify: (i) the mechanism — who may trigger mutation, neutralization, or reversal, under what legal basis and technical constraints (e.g., quorum voting, timelocks, guardian keys, policy-controlled redaction), with what checks, delays, appeal paths, and accountability; (ii) demonstrated security and decentralization properties of that mechanism against the documented attack models — admin-key compromise, governance capture, and flash-loan-driven voting — so that emergency powers are bounded, transparent, and cannot be exercised unilaterally outside the specified procedure; and (iii) the design's compatibility with existing legal requirements for correcting void or mistaken contracts and protecting consumers, illustrated by obligations of the type the EU Data Act now imposes (safe termination and interruption); since such requirements differ across jurisdictions and instruments, compatibility is assessed for the legal regime(s) the design specifies. The problem includes establishing whether such a reconciliation is achievable at all at acceptable cost, or whether the mutability–decentralization tension is fundamental. Because 'safely mutable', 'preserved decentralization', 'bounded' and 'transparent' emergency powers, and 'acceptable cost' are not fixed by any established metric, resolving the question in either direction requires definite criteria for these properties, applied consistently throughout, whether the argument is for or against achievability; the criteria may draw on the indicators documented in this statement (voting-rights distribution, key and threshold structure, timelock bounds, public auditability of interventions) but are not limited to them. A negative resolution establishes, for fixed criteria, that no mechanism meeting those criteria can reconcile neutralization with decentralization — ruling out designs that meet the criteria rather than merely asserting centralization or capture risk; criteria chosen so that no candidate design could satisfy them do not settle the question. Any blockchain platform, model class, or answer form may be used.

References

  1. Drummer, Daniel; Neumann, Dirk (2020). 'Is code law? Current legal and technical adoption issues and remedies for blockchain-enabled smart contracts.' Journal of Information Technology 35(4): 337–360. DOI: 10.1177/0268396220924669. https://doi.org/10.1177/0268396220924669
  2. Seneviratne, Oshani (2024). 'The Feasibility of a Smart Contract "Kill Switch".' arXiv:2407.10302. https://arxiv.org/abs/2407.10302 (published version: 2024 6th International Conference on Blockchain Computing and Applications, DOI: 10.1109/BCCA62388.2024.10844477)
  3. Liu, Ye; Li, Shuo; Wu, Xiuheng; Li, Yi; Chen, Zhiyang; Lo, David (2024). 'Demystifying the Characteristics for Smart Contract Upgrades.' arXiv:2406.05712. https://arxiv.org/abs/2406.05712
  4. Li, Xiaofan; Yang, Jin; Chen, Jiaqi; Tang, Yuzhe; Gao, Xing (2024). 'Characterizing Ethereum Upgradable Smart Contracts and Their Security Implications.' arXiv:2403.01290. https://arxiv.org/abs/2403.01290 (published in Proceedings of the ACM Web Conference 2024, DOI: 10.1145/3589334.3645640)
  5. Qasse, Ilham; Hamdaqa, Mohammad; Jónsson, Björn Þór (2024). 'Immutable in Principle, Upgradeable by Design: Exploratory Study of Smart Contract Upgradeability.' arXiv:2407.01493. https://arxiv.org/abs/2407.01493
  6. Calandra, Federico; Bernardo, Marco; Esposito, Andrea; Fabris, Francesco (2025). 'Redactable Blockchains: An Overview.' arXiv:2508.08898. https://arxiv.org/abs/2508.08898
  7. Gudgeon, Lewis; Perez, Daniel; Harz, Dominik; Livshits, Benjamin; Gervais, Arthur (2020). 'The Decentralized Financial Crisis.' arXiv:2002.08099. https://arxiv.org/abs/2002.08099
  8. Barbereau, Tom; Smethurst, Reilly; Papageorgiou, Orestis; Rieger, Alexander; Fridgen, Gilbert (2022). 'DeFi, Not So Decentralized: The Measured Distribution of Voting Rights.' Proceedings of the 55th Hawaii International Conference on System Sciences. DOI: 10.24251/hicss.2022.734. https://doi.org/10.24251/hicss.2022.734
  9. Pahari, Vabuk; Chandrasekaran, Balakrishnan; Messias, Johnnatan; Gummadi, Krishna P.; Dash, Abhisek (2026). 'On Exercising Governance Power in Decentralized Autonomous Organizations.' arXiv:2607.26204. https://arxiv.org/abs/2607.26204
  10. Kwon, Soonhong; Son, Wooyoung; Lee, Jong-Hyouk (2024). 'Smart Contract Kill Switch for Security in a Private Blockchain-based Software Transaction System.' 2024 IEEE International Workshop on Information Forensics and Security (WIFS). DOI: 10.1109/WIFS61860.2024.10810726. https://doi.org/10.1109/WIFS61860.2024.10810726