I've started developing smart contracts with Truffle and when I edit a contract I always redeploy it by adding another migration script. There are two things that I wonder about:

  1. Is this the way it should be done, or is there a better way?
  2. When I redeploy a contract with a new migration script, the deployed contract also gets a new address. Is it also possible to migrate a smart contract and let it keep the existing address?

All tips are welcome!

  • 2
    You can not update an existing contract. Thats the whole idea of the blockchain. Decentralized smart contracts are autonomous and P2P. If you, as the developer, have full controll over the SC and can manipulate it all you want, than it would be no different than a client-server application. Commented Feb 6, 2017 at 14:09
  • 1
    @MaxBinnewies - So that means that I can only deploy a new version of the contract. For every small change I now manually have to add another migrate script, isn't there an easier way of doing that?
    – kramer65
    Commented Feb 6, 2017 at 17:17

1 Answer 1


Contract code is permanent. There is no way to alter the code of a deployed contract except by destroying it altogether by the SELFDESTRUCT opcode (selfdestruct() in solidity.)

There's four ways, more or less, to cope with this:

  1. Don't. Just have the contract be eternal, no matter what happens.
  2. Use some scheme to work around this limitation.
  3. Create a new contract, and find some way to reconnect to old users/other contracts.
  4. Create temporary contracts.

Note that some of these bleed into each other--3 and 4 are quite similar.

1 is the second-easiest, since you don't have to do anything. It's also the most dangerous, since it basically hopes that there will never be a critical bug, ever. This is almost certainly a false hope.

2 is a lot harder. There are ways to have the effect of changable contract code. For example, you could put the data in one unchanging contract, then call a library to actually execute it. Here would be my advice on how to do that. However, as I mention, it's not for the faint of heart, and it's probably not worth it on a small scale.

3 is what the DAO would have used to upgrade itself, had it not been attacked. One option is to have a simple contract acting as an entry point to the current, "real" contract.

4 is the easiest, and IMHO, the best, if possible. If no contract has a need for long-term state, then it might be best to flat-out create a new one every time you update. The Ethereum Alarm Clock, as I understand it, simply just has newer and older versions on the chain. There's no need for complicated schemes, and if you do need an older version, it can stick around.

The best question is to ask yourself what you require. Will there be a "final" state to the contract? In that case, you might get away with 1. If there's not, you might be able to use 4. If neither, or if you absolutely need to keep the same address, then it might be time to look into 2 or 3.

EDIT: See also this question for other ideas.

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