fix: add sanity upper bound on src_amount/min_dst_amount inputs

[bambuska-man]

fix: add sanity bounds, reentrancy tests, economic security tests,
and fill_amount trust docs

Closes #41
Closes #40
Closes #39
Closes #38

---

What changed

#41 — Sanity upper bound on src_amount / min_dst_amount

submit_intent previously only checked that amounts were positive. A
fat-fingered
or malicious caller could pass an astronomically large value that
interacts badly
with fee/slash arithmetic downstream.

• Added MAX_AMOUNT = 10^30 constant (one trillion 18-decimal tokens
  — round,
  economically implausible, and well within i128::MAX / PROTOCOL_FEE_BPS so
  fee multiplication can never overflow)
• Added Error::AmountTooLarge (variant 22)
• Guard added in submit_intent immediately after the existing
  zero-amount check
• 4 boundary tests: at-max succeeds, src one-above-max fails, min_dst
  one-above-max
  fails, i128::MAX fails

#40 — Reentrancy-focused tests using a hostile mock SEP-41 token

None of the existing tests used a non-SAC destination token. Added:

• HostileToken — a minimal self-contained SEP-41 implementation
  registered as
  dst_token in tests, with only transfer and balance doing real
  work
• setup_with_hostile_dst / hostile_mint helpers
• 4 tests covering fill_intent, storage ordering
  (checks-effects-interactions),
  slash_solver, and a double-call to register_solver (simulating
  a hypothetical
  hostile-token callback)

Note: Soroban's single-threaded execution model prevents true
EVM-style mid-frame
reentrancy. These tests instead confirm correct CEI ordering and
compatibility with
arbitrary SEP-41 implementations.

#39 — Economic security test: MIN_BOND vs worst-case notional

MIN_BOND is a flat 50 USDC regardless of intent size. A min-bonded
solver can
accept a trillion-USDC intent and lose only 5 USDC if they default —
0 basis points
of notional.

• economic_security_min_bond_slash_vs_large_notional — documents
  the gap with a
  10^19-unit intent; asserts the penalty rounds to 0 bps
  (intentionally failing
  to be "safe", to make the gap visible)
• economic_security_proportionate_bond_yields_meaningful_penalty —
  positive
  counterpart showing that a solver bonded at 1% of notional produces
  a ≥10 bps
  penalty, documenting the target ratio for a future accept_intent
  guard

A follow-up design issue should add a per-intent bond-to-notional
ratio check
inside accept_intent.

#38 — Trust-assumption docs for solver-reported fill_amount

The Known Limitations section was added to the README covering:

• What is and isn't verified on-chain (fill_amount is
  solver-attested)
• The unverified source-chain leg
• Planned mitigation via cross-chain proof verification
• Impact scope for auditors and integrators

---

Testing

All new tests are in intent_settlement/src/test.rs. No existing
tests were modified.

[drips-wave]

@bambuska-man Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits.

You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀

Learn more about application limits