ERC1538: Future Proofing Smart Contracts and Tokens

A new Ethereum Standard has been proposed. While I rarely cover still developing tech, ERC1538 is an interesting one worth bringing up.

Smart contracts are the current and next big thing in cryptocurrencies. They could change the way we do business. They could eliminate countless middle men in supply chains. They could create entirely new businesses that don’t even have to be manned. When a conscious AI finally emerges, it will likely kill us all, but before that happens we will likely interact with it through smart contracts.

But smart contracts are currently limited in their flexibility. Once one is created, it is set in stone. That, of course, goes back to the old programming trope, “it’s not a bug, it’s a feature!” and in this case that is true. Most smart contracts are meant to be locked in stone. The idea being that the terms of the deal can’t be changed and therefore everyone goes in with open eyes and knows exactly what to expect.

That can be frustrating though. The world is changing all of the time, the crypto world especially. And there are times when updating a contract is necessary. The technology could be updated. The political or economic situation could make the original contract unprofitable. A company who wishes to stay in compliance could have been told by authorities that their first contract was illegal.

Whatever the case, there are plenty of reasons one might want to change a smart contract once its been deployed and ERC1538 “Transparent Contract Standard” is designed to do just that. Unlike ERC721 and ERC20, ERC1538 isn’t an entirely new set of tokens. Rather it is a standard to add to current standards like ERC20 and ERC721 that will enable newly deployed contracts to be transparently modified. It also allows for much larger contracts to be written, which is likely just as significant.

In short: ERC1538 futureproofs all smart contracts and tokens.

I spoke to Nick Mudge, the creator of the proposal. He explained how ERC1538 can futureproof smart contracts and tokens going forward.

“I have a project called the Mokens project. That allows people to design and mint their own non-fungible tokens. It uses the Mokens contract which has implemented ERC1538. Having this upgradable function allows me to add more features and add more things over time. For projects that start small and want to grow, this upgradeable contract standard is good for that.”

The importance of transparency to smart contracts, especially modifiable ones, can’t be understated. So much of the blockchain economy and the digital world in general, is done in a faceless way. We can’t judge the person on the other end and in many cases, there might not even be a person. So we have to be sure what we are dealing with. Contract details have to be open for everyone to see and audit and when changes happen we need to see exactly when, where and hopefully why the changes took place.

Thanks to the glorious power of the blockchain, we can do just that. Every change made to an ERC1538 contract will be committed and visible for everyone involved. Sort of a verifiable changelog. While it currently looks like opaque codespeak, it would not be difficult for any Ethereum block explorer to pull that data and present it in a way that is easy to understand. Developers can always add comments to explain the changes in simple terms.

I’m not a coder, so I probably shouldn’t try to explain how it works with any authority, but I’m going to try anyway. Every proposal for upgradable contracts has to do with making a new contract at a new address and essentially forwarding everything from there. But ERC1538 is unique in that different aspects of the contract can be dolled out to different addresses and still have them execute at the same time. This eliminates the 24KB max size of smart contracts and makes future adjustments that much easier. You don’t have to throw out the whole contract, just the part you need to be changed.

You can also turn off the mutability. Making it so once a contract is “finished” it can’t be changed again. This would have been helpful when ERC721 first burst onto the scene. People wanted to develop using it, but it was still under construction. Had ERC1538 been around, they could have implemented it and then upgraded when it was finished. That is an example of a time when a developer might want to first have mutable contracts and then later switch to an immutable one.

ERC1538 is still a ways off from being a popular standard. But it is an exciting development. There are other option, there always is in crypto, but this one intrigued me. Mudge is aware of the other projects, like OpenZeppelin and hopes to work with them in the future.

We will monitor ERC1538 and see if it gets any traction going forward. In the meantime, you can check out its git here.