On March 14, the European Parliament voted in favor of new data controls to be included in a larger bill designed to address data privacy without stifling innovation. A new clause in the bill known as the Data Act requires all smart contracts to include a “kill switch.”
In the IT world, administrators commonly use the kill switch mechanism to shut off a device, network or software in the event of a security threat. In a smart contract setting, a kill switch can either destroy the contract or deploy a halt, patch and re-release of the contract in the case of a major bug or breach.
Shahar Shamai is the chief technology officer and co-founder of GK8, a crypto self-custody platform.
While the intention of the regulators was to give people more protection over their own personal information, the act has generated concerns in the Web3 community. Some fear a kill switch mandate would curb the decentralization of smart contracts by giving one person or a group of people the power to shut down operations.
Others claim that this kill switch provision will lead to inevitable security flaws.
Some people might remember an incident that occurred in August when decentralized exchange (DEX) OptiFi accidentally activated a kill switch to its mainnet, leading to it permanently being shut down, and losing $661,000 worth of USDC stablecoin tokens. While this kill switch was not used in a smart contract setting, it does shed light on the risks that classic kill switches create for crypto-related businesses and projects.
Many smart contracts can and do store value rather than merely representing ownership of assets located elsewhere. As such, activating a kill switch that in effect destroys the smart contract would essentially wipe out all the value being held, and shouldn’t be used. What’s the point of protecting consumers with a kill switch if you lose all the value stored in the smart contract?
I also share the concern about safeguarding decentralization, mostly because decentralization is a crucial safeguard of the communities’ assets. We have all witnessed cybercriminals zeroing in on points of centralization for hacking purposes, because these points of centralization give them access to more assets in one fell swoop.
Still, it’s important to keep a few things in mind. First of all, some smart contracts already include some form of a kill switch and many users probably don’t even know it. Secondly, there are clear advantages to deploying such functionality to a smart contract, especially considering there are ways to minimize centralization while maximizing security.
A kill switch’s form, application and function may vary drastically depending on the industry and business, or even the type of device. For blockchain-based businesses, projects and protocols operating within EU territory, perhaps the most important place to start is what kind of smart contract kill switches make the most sense for users and regulators.
The term “kill switch” immediately brings to mind a self-destruct button. But the language of the data act is currently vague. Instead of a self-destruct button, one could consider the alternative of a pause function. The pause functionality, as opposed to a classic kill switch, won’t completely wipe out the smart contract (and its value) because it can be unpaused.
For example, if a smart contract is compromised, the contract administrator can apply the pause functionality, which essentially freezes the smart contract. After the situation is rectified and stabilized, the unpause functionality can be activated and resume the smart contract.
The pause functionality is not uncommon in the blockchain and crypto space. Tether, the maker of leading stablecoin USDT, also uses the pause function, as seen in the smart contract’s code on Etherscan.
When compared with a classic kill switch mechanism, the pause functionality represents a better fail-safe. Not only does it protect the network if caught on time, it also salvages the contract – and its funds – by enabling it to resume operations.
To pause the smart contract, code admins need to use the system’s private key. Once a private key is used online, however, it becomes vulnerable to cyber attack. In theory, access to this private key could give hackers admin privileges to the entire contract and has grave implications on the immutability of smart contracts.
So how can smart contract admins deploy a pause functionality without endangering the security of the entire smart contract?
The answer is surprisingly simple: Use different keys. One that enables the pause functionality and another that enables the unpause functionality. For added security, store these different keys in an offline manner. Separating the pause and unpause keys and storing both in a truly offline manner strengthens the security of the smart contract and eliminates potential points of failure.
This method still raises questions about centralization in crypto apps. Achieving complete decentralization may not be possible under the best circumstances, and will be made even more difficult under EU rules.
However, the problems of centralized control of mandated kill switches can be greatly reduced through the utilization of a multisignature approval protocol. In this scenario, emergency powers to flick the pause switch could be granted for immediate action (such as in the case of a hack or a glitch). The unpause switch may require a quorum approval.
This group of trusted parties or community members, given the authority to activate the unpause function, would ensure that no single individual or entity has complete control over a smart contract.
Another best practice is to change the admin keys once a kill switch is used or reversed, because the moment they are used they go online and therefore become vulnerable to cyberattacks.
The EU’s data privacy, tech and crypto regulatory frameworks have so far proven to be quite transparent and forward-looking, and with time, the scope of this new “kill switch clause” will become apparent. In the meantime, smart-contract developers would be wise to do their due diligence regarding deploying the pause functionality.
By utilizing the pause method, separating the keys and establishing a multi-signature approval of the unpause button, smart contracts wouldn’t have to self-destruct in the event of a security breach, while also enjoying greater security and limited centralization.
