DEV Community

Cover image for TON Storage Fees, Part 2: Important Notes and Practical Tips
Salikh Osmanov
Salikh Osmanov

Posted on

TON Storage Fees, Part 2: Important Notes and Practical Tips

#func #tvm #ton #smartcontract

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
Enter fullscreen mode Exit fullscreen mode

only part of the debt is collected.

The remaining amount is stored as:

due_payment
Enter fullscreen mode Exit fullscreen mode

Therefore:

Collected Storage Fee
≠
Total Storage Debt
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

Non-bounceable message:

Credit → Storage → Compute
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

If the message is bounceable:

Storage Phase runs first.
Balance = 0 TON.
Storage fee cannot be collected.
Enter fullscreen mode Exit fullscreen mode

If the message is non-bounceable:

Credit Phase runs first.
Balance becomes 1 TON.
Storage fee can be collected immediately.
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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;
Enter fullscreen mode Exit fullscreen mode

The assumption is that:

my_balance =
balance_before_message +
msg_value
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

During the next transaction:

new_storage_fee
+
previous_due_payment
=
total_storage_fee
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
);
Enter fullscreen mode Exit fullscreen mode

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

Top comments (0)