hard: creditline user-loan index lives in instance storage — unbounded growth bricks accounts and risks ledger-limit DoS

[EmeditWeb]

Problem

The creditline contract tracks user_active_debt, loan counters, and per-user loan indexes in instance storage (see contracts/creditline-contract/src/storage.rs). Instance entries have a hard ledger footprint ceiling and a shared budget per contract instance. Every create_loan() appends to the borrower's paginated loan index and mutates debt counters; repay_loan() and repay_installment() mutate the same entries plus the loan body on every payment.

As a borrower's loan count grows, the instance entry holding their index grows linearly: read cost grows, and eventually the entry approaches Soroban's max instance size — at which point create_loan() (which writes the index) and repay_installment() (which writes loan + counters) start failing outright. A borrower who cannot repay is frozen mid-loan; a malicious actor can deliberately fragment many loans to hit the ceiling, and because mark_defaulted() also writes these entries, default handling can be made to fail — leaving defaulted principal locked in the pool forever with absorb_loss() unreachable.

TTL handling compounds it: verify whether every instance/persistent write in the repay/create paths extends TTL appropriately; an expired index entry mid-flow yields silent index loss (loan exists, invisible in listings, unreachable by the indexer).

Ground Rules

1. Read context/architecture-context.md, context/code-standards.md, context/progress-tracker.md in full
2. Read contracts/creditline-contract/src/storage.rs in full and map every key to its storage class (instance vs persistent)
3. Compare with liquidity-pool-contract/src/storage.rs:123–139 which demonstrates the correct persistent-key + extend_ttl pattern

What To Build

1. Move per-user loan indexes and debt counters from instance storage to persistent per-borrower keys with extend_ttl after every write, mirroring the LP-shares pattern.
2. Cap or chunk the index (e.g. fixed-size pages keyed (borrower, page)) so no single entry can grow unbounded; document the pagination contract for consumers.
3. Audit every write site in lib.rs for a paired extend_ttl.
4. Add a storage-layout regression test asserting entry classes and that a 200-loan borrower can still create and repay loans within footprint budgets.

Files To Touch

• contracts/creditline-contract/src/storage.rs
• contracts/creditline-contract/src/lib.rs
• contracts/creditline-contract/src/tests.rs
• context/progress-tracker.md

Acceptance Criteria

• No unbounded instance-storage entry remains on the hot loan paths
• Every persistent write is followed by extend_ttl
• High-loan-count stress test passes
• Suite green

Mandatory Checks Before Opening PR

Standard Grantfox checklist applies.

[JuliobaCR]

Hi @EmeditWeb 👋 I'd like to work on this issue.

Problem

The creditline contract keeps per-user loan indexes and debt counters in instance storage instead of persistent storage. Since instance entries share a single ledger-footprint budget per contract, a borrower's index grows linearly with every create_loan() / repay_installment() call. Once an entry approaches Soroban's max instance size, writes start failing outright — freezing borrowers mid-loan, and (since mark_defaulted() writes the same entries) potentially blocking default handling entirely, leaving defaulted principal stuck with absorb_loss() unreachable. It's also exploitable deliberately by an attacker fragmenting many loans to hit the ceiling.

Proposed Solution

• Move per-user loan indexes and debt counters from instance storage to persistent, per-borrower keys, mirroring the LP-shares pattern already used in liquidity-pool-contract/src/storage.rs:123–139.
• Call extend_ttl after every persistent write to prevent silent index loss from TTL expiry.
• Paginate the loan index (fixed-size pages keyed (borrower, page)) so no single entry can grow unbounded, and document the pagination contract for consumers.
• Audit every write site in lib.rs to confirm each persistent write has a paired extend_ttl call.
• Add a storage-layout regression test asserting entry classes (instance vs. persistent), plus a stress test simulating a 200-loan borrower to confirm create_loan/repay_installment stay within footprint budgets.

I've read through architecture-context.md, code-standards.md, and progress-tracker.md, and compared the current creditline-contract/src/storage.rs against the correct persistent-key + extend_ttl pattern in the liquidity pool contract.

Estimated time: 1–2 days, including tests and the stress-test scenario.

Happy to coordinate here or on Telegram if helpful looking forward to your go-ahead!

[MerlinTheWhiz]

Hello, I'm MerlinThewhiz, a software engineer with a strong background in smart contract, and a couple years in my arsenal. Having read the task requirement, I'd love to work on this issue. Please assign.

[sublime247]

I would love to work on this issues

[grantfox-oss]

🦊 GrantFox — @sublime247 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #88)
2. Your PR will be reviewed by the StepFi-app maintainers

Good luck! Track your progress on GrantFox.