Propose extend-on-write to OpenZeppelin's Stellar library (v2) #331

Priority

Low — nice to have, can wait. A v2 item, after Tranche 3.

User story / Problem statement

OpenZeppelin's Stellar library (stellar-* 0.7.2) extends a persistent entry's TTL when it reads the entry, not when it writes it. So every new balance, freeze, role, compliance module or bound token starts at the network's minimum lifetime. The kit works around this by reading back each entry it creates (#276, #299). In its review of the kit, aha suggested that the general fix belongs in OpenZeppelin: extend an entry when it is written, so every adopter gets it without a read-back.

As a kit maintainer, I want the library to extend entries when it writes them, so the kit can drop its read-backs and other adopters do not hit the same gap.

Expected outcome

A proposal to OpenZeppelin's Stellar contracts for extend-on-write, and, once a release includes it, the kit without its read-back helpers.

Acceptance criteria

• An issue or pull request on OpenZeppelin's Stellar contracts describes extend-on-write for persistent entries, with the cases the kit hit: balances, freezes, roles, compliance modules and bound tokens
• Once a release includes it, the kit removes its read-back helpers and keeps the tests that check a new entry's full lifetime

Alternatives considered

Keep the read-backs. They work, but every adopter has to know about the gap and repeat the fix.

Technical notes

The read-backs live in the share token's extend module (#276) and the compliance stub's (#299). Their tests set the ledger's minimum lifetime to testnet's (120,960 ledgers), so a regression shows up.