[Bug] No TTL management anywhere; depositor state and the contracts themselves can be archived

[collinsezedike]

Description

None of the three contracts (vault, blend-adapter, defindex-adapter) ever call extend_ttl or bump_instance_ttl. Soroban archives persistent and instance storage entries whose time-to-live lapses; persistent entries become inaccessible until an explicit RestoreFootprint operation runs, and instance storage archival takes the entire contract out of service.

Two failure modes follow from this. First, a depositor's DataKey::Balance, DataKey::Entry, and DataKey::Principal entries are written on deposit and never touched again until the depositor next acts. A saver who deposits and leaves the position alone — the entire premise of a savings product aimed at long-horizon users — has their entries archived after the default persistent lifetime elapses. Their withdraw then fails at the footprint stage until they discover and pay for a restore they have no reason to know exists, and get_position's unwrap_or(0) makes the balance display as zero in the meantime, indistinguishable from total loss.

Second, every vault configuration value (ADMIN, ADAPTER, TOTAL_SH, ADPT_SH) and each adapter's pool/vault wiring lives in instance storage. If the contracts see no traffic for the instance lifetime, the whole deployment archives at once, and with no upgrade path recovery means a full redeployment plus manual reconstruction of every depositor position.

Steps to Reproduce

1. Deposit into the vault, then take no further action against it for longer than Soroban's default persistent-entry TTL.
2. Call get_position(address) — it silently returns 0 (via unwrap_or(0)) once the entry archives, indistinguishable from having no position.
3. Attempt withdraw — it fails at the ledger footprint stage rather than with a typed contract error, since the entry no longer exists on-ledger.

Expected Behavior

A depositor who takes no action should still be able to read and withdraw their position at any point in the future without needing to know about or manually run a RestoreFootprint operation.

Actual Behavior

Positions silently archive and read as zero; the contract itself provides no mechanism to keep state alive or to signal that archival, not loss, is what happened.

Environment

Field	Value
Network	testnet / mainnet
Wallet	N/A (contract-level)
Protocol affected	None (all three contracts)
Browser (if frontend)	N/A
Node.js version	N/A
pnpm version	N/A

Transaction Details (if on-chain)

• Transaction hash: N/A — takes months to manifest under real traffic patterns, not yet observed
• Ledger: N/A
• Soroban RPC endpoint used: N/A

Logs / Screenshots

N/A — static analysis finding: zero occurrences of extend_ttl / bump_instance_ttl
across packages/contracts/vault, blend-adapter, defindex-adapter

Possible Cause / Fix

Add ledger-denominated TTL constants, extend instance storage on every state-changing entry point, and extend a depositor's three persistent entries whenever they're read or written:

// One ledger closes in roughly five seconds, so ~17 280 ledgers per day.
const DAY_IN_LEDGERS: u32 = 17_280;

const INSTANCE_BUMP: u32 = 30 * DAY_IN_LEDGERS;
const INSTANCE_THRESHOLD: u32 = INSTANCE_BUMP - DAY_IN_LEDGERS;

// Positions are bumped far harder than config: a saver who does nothing for
// a quarter is the target user, not an edge case.
const POSITION_BUMP: u32 = 120 * DAY_IN_LEDGERS;
const POSITION_THRESHOLD: u32 = POSITION_BUMP - 7 * DAY_IN_LEDGERS;

fn extend_instance(env: &Env) {
    env.storage().instance().extend_ttl(INSTANCE_THRESHOLD, INSTANCE_BUMP);
}

fn extend_position(env: &Env, address: &Address) {
    let storage = env.storage().persistent();
    for key in [
        DataKey::Balance(address.clone()),
        DataKey::Entry(address.clone()),
        DataKey::Principal(address.clone()),
    ] {
        if storage.has(&key) {
            storage.extend_ttl(&key, POSITION_THRESHOLD, POSITION_BUMP);
        }
    }
}

Call extend_instance(&env) as the first statement of deposit, withdraw, set_paused, set_admin, set_adapter, and migrate_adapter; call extend_position at the end of deposit/withdraw and inside get_position. Mirror extend_instance in both adapters' deposit, withdraw, and accrue.

Add a permissionless keeper entry point so a position can be kept alive without its owner transacting, which is what makes the guarantee real for a passive saver:

/// Permissionless. Lets a keeper (or anyone) refresh a depositor's state
/// lifetime without the depositor needing to submit a transaction. Extending
/// a TTL cannot change any balance, so no authorization is required.
pub fn extend_position_ttl(env: Env, address: Address) {
    extend_instance(&env);
    extend_position(&env, &address);
}

Scope

Field	Value
Area	Contracts
Protocol affected	None
Network	testnet, mainnet
Breaking change?	No — additive, no ABI removal

[Ekpemark]

@Ekpemark has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi
I am a Smart Contract and Full-Stack Developer with expertise in building secure, scalable, and production-ready blockchain applications. With strong proficiency in Rust, Solidity, Soroban smart contract development, and the Stellar SDK, I transform complex ideas into reliable systems that are efficient, maintainable, and built for real-world use. My experience spans smart contracts, decentralized applications, and Web3 infrastructure, with a focus on security, performance, and delivering solutions that create tangible value for users and ecosystems.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @Ekpemark to this issue.

[drips-wave]

Congratulations, @Ekpemark! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on August 31, 2026.

🧑‍💻 @Ekpemark: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊

[collinsezedike]

@Ekpemark same check-in as #551, no update yet here either. You've got three assigned right now, let me know if that's too much to land by August 31 and I can free one up.

[ZacLou]

I'd like to work on this. I'll add TTL extension to the vault and both adapters, plus a permissionless extend_position_ttl entry point, and update the test suite accordingly.

[ZacLou]

Implemented TTL management for the vault and both adapters in #704.