PERK.FUND

The project's audits/ folder contains 53 files named after recognized security firms (OtterSec, Pashov, Apex). However, every file is an AI-generated self-review authored by 'Kai (AI Security Auditor)', 'Kai (Pashov-style solo review)', 'Apex-style DeFi Red Team (automated)', 'Predator (adversarial smart contract auditor)', and similar AI agents. No verified third-party security audit reports (signed PDFs or on-chain attestations) exist in the repository. The 'OtterSec verified' claim in README and SECURITY.md refers to Solana build verification (confirming deployed bytecode matches source code), not an OtterSec security audit engagement. The security_txt macro in lib.rs lists auditors as 'OtterSec (on-chain verified)' which further conflates build verification with security auditing. Naming AI self-reviews after recognized audit firms implies endorsement that does not exist and is misleading to users evaluating the project's security posture. Evidence: pashov-review-round1.md ('Auditor: Kai (AI Security Auditor)'), apex-red-team-round1.md ('Auditor: Apex-style DeFi Red Team (automated)'), pashov-cranker-audit.md ('Auditor: Pashov-style solo review'), predator-final-oracle-audit.md ('Auditor: Predator (adversarial pass)').

The Content-Security-Policy header includes 'unsafe-inline' and 'unsafe-eval' in the script-src directive, and allows connections to any https/wss endpoint via a broad connect-src. This significantly weakens XSS protection — if an attacker can inject HTML (via a compromised dependency, DNS hijack, or user-generated content), they can execute arbitrary JavaScript. Combined with the broad connect-src, injected scripts could construct and submit malicious Solana transactions to any RPC endpoint. The CSP also allows Access-Control-Allow-Origin: * on HTML responses.

The on-chain program (3L72e4b8wKJ8ReMpLUeXxVNrRGpiK6m4VYxeSnecpNW2) is deployed via BPFLoaderUpgradeable with upgrade authority 86ghiskDv1HUJggeQyit4EhLs3K7ZqU4oU8tjwNYXt1g. This is a single externally-owned account — not a multisig, not behind a timelock. The authority holder can push arbitrary program updates at any time without on-chain governance or delay. While upgradeability is necessary during active development, the lack of a multisig or timelock means a compromised key could result in a malicious upgrade. The protocol also has a single admin key controlling: global pause, fee rates, oracle authority, market parameters, and SOL withdrawal from protocol PDA. The two-step admin transfer (propose/accept) mitigates key rotation risks but doesn't address single-key compromise.

The Helius RPC API key is embedded in client-side JavaScript and visible in all network requests to mainnet.helius-rpc.com. While Helius keys for public RPC are designed to be client-facing, exposing the key allows any third party to abuse the project's rate limits and credits. Observed ~150 getAccountInfo calls per page navigation (3,002 POST requests across 20 pages tested), which further amplifies the impact of rate-limit abuse.

Multiple locations in the risk engine (engine/risk.rs) use assert!() which causes a BPF panic/abort rather than returning a structured Anchor error via require!(). While functionally equivalent (both abort the transaction), panics produce opaque error codes that are harder to debug. More importantly, if any assert!() is reachable through normal user operations (not just corrupt state), it could prevent users from interacting with their positions. Examples found in: set_pnl(), consume_released_pnl(), begin_full_drain_reset(), and several conservation checks.

SECURITY.md line 31 lists program ID 3L72e4b8wKJ8ReiNMcFViSmYHPJB81oKzPqFDdBmJvXq (ending ...vXq), while every other file in the repository — Anchor.toml, lib.rs, constants.ts, README.md, all docs — consistently uses 3L72e4b8wKJ8ReMpLUeXxVNrRGpiK6m4VYxeSnecpNW2 (ending ...NW2). This could mislead security researchers or integrators attempting to verify the deployed program.

The oracle_equity_net function in engine/risk.rs uses saturating_add and saturating_sub for margin calculations. If extreme values cause saturation, a position could appear healthier than it actually is, potentially preventing a necessary liquidation. The normative bounds on oracle price (MAX_ORACLE_PRICE) and position size (MAX_POSITION_ABS_Q) make this practically unreachable, but it diverges from the strict checked-math discipline used throughout the rest of the risk engine.

Anchor.toml line 21 contains a Windows filesystem path to the deployer keypair: C:\Users\pomch.openclaw\workspace\perk\deployer-keypair.json. While the actual keypair is not in the repository, this reveals developer identity (username 'pomch') and workspace structure. This is an information disclosure in a public repository.

The protocol has genuine formal verification: Kani formal verification with 10 proof suites covering arithmetic, engine, funding, instructions, invariants, liveness, margin, and safety — run in CI on every push to main. Additional verified security measures: (1) Sec3 X-ray static analysis available via manual dispatch. (2) Fuzz testing via fuzz_e2e.rs. (3) E2E security tests targeting oracle hardening. (4) overflow-checks=true in release profile. (5) security_txt macro for on-chain disclosure. (6) Two-step admin transfer. (7) Conservation invariant checked at end of most instructions. (8) Defense-in-depth: warmup windows, haircuts, insurance fund epoch caps, oracle circuit breakers, price banding, sliding window bands. Note: while the Kani proofs and automated testing are real and verifiable in the codebase, the 53 files in the audits/ folder are AI-generated self-reviews (see TG-009), not third-party audit reports.