Repository navigation
fix(fundraiser): avoid overflow in contribution limits - #791
Bismithblde wants to merge 1 commit into
Conversation
|
Hi @Bismithblde, Thanks for the pull request. We ask that every change references an issue a maintainer has accepted, and there isn't one linked here. These examples are a teaching resource and each one has to stay small enough to read in one sitting, so whether a new example or framework flavor belongs here is worth settling before anyone writes it. Agreeing on the approach in an issue first means nobody writes code that can't be merged. See CONTRIBUTING.md for the full workflow. Please open an issue describing the change, or comment on the existing one. Once a maintainer has labelled it |
Linked issue
Fixes #790
What and why
A fundraiser target above
u64::MAX / 10is accepted at initialization, but even a one-token contribution panics when calculatingtarget * 10 / 100inu64.Calculate the contribution limit once in
u128and reuse it for both contribution checks. Widen the cumulative comparison as well. The existing 10% cap and rounding are preserved. Update the README's embedded implementation.Testing
attempt to multiply with overflow.u64::MAX / 10 + 1andu64::MAX, small contributions, the exact cumulative cap, over-limit rejections, token balances and recorded totals.NO_DNA=1 cargo build-sbf --manifest-path programs/fundraiser/Cargo.toml --sbf-out-dir target/deploy --tools-version v1.57 --arch v3.cargo testwith the shared local target directory passed all three fundraiser integration tests.git diff --checkpassed.AI disclosure