Description:
All persistent storage entries (vaults and escrows) are set with:
env.storage().persistent().extend_ttl_info(&key, 10_000, 100_000);
At ~6 seconds per Stellar ledger, 10,000 ledgers ≈ 16 hours minimum TTL, and 100,000 ≈ 6.9 days maximum extension. A user who doesn't interact with their vault for a week risks having it archived and their funds unrecoverable without a bump transaction.
For a product designed around monthly rent cycles, this is dangerously short.
Proposed fix:
Raise the TTL extension to at least 500,000 ledgers (~1.3 years) for vaults: extend_ttl_info(&key, 50_000, 500_000)
Document the TTL bump strategy in STORAGE_LAYOUT.md
Consider an off-chain heartbeat job or on-chain bump instruction for long-lived vaults
Acceptance criteria:
TTL constants updated for both Vault and Escrow entries
STORAGE_LAYOUT.md updated with TTL explanation and risk notes
Added test verifying a vault is still accessible after a simulated long idle period
Description:
All persistent storage entries (vaults and escrows) are set with:
env.storage().persistent().extend_ttl_info(&key, 10_000, 100_000);
At ~6 seconds per Stellar ledger, 10,000 ledgers ≈ 16 hours minimum TTL, and 100,000 ≈ 6.9 days maximum extension. A user who doesn't interact with their vault for a week risks having it archived and their funds unrecoverable without a bump transaction.
For a product designed around monthly rent cycles, this is dangerously short.
Proposed fix:
Raise the TTL extension to at least 500,000 ledgers (~1.3 years) for vaults: extend_ttl_info(&key, 50_000, 500_000)
Document the TTL bump strategy in STORAGE_LAYOUT.md
Consider an off-chain heartbeat job or on-chain bump instruction for long-lived vaults
Acceptance criteria:
TTL constants updated for both Vault and Escrow entries
STORAGE_LAYOUT.md updated with TTL explanation and risk notes
Added test verifying a vault is still accessible after a simulated long idle period