Ethereum has a new proposal in development that would change how smart contracts function after deployment. The standard, called ERC1538 or the Transparent Contract Standard, comes from Nick Mudge. I
Ethereum has a new proposal in development that would change how smart contracts function after deployment.
The standard, called ERC1538 or the Transparent Contract Standard, comes from Nick Mudge. It addresses a fundamental constraint that has limited smart contract development since the beginning: immutability.
Smart contracts represent the potential next phase of commerce and business automation. They could eliminate countless intermediaries in supply chains. They could underpin self-operating businesses that require no human staff. The possibilities extend into uncertain territory. When artificial intelligence reaches a point of genuine consciousness, smart contracts may become the medium through which humans interact with it. Before that science fiction becomes reality, the current limitations of smart contracts will constrain what the technology can do.
The core issue stems from a programming principle that has existed for decades: "It's not a bug, it's a feature." Smart contracts work better when locked in place. The unchanging code provides security and certainty. Both parties know the deal cannot be altered. No one can make surprise modifications behind the scenes. This intentional design is valuable.
Yet circumstances change. Technologies improve. Regulatory environments shift. Economic conditions make an original agreement no longer profitable. A company facing legal pressure might discover its contract violates new requirements. The Ethereum ecosystem itself is constantly evolving. These realities create demand for a way to update deployed contracts.
ERC1538 proposes a solution. Unlike ERC721 and ERC20, which define new token types, ERC1538 operates as a standard that builds onto existing standards. It enables newly deployed contracts to be modified in a transparent, auditable way. It also permits the creation of much larger contracts, sidestepping the current 24-kilobyte maximum.
The technical approach differs from other proposals for upgradable contracts. Previous attempts typically involve creating a new contract at a new address and forwarding all transactions there. ERC1538 works differently. Different aspects of the contract can operate from different addresses and execute at the same time. This prevents any one piece from becoming a bottleneck. The architecture reduces complexity and avoids the need to redeploy an entire system when only a piece requires change. Instead of throwing out a complete contract, developers modify or replace the specific component that needs updating.
Mudge applies the standard in his Mokens project, which lets users design and mint their own non-fungible tokens. He explained the practical value: "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 Mokens approach exemplifies the real-world problem ERC1538 solves. A startup building on blockchain often begins small. The initial contract reflects the current needs. But as the user base grows and the business evolves, the original code becomes limiting. New features are needed. Scaling requires optimization. Market feedback demands changes. With ERC1538, these adaptations happen without abandoning the existing contract or asking users to migrate to a new one.
Transparency matters especially when modifications can occur. The blockchain stores every change in an immutable record. This creates a documented change history that all participants can verify. Ethereum block explorers would present these records in human-readable form rather than code. Developers could add explanatory comments. The ledger maintains a permanent audit trail of when and how the contract changed.
The blockchain economy operates in an often faceless manner. Parties transact without seeing each other. Sometimes no human sits on one side at all. Under these conditions, people can only trust what they can verify. Contract terms must be open for inspection and audit. When changes happen, their timing and nature must be transparent. The blockchain provides exactly this capability. It enables the kind of verifiable record that participants need when trust cannot be built through personal relationships.
ERC1538 includes another feature: developers can disable upgradability once a contract reaches completion. Once switched off, the contract becomes immutable again, locking in its final form. This option addresses a real problem that occurred when ERC721 was first released. Developers wanted to build with the standard, but the specification was still under active development. The standard kept changing. Building on an incomplete standard carried risk. If ERC1538 had existed, developers could have deployed mutable contracts initially and later made them permanent once the specification stabilized and was finalized.
Whether a contract should be upgradable or immutable depends on its purpose and lifecycle. Some contracts are designed to serve temporary purposes and should eventually lock. Others manage ongoing relationships that require adjustment over time. ERC1538 lets developers choose the right approach for their specific needs. They can launch in a fluid state and graduate to immutability, or maintain the option to adjust as long as needed.
The proposal is not yet established as a standard. Other options exist in the space. OpenZeppelin and similar projects offer competing approaches to the problem of upgradable contracts. Mudge indicated he hopes to work with these other teams in the future. Whether ERC1538 gains adoption remains to be seen. But it addresses a genuine friction point in smart contract development, where the need for permanence must somehow coexist with the practical need for change.
