refactor: add persistent-storage TTL extension to parameters-contract

[EmeditWeb]

Problem

The parameters-contract/storage.rs does not define PERSISTENT_TTL_THRESHOLD and PERSISTENT_TTL_EXTEND_TO constants. Other contracts have these in their storage.rs.

What To Build

1. Add TTL constants matching other contracts
2. Apply extend_ttl() on all persistent writes

Files To Touch

• contracts/parameters-contract/src/storage.rs

Acceptance Criteria

• TTL constants defined
• extend_ttl() called after all persistent writes
• All existing tests pass

Mandatory Checks

• context/ files read
• cargo build passes
• cargo test passes
• PR references this issue

[julianvillalba688]

Hi team,

I would love to take on this issue! Ensuring consistent persistent-storage TTL (Time-To-Live) management across all contracts is essential for preventing state expiration on-chain. Here is a brief summary of my experience and how I plan to handle this task:

My Experience
As a backend and systems engineer proficient in Rust, I am very comfortable with smart contract development and state storage paradigms. I understand the mechanics of Soroban’s ledger storage model, specifically the difference between temporary and persistent storage, and how the host environment manages data longevity via threshold checks and TTL extensions.

Proposed Approach
Define TTL Constants (contracts/parameters-contract/src/storage.rs): I will audit the companion contracts in the repository to extract the uniform PERSISTENT_TTL_THRESHOLD and PERSISTENT_TTL_EXTEND_TO values, declaring them explicitly inside the parameters-contract storage layer.

Implement TTL Extensions: I will locate all instances where persistent data is written or updated within the contract and inject the env.storage().persistent().extend_ttl() lifecycle hook directly following the write operation. This ensures that any interaction updating contract parameters automatically bumps its ledger viability window.

Validation & Testing: I will verify the implementation using local simulation testing. I'll make sure that all existing contract tests continue to pass and that the state extension logic integrates seamlessly without breaking current test coverage or altering expected gas/resource consumptions.

I will read all required context/ files before making modifications and ensure that both cargo build and cargo test execute perfectly with zero warnings before opening the PR. Ready to get to work!

[ebubeb683-ship-it]

I have experience using React, I have looked through the project’s code, and I can submit a Pull Request (PR) with the fix within 2 days.

[Emmanuel-Ugochukwu1]

Hi , I’m ready to solve this issue.
To resolve the missing explicit extension policy, I will define PERSISTENT_TTL_THRESHOLD and PERSISTENT_TTL_EXTEND_TO in storage.rs, matching the values used in the other contracts for consistency. I will then systematically apply extend_ttl() to all persistent writes in that file.
I will verify the implementation against your acceptance criteria by ensuring cargo build and cargo test pass completely before submitting a linked PR.
I can begin working on this right away.