Compiling a simple contract on Remix with the most recent nightly I get the following warning

"Use of selfdestruct can block calling contracts unexpectedly. Be especially careful if this contract is planed to be used by other contracts (i.e. library contracts, interactions). Selfdestruction of the callee contract can leave callers in an inoperable state."

"More" leads to here, about the infamous Parity multi-sig wallet bug (Pmswb).

What drew my attention is the mention of interactions.

Can interaction with a selfdestructing (note the continuos -ing) contract leave my contract in an inoperable state? Mind, I am not talking about libraries here (that was the Pmswb scenario), but then is the distinction between using a library and interacting with a contract a meaningful one in Ethereum?

What I have in mind is a contract with which I conduct a transaction, which for whatever reason (malicious or not) selfdestructs and leaves my contract inoperable. Is this a possible/realistic scenario? If yes, isn't this a very serious problem?

1 Answer 1


What that warning is telling you is that you should be careful with deploying your contract which can selfdestruct and having other contracts depend on it.

If you have contract B which calls a function on contract A and contract A is selfdestructed, then contract B will stop working.

If you have a contract with a function that selfdestructs, there are two potential things that could happen when that function is being called from another contract. Say you have contract A as follows:

contract A {
    address public owner = msg.sender;

    function bye() public{

and contract B:

contract B {

    uint public data = 34;

    function killContractA(address _a) public {
        A a = A(_a);

    function killMyself(address _a) public {

If contract B (which can be deployed by anyone else) calls killContractA() then it will effectively cause your contract A to selfdestruct.

If contract B calls killMyself(), given it uses delegatecall, the one that will get destroyed is itself.

That is why you should never use delegatecall to target a contract you don't know anything about.

In both cases, you could prevent this behavior by requiring that the msg.sender is the owner of the contract in contract A.

  • Thanks for your reply. You wrote: "f you have contract B which calls a function on contract A and contract A is selfdestructed, then contract B will stop working." So if I make a call to a contract containing a bug or malicious code, it may disable my contract. This is what I was referring to as a very serious problem. If I can call only contracts I know and trust, the whole purpose of Ethereum, at least in my understanding, is seriously limited. Dec 17, 2017 at 13:00
  • I wouldn't say so. What other platform allows you to freely use other people's code in production to built on top of them? If you want to build something on top of someone else's contract, you should read the code and make sure it will not harm your own contract. It's no different than relying on some 3rd party API which if stops working or is taken down your app will not work anymore. Dec 17, 2017 at 13:06
  • I disagree. It is more like a situation where, if I make a call to a server, no matter how secure my code is, it may disable my computer forever. Still, as far as my question is concerned, the answer is clear. Dec 17, 2017 at 13:12
  • Also, there seems to be a misunderstanding from your previous comment. If you "call to a contract containing a bug or malicious code, it may disable my contract". If we are talking particularly about calling a function that selfdestructs, your own contract would only be destroyed if you had called that function using delegatecall (which unless you have some extremely good reason to do it, you shouldn't). Dec 17, 2017 at 13:17
  • If the above is not the case, your contract that depends on contract A would break if contract A stops working. In the same sense as your website would stop working correctly if it depends on the Facebook API and suddenly they change it or take it down. Dec 17, 2017 at 13:18

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.