[aduagba4133]

Summary

• Add create_split_escrow for up to eight unique payees with positive basis-point shares totaling exactly 10,000; keep create_escrow as the one-payee form.
• Record the split in get_escrow and distribute payments directly on release. Shares are floored in order and the final recipient gets the remainder, preserving the exact total.
• Add contract regression tests, docs, and ADR 0010.

Closes #22

Verification and follow-up

• Added tests for split rounding and conservation, one-payee compatibility, invalid totals, and duplicate payees. Tests were not run, per the requested fast workflow.
• Did not run a WASM build, regenerate TypeScript bindings, or measure resource use at the eight-payee maximum. Those should be completed before deployment; ROADMAP.md records them as pending.
• Per repo policy, this is source-only and testnet-only until security review.

[drips-wave]

@aduagba4133 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

[afeezorobsco-cyber]

@aduagba4133

This PR has merge conflicts with main, which has moved on since this branch was created. Please rebase onto the latest main (or merge main into your branch), resolve the conflicts, and push. CI will then re-run, and the PR can be merged once it's conflict-free, CI is green and it's been reviewed. Thanks!

[afeezorobsco-cyber]

@aduagba4133 Thanks for the PR. It can't be merged yet. To unblock it:

Merge conflicts: this branch conflicts with main. Please rebase onto the latest main (git fetch upstream && git rebase upstream/main), resolve the conflicts (often ROADMAP.md, ARCHITECTURE*.md or prisma/schema.prisma), and force-push.

Push to this same branch and CI will re-run. Once it's green and conflict-free, it'll be reviewed for merge.

[zeemscript]

Hi @afeezorobsco-cyber — I reviewed the conflict against current main. It now overlaps the escrow storage model and settlement paths, plus README/architecture/roadmap edits; resolving mechanically would risk dropping newer contract behavior or introducing a storage compatibility break. I left the branch unchanged. Could you advise whether this split-payout feature should be redesigned against the current storage schema before rebasing?

[zeemscript]

@afeezorobsco-cyber I reviewed the current head and the merge against main still conflicts in the escrow storage and settlement logic, along with shared docs. The prior review correctly calls out that this needs a deliberate port to the current model; I have not merged or rewritten that behavior. The existing CI and malware scan pass on the current head. Please advise whether you want the split-payout implementation ported to the new storage model.

[aduagba4133]

@afeezorobsco-cyber I updated the split payout implementation on current main and pushed the audit delta note. The full Rust contract suite, focused split tests, release WASM build, generated-binding check, and resource-baseline check pass locally. PR #159 is mergeable and its refreshed malware scan passed. The TLA+ payout-destination invariant is updated; TLC could not run here because Java is unavailable. Please review the delta security note.

[github-actions]

@aduagba4133 This PR now has merge conflicts with main, most likely because #154 (fix(contract): keep failed releases recoverable) was just merged, so it can't be merged until it's rebased:

git fetch upstream            # upstream = https://github.com/DocForum/docforum-escrow.git
git rebase upstream/main
# resolve the conflicts, re-run the tests, then:
git push --force-with-lease

The usual culprits are shared docs like ROADMAP.md and ARCHITECTURE*.md. If the conflict is in the ROADMAP.md changelog, move your entry into a new file under changelog.d/ (see changelog.d/README.md) rather than resolving it in place, so it can't conflict again. CI re-runs when you push, and the needs-rebase label is removed automatically once the conflicts are resolved.

_{Automated message. It won't repeat unless the PR conflicts again after your next push.}

[afeezorobsco-cyber]

@aduagba4133 Heads-up: #268 just changed how contract PRs work in this repo. Your PR changes contracts/escrow/src/lib.rs, so CI's new "Contract changes use a fragment, not a version bump" step will fail it until you make these changes (details in contract-changes.d/README.md):

1. Revert your CONTRACT_VERSION change. This branch sets 2.7.0. Leave the line exactly as it is on main (currently 2.3.0). A maintainer bumps it once per batch now, so nobody picks the same "next" version any more.

2. Add a fragment, e.g. contract-changes.d/22-feat-contract-split-payouts-to-multiple.md:

   bump: minor
   ---
   Issue #22: one-paragraph summary of the contract change.

   Use patch for a behaviour fix with no interface change, minor for new entry points, arguments, events or errors, and major for breaking changes.

3. Switch your new Error codes to provisional ones (issue number × 100 + n). This branch adds InvalidPayeeList = 40, TooManyPayees = 41, DuplicatePayee = 42, InvalidBasisPoints = 43, SplitAmountOverflow = 44; use InvalidPayeeList = 2200, TooManyPayees = 2201, DuplicatePayee = 2202, InvalidBasisPoints = 2203, SplitAmountOverflow = 2204. The fold assigns the final numbers. Don't renumber existing codes.

This should also make your next merge from main much easier: the version line was the one thing every contract PR conflicted on.