[Bug] Enforce bond_amount <= i128::MAX / 2 at initialization

[collinsezedike]

Description

resolve computes let payout = assertion.bond * 2; when a dispute resolves, but initialize only rejects bond_amount <= 0. There is no upper bound, so a large enough bond_amount overflows on the doubling.

Steps to reproduce

1. Call initialize with bond_amount close to i128::MAX (anything greater than i128::MAX / 2).
2. Have an asserter post an assertion and a disputer dispute it.
3. Have resolvers vote to a majority.

Expected behavior

initialize rejects a bond_amount that could overflow bond * 2 during resolution, with a new Error variant (e.g. InvalidBondAmount extended, or a new variant).

Actual behavior

initialize accepts the value. The overflow happens later, inside resolve, at the point the payout is computed, permanently stranding both bonds since the dispute can never successfully resolve.

Environment

• Network: local
• Contract: tholos
• Commit or tag: f9ad187

Possible impact

Yes, this affects fund safety: both the asserter's and disputer's bonds become permanently locked in the contract once a dispute on an overflow-prone assertion is resolved, since the payout transfer can never succeed. This does not rise to a live vulnerability requiring private disclosure since it requires the admin to configure an extreme bond_amount, not something an attacker can trigger against a sanely configured deployment, so a public issue is appropriate rather than SECURITY.md.

[Cyber-Mitch]

Hi, I'd like to apply for this issue.

This is a clean fund-safety fix and squarely my area — I'm a smart contract security researcher, and "permanently stranded funds from an unhandled arithmetic edge case" is exactly the class of bug I look for.

Fix: in initialize, reject bond_amount > i128::MAX / 2 (in addition to the existing <= 0 check), returning a dedicated error variant rather than overloading the existing one, since the failure modes are distinct (invalid input vs. overflow-prone input).

Tests: initialize with bond_amount at exactly i128::MAX / 2 succeeds; bond_amount one above that boundary is rejected; and I'd add a full end-to-end repro of the original bug report (assert → dispute → resolve) confirming resolution now succeeds cleanly at the boundary instead of stranding funds, so the fix is verified against the actual failure path, not just the input-validation boundary in isolation.

I'll complete the task within a day of assignment and open a draft PR early once the check and boundary tests are up.

[grantfox-oss]

🦊 GrantFox — @Cyber-Mitch has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #34)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Cyber-Mitch's PR #45 was approved and merged by @collinsezedike.

🏆 @Cyber-Mitch: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (363 total points). Track your full progress on GrantFox.

👏 Great work, @Cyber-Mitch! Keep contributing to drydocs.