Quantstamp reviewed OnRe (OnRe - mmbot) on 7 Apr 2026: 3 findings, 0 critical; 2 marked fixed, 1 acknowledged.
Report hosted on certificate.quantstamp.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 0 |
| Medium | 0 | 0 | 0 |
| Low | 0 | 1 | 2 |
The initialize instruction accepts `onre_program_id` as a caller-supplied parameter. This value is used to validate the `onre_state` account via owner and seeds constraints, and is then stored permanently in `ProgramState`. All subsequent boss and admin authorization checks (`withdraw`, `set_executor`, `set_kill_switch`) derive the `onre_state` PDA from this stored value. However, because `onre_program_id` is a free parameter at initialization, an attacker who observes the program deployment can front-run the legitimate initialization by deploying their own fake program with a state PDA containing the attacker's pubkey as boss. The attacker calls initialize with their fake `onre_program_id`, signs as the boss that matches their fake state, and all Anchor validations pass. The `ProgramState` is then permanently linked to the attacker's program. Since init can only be called once, the legitimate team is locked out. This could lead to full program takeover if initialization is not performed atomically with deployment. The attacker would control the boss role, could set the executor to their own key, disable the kill switch, and withdraw any funds deposited after the hijack. The legitimate boss of the real Onre program would have no authority over the mmbot program.
The report names a repository or files. Open the report to see its scope.
236 projects reviewed · 332 reports · latest Oct 2026
See Quantstamp’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us