🔴 No TTL management for token bookkeeping — state can be archived and the factory has no rent strategy

[Ejirowebfi]

Area: Smart contract · lib.rs (extend_token_ttl, all storage writes)

Description

extend_token_ttl(env, _token_address, _index) ignores both of its arguments and merely extends
the instance TTL — a misleading no-op wrapper. The entire factory relies on a single instance-storage
TTL that is only extended when someone happens to call a state-writing function. If the factory sits
idle longer than the TTL window (MAX_TTL = 535_000 ledgers ≈ 31 days), the instance entry —
containing all token records, metadata pointers, creator lists, and the admin/fee configuration — is
archived. Reads start failing (StateNotFound / missing-entry traps) and every user's token becomes
invisible to the app until someone performs a state restoration, a flow neither the contract, the
scripts, nor the frontend implements or documents. On mainnet, "the app went dark because nobody made
a transaction for a month" is a critical operational failure. This issue is the TTL/archival half of
the storage redesign in Issue 3.

Tasks

• After the persistent-storage migration (Issue 3), implement real per-key TTL extension: extend a
  token's TokenInfo/TokenIndex/Metadata/owner/supply keys whenever that token is touched.
• Delete or fix the argument-ignoring extend_token_ttl so its behavior matches its name.
• Add a public extend_ttls(keys)-style maintenance entrypoint (or document use of the ledger
  RestoreFootprint/ExtendFootprintTTL operations) so anyone can keep entries alive
  permissionlessly.
• Add an operational runbook (docs/): monitoring entry TTLs, restoring archived entries, and the
  expected rent budget; wire a scheduled CI job or cron doc for TTL keep-alive on mainnet.
• Add tests that advance the ledger past TTL boundaries and verify (a) touched entries survive,
  (b) restoration of archived entries works.

Acceptance criteria

• Every persistent entry a user's token depends on gets its TTL extended on access, proven by
  ledger-advancing tests.
• An archived-entry recovery procedure exists, is documented, and is exercised by a test.
• No function signature advertises per-token TTL behavior it does not implement.

---

Issue 7 of 20 from the codebase audit tracked in ISSUES.md.

[mayborn005]

Hello @maintainer, I’ve gone through the requirements and I’m confident I can implement a proper solution that matches the acceptance criteria. Kindly assign this issue to me. And I will deliver at the shortest possible time.

[Markodiba6399]

Hi, I'd like to work on this issue.

This is a real "the app went dark and nobody knew why" risk. A factory that only extends TTL incidentally, whenever some unrelated state-writing call happens to occur, means archival is basically a matter of time on any contract with irregular usage, and there's currently no recovery path documented anywhere. The misleading extend_token_ttl signature makes it worse, since it looks like the safeguard already exists.

My proposed approach:

Coordinate with (or build on top of) the persistent-storage migration from Issue 3 first, since real per-key TTL extension only makes sense once storage is structured around individual keys rather than one shared instance entry.
Implement per-key TTL extension so that touching a token's TokenInfo, TokenIndex, Metadata, owner, and supply entries extends each of their TTLs on access, rather than relying on the single instance-level TTL as a proxy for all of them.
Delete or rewrite extend_token_ttl so its behavior actually matches its name and arguments, no longer silently ignoring _token_address and _index.
Add a public, permissionless extend_ttls(keys)-style maintenance entrypoint so any caller (a cron job, a concerned user, anyone) can keep entries alive without needing special permissions, and document the alternative of using RestoreFootprint/ExtendFootprintTTL directly if that's preferable for some callers.
Write the operational runbook in docs/: how to monitor entry TTLs approaching expiry, how to restore an archived entry, and what rent budget to expect, plus a cron/CI job doc for scheduled keep-alive on mainnet so this doesn't silently regress after the fix ships.
Write ledger-advancing tests that push past the TTL boundary and verify both that touched entries survive and that archived entries can actually be restored, since the acceptance criteria specifically require this to be proven, not just asserted.

I have experience building Stellar/Soroban contracts including token/wallet-style state that needs to stay durable over time, so I'm comfortable with the storage TTL model and the ledger-advancing test patterns Soroban requires here. Since this issue explicitly depends on Issue 3's storage migration landing first, I'd want to confirm sequencing with maintainers, either picking this up right after Issue 3 merges or coordinating a combined PR if that's a better fit.

[grantfox-oss]

🦊 GrantFox — @Markodiba6399 has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #1011)
2. Your PR will be reviewed by the Favourorg maintainers

Good luck! Track your progress on GrantFox.