Security is a continuous process for Levr Bet, and we believe transparency is part of earning trust. As we approach launch, we’ve completed multiple independent security audits across the Levr Bet smart contract system, remediated confirmed issues, and documented outcomes.
This post summarizes the audits we’ve completed, how we categorize fixes vs. acknowledgements, and what we’re doing next.
Why we do multiple audits
Different auditors and different methodologies catch different classes of risk, business logic bugs, edge-case settlement failures, denial-of-service vectors, access control mistakes, and integration hazards. No audit can guarantee the absence of bugs, so our approach is layered:
- Multiple independent security audits
- Remediation cycles with clear tracking
- Strong internal testing and review discipline
- Monitoring and operational controls
- Additional audits and a public-facing security program as we approach mainnet readiness
Audit summary
0xWeiss - Security Audit (Jan 2026)
We engaged 0xWeiss through Hyacinth Audits (https://www.hyacinthaudits.xyz/). 0xWeiss is an independent security researcher specializing in smart contract auditing with 4+ years in the auditing space and experience helping secure DeFi protocols.
The engagement ran over multiple weeks and focused on practical exploit paths and protocol safety across core mechanics.
Vulnerability summary:
- High: 1 (fixed)
- Medium: 5 (4 fixed, 1 acknowledged)
- Low: 7 (6 fixed, 1 acknowledged)
- Informational: 4 (3 fixed, 1 acknowledged)
Octane - Security Analysis of Levr (Jan 2026)
Octane performed an analysis using automated techniques paired with team feedback and triage.
Summary of findings:
Octane identified 13 issues, with 13/13 confirmed, and recorded outcomes as resolved or acknowledged.
Severity breakdown:
- Critical: 0
- High: 1
- Medium: 2
- Low: 4
- Informational: 6
The report also highlights areas where the current architecture relies on explicit operational assumptions (for example, what is enforced by an off-chain orderbook component vs. what is enforced on-chain). Those items are tracked as acknowledged, with a clear direction to migrate more validation on-chain in future iterations.
How we treat “Acknowledged” findings
In audit reports, “Acknowledged” does not mean “ignored.” It usually means one of the following:
- The item is a known tradeoff of the current architecture
- The item is out of scope for the version being reviewed
- The item is mitigated through operational controls and monitoring
- The item will be addressed in a future version where the design changes meaningfully
We track acknowledged items explicitly because they’re part of being honest about the system’s current assumptions.
What we changed as a result
Across these security audits, remediation work focused on:
- Hardening core flows where user funds or settlement correctness are at stake
- Tightening permissions and role-based access control
- Expanding negative testing and scenario coverage
- Improving clarity around assumptions, failure modes, and operational mitigations
What’s next
- Continued internal review and testing improvements
- Additional independent security audits as the codebase stabilizes
- A public security process (including a disclosure channel and, when appropriate, incentives)
Read the reports
- 0xWeiss - Security Audit (PDF)
- Octane - Security Analysis (PDF)
