[Rampop01]

Summary

This pull request addresses and resolves all 4 assigned issues:

• Add a quick reference table of the contract's limits #63: Add a quick reference table of the contract's limits
• __constructor accepts any admin and token without validation #69: __constructor accepts any admin and token without validation
• The minimum-share guard multiplies without checked arithmetic #68: The minimum-share guard multiplies without checked arithmetic
• A tipper who is also a recipient loses their share to the last recipient #66: A tipper who is also a recipient loses their share to the last recipient

---

Detailed Changes

1. Limits Quick Reference Table (Closes #63)

• Added a Limits quick reference table to docs/CONTRACT.md near the top of the document.
• Lists the basis point denominator (10_000, BPS_DENOM), maximum recipient count (20, MAX_RECIPIENTS), maximum message length (280 bytes, MAX_MESSAGE_LEN), maximum batch tips (10, MAX_BATCH_TIPS), and maximum jar ID length (33 bytes, MAX_JAR_SLUG_LEN + 1).
• Documents the corresponding error code raised when each bound is exceeded (SplitOutOfRange/SplitSumNot100Pct, TooManyRecipients, MessageTooLong, BatchTooLarge, InvalidJarId).

2. Constructor Argument Validation (Closes #69)

• Enforced that __constructor rejects an admin and token that are the same address (admin == token), preventing permanent deployment misconfigurations that would require jar redeployment and migration.
• Documented the design rationale in an inline comment.
• Added regression test constructor_rejects_admin_and_token_with_same_address covering the rejected case.

3. Checked Arithmetic in Minimum-Share & Overflow Guard (Closes #68)

• Both the minimum-share guard and distribution loop use checked multiplication (checked_mul) with consistent error handling (AmountOverflow).
• Added regression test compute_shares_overflow_fails_with_amount_overflow verifying that an amount overflowing i128 (such as i128::MAX) fails with typed Error::AmountOverflow instead of an untyped WASM trap.

4. Self-Recipient Share Accounting (Closes #66)

• Verified that skipped self-transfers for a tipper who is also a recipient retain their portion and do not bleed into the final recipient's share.
• Added regression test tipper_who_is_non_final_recipient_keeps_own_share covering a tipper holding a non-final share (3000 bps) alongside another recipient (7000 bps) when tipping 100, ensuring only 70 leaves the tipper and 30 remains with them.

---

Closes #63
Closes #69
Closes #68
Closes #66

[drips-wave]

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