Applied is self explanatory but the others really arent. The source code gives a bit of clues though; as file apply_results.mli says

[Skipped] ones should always be at the tail, and after a single [Failed]

So in which cases would failed be used over backtracked, and vice-versa? And will we always have guaranteed atomicity on the entire group of transactions in an operation?

  • Just a guess, but say we have transactions A that generated internal transactions B C and D. If C, fails, then C is Failed, A and B are Backtracked and D is Skipped.
    – arvidj
    Feb 23, 2020 at 9:24

1 Answer 1


The idea is pretty simple:

  • failed - operations which failed with some particular error (not enough balance, gas limit, etc);
  • backtracked - operations which were successful but reverted due to one of the following operations in the same operation group was failed;
  • skipped - all the operations after the failed one.

However, after Babylon update some errors cause the operation to be marked as backtracked, but not failed. For example, when sender can't pay allocation fee.

So, it looks like this:

Operation group:
  failed (or backtracked)    <-- here is the actual error

And yes, all operations in the same operation group are atomic.

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.