Overview
escrow::release and milestones::release_issue both compute fee + payouts via the shared mergefi_common::compute_split (contracts/common/src/split.rs). maintenance-pool::withdraw (contracts/maintenance-pool/src/lib.rs:158-211) instead computes its fee inline, independently:
let fee = amount * (fee_bps as i128) / BPS_DENOMINATOR;
let payout = amount - fee;
(:185-186). Functionally this is fine today (there's only one recipient, so there's no dust-distribution question compute_split's largest-remainder logic exists to solve), but it means there are now two independent implementations of "compute a fee from bps" in this codebase that could in principle drift (e.g. if compute_split's fee-rounding direction is ever revisited for #6/#28-style dust analysis, maintenance-pool wouldn't inherit that fix automatically since it doesn't call the shared function at all).
Requirements
Either route withdraw's fee computation through a shared single-recipient helper in mergefi_common (even if it's a thin wrapper that skips the multi-recipient dust logic), or, if keeping it inline is intentional (e.g. because a full compute_split call for a single recipient is unnecessary overhead), add a comment at contracts/maintenance-pool/src/lib.rs:185 explaining why this one path is deliberately not centralized, so a future reader doesn't mistake it for an oversight.
Acceptance Criteria
Additional Notes
Verified via direct inspection of contracts/maintenance-pool/src/lib.rs:180-186 vs. contracts/escrow/src/lib.rs:312-318 and contracts/milestones/src/lib.rs:384-390 (both call mergefi_common::compute_split).
Overview
escrow::releaseandmilestones::release_issueboth compute fee + payouts via the sharedmergefi_common::compute_split(contracts/common/src/split.rs).maintenance-pool::withdraw(contracts/maintenance-pool/src/lib.rs:158-211) instead computes its fee inline, independently:(
:185-186). Functionally this is fine today (there's only one recipient, so there's no dust-distribution questioncompute_split's largest-remainder logic exists to solve), but it means there are now two independent implementations of "compute a fee from bps" in this codebase that could in principle drift (e.g. ifcompute_split's fee-rounding direction is ever revisited for #6/#28-style dust analysis,maintenance-poolwouldn't inherit that fix automatically since it doesn't call the shared function at all).Requirements
Either route
withdraw's fee computation through a shared single-recipient helper inmergefi_common(even if it's a thin wrapper that skips the multi-recipient dust logic), or, if keeping it inline is intentional (e.g. because a fullcompute_splitcall for a single recipient is unnecessary overhead), add a comment atcontracts/maintenance-pool/src/lib.rs:185explaining why this one path is deliberately not centralized, so a future reader doesn't mistake it for an oversight.Acceptance Criteria
cargo test --workspacepassesAdditional Notes
Verified via direct inspection of
contracts/maintenance-pool/src/lib.rs:180-186vs.contracts/escrow/src/lib.rs:312-318andcontracts/milestones/src/lib.rs:384-390(both callmergefi_common::compute_split).