Distributed Ledger Technologies (DLTs) commonly have simple and inflexible forms of immutability. Hedera supports a more flexible form of controlled mutability, which allows certain changes under certain circumstances, but prevents other types of changes. One area where this is particularly important is for smart contracts.

In 1996, Nick Szabo, the cryptographer known for his research on digital currency, published in the magazine Extropy an article, “Smart Contracts,” in which he predicted many of the characteristics of distributed ledger applications. Szabo forecast that a DLT could be used to supervise the execution of computer code stored and replicated on the nodes of the DLT. Rather than a software program running on a single computer, it would run on all the nodes, creating transparency and decentralization. The first generation of DLTs only supported cryptocurrency, but the second generation added the ability to run smart contracts. Each smart contract would encode rules for performing operations such as the movement of digital currencies or assets between parties under certain conditions.

Smart contracts promise to automate the exchange of money and other value, securely and with little friction. But they are ultimately just software programs, and so face the same challenges as all other software — including bugs, design flaws, and even their behavior in unanticipated situations. The normal development process for software, that of iterative refinement and improvement, acknowledges that the first version of a program is never perfect — there will be flaws. No human can write perfect code or anticipate every situation.

However, in most implementations, the smart contracts are immutable. Once deployed, a smart contract can not be edited, either to fix a glaring bug that becomes apparent, or to refine the functionality and add a new feature. If the developer wants to make any such changes to the smart contract, their only option is to deploy a new version, and then endeavour to transfer token balances or other state from the old to the new. If another bug is discovered, they must repeat the process.

Beyond simply fixing software bugs, immutability is hard to reconcile with the reality of changing technologies, regulations, and circumstances. As a concrete example, in 2016, hackers took advantage of flaws in the Distributed Autonomous Organization (The DAO) Ethereum smart contract to take millions of dollars. It was the Ethereum community’s inability to decide how to deal with these funds that led to the Ethereum Classic fork. Those Ethereum community members who strongly believed in the ‘code is law’ mantra argued that to give back the DAO funds would be to violate the fundamental value proposition of blockchain immutability — and so opted to fork the chain to maintain that guarantee.

To better reflect the dynamic nature of software development and business, Hedera offers an optional mechanism that enables a model of “binding arbitration” for smart contracts. Specifically, a Hedera smart contract is immutable (in the same sense as other DLTs), unless several parties (designated by the smart contract developer) agree that it should change.

On Hedera, when a developer deploys a smart contract (i.e., submits a transaction to the network with the compiled bytecode), they have a choice to make on the contract’s subsequent mutability. The default choice is that it will have the same guarantee of immutability as on other DLT’s, specifically that it will forever be impossible for anyone to change its programming code. With this choice, “the code is law” and that law won’t change.

The other choice is for the developer to deploy the smart contract with a list of public keys of arbitrators. In that case, the arbitrators have the authorization to subsequently edit the contract code, and so to fix bugs or add features or reverse specific transactions. Once a contract’s bytecode is deployed with such a stipulation, if the designated arbitrators subsequently agree that the contract should change, then a transaction with the new contract bytecode, signed by the keys of those arbitrators, will be approved by the network, and the change will be implemented — the arbitrator’s decision is binding.

It is common in some countries for legal contracts to include a clause that says disputes will be resolved by binding arbitration instead of by the (more expensive & time-consuming) court system. In that case, the parties must present their case to one or more arbitrators, who form a tribunal, and who then have the power to reach a decision that is legally binding for the parties involved.

The same can be done for smart contracts. For example, a developer could set up a contract to require agreement from 8 out of 10 members of the dev team before the bytecode can be updated. More complex rules are possible — for example, saying the agreement must be by BOTH the president, AND either a majority of the house OR a majority of the senate. It would even be possible to use actual arbitrators who professionally provide binding arbitration for legal contracts. There may even arise a whole new industry of binding arbitration professionals who specialize in smart contracts.

This mechanism is completely transparent. Anyone can see whether a given smart contract allows binding arbitration or not, and so whether the contract is mutable. Anyone can see which public keys have that ability, and the rules for the decision making. And anyone monitoring the transactions flowing through the ledger, will see when a smart contract is modified.

Smart contracts need the same sort of flexibility as found in legal contracts. This ability to edit smart contracts through a transparent arbitration model is absolutely vital to the long-term success of a public smart contract platform.

At Hedera, we support the immutable “code is law” model, for any developer of a smart contract that believes it is appropriate. But we also support a more flexibly mutable binding- arbitration model, which we believe will become more necessary and common as distributed ledgers begin to be used for more complex, real-world applications.