Audits

SportsPerp’s approach to security audits is: internal first, external before mainnet, continuous thereafter.

Status summary

Internal self-audit (complete)

Completed April 17, 2026. Scope: full on-chain program + off-chain services. 17 findings across all severity levels:

• 1 Critical (fixed)
• 5 High (all fixed)
• 4 Medium (documented, non-blocking)
• 4 Low (documented)
• 3 Informational (documented)

All Critical and High findings have been resolved and verified with regression tests. See Self-Audit Summary for the full summary and docs/SELF-AUDIT-REPORT.md for the canonical report.

External audits (in flight, mainnet-blocking)

Scope

The external audit scope includes:

1. The on-chain program — all 30 instructions, all 7 PDA types, all math modules, IDL correctness.
2. The SDK math parity — verification that TypeScript math matches Rust math bit-for-bit.
3. The oracle pipeline — specifically the update_oracle authorization path and the planned multi-source consensus path.
4. The liquidation cascade — Layer 1 / 2 / 3 mechanics, insurance fund accounting, ADL correctness.
5. Deployment and upgrade mechanics — program upgrade authority, admin keypair handling, multi-sig migration plan.

Auditor selection

We intend to engage two Solana-specialist audit firms before mainnet — ideally with parallel or sequenced reviews so findings are cross-validated. Specific firm names will be published here once engagement letters are signed.

Solana-specific expertise (BPF semantics, Anchor quirks, Solana-unique attack vectors) is essential — a general smart-contract auditor without deep Solana background would miss class-specific issues. Our shortlist comprises firms with track records auditing major Solana DeFi protocols.

Timeline

The audit window is gated on engagement scheduling. Indicative pre-launch sequence:

• Engagement kick-off: subject to availability of selected firms
• Initial report: before mainnet target
• Remediation window: 1–2 weeks for High/Critical findings
• Re-review: 1 week
• Mainnet deploy: conditional on a clean final report

Mainnet is gated on a clean final report, not on a target date. If the audit report lands later than planned, mainnet slips.

What happens if the audit finds Critical issues

If the audit report lands with unresolved Critical or High issues that we can’t remediate in the timeline window, mainnet slips. A delayed launch is strictly preferable to a launch with known unresolved security issues. The World Cup window is important but not worth overriding the security gate.

Public disclosure

Audit reports will be published in full after:

• All Critical/High findings have been remediated or explicitly accepted.
• A 30-day responsible-disclosure window for any findings that might be exploitable during remediation.

Audit reports will live alongside this whitepaper in the documentation site and be archived permanently.

Continuous security review (post-launch)

One-time audits are table stakes. Continuous review is what catches issues introduced after the initial audit.

Our post-launch plan includes:

Automated analysis

• Static analysis on every PR — cargo-audit, cargo-clippy, custom lints for checked arithmetic.
• Property-based testing — every math function has QuickCheck-style invariant tests.
• Fuzzing — Rust fuzzer continuously explores instruction handlers with random inputs.

Regular review cadence

• Quarterly external reviews post-mainnet. Smaller scope than the pre-launch audit; focus on changes since the previous review.
• Annual full re-audit. Every 12 months, a firm re-scopes the entire program to catch drift since initial audit.

Bug bounty

A live bug bounty program — see Bug Bounty — is the long-tail defense. Security researchers outside the auditor relationship have incentive to report issues.

Other security practices

Code review

Every PR requires review from a team member not involved in writing the code. Security-sensitive changes (math modules, instruction handlers that move tokens, admin-facing instructions) require two reviewers.

Dependency review

Third-party dependencies are a supply-chain risk. Our approach:

• Rust program: only standard Anchor/Solana dependencies. No exotic crates.
• TypeScript SDK + engine: standard Solana, Anchor, Express, better-sqlite3, ws. Dependencies are pinned to exact versions in package.json and updated deliberately, not via npm update.
• cargo-audit on every CI run to catch known vulnerabilities in Rust dependencies.

Keypair handling

• Admin keypair lives on the Hetzner server in a systemd EnvironmentFile with 600 permissions. Never committed to the repo; never transmitted out of band.
• Backup copies held by two team members on separate hardware security modules.
• For mainnet: admin moves to 3-of-5 multi-sig. Upgrade authority follows.

What we will not do

• Ship to mainnet without external audit. Non-negotiable.
• Hide audit findings. All public, all archived.
• Claim “audited” based on a partial or narrow-scope review. Scope is always disclosed alongside any audit claim.
• Re-use audit findings from other protocols. Every audit is specific to our codebase. “Hyperliquid is audited” does not imply SportsPerp is safe.

Further reading

• Self-Audit Summary — what the internal audit found.
• Bug Bounty — reward structure for external researchers.
• Smart Contract Risk — the risk audits address.