Security Audit
Our security program, our most recent review, and how we handle what we find
Overview
Security is an ongoing program, not a one-time checkbox. Our contracts are reviewed repeatedly as the code evolves, and we hold ourselves to publishing where we stand — including a clear picture of our most recent review below.
The program covers four areas:
- Smart Contract Audit — repeated static-analysis and manual review of all deployed contracts, backed by an invariant test suite
- Application Penetration Test — black-box red-team testing of the live API and web app
- Application Security Scan — Bandit (Python) + Semgrep (full-stack) across backend and frontend code
- Dependency Audit — pip-audit (Python) + npm audit (Node.js) for known CVEs
These are rigorous, AI-assisted internal reviews — not a third-party audit. An independent third-party audit has not yet been completed. Because of that, our real-money launch is deliberately capped: entry fees are limited to the micro tier so that no player can put more at risk than that while the external audit is still outstanding. We will review the cap once that audit is complete.
Detailed reports are available on request — please contact our team.
Smart Contract Audit
Scope
| Contract | Purpose |
|---|---|
| TournamentEscrow | Escrow and settlement for every contest, player-paid registration |
| FeeManager | Tiered service-fee calculation, keyed to entry-fee size |
| PlatformState | Emergency kill-switches |
| GameRegistry | Approved-game and entry-fee-bound registry |
Every contest settles through TournamentEscrow — a head-to-head match runs as a two-player Sit & Go, so it uses the same reviewed code path as a full tournament. A second, older escrow contract for direct head-to-head matches exists in our codebase but no longer sits on any path a player can reach; it is excluded from the mainnet deployment and from the external audit scope.
Native ETH and BNB are escrowed and paid out directly — there is no wrapped-token contract and no intermediary in the settlement path. Service fees settle to a single treasury address rather than a separate on-chain contract.
Methodology
- Static Analysis: Slither, Mythril, and solhint across the full contract set
- Invariant Testing: Foundry property-based tests verifying that escrowed value is always conserved, plus a Hardhat regression suite
- Symbolic Proof: Halmos proves the service-fee arithmetic across the entire range of possible inputs rather than sampling it, and runs as a blocking build gate
- Property Fuzzing: Echidna generates tens of thousands of random transaction sequences against a live contest while fee settings are changed underneath it, checking that a fee rate locked at entry can never move
- Adversarial Verification: each candidate finding independently re-checked by multiple reviewers against the source before it is accepted, to filter false positives and confirm real ones line-by-line
- Manual Review: line-by-line review of all state-changing functions, access controls, and fund flows
- Solidity Version: pinned to 0.8.24 (overflow protection built in)
- Dependencies: OpenZeppelin v5 (Ownable, ReentrancyGuard, Pausable, SafeERC20, ECDSA)
Latest Re-Verification (August 2026)
Our most recent review, in August 2026, re-derived the current contract code from scratch with twelve specialty review agents across two independent toolchains. Its headline conclusion is unchanged and stronger: the core money paths are structurally sound. Escrowed value is conserved, checks-effects-interactions ordering is correct throughout, reentrancy guards are present on every value-moving function, and the pull-payment architecture is well-built. No critical and no high-severity findings, and no path by which an ordinary player or outside attacker could drain a correctly-deployed contract.
Every finding was independently re-derived by a separate skeptical reviewer whose instruction was to refute it before it could be accepted. That pass reversed four claimed medium-severity items down to low, and refuted two informational ones outright — each reversal verified against the source line by line. What remained were defence-in-depth items: fuller symmetry of sanctions handling between our escrow contracts, a firmer on-chain bound on one legacy creation path, and gas-capped payouts so a single unreachable recipient can never block anyone else's prize. All five were fixed the following day, and the fix removed the duplication that allowed them rather than patching each site.
When we re-checked a fix from the July review and proposed marking it closed, a reviewer whose only job was to disprove that claim traced the recovery condition rather than the recovery function — and found that an organiser's service-fee share, if it ever became unreachable through one of the two settlement paths, could never be recovered afterwards. The rescue function existed; the clock it depended on was only ever started by the other path.
No player prize was ever affected, the situation had never occurred, and the contracts involved existed only on our test networks. It was fixed the same day and both test networks were redeployed onto the corrected code on 2026-08-09. We are describing it in full because a finding that only surfaces when you attack your own conclusions is worth more than one found by reading code.
Thirteen of the fifteen findings from the July review are fixed in our contract codebase and verified by the full test suite — 229 Hardhat regression tests, 30 Foundry property and invariant tests, 12 symbolic proofs run as a blocking build gate, and a property-fuzzing campaign of over 50,000 generated transaction sequences, all passing. Of the remaining two, one is an accepted design decision documented in our risk register, and one is a low-severity deployment-configuration check enforced by our deploy scripts rather than by the contract itself.
The contracts currently live on our test networks are the reviewed builds, redeployed on 2026-08-09. Because no remaining finding is reachable without a compromised operator key — the exact scenario we separately invest in defending through hardware-backed key custody — there is no unprivileged exposure on the live contracts.
Earlier rounds (the March 2026 initial review, the July 2026 player-paid delta review, and the July 2026 pre-mainnet re-verification) were remediated and deployed on 2026-07-05, 2026-07-20 and 2026-08-07. The August round above supersedes them as our current security picture.
Application Penetration Test (July 2026)
Separately from the contract review, we ran an autonomous black-box penetration test against the live API and web app — no source code provided to the tester, real production endpoints, mapping and probing the same surfaces an outside attacker would: authentication and sessions, access control, the oracle and payout flow, server-side request handling, and the admin surface.
Authentication, access control (no IDOR / privilege-escalation paths), the oracle-signed payout flow, CSRF/CORS, two-factor authentication, and the admin surface all held up under active testing. The one meaningful item — session tokens not being rotated on re-login — and a handful of minor error-handling hardening points were fixed and deployed. A cross-chain signature-replay concern the tool flagged was refuted on source review: signed match results are bound to the chain, contract, and a per-match nonce.
Game-logic, WebSocket authorization and payout concurrency were subsequently covered by a dedicated round of deterministic regression tests, which is now part of the standing suite.
Application Security
Backend (Python/FastAPI)
| Tool | Scope | Result |
|---|---|---|
| Bandit | Full Python backend | 0 High (Medium findings are parameter-bound SQL patterns, not injection vectors) |
| Semgrep | Full backend | 0 findings |
| pip-audit | Python dependencies | Known CVEs tracked for upgrade on a regular cadence |
Frontend (React/Vite)
| Tool | Scope | Result |
|---|---|---|
| Semgrep | Full frontend | 0 findings |
| npm audit | Node.js dependencies | Tracked for upgrade; none affect production runtime behavior |
Dependency CVEs are tracked and upgraded on a regular cadence, subject to a minimum release-age cooldown so we never pull a freshly-published package blindly.
OFAC Compliance
SkillClassics screens all wallet addresses against the U.S. Treasury's Office of Foreign Assets Control (OFAC) Specially Designated Nationals (SDN) list. This is a regulatory requirement for platforms operating under U.S. jurisdiction.
Multi-Layer Screening
Wallet screening operates at three independent layers to prevent sanctioned addresses from interacting with the platform:
| Layer | Method | Scope |
|---|---|---|
| Backend API | Chainalysis Sanctions API + local SDN cache | Authentication, match creation, tournament registration |
| Smart Contracts | Chainalysis on-chain Sanctions Oracle | Entering a contest, claiming a prize, claiming a refund (on-chain enforcement) |
| Background Tasks | Periodic SDN list re-sync and player re-screening | All active players (ongoing compliance) |
On-chain screening is enforced by the contract itself, independently of our servers. The check is gas-capped and fails closed: if the sanctions oracle is unreachable, funds are held rather than released.
Design Principles
If the screening service is temporarily unavailable, the platform blocks the action rather than allowing it through. This is the opposite of fail-open — compliance takes priority over availability.
No single layer can be bypassed to circumvent screening. The API layer catches addresses at first contact. The smart contract layer provides on-chain enforcement independent of the backend. Background re-screening catches addresses added to the SDN list after initial registration.
Sanctioned addresses are prevented from creating or joining contests. Existing funds are never trapped in escrow — blocking withdrawals would create legal and technical complications. The screening prevents new interactions instead.
Data Sources
- Chainalysis Sanctions API — Real-time screening against known sanctioned addresses across all major blockchains
- OFAC SDN List — Direct sync from the U.S. Treasury's published SDN Advanced XML, refreshed daily
- Chainalysis On-Chain Oracle — Deployed at
0x40C5...8fbon Ethereum, Arbitrum, Polygon, Base, and other major EVM chains. Free to call, no API key required.
Audit Trail
All screening checks are logged with timestamps, sources, and results. Screening logs are retained in compliance with OFAC's 5-year recordkeeping requirement (31 CFR Part 501).
Ongoing Practices
ReentrancyGuard on all state-changing functions. SafeERC20 for token transfers. ECDSA signature verification for oracle operations. 48-hour timelocks on admin changes. Emergency pause controls via PlatformState. Token whitelist — only approved ERC-20s accepted. Oracle keys held in hardware-backed custody.
Isolated oracle signing keys. HttpOnly cookies (no localStorage for tokens). Session tokens rotated on every authentication. Rate limiting via SlowAPI. Server-side move validation for all games. OAuth token verification for social logins. Non-root Docker containers. Redis authentication enabled. Source maps gated to development builds.
Automated integrity checks run across matches, with results recorded per match. Admin review panel for flagged matches. Geofencing middleware for OFAC and restricted jurisdictions. OFAC SDN wallet screening with fail-closed policy. KYC entry fee limits enforced at the API layer.
Related Pages
- Smart Contracts — How non-custodial escrow protects your funds
- Fair Randomness — How our cryptographic fairness works
- Fair Play Policy — Game integrity and reporting