Arithmetic hardening: saturating_add on earnings and next_event_id should be checked

[0xdevcollins]

Severity: LOW · Contract · boundless-profile + boundless-events

Surfaced by the Almanax scan of e1f17937. Closes Earnings overflow silently clamps to i128 max and Saturating event-id counter can freeze at u64 max.

Files

• contracts/profile/src/earnings.rs:28-30 — register earnings saturating_add
• contracts/events/src/idempotency.rs:33-38 — next_event_id double saturating_add

Problem

• Earnings accumulate with saturating_add, which silently pins a (user, token) value at i128::MAX forever on overflow → irrecoverable accounting drift; later increments are no-ops.
• next_event_id saturating at u64::MAX freezes the counter, returning the same id forever → id collisions / event-state aliasing.

Fix

Use checked arithmetic that reverts with a typed error:

• current.checked_add(amount).ok_or(Error::EarningsOverflow)?
• id.checked_add(1).ok_or(Error::EventIdOverflow)? (and the stored next-id)

This aligns with the repo hard rule ("no unwrap on host Option/Result; return a typed Error"). Reverting is the correct failure mode for both.

Tests

• Overflow inputs return the typed error rather than clamping.

[coderabbitai]

🔗 Related PRs

#46 - test: hackathon pillar — select_winners distribution + claim [merged]
#47 - test(events): added bounty pillar — apply / withdraw_application + c… [merged]
#48 - test(profile): add credits.rs coverage for spend/earn/refund/admin_grant [merged]
#51 - test(profile): earnings register — full coverage [merged]
#54 - test(coverage): add 9 test modules for contract test coverage push [merged]

---

📝 Issue Planner

_{Check the box below or use the @coderabbitai plan command to generate an implementation plan and prompts that you can use with your favorite coding assistant.}

• Create Plan

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord!

[Violetlove200100]

I'd like to work on this issue. My plan is to review the arithmetic operations involving earnings and next_event_id, verify that saturating_add is used correctly to prevent overflow, implement any necessary fixes, and add tests to cover edge cases.
I'll ensure the solution is well-tested and follows the project's coding standards. I look forward to contributing.

[SudiptaPaul-31]

Hey Maintainer!!! My name is Sudipta Paul a very old contributor of GrantFox and other platform having quite a lot of experience in open source and working with full stack issues as well as very much proficient in writing contracts and would love to work on this issue and contribute to your project, May I be assigned to this task

[Shadow-MMN]

Hey,

I'd like to work on this issue.

From my understanding, the goal is to replace the current saturating_add behavior with checked arithmetic in both the profile earnings accounting and the event ID generation logic. Rather than silently clamping values on overflow, the contract should return typed errors that align with the repository's error-handling conventions and prevent irreversible accounting drift or event ID collisions.

My implementation will replace the existing saturating_add calls with checked_add and return the appropriate typed errors (EarningsOverflow and EventIdOverflow) when an overflow occurs. I'll also add the corresponding tests to verify that overflow scenarios correctly return the expected errors instead of silently saturating, while ensuring the existing success paths remain unchanged.

I've previously contributed to this repository, so I'm already familiar with its contract architecture, coding standards, and the requirement to return typed errors instead of relying on host panics or silent failure modes. You can also review my previous work and experience on my GitHub profile.

ETA: Within 1 day.