I'm reading bits and pieces that selfdestructs within contracts are a good thing. Can someone explain what the benefits are of doing a contract selfdestruct when it comes to Ethereum programming? Is there a difference if you're using different clients or implementations, or languages?

  • This question is very unclear. Are you asking about contract suicides, or clients or what? Commented Jan 22, 2016 at 4:43
  • Sorry about that - contract.
    – high110
    Commented Jan 22, 2016 at 4:46
  • The last sentence is the confusing part, because the go client is a client, solidity is a language, and python could be referring to the python client, or possibly to serpent, the python-like Ethereum language Commented Jan 22, 2016 at 4:51
  • 1
    tried again - let me know if it's more clear - just trying to see if there are any differences within each implementation?
    – high110
    Commented Jan 22, 2016 at 4:57

5 Answers 5


Selfdestructs in Ethereum are an operation (an OPCODE actually) at the EVM level, independent of what language or client you are using.

For example, calling selfdestruct(address) sends all of the contract's current balance to address.

This is useful when you are finished with a contract, because it costs far less gas than just sending the balance with address.send(this.balance).

In fact, the SELFDESTRUCT opcode uses negative gas because the operation frees up space on the blockchain by clearing all of the contract's data.

This negative gas deducts from the total gas cost of the transaction, so if you're doing some clean-up operations first, SELFDESTRUCT can reduce your gas costs.

  • 3
    What happens if you try to call suicided contract? Is it state back to zero or does EVM set some flag telling this contract is no longer here? Commented Feb 9, 2017 at 20:53
  • 1
    What happens if you send ether to the contract which is suicided? Commented Jun 12, 2017 at 19:21
  • 7
    The balance of the address increases, but since there is no code at the address anymore, the ETH just gets stuck. That ETH is then essentially burned. Commented Jun 12, 2017 at 19:23

Note: this question originally asked about the suicide opcode, which has become selfdestruct in the meantime as per EIP6.

selfdestruct is the encouraged term and may be found in newer Solidity and Serpent code. It is the same API and behavior, as described in the other answers, and is an alias for suicide.

EIP6 describes the motivation:

The primary reason for us to change the term suicide is to show that people matter more than code and Ethereum is a mature enough of a project to recognize the need for a change. Suicide is a heavy subject and we should make every effort possible to not affect those in our development community who suffer from depression or who have recently lost someone to suicide.

  • 1
    selfdestruct alias has been applied to the codebases of Solidity and Serpent and is the preferred term to use. Commented Feb 14, 2016 at 6:10

The selfdestruct() function and the relative OPCODE are used when you have a contract that has a bug or an unwanted behaviour and you want to get rid of it.

The selfdestruct(address) is a better version as @tjaden-hess pointed out, when you have a payable contracts (contracts that receive ethers) the ethers will be redirected to address which is a big win.

When you interact with a selfdestructed contract NOTE this: If you send a transaction and/or funds to it then your funds are LOST. Be sure to not send funds or other transactions to it after self-destructing a contract.

That's an issue you always have to keep in mind when developing apps that use contracts with a selfdestruct function, be sure the address of the contract is removed from your app after selfdestruct() has been called on the contract, maybe you can always call a getter method to see if the contract responds with a valid value before sending a transaction and/or transferring ethers to it.


The name of the method is now selfdestruct. We have some description of it in the new solidity docs.

Here's a post from r/ethereum about suicide with more infos and a small discussion about it.

  • This should be the accepted answer. Commented Jun 12, 2017 at 19:22
  • will a self-destruct smart contract no longer exists in blockchain?. I think, people can still see it, but it's a non-functionality smart contract. Is that true?
    – Ender
    Commented Jul 22, 2019 at 8:55
  • @ender - yes, the purpose/benefit of selfdestruct() is that if you have a dangerously buggy contract you can "terminate" it
    – makevoid
    Commented Oct 27, 2019 at 5:22
  • @makevoid thanks, I found the answer on the same date. Ppl can see it after destructed. For example etherscan.io/address/…
    – Ender
    Commented Oct 28, 2019 at 6:17
  • @ender in the etherscan (or etherchain) contract page you see the contract source only if it's uploaded by a user (it gets compared and verified by etherscan byw). The only way to interact with that contract / code is to fetch the bytecode from the block in which it was deployed thou and re-deploy it if you want to "resurrect" it, you still the ABI and you won't be able tor estore any state / ethers / tokens sent to the contract.
    – makevoid
    Commented Nov 3, 2019 at 19:43

IMHO selfdestruct is a bad thing that should never be introduced. It breaks contract's immutability principle and introduces many problems:

  1. It allows successfully sending ether to contract that tries to disallow incoming ether transfer (have no payable functions)
  2. If allows sending ether to a contract that tries to actively react on incoming ether transfers, in such a way that the contract will not notice the transfer
  3. While it does send all the ether from contract's balance to specified address, it does not sent tokens and other assets
  4. Assets sent to a contract after selfdestruct are lost in most cases, checking that contract is not selfdestructed before the transfer does not help much, because transfer may be frontrunned with selfdestruct
  5. It allows modifying bytecode of a deployed smart contract (EIP-1014)

Why are selfdestructs used in contract programming

Once a contract is created on the Ethereum blockchain it cannot be modified.

  1. Each block in the blockchain commits to all of the transactions in the block and the order that they are in. It does this by including the hash of all of the transactions in the block header, which is then part of the data that is hashed for the proof of work.
  2. Modifying a smart contract in a block will change the hash of all of the transactions which ultimately changes the hash of the block header. This will likely make the block header's hash have an invalid proof of work. Thus in order to modify the transaction, you would have to redo the block's proof of work, i.e. remine the block.
  3. Furthermore, the block header includes the hash of the previous block. So if you want to change a transaction which would contain the smart contract eventually , you will need to also remine all of the blocks following the block which contains the transaction(smart contract) you modified. Lastly, your set of modified blocks are actually a blockchain fork. In order to get it to be accepted by the rest of the network, your fork will need to have more cumulative work than the current blockchain, which effectively means that your fork needs to be longer than the current blockchain.


|     Benefit     |                                       Reasoning                                       |
| Stop Execution  | If you no longer want the contract running, you can selfdestruct it to “turn it off”. |
| Eliminate Bugs  | (Similar to above). You can kill off smart contracts that are buggy.                  |
| Lower Gas Price | It costs less gas to selfdestruct a contract.                                         |

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.