Dealing with Ethereum’s Code Immutability to develop Security Tokens

By design smart contracts are immutable on the Ethereum blockchain. It’s part of the deal between the Ethereum network, its developers and users. Immutability is the cornerstone of decentralized systems: rules are transparent, known in advance and no central entity has the power to change them. However, immutability creates material security and operational challenges. It leaves no room for mistakes. As a harsh reminder, there are 500,000 frozen Ether on smart contracts following the Parity multisig disaster, when a hacker took advantage of a smart contract vulnerability. There is no solution for recovering the Ether, except forking Ethereum, and this is certainly not on the table.

With immutability, high standards for code and quality assurance are not only a good strategy, they are an absolute must. For the entity deploying the smart contract, it means additional costs as the final code needs to go through extensive and expensive audits. And because smart contracts can be extremely complex, one can never be completely sure that no vulnerability slept through. Another source of insecurity is that immutability increases the need for product teams to figure out up-front the different situations that the system will face. A project that issued in 2017 a token which turned out to be a security in 2018 without anticipating the change must be in a devilishly complicated situation today.

Code immutability is a wonderful concept, but it comes at a steep cost and is only truly useful for decentralized applications. Financial securities are by design centralized instruments. They are typically issued by a single legal ‘off-chain’ entity, and their value mostly lies in having such entity fulfilling its commitments. Also, securities are impacted by an ever-changing regulatory environment, to which issuing companies will continuously need to adapt. We don’t know for sure the rules that will apply to the exchange or the selling of financial securities in the future. No one does. Compared with a cryptocurrency, a Security Token is a much more complex instrument. It can take different forms and grants different rights to different parties. For example, an equity token grants dividend and governance rights. A debt token must receive payments according to a pre-defined schedule and has liquidation preferences in case of bankruptcy. Security token transactions must be monitored and possibly restricted, depending on the place of residence of the transacting parties. It is impossible to anticipate all rules and carve them into stone once for all.

So in the context of a Security Token, code immutability creates little to no value, and upgradeability is a desirable feature. Changes in regulation or bug fixes are not the only reasons for this. If a smart contract is part of the technical architecture of a product or service, immutability can be a restriction because products and services also evolve to propose new capabilities to users. The way exchanges operate, or investors are whitelisted, might be different in a few years from what it is today.

Fortunately, there are solutions to deal with Ethereum’s smart contract immutability. The first obvious option, which we’ll call the reactive option, is the smart contract fork. Forking the contract involves reworking the contract code, and of course go once again through extensive testing, quality assurance and audit. The new version of the smart contract must then be deployed at a new address. The state data needs to be migrated to this new address, which is a tricky operation. It involves accessing the legacy contract event logs and feeding the new contract state, potentially paying a tremendous amount of gas depending on the number of token holders. If the smart contract holds an Ether balance, it might be impossible to recover, unless the fork was anticipated, for instance with a selfdestruct sending the Ether to the owner. Crucially, the issuers need to ensure that users and third parties such as exchanges take the new address into consideration. This is obviously all cumbersome and expensive.

The second option, which we’ll call the proactive one, is up-front design. There have been lots of discussions in the recent months around Upgradeable design patterns. There are also a number of EIPs draft ideas related to this matter: EIP644, ERC1214, EIP-897 to name a few examples.

For instance, the smart contract could be embedded into a Proxy design pattern. Using this design pattern, transactions from the off-chain world are sent to a specific contract, called a proxy contract. The proxy contract holds the storage but redirects the function calls to implementation contracts, using the solidity low-level delegatecall function. There is always one unique active implementation contract at one point in time. Upgrading the contract simply involves deploying a new implementation contract, which becomes the current active implementation. Of course, for the design pattern to work, the Proxy and the implementation contracts need compatible storage structures.

So upgradable patterns bring some flexibility which is welcome for the use of smart contract in a business context. At the same time, all past and current rules remain publicly available by looking at the history of implementation contracts. The Zeppelinos project recently published a new framework that allows a seamless use of this pattern, which is well documented and appears relatively easy to implement.

To summarize, in the context of a Security token, smart contract immutability is not desirable and there are design options to build flexible smart contracts. The power of blockchain for securities management resides in an increased operational efficiency, which itself requires to be able to regularly update the blockchain code. In the future, and thanks to Security Tokens, the processes around the emission, payment and exchange of securities will be streamlined and disintermediated. All historical data about transactions and shareholder balances will be available publicly and unforged thanks to cryptography. And a new horizon with an increased liquidity is shaping for illiquid private shares or assets.