Security & Audits
Security Overview
What has been hardened, what has been tested, and what is still trust.
The deployed contract is a hardened revision. Three P0 findings from the internal audit were fixed before deployment, and the live bytecode was re-verified byte-for-byte against the audited source.
| Runtime code | 11,028 bytes on Base |
| Compiler | solc 0.8.20, optimizer 200 runs, evmVersion paris |
| Source == deployment | 10 immutable slots differ, 0 unexplained bytes |
| Unit + invariant tests | 27 passing |
| Red-team scenarios | 11/11 blocked, 1 recovery path verified, 1 documented residual |
| On-chain attack suite | 43 checks, 0 failures (fork against real bytecode) |
What is enforced on-chain
- Every value-moving entry point is nonReentrant and follows checks-effects-interactions
- The bet token can never be rescued by anyone, including the owner ā a compromised key cannot drain the pool through rescueERC20
- Fees are escrowed per market and only released by settle(); a cancelled market releases nothing
- A cancelled market refunds 100% of gross stake, so the platform cannot keep rake on a void
- Anyone may force a cancelled market 30 days after the close time if the operator disappears
Documented residual risk
The owner is the oracle and may bet through a fresh wallet (address-based guard only blocks the owner address). This is a trust assumption, not a code hole ā decentralising settlement is the only complete fix and is scheduled for Phase 3.
Where to read more
- Hardened Contract Spec ā the exact invariants and storage layout
- P0 Vulnerabilities Mitigation ā F-01 / F-02 / F-03 in detail
- Emergency Escape Hatch ā the 30-day permissionless refund path