#What’s the best strategy to update the contract's TTL?

3 messages · Page 1 of 1 (latest)

dreamy ember
#

What’s the best strategy to update the contract's TTL?

OPTION 1

  • Update it within certain contract functions?
    That’s how we currently have it set up, but we have two questions:
  • What’s a recommended value for updating the TTL?
  • Is it advisable to update the TTL in __check_auth?

OPTION 2

  • Monitor the contract and update the TTL when it’s close to expiring

Combine any of the above options with implementing logic on the client side (SDK) to “unarchive” the contract before interacting with it, if it’s been archived

We understand and have read about many of these topics in the documentation, but we’d like to hear your opinion based on our specific case.

rare pagoda
#

both options are viable and make sense depending on context. they're also mentioned in best practices doc: https://developers.stellar.org/docs/learn/encyclopedia/storage/persisting-data#best-practices
for most of the contracts it makes sense to extend ttl of persistent entries on access (this includes custom accounts and I think extension in __check_auth makes perfect sense). the exact extension parameters depend on the contract. for example, if you have a token, it makes sense for every user to extend the contract instance a little bit - this way you spread out the costs relatively evenly among the users. but for example for the custom account you wouldn't really expect anyone but the sole user to access it, so it makes sense to make longer extensions. also it makes sense to use the thresholds when extending TTL, so that you don't extend it on every call - e.g. an extension policy may look like 'extend entry by 2 weeks if it will expire in 1 week or less'.
the good news is that you hopefully don't need to worry about entries being archived too much. even today it's realtively easy to restore an archived entry, but in p23 (in a few months) the entries will be automatically restored on invocation, so you won't need to do anything specil to restore the entries. it still makes sense to keep the frequently accessed entries alive (e.g. to spread out user costs), but having rarely accessed entries auto-restored every once in a while should not be an issue.

#

so I'd say option 2 will become less useful, though it still has place if you want to centralize the contract maintenance costs and make it as cheap as possible for the users