You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It's been a while since this has been filed and we've released Soroban with 30 days. However, the semantics is not as simple:
When balance is created, it will be bumped to at least 30 days, but not less than the minimum persistent entry TTL, which is currently 120 days, i.e. new balances will be at least 120 days
The balance entry TTL is automatically extended to 30 days if the current TTL is less than 29 days. The goal here is to provide some sustainability for the contract balance entries (as long as the contract is being used), but also try to limit the maximum fees for the rent extension
Increasing the initial TTL to the max value is not an obvious choice. Since balance entries belong to contracts, it is possible that the contract itself is not meant to be used for that long (think claimable balance style contract). Basically, from the fees standpoint it's always better to do the minimum extension only and let the users to bump the rent explicitly if necessary. Even the current default behavior might be too aggressive for some use cases.
I think the only potential improvement here is to allow the token admin to change the TTL settings, though even then it's not obvious that admin is in the right position to determine the rent/fee policy for all token users. Thus I'd like to see a case for that feature before implementing it.
As for this particular issue, I'm inclined to close it - @tomerweller please let me know if you have any objections.
Currently balance bumps are hardcoded for 30 days: https://github.com/stellar/rs-soroban-env/blob/main/soroban-env-host/src/native_contract/token/storage_types.rs#L9
The text was updated successfully, but these errors were encountered: