Add a “Max Extension” Parameter to TTL Extension to Improve Extension Fee

[HansonYip]

Background

In the current TTL extension flow, many contracts implement self-extension using fixed parameters such as:

threshold = 23 days
extend_to = 30 days

This approach introduces a significant cost issue:

When a contract entry (instance or code) has very low remaining TTL — for example, 1 day — any user interacting with the contract will trigger an extension from 1 day → 30 days, forcing that user to pay rent for roughly 29 days.
For large contracts, this can be unexpectedly expensive and creates unfair cost allocation among users.

This becomes especially problematic for contracts that are used infrequently.

---

Limitations of Current Workarounds

1. Small threshold & small extension window

Developers can set:

threshold = 1 day
extend_to = 2 days

This limits fee spikes, but introduces a new risk:

• If the contract is not used frequently enough, it may expire, causing a forced 120-day restoration, which is far more expensive.

Thus, the tradeoff becomes unacceptable for certain applications.

---

2. Idea: Set extend_to = current_ttl + 1 day

This would spread rent cost across users by allowing small incremental extensions.

However, this approach is not feasible today: Contracts cannot read TTL on-chain, so they cannot compute current_ttl + 1 day.

---

Proposed Solution: Add a “Max Extension” Parameter

Introduce a new parameter in the TTL extension host function:

max_extension: u32 (in ledgers)

Behavior Example

If a contract specifies:

threshold = 29 days
extend_to = 30 days
max_extension = 1 day

And the current TTL is only 1 day:

• Instead of extending 1 → 30 days, the VM would apply only +1 day
• Future calls would gradually extend TTL as needed
• No single user pays the entire extension cost

---

Request

I’d like to propose adding a max_extension parameter to the TTL extension host function and include this enhancement in protocol development.

This feature would greatly improve:

• Cost fairness
• UX for contract users
• Safety for infrequently accessed contracts

[fazzatti]

+1 to this request!

It might seem like a small change but I believe this would greatly expand the ways in which contract builders optimize their storage strategies to improve the average cost of transactions for most users.

[dmkozh]

I think this seems very reasonable, and I'm honestly a bit surprised that this hasn't come up sooner. The current TTL extension interface is not perfect by any means, and it was based on our intuition of what would be the minimal usable way to manage TTL from within the contract. It definitely can be improved.

Another idea that I've got is to provide a limit for the maximum extension fee, either in addition to the maximum extension proposed here, or instead of it. Or even provide a purely fee-based extension function, in order to spread out the fees among users in a more even fashion.
I think the main downside would be the additional complexity this introduces: TTL extensions are already a pretty tricky concept to grasp, and adding more ways to do it might make things even more confusing. But on the other hand this may be possible to mitigate via detailed guides and documentation, and the flexibility may be really useful to support diverse protocols.

Does anyone have any thoughts on this?