Problem
Soroban persistent storage entries have a finite ledger Time-To-Live (TTL). Without explicit TTL extension calls, any Campaign, Application, Submission, or SelectedCreators entry will eventually be archived and become unreadable — even for an active, fully-funded campaign.
Currently no function in the contract calls extend_ttl on any persistent key. A campaign created on day 1 with a 90-day content deadline will silently expire before the deadline is reached if no ledger bump occurs.
Current behaviour
// create_campaign stores campaign but never bumps its TTL
env.storage().persistent().set(&DataKey::Campaign(id), &campaign);
Expected behaviour
Every write and every read of a persistent entry should extend its TTL to at least MAX_TTL ledger sequences (approximately 1 year at current ledger cadence on Stellar).
Implementation
Add constants:
const LEDGER_BUMP: u32 = 535_680; // ~1 year at 5s/ledger
const LEDGER_THRESHOLD: u32 = 500_000;
Wrap every persistent().set() with a TTL extension:
env.storage().persistent().set(&DataKey::Campaign(id), &campaign);
env.storage().persistent().extend_ttl(&DataKey::Campaign(id), LEDGER_THRESHOLD, LEDGER_BUMP);
Also bump the instance() storage in every public function:
env.storage().instance().extend_ttl(LEDGER_THRESHOLD, LEDGER_BUMP);
Affected keys to bump
Every read/write of: Campaign(id), Application(id, addr), Submission(id, addr), SelectedCreators(id), CampaignApplicants(id)
Files
src/lib.rs — every function that reads or writes persistent storage
Acceptance criteria
Problem
Soroban persistent storage entries have a finite ledger Time-To-Live (TTL). Without explicit TTL extension calls, any
Campaign,Application,Submission, orSelectedCreatorsentry will eventually be archived and become unreadable — even for an active, fully-funded campaign.Currently no function in the contract calls
extend_ttlon any persistent key. A campaign created on day 1 with a 90-day content deadline will silently expire before the deadline is reached if no ledger bump occurs.Current behaviour
Expected behaviour
Every write and every read of a persistent entry should extend its TTL to at least
MAX_TTLledger sequences (approximately 1 year at current ledger cadence on Stellar).Implementation
Add constants:
Wrap every
persistent().set()with a TTL extension:Also bump the
instance()storage in every public function:Affected keys to bump
Every read/write of:
Campaign(id),Application(id, addr),Submission(id, addr),SelectedCreators(id),CampaignApplicants(id)Files
src/lib.rs— every function that reads or writes persistent storageAcceptance criteria
LEDGER_BUMPandLEDGER_THRESHOLDconstants definedinstance()storage TTL bumped in every#[contractimpl]functionpersistent().set()paired withextend_ttlon the same keypersistent().get()on a non-optional key extends TTL before returning