Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SAC should write balances with max expiration #1096

Open
tomerweller opened this issue Oct 5, 2023 · 1 comment
Open

SAC should write balances with max expiration #1096

tomerweller opened this issue Oct 5, 2023 · 1 comment
Assignees

Comments

@tomerweller
Copy link

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

@dmkozh
Copy link
Contributor

dmkozh commented Jun 17, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants
@tomerweller @sisuresh @dmkozh and others