Solana Program Security Audits

Yes. We audit both Anchor-based and native Solana programs. Anchor constraints reduce some vulnerability classes but don't eliminate business logic bugs, CPI risks, or economic exploits.

Entirely different vulnerability classes. Solana's account model means we're auditing data ownership, account validation, CPI safety, and PDA correctness (concepts that don't exist in the EVM).

Yes. Our Solana auditors are Rust-native. They build programs, not just review them. This matters for understanding idiomatic patterns and non-obvious attack vectors.

Solana audits are priced by scope: the review time and number of auditors a program needs, not a fixed per-line rate. Rust and Solana work often carries a premium over equivalent EVM audits because the specialist auditor pool is smaller. We give a fixed-price quote after a free scoping review. See our pricing page for current ranges.

Most Solana program audits take 1 to 3 weeks. Simple programs can be under a week. Complex protocols with multiple programs, heavy CPI chains, or custom on-chain state machines take longer. We confirm the timeline in the scoping review before work starts.

Every finding is severity-ranked (Critical, High, Medium, Low, Informational) with a clear description, root cause, a proof-of-concept where applicable, and concrete remediation steps. We re-audit your fixes at no extra cost.

It is not protocol-required, but it is standard practice before mainnet, before a major upgrade, or before a program starts handling meaningful value. Critical and high-severity findings show up in a large share of first audits, and finding them before deployment is far cheaper than after.

Yes. Liquid staking and restaking audits cover stake-pool authority and delegation logic, exchange-rate and reward calculations, withdrawal queues, and validator-set management, on top of the account-validation and CPI classes every Solana program needs. If your LST is used as collateral elsewhere, we also review the assumptions integrators inherit from your program.

Yes. Claim and distribution programs get reviewed for Merkle-proof validation, claim replay protection, distribution math, sybil-resistance assumptions, and authority controls — the failure modes that surface in the first hours after launch, when transaction volume is highest and fixes are hardest to ship.