Skip to content

No test coverage for set_fee_split / distribute_fee at realistic recipient-map sizes #918

Description

@Ejirowebfi

🔴 Critical · contracts/token-factory/src/test.rs, contracts/token-factory/src/lib.rs:167-204

Description

The fee-split distribution logic performs per-recipient checked_mul/division/checked_add and an external transfer call per recipient inside a loop. Existing tests (inferred from test.rs naming conventions visible in test_snapshots/) appear to cover basic pause/burn/batch scenarios but there's no evidence of a test exercising set_fee_split + a subsequent fee-paying call (create_token/mint_tokens/set_metadata) with more than a trivial number of recipients, uneven basis-point distributions that produce rounding remainders, or a recipient with bps low enough that share floors to 0 (the if share > 0 skip at line 187). This is exactly the kind of arithmetic-heavy, loop-driven code most likely to hide an off-by-one, an unexpected zero-transfer skip that silently under-pays a recipient, or a remainder-accounting bug that leaks or double-counts fee-token units.

Tasks

  • Add a test: 2-way split (5000/5000 bps) on an odd fee amount, asserting both recipients receive floor(amount/2) and the 1-unit remainder lands on treasury.
  • Add a test: a recipient configured with bps low enough relative to a small fee_payment that its computed share is 0, asserting the transfer is correctly skipped and the recipient's full notional share is folded into the remainder sent to treasury (verify this matches the intended product behavior — currently a "skipped" small-share recipient's funds silently go to treasury rather than accumulating for them, which may itself be worth flagging as a product decision to confirm).
  • Add a test at MAX_FEE_SPLIT_RECIPIENTS (once issue Expand Contract Test Coverage #6 lands) verifying total distributed equals fee_payment exactly (no leaked or double-spent stroops), summed across all recipient balance deltas plus the remainder.
  • Add a fuzz target (or extend fuzz_fee_arithmetic) that generates random (fee_payment, splits) pairs (with valid bps summing to 10,000) and asserts the invariant sum(all transfers) == fee_payment always holds.

Acceptance Criteria

  • The three new unit tests above exist and pass.
  • The fuzz target runs for at least 5 minutes with no invariant violation.
  • Test coverage report (if generated via cargo tarpaulin or similar) shows distribute_fee's split branch as covered by more than the "happy path, 1 recipient" case.

Metadata

Metadata

Labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions