Area
Project Registry / Storage
Complexity
Medium
File(s)
project_registry/src/lib.rs:210-218 (create_project, the only extend_ttl call in the file)
Problem
create_project calls extend_ttl(&DataKey::Project(project_id), 17280, 518400) once, at creation. Every subsequent write to that same key — update_impact_score_internal, update_credit_quality_score, certify_project, archive_project — calls .set() but never calls extend_ttl again. Writing does not automatically re-extend a persistent entry's TTL in Soroban, so an actively-scored project whose TTL was set once at creation will still expire ~518,400 ledgers after creation regardless of how many score updates happen in between. Other persistent keys (Whitelist, Collateral, CreatorReputation, Proposal, HasVoted, ScoreHistorySlot/Total, Arch) never call extend_ttl at all, anywhere.
Scope
In:
- Add extend_ttl calls (with sensible threshold/extend-to values) to the write paths for Project, at minimum.
Out:
- A full storage-wide TTL audit across investment_vault (tracked separately).
Acceptance Criteria
Area
Project Registry / Storage
Complexity
Medium
File(s)
project_registry/src/lib.rs:210-218 (create_project, the only extend_ttl call in the file)
Problem
create_project calls extend_ttl(&DataKey::Project(project_id), 17280, 518400) once, at creation. Every subsequent write to that same key — update_impact_score_internal, update_credit_quality_score, certify_project, archive_project — calls .set() but never calls extend_ttl again. Writing does not automatically re-extend a persistent entry's TTL in Soroban, so an actively-scored project whose TTL was set once at creation will still expire ~518,400 ledgers after creation regardless of how many score updates happen in between. Other persistent keys (Whitelist, Collateral, CreatorReputation, Proposal, HasVoted, ScoreHistorySlot/Total, Arch) never call extend_ttl at all, anywhere.
Scope
In:
Out:
Acceptance Criteria