I have a smart contract which I might want to modify in future. Should I use self-destruct to destruct that contract and then deploy a new one? Or, should I make that contract upgradable to make changes in future? Which one is most feasible solution in terms of cost and other factors?

  • Self-destruct will remove the contract and you have to deploy a new contract and your users have to know the new address. You can write an upgradable smart contract that will route calls to the new contract without creating any problems to users. It all up to what exactly your requirement. Implementing self-destruct is much easier as compared to writing upgradable smart contracts. Jan 31, 2018 at 10:39

4 Answers 4


The cost is theoretically the same. It's really up to your own preference if you want the old contract to continue existing or not.

One benefit to using an upgrade-able contract is that it can store a reference to the new contract which could make it easier for someone to find the newer contract.

One downside to using an upgrade-able contract is that people may continue trying to use the old contract (which you may or may not have disabled functionality for) and that could be quite frustrating as a user.

  • You can keep the old contract running and delegate the calls to the new contract
    – sea212
    Feb 29, 2020 at 13:41

This is how the contract updation would work if you used selfdestruct:

  • Deploy a new version of the contract.

  • Manually migrate all state from the old one contract to the new one (which can be very expensive in terms of gas fees!)

  • Update all contracts that interacted with the old contract to use the address of the new one

  • Reach out to all your users and convince them to start using the new deployment (and handle both contracts being used simultaneously, as users are slow to migrate)

  • selfdestruct the old contract.

But if you use upgradable contracts, you can upgrade your contracts, keeping(preserving) the contract state (storage & balance) while keeping the same contract address.

So, in this sense, I think using selfdestruct approach WILL COST YOU MUCH MORE than using upgradable contracts.

In case you would like to know how upgradable contracts work, and how you can wtite one easily, you can check out this post on smart contract versioning.


selfdestruct will remove all storage from the state, which isn't ideal if you might ever need it in future.

Upgradeable contracts can be established with a version flag and a pointer to the address of any new contracts after they are deprecated - you could also include a 'pause' function in your contract (with an onlyOwner modifier to make sure nobody else pauses it) so once it has been deprecated the functions within the original contract no longer work.

We use a contract register on our private chain to keep an eye on the latest version of each contract - when updates are made the original contract is paused, its latestVersion bool is set to false and successorAddress is added to their register mapping entry to point towards the correct new version. Our contract register is also upgradeable, for additional resilience :)

There is plenty of in-depth coverage on this topic in this question


if you selfdestruct your contract, its bytecode will be deleted and you no longer can interact with the contract.

In upgradable proxy, you have proxy contract and implementation contracts.

 user => Proxy => ImplementationContract

in this design, the state is stored inside the Proxy contract. If in the future you deploy the next version of your contract, this new contract can still access the previous state. that is why upgradable contracts are designed for: you can change the logic and yet still access to the previous transactions or any other state variables.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.