Reject a Split dispute resolution whose components are individually within but jointly exceed balance
Description
resolution_payouts in contracts/escrow/src/dispute.rs handles DisputeResolution::Split(client, freelancer) by rejecting negative components and requiring client + freelancer == available. The safe_add_amounts guard catches overflow, but the boundary where each component is a large positive value near i128::MAX such that their sum overflows — and must be rejected as PotentialOverflow rather than wrapping into a value that coincidentally equals available — is not directly tested.
This issue adds targeted tests proving the Split validation rejects overflow-prone and mismatched component pairs, and accepts only exact, conserving splits.
Requirements and context
- Repository scope: Talenttrust/Talenttrust-Contracts only.
- Test:
Split with a negative component returns InvalidDisputeSplit.
- Test:
Split whose components sum to less/more than available returns InvalidDisputeSplit.
- Test:
Split components near i128::MAX that would overflow return PotentialOverflow, not a wrapped match.
- Test: an exact, conserving
Split succeeds and updates released_amount/refunded_amount correctly.
Suggested execution
- Fork the repo and create a branch
git checkout -b security/contracts-split-overflow-guard
- Implement changes
- Test and commit
Test and commit
- Run
cargo fmt --all -- --check, cargo build, and cargo test.
- Cover negative, mismatched, overflow, and exact splits.
- Include the full
cargo test output in the PR description.
Example commit message
test: harden Split dispute validation against overflow and mismatch
Guidelines
- Minimum 95 percent test coverage for impacted modules.
- Clear, reviewer-focused documentation.
- Timeframe: 96 hours.
Community & contribution rewards
- 💬 Join the TalentTrust community on Discord for questions, reviews, and faster merges: https://discord.gg/WqnGpcPx
- ⭐ This is a GrantFox OSS / Official Campaign task and may be rewarded. When your PR is merged you'll be prompted to rate the project — if this issue and the maintainers helped you ship, we'd be grateful for a 5-star rating. Clear questions in Discord and tidy, well-tested PRs are the fastest path to a merge and a reward.
Reject a Split dispute resolution whose components are individually within but jointly exceed balance
Description
resolution_payoutsincontracts/escrow/src/dispute.rshandlesDisputeResolution::Split(client, freelancer)by rejecting negative components and requiringclient + freelancer == available. Thesafe_add_amountsguard catches overflow, but the boundary where each component is a large positive value neari128::MAXsuch that their sum overflows — and must be rejected asPotentialOverflowrather than wrapping into a value that coincidentally equalsavailable— is not directly tested.This issue adds targeted tests proving the
Splitvalidation rejects overflow-prone and mismatched component pairs, and accepts only exact, conserving splits.Requirements and context
Splitwith a negative component returnsInvalidDisputeSplit.Splitwhose components sum to less/more thanavailablereturnsInvalidDisputeSplit.Splitcomponents neari128::MAXthat would overflow returnPotentialOverflow, not a wrapped match.Splitsucceeds and updatesreleased_amount/refunded_amountcorrectly.Suggested execution
git checkout -b security/contracts-split-overflow-guardcontracts/escrow/src/dispute.rsonly if the overflow ordering needs hardening.contracts/escrow/src/test/dispute.rsandcontracts/escrow/src/test/resolution_payouts_prop.rs.docs/escrow.///) on the Split branch.Test and commit
cargo fmt --all -- --check,cargo build, andcargo test.cargo testoutput in the PR description.Example commit message
test: harden Split dispute validation against overflow and mismatchGuidelines
Community & contribution rewards