fix(math): correct distribute_fees fee split at extreme values — senior no longer zeroed (closes #120) - #133
Conversation
…dcccrypto#120) In the overflow path, part2 computed r * junior_weight / total_weight, but r (< total_weight, ~2^81) * junior_weight (~2^80) overflows u128, and the unwrap_or(total_fee) fallback then handed the junior tranche 100% of the fee (0% to the protected senior tranche). Compute part2 with an exact, overflow-safe 256-bit mul-div (mul_div_floor: full 256-bit product via u64 limbs, then bitwise long division). Added unit tests with arbitrary-precision-verified expected splits for the overflow cases (symmetric/junior-heavy/senior-heavy/mid). Full suite incl. proptest_math passes. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
|
Warning Review limit reached
More reviews will be available in 24 minutes and 41 seconds. Learn how PR review limits work. Your organization has used up its prepaid credits, and credit purchases are no longer available. Enable the review add-on in the billing tab to keep reviews running — you're only billed for reviews past your plan's rate limits ($0.25/file). ⌛ How to resolve this issue?After more reviews become available, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans include higher PR review limits than trial, open-source, and free plans. In all cases, reviews become available again over time. During sustained high-volume PR review activity, CodeRabbit may temporarily slow when the next review becomes available. Please see our Fair Usage Limits Policy for further information. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
2 participants
Closes #120.
In
distribute_fees's overflow path,part2 = floor(r * junior_weight / total_weight)was computed asr.checked_mul(junior_weight).map(|p| p / total_weight).unwrap_or(total_fee as u128). Withr < total_weight(~2^81) andjunior_weightup to ~2^80, the productr * junior_weight(~2^161) overflows u128, sochecked_mulreturnsNoneand the fallbackunwrap_or(total_fee)hands the junior tranche 100% of the fee — 0% to the protected senior tranche.This replaces that fallback with an exact, overflow-safe
mul_div_floor(r, junior_weight, total_weight)(full 256-bit product via u64 limbs, then bitwise long division).part1is unchanged — it's already bounded byjunior_weight <= total_weight, so it can't overflow.Verification:
test_distribute_fees_overflow_proportionalwith expected splits computed via arbitrary-precision integers, e.g. symmetricu64::MAXbalances at 5x → junior15372286728091293012(~5/6), senior3074457345618258603(~1/6) — previously junior got 100%.test_mul_div_floor_matches_native_when_product_fits(fast-path agreement + a slow-path sanity case).cargo testpasses — includingproptest_math(17) andproptest_extended(34); no property regressed.Note: the
kani.rsharness is unaffected by this change (conservation + senior-protection still hold), but worth re-running it on your side as a belt-and-suspenders check.