Problem
The escrow contract (escrow/src/lib.rs, escrow/src/error.rs, escrow/src/events.rs, escrow/src/test.rs) is a fully-implemented, real fourth contract in this repository — with its own lifecycle (Locked → Released | Refunded), its own error type, its own events, and its own test suite — yet it is not mentioned anywhere in the README's feature table, architecture overview, or API reference (all three of which, per the existing issues in this batch, discuss fee_collector, stellar_send, and token_bridge as if they are the complete set of contracts in the repo). It's also absent from issue #5's original workspace-config members list and issue #4's originally-described CI matrix, both of which had to be corrected in this batch's addenda to include it.
Why it matters
A repository README is the primary orientation document for both external contributors evaluating bounty issues and integrators deciding what to build against. A fully-functional contract that's simply invisible in that document means: contributors may not realize there's a fourth surface area to find bugs in or extend, integrators may not discover a conditional-transfer/escrow primitive already exists (and might reimplement one elsewhere unnecessarily), and any onboarding contributor reading only the README would reasonably conclude the repo has three contracts, not four.
Detection
grep -i escrow README.md — confirm zero matches (verify directly against the current README; if a match is found, this issue may already be partially addressed and should be scoped down to whatever gaps remain).
Proposed fix
Add an escrow section to the README's feature table and API reference, following the same structure/depth already used for the other three contracts (storage layout summary, public function list with parameters, error enum reference, events table). Source the release/refund rules directly from the extensive module doc comment already at the top of escrow/src/lib.rs (lines 1-33), which is thorough and can largely be adapted rather than written from scratch.
Edge cases
- Should also cross-reference the architecture-level relationship between
escrow and the other three contracts — the module doc comment already explains this well ("a distinct concern from stellar_send... because escrowed funds are held by the contract itself across an arbitrary number of ledgers"), so the README addition should preserve that framing rather than just listing escrow as an unrelated fourth item.
Testing strategy
Documentation-only change; "testing" here means a documentation review pass confirming every public function in escrow/src/lib.rs's #[contractimpl] block (create_escrow, release_escrow, refund_escrow, get_escrow) has a corresponding, accurate README entry, and that the described release/refund/grace-period rules match the actual code (especially once issues #9/#10/#11 in this batch land and change some of that behavior).
Problem
The
escrowcontract (escrow/src/lib.rs,escrow/src/error.rs,escrow/src/events.rs,escrow/src/test.rs) is a fully-implemented, real fourth contract in this repository — with its own lifecycle (Locked → Released | Refunded), its own error type, its own events, and its own test suite — yet it is not mentioned anywhere in the README's feature table, architecture overview, or API reference (all three of which, per the existing issues in this batch, discussfee_collector,stellar_send, andtoken_bridgeas if they are the complete set of contracts in the repo). It's also absent from issue #5's original workspace-configmemberslist and issue #4's originally-described CI matrix, both of which had to be corrected in this batch's addenda to include it.Why it matters
A repository README is the primary orientation document for both external contributors evaluating bounty issues and integrators deciding what to build against. A fully-functional contract that's simply invisible in that document means: contributors may not realize there's a fourth surface area to find bugs in or extend, integrators may not discover a conditional-transfer/escrow primitive already exists (and might reimplement one elsewhere unnecessarily), and any onboarding contributor reading only the README would reasonably conclude the repo has three contracts, not four.
Detection
grep -i escrow README.md— confirm zero matches (verify directly against the current README; if a match is found, this issue may already be partially addressed and should be scoped down to whatever gaps remain).Proposed fix
Add an
escrowsection to the README's feature table and API reference, following the same structure/depth already used for the other three contracts (storage layout summary, public function list with parameters, error enum reference, events table). Source the release/refund rules directly from the extensive module doc comment already at the top ofescrow/src/lib.rs(lines 1-33), which is thorough and can largely be adapted rather than written from scratch.Edge cases
escrowand the other three contracts — the module doc comment already explains this well ("a distinct concern fromstellar_send... because escrowed funds are held by the contract itself across an arbitrary number of ledgers"), so the README addition should preserve that framing rather than just listingescrowas an unrelated fourth item.Testing strategy
Documentation-only change; "testing" here means a documentation review pass confirming every public function in
escrow/src/lib.rs's#[contractimpl]block (create_escrow,release_escrow,refund_escrow,get_escrow) has a corresponding, accurate README entry, and that the described release/refund/grace-period rules match the actual code (especially once issues #9/#10/#11 in this batch land and change some of that behavior).