Introduction
In Part 1 we discussed how storage fees are calculated and collected.
This article focuses on practical consequences of the storage fee mechanism and several behaviors that may surprise developers who are new to TON.
If you have not read Part 1 yet, start there:
➡ TON Storage Fees, Part 1: Understanding the Mechanism
Storage Fees Are Collected Only During Transactions
One of the most common misconceptions is that account balances continuously decrease over time.
This is not how TON works.
Storage fees are collected only when a transaction occurs and the Storage Phase is executed.
As a result:
- an account may accumulate storage debt for months;
- its balance may appear unchanged;
- the actual collection happens only during the next transaction.
This distinction is important because an account can accumulate a significant due_payment value before any funds are actually deducted.
Total Fees in Explorers May Be Misleading
When examining transactions in blockchain explorers, developers often look at the reported storage fees and assume that all accumulated debt was paid.
This is not always true.
If an account does not have enough balance to pay the full storage debt:
total_storage_fee > available_balance
only part of the debt is collected.
The remaining amount is stored as:
due_payment
Therefore:
Collected Storage Fee
≠
Total Storage Debt
The value displayed by an explorer usually represents the collected portion only.
A non-zero storage debt may still remain inside the account.
Bounceable and Non-Bounceable Messages Produce Different Results
The most important practical implication of the Storage Phase is the different ordering of transaction phases.
Bounceable message:
Storage → Credit → Compute
Non-bounceable message:
Credit → Storage → Compute
As a consequence, the same incoming value can produce different results depending on the bounce mode.
Example
Assume:
Account balance: 0 TON
Storage debt: 0.5 TON
Incoming value: 1 TON
If the message is bounceable:
Storage Phase runs first.
Balance = 0 TON.
Storage fee cannot be collected.
If the message is non-bounceable:
Credit Phase runs first.
Balance becomes 1 TON.
Storage fee can be collected immediately.
Why msg_value Is Not Always the Original Message Value
Many developers assume that msg_value inside recv_internal() is always equal to the value contained in the incoming message.
This assumption is not always correct.
Storage fee collection may affect the value that eventually becomes visible during the Compute Phase.
The value passed to TVM is effectively:
msg_value_before_compute
rather than the original message value.
Why my_balance - msg_value Can Be Dangerous
A common pattern looks like:
int balance_before_msg = my_balance - msg_value;
The assumption is that:
my_balance =
balance_before_message +
msg_value
Unfortunately this assumption is not always true.
Because storage fees may be collected before the Compute Phase, both values may already have been adjusted.
Storage Debt Survives Between Transactions
Unpaid storage fees are not forgotten.
Whenever the account cannot fully pay storage debt, the remaining amount is stored internally as:
due_payment
During the next transaction:
new_storage_fee
+
previous_due_payment
=
total_storage_fee
This means storage debt accumulates until it is eventually paid.
Active Accounts Are Not Deleted Immediately
Another common misconception is that accounts are deleted as soon as storage debt becomes large enough.
The actual process is usually:
ACTIVE
↓
FROZEN
↓
DELETED
The account first becomes frozen.
Only later can it become deleted if debt conditions remain satisfied.
Frozen Accounts May Survive Much Longer Than Expected
When an account becomes frozen, TON removes most of the stored state.
The account retains only a compact representation containing hashes of the original code and data.
As a result:
Frozen state size
<<
Active state size
Storage fees continue accumulating, but much more slowly.
Freezing or Deletion Does Not Necessarily Mean TVM Execution
Depending on account state and available balance:
- TVM may execute;
- TVM may be skipped;
- Compute Phase may be recorded with a skip reason.
Examples include:
sk_no_state
sk_no_gas
Practical Tips
Use Non-Bounceable Messages When Funding Contracts
If the purpose of the transfer is simply to fund a contract, a non-bounceable message is often preferable.
Include Existing Storage Debt in Reservations
raw_reserve(
MIN_TONS_FOR_STORAGE +
my_storage_due(),
2
);
Ignoring storage debt may leave the contract underfunded.
Monitor due_payment
Storage debt can silently accumulate for a long time.
Monitoring my_storage_due() helps avoid unpleasant surprises.
Do Not Assume msg_value Equals Incoming Value
Whenever precise accounting is required, remember that the value visible inside TVM may differ from the original incoming message value.
Related Article
TON Storage Fees, Part 1: Understanding the Mechanism
Useful Links
Simplified Storage Fee Flowchart
https://raw.githubusercontent.com/a08778/ton-fee-lab/9f3d24abe6c4d2d56ac9506c2efbc69f563e5d1b/simplified_storage_fee_flowchart.svgTON transaction processing source code
https://github.com/ton-blockchain/ton/blob/master/crypto/block/transaction.cppTON blockchain configuration parameters
https://tonviewer.com/configStorage fee research and tests
https://github.com/a08778/ton-fee-lab
