This question already has an answer here:

Most introductory guides for contract design talk about creating "mortal" contracts (contracts that include some function that triggers a suicide() call), but what about if that contract was for some sort of sub-currency (Fungible Token/FT)? Is it possible to see the state of a contract as it existed immediately before suicide? So in theory someone could create a new contract that has its initial state mirroring what the old contract had?

I'm envisioning a situation where a contract/currency has been in circulation for a while and then an edge-case bug is discovered in the contract code. How to fix/correct it? It seems there needs to be at least some basic hooks programmed into the contract from the get-go to recover from a situation like that, but what are they?

The "creating a crypto-currency" guide talks about adding a freezeAssets call, which seems a good start; if need-be, the maintainer could freeze everyone's assets, which would keep the contract alive, and able to return queries about account's values. Then a new currency could be spun up that users could call some sort of transfer function to replicate assets in the new coin.

Since the address a contract gets created at is deterministic, would it be possible for a contract owner to suicide the old contract, and then deploy a new contract to the same address (which would mean re-use the nonce used when creating it in the first place)? Would a new contract at the same location have access to the same State as the previous contract (meaning everyone's alt-coins would be restored to the same state)?

merged by eth Jun 23 '16 at 10:07

This question was merged with Upgradeable smart contracts because it is an exact duplicate of that question.