In our recent guide on smart contract versioning, we explored how smart contracts can be versioned and suggested a few ideas on how to integrate contract versioning in your existing deployment pipelines. This post is a sequel explaining how similar ideas can be applied when you have upgradeable contracts.
In software engineering, versioning is a core tenet of release management. However, when smart contracts are deployed to Ethereum networks, the deployment artifacts live as 42-character hexadecimal strings, with no onchain versioning information being captured about them.
Foundry is one of the most popular toolchains for Ethereum smart contract development. Built in Rust, Foundry provides everything needed to build, test, and deploy smart contracts. At the center of this workflow is Forge, Foundry’s scripting and deployment tool. Forge scripts are written in Solidity itself, allowing developers to deploy contracts and interact with them.
Last week, we announced the hardhat-enscribe plugin for smart contract developers to name their contracts. We showed how smart contract developers can name their contracts with hardhat:
Under the hood, the hardhat-enscribe plugin uses the same @enscribe/enscribe library. It is a small TypeScript library you can use in any app or tool.
Adding support for contract naming into dev workflows has always been our top priority. Hardhat is a leading Ethereum developer environment. It’s TypeScript-first, fast, and built around a clean plugin architecture. Hence, it’s the perfect tool for contract management like deployment, testing, etc. We are excited to announce a plugin for the popular Hardhat ecosystem that adds contract naming to it.
Foundry and Alloy are foundational tools in the smart contract development stack, and we want smart contract naming to be integrated into all core developer workflows.
Foundry is referred to as the smart contract development toolchain while Alloy, used by Foundry as a dependency, provides a range of functionality for interfacing with any Ethereum-based blockchain.
Ethereum contracts are powerful — but to most users, they’re still just anonymous strings of hex. With Enscribe, we’re changing that. Today, we’re adding support for ReverseClaimable and ReverseSetter contracts, making it easier than ever to give your smart contracts a name that users and apps can actually recognise.
Deploying smart contracts with constructor arguments just got a whole lot easier with Enscribe.
Previously, if your contract required constructor arguments, Enscribe expected you to manually encode those arguments, append them to your compiled bytecode using external tools like Remix or Hardhat, and then paste that full bytecode into the UI. This approach was complex, error-prone, and completely unintuitive — especially for contracts with more than a simple string or uint.