Persist and enforce a single canonical max escrow cap across create_contract and deposit

[mikewheeleer]

Description

lib.rs defines two conflicting caps: MAX_TOTAL_ESCROW_STROOPS = 10_000_000_000_000 (enforced in create_contract) and MAINNET_MAX_TOTAL_ESCROW_PER_CONTRACT_STROOPS = 1_000_000_000_000_000 (reported by get_mainnet_readiness_info but never enforced). amount_validation.rs adds a third bound MAX_SINGLE_AMOUNT_STROOPS. Consolidate to one enforced, governable cap to avoid silent mismatch between reported and enforced limits.

Requirements and context

• Scoped to TalentTrust escrow Soroban contract (contracts/escrow).
• Choose a single canonical per-contract cap, enforce it in create_contract and as the ceiling in deposit_funds, and have get_mainnet_readiness_info report the same value.
• Document the relationship between per-contract cap and amount_validation::MAX_SINGLE_AMOUNT_STROOPS.
• Invariant: the cap reported by readiness equals the cap enforced at create/deposit time.
• Must be secure, tested, and documented.

Suggested execution

• Fork the repo and create a branch:
  • git checkout -b security/canonical-escrow-cap
• Implement changes:
  • contracts/escrow/src/lib.rs
  • Tests: contracts/escrow/src/test/mainnet_readiness.rs
  • Docs: docs/escrow/mainnet-readiness.md
  • Include rustdoc/NatSpec-style doc comments on public functions
  • Validate security assumptions (auth, overflow, fail-closed state machine, storage TTL, fee accounting)

Test and commit

• Run tests: cargo test
• Cover edge cases (unauthorized callers, double release/refund, expired approvals, fee rounding, paused state)
• Include test output and security notes in the PR

Example commit message

fix(escrow): unify enforced and reported escrow caps

Guidelines

• Minimum 95% test coverage on new/changed code
• Clear documentation
• Timeframe: 96 hours from assignment

[ZEMAD0N26]

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

Please kindly assign me to this issue, thank you!

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

[drips-wave]

Congratulations, @ZEMAD0N26! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 2, 2026.

🧑‍💻 @ZEMAD0N26: 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 🌊