Rigor Protocol — disclosed vulnerability reports and payouts
Every publicly disclosed and closed bug bounty report we hold for Rigor Protocol, with our own summary of each finding and a link to the original disclosure.
- Reports indexed
- 3
- Total paid
- $0
- Critical
- 0
- Largest payout
- $0
This page collects the 3 closed, publicly disclosed Rigor Protocol reports indexed on Coin Buggie. Nothing here is active or unpatched — every entry was published by the programme or the researcher after remediation.
The findings concentrate in Reentrancy, Logic error, across EVM-Solidity. Reading a single protocol end to end is the fastest way to see which assumptions its codebase repeatedly gets wrong, which is usually a better predictor of where the next finding lives than the category alone.
Use the vulnerability class links below to compare these findings against the same bug class in other protocols.
What reviewers look for
- Reentrancy findings disclosed against Rigor Protocol
- Logic error findings disclosed against Rigor Protocol
Curated highlights
The largest disclosed payouts in this group, with our own summary of each. Every report links back to the original disclosure.
Rigor Protocol: New subcontractor can be set for a SCConfirmed task without current subcontractor consent
Rigor Protocol's subcontractor management lets a builder or contractor reassign a task's subcontractor through inviteSC() without any signature check, whereas changing terms mid-task normally requires consent from all parties via checkSignatureTask(). Although the direct path (replacing a subcontractor on an already-confirmed, active task) is blocked by inviteSubcontractor()'s onlyInactive modifier, the warden showed the check is bypassed in changeOrder() budget-increase flows: when added funds are not yet lent, the task is unapproved and reset to inactive, after which a dishonest contractor can invite their own subcontractor who then collects the full task budget on completion, divesting the subcontractor who actually performed the work of their payment.
Rigor Protocol: Task Functionality completely sidestepped via `autoWithdraw`
Rigor Protocol's Project contract exposes an `autoWithdraw` path that always forwards funds to the builder's wallet when a task's allocated cost is reduced. Because only the builder's signature is required for `addTasks`, `allocateFunds`, and `changeOrder`, a builder can repeatedly create, allocate, and reduce task costs to drain all funds out of the Project contract into their own wallet. This bypasses the task-based accounting and transparency guarantees, leaving no funds in the contract to enforce project progress. The judge confirmed the finding's validity as a trust/transparency invariant break and downgraded severity from High to Medium.
Rigor Protocol: `Project.addTasks()` wouldn't work properly when it's called from disputes contract.
A stale task-count consistency check in Rigor's Project.addTasks() causes task additions to revert when a dispute is pending. Because disputes take days to resolve while builders/contractors may legitimately add tasks in the interim, the project becomes unable to add new tasks (beyond the count snapshot at raiseDispute time) until the dispute is settled. The report proposes skipping the taskCount equality check when addTasks is invoked from the disputes contract, and the developer confirmed the issue.