Transaction Phase

Transaction Phase is one of the discrete stages every TON transaction passes through. Unlike EVM, where a transaction is a monolithic call, TON splits execution into clearly separated phases — and understanding them is essential when debugging.

The full sequence

1. Storage Phase. The network first deducts the accumulated storage fee — payment for state held since the previous transaction.
2. Credit Phase. If the transaction was triggered by an inbound internal message, the message’s value is credited to the contract’s balance. This happens before compute, so the contract can spend the incoming TON within the same transaction.
3. Compute Phase. TVM runs the contract’s code: parses the message, mutates data, builds a list of outgoing messages (actions). This is the expensive phase — gas is consumed here.
4. Action Phase. Items from the action list are applied: outbound messages are sent, storage is updated, reserve logic runs. It can fail independently of compute — e.g. if the balance is too small to cover forward fees.
5. Bounce Phase. If the compute phase failed with an error and the incoming message had bounce=true, a bounce message is built and returned to the sender.

Why it matters

• Transaction exit code is the compute phase’s return code. 0 means success; anything else signals an error (13 = out of gas, 33 = invalid signature, etc.).
• Action phase can fail separately. Compute may succeed while action can’t send a message; that has its own error code.
• Storage phase always runs. Even if compute fails, storage fee was already deducted.
• Bounce is a separate transaction. The refund triggered by a bounce is itself a transaction in the sender’s shard, with its own phases.

This structure is the backbone of debugging. When something “didn’t work”, the first step is to identify which phase failed and with what exit code.