Critical: liquidity pool blindly pays any merchant address the creditline names — no recipient validation or exposure cap

[grantfox-oss]

Problem

fund_loan() in liquidity-pool-contract (lib.rs:220–256) honors transfer(pool → merchant, amount) for whichever merchant address the registered creditline supplies. The pool performs zero independent verification: it cannot confirm the merchant is registered/approved in the vendor registry, that a real loan object exists, or that cumulative exposure to this merchant/borrower pair is sane. Its only guards are available-liquidity arithmetic and the creditline address check.

Trust model consequence: the pool's entire solvency rests on the creditline contract being bug-free forever. The unfunded-approval defect filed separately shows creditline lifecycle bugs are real. A single creditline bug or compromised creditline admin (who can repoint set_creditline() — lib.rs:50–54 — to any contract they deploy) converts the pool into an open faucet: fund_loan() repeatedly to attacker addresses up to available liquidity, instantly, with absorb_loss() afterwards erasing the accounting trace.

Defense-in-depth requirements: the pool should enforce its own caps and sanity checks so a misbehaving upstream degrades gracefully instead of draining.

Ground Rules

1. Read context/architecture-context.md, context/code-standards.md, context/progress-tracker.md in full
2. Read liquidity-pool-contract/src/lib.rs in full and vendor-registry-contract/src/lib.rs is_active()
3. Respect the existing require_creditline pattern — this issue adds layered defenses, it does not replace caller restriction

What To Build

1. Per-ledger outflow cap: bound total fund_loan outflows within a single ledger to a configurable fraction of available liquidity, enforced with a rolling window reset.
2. Single-recipient concentration cap: track cumulative funded-per-merchant and reject transfers exceeding a configurable ceiling.
3. Optional vendor cross-check: accept an optional registered vendor-registry address in initialize()/admin setter and, when present, require is_active(merchant) before transfer — keeping backward compatibility when unset.
4. Emit granular events (already exists: emit_loan_funded) extended with merchant and remaining-cap fields for indexer monitoring.
5. Tests proving caps hold under repeated calls, window resets work, admin setters are guarded, and honest single-loan flows are unaffected.

Files To Touch

• contracts/liquidity-pool-contract/src/lib.rs
• contracts/liquidity-pool-contract/src/storage.rs
• contracts/liquidity-pool-contract/src/types.rs
• contracts/liquidity-pool-contract/src/tests.rs
• context/progress-tracker.md

Acceptance Criteria

• Outflow and concentration caps enforced on-chain with tests
• Optional vendor validation wired and tested in both enabled/disabled modes
• Honest flows unchanged (regression tests)
• Suite green

Mandatory Checks Before Opening PR

Standard Grantfox checklist applies.

[angelraph]

Hi, I’d like to work on #106.

I understand the main concern is making the liquidity pool enforce its own safety limits instead of relying entirely on the creditline contract.

I’ll review the existing pool, storage, vendor registry, and test structure first, then implement:

• A rolling per-ledger outflow cap.
• A cumulative per-merchant exposure cap.
• Optional active-vendor validation with backward compatibility.
• Properly guarded admin configuration.
• Updated funding events with the required monitoring data.
• Tests covering repeated funding, cap limits, window resets, vendor validation, and normal loan flows.

I’ll keep the changes focused on the requested files, preserve the existing creditline restriction, and run the full test suite before submitting the PR.

[skull-X]

Hi 👋
I’m a blockchain developer with strong expertise in Stellar, Rust,TS and Stellar SDK integrations. I’ve worked on multiple Stellar-based smart contract and backend systems.

Plz assign me !!

ETA: 4 hours

[dimin4241-svg]

Hi, I’d like to work on this. I’ve worked with Rust/Soroban accounting invariants and understand the pool must enforce its own outflow and merchant-concentration limits, while keeping the creditline guard and optional vendor validation backward-compatible. I can deliver a focused implementation with cap/window/admin and honest-flow regression tests in about 2 days. Please assign me through GrantFox.

[Emeka-12]

Hi Team, I would love to take on this issue. Adding defense-in-depth risk controls to fund_loan() within liquidity-pool-contract is vital to protecting pool liquidity from upstream logic bugs or compromised credit line configurations.Before writing code, I will thoroughly review architecture-context.md, code-standards.md, and progress-tracker.md to ensure complete alignment with established Soroban smart contract patterns and storage layouts.To implement these safeguards:Per-Ledger Outflow & Concentration Caps: In storage.rs and types.rs, I will define storage helpers and configuration parameters for a per-ledger outflow cap (rolling window reset tracking total fund_loan volume) and a single-recipient cumulative merchant cap.Optional Vendor Cross-Check: In lib.rs, I will add an optional vendor_registry address configuration (settable during initialize() or via an admin setter). When configured, fund_loan() will invoke is_active(merchant) to verify vendor authorization before dispatching token transfers, maintaining full backward compatibility when unset.Granular Observability: I will extend the emit_loan_funded event payload to include merchant metrics and remaining cap thresholds for downstream indexer alerting.Testing & Verification: In tests.rs, I will add unit tests covering per-ledger outflow limits, merchant concentration ceilings, window resets, vendor registry check assertions (enabled/disabled), and admin access controls—confirming honest single-loan execution flows remain unaffected. I will also update context/progress-tracker.md upon completion.With strong experience in Rust, Soroban smart contracts, and protocol risk management, I am ready to deliver a clean implementation. Please assign this issue to me!

[grantfox-oss]

🦊 GrantFox — @Emeka-12 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 #106)
2. Your PR will be reviewed by the StepFi-app maintainers

Good luck! Track your progress on GrantFox.