From the docs:

Write your functions in a way that, for example, calls to external functions happen after any changes to state variables in your contract so your contract is not vulnerable to a reentrancy exploit.

I was wondering if it is possible (and viable) to enforce this rule syntactically or as a check in the compiler to prevent this class of attacks?

If it is not possible, why? Is there a necessity to allow external calls anywhere in the middle of functions?

I stumbled upon EIP 214 which says:

this proposal adds a new opcode that can be used to call another contract (or itself) while disallowing any modifications to the state during the call (and its subcalls, if present).

It sounds like it addresses the problem but from the other end. My question is focused on the enforcing of non-static calls to be always placed last inside functions.

1 Answer 1


This rule is indeed relatively easy to formalize. Static analysis tools like Securify identify this vulnerability (see their pre-loaded example).

  • Are there any plans of including those checks into the compiler?
    – scriptin
    Commented Jul 31, 2017 at 23:02
  • @scriptin not that I'm aware of... A future full-fledged Ethereum IDE will run a static analyzer before compilation and show such things as warnings, that's what I expect. Commented Jul 31, 2017 at 23:08

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.