Skip to content

Most persistent storage keys in investment_vault never get a TTL extension #317

Description

@abayomicornelius

Area

Investment Vault / Storage

Complexity

Medium

File(s)

investment_vault/src/types.rs:99-181 (VaultKey variants), cross-referenced against the single extend_ttl call at investment_vault/src/lib.rs:456

Problem

Persistent keys such as YieldPerShareAccum, YieldDebt(Address), ProjectInvestment(u32), InsuranceFund, QueueEntry(u64), ComplianceEvent(u64), CarbonCreditBalance(Address), and LastDeposit(Address) are written via plain .set() with no accompanying extend_ttl. ADR-002 asserts "rent is implicitly paid when the entries are read or written," which is not how Soroban's TTL model works — writes don't auto-extend beyond the network's default minimum. Long-idle vaults risk archival of yield/queue/insurance state, which would require an explicit restore operation (or fail) on next access.

Scope

In:

  • Audit and add extend_ttl calls (or a periodic bump function) for the listed keys.

Out:

  • Switching storage tiers (instance vs. persistent) wholesale.

Acceptance Criteria

  • Each frequently-relevant persistent key has a documented TTL policy
  • A test/benchmark demonstrates a key survives N ledgers without being touched

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programcontractSmart contract logic and design

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions