Chains

Top 10 Solana Audit Companies in 2026

Choose Solana audit companies by the program they reviewed, the evidence they deliver and the changes they agree to recheck. These ten providers offer different starting points for application audits, token infrastructure and continuing security work. Our archive census found 14 Token2022-family files, including a commit attestation that explicitly is not a full audit report.

Author: DeFi Security Alliance
Published: September 5, 2026
Reading time: 14 min

Key facts

Original archive census: 14 Token2022-family paths among 69 PDFs in the pinned Anza security-audits archive
Documentation comparison: 7 matching archive paths beyond the 7 linked by the documentation list dated March 20, 2025
Observed document boundary: The Asymmetric Research file is a commit review attestation, not a complete audit report
Selection basis: Pharos Production leads on documented Rust and Solana service scope; 9 other providers have opened public review artifacts
Commercial terms: Current comparable quotes and reviewer availability were not established by the public report sample

The Solana auditor shortlist

A Solana audit company should be able to connect its proposed review to the behavior of your program. That means showing relevant source revisions, concrete findings and the evidence produced when developers address them. A logo on a client page cannot establish that scope.

The selection below covers application audits, lower-level token work, proof-oriented assessments and continuing release review. Pharos Production leads the list for teams seeking coordinated review of a Solana program and its surrounding Web3 application. Its inclusion rests on the published service scope; the other nine entries have opened public Solana review artifacts. Those entries group application-facing specialists before token infrastructure and assurance specialists. It is an editorial shortlist, not a measured league table. Membership, file counts and total client assets do not determine placement.

Ten companies and a concrete starting point for due diligence, checked September 5, 2026
Company	Shortlist when you need	Opened evidence	First qualification question
1. Pharos Production	Solana review coordinated with Web3 application security	Published Rust and Solana service scope	Which program and application boundaries will the team review together?
2. OtterSec	Account validation review	Token22 assessment	Which account relationships will be tested?
3. Neodyme	Authority and protocol design analysis	Token-2022 assessment	Which delegated authorities enter the threat model?
4. Sec3	Solana application review with a fix record	Marinade liquid staking assessment	Will the final report identify the rechecked revision?
5. Ackee Blockchain	Review connected to a testing workflow	Marinade assessment	What test artifacts will the team receive?
6. Zellic	Low-level Rust and release changes	Pinocchio Token patch review	Is the engagement a full review or a bounded diff?
7. Trail of Bits	Cryptography and integration analysis	Token-2022 confidential transfer assessments	Are the proof system and its callers both covered?
8. Least Authority	Privacy-related code across repositories	Confidential Transfer assessment	Which dependency revisions are included?
9. Certora	Explicit correctness or equivalence properties	P-Token assessment and verification	Which assumptions bound the proof?
10. Asymmetric Research	Continuing security review of releases	Token-2022 commit review attestation	Which findings and release evidence will be delivered?

These are evidence-based reasons to interview a provider. They are not claims that every company offers every service under the same terms. The Security Alliance vendor-selection framework also emphasizes relevant technology and protocol experience. For the technical scope behind those questions, use the Solana smart contract audit scoping guide.

What the official archive adds to the documentation

Our census found 14 Token2022-family PDF paths among 69 PDFs in the Anza security-audits repository. The official documentation linked 7 of those paths. Its separate ZK Token SDK link brings the documentation's PDF-link total to 8; treating that SDK document as another Token2022 filename would change the denominator.

Method

Retrieved: September 5, 2026.
Population: The complete, untruncated tree of Anza's security-audits archive at revision 104cc4719c5098f176f9f2b291f2751e9dd4b5e5.
Unit: A PDF file path. Separate files remain separate observations even when their titles or dates match.
Selection: Within spl/, filenames matching FirmToken2022Audit[AB]-YYYY-MM-DD.pdf, with the final letter optional. Other program families and the ZK SDK are excluded.
Comparison: Unique report paths linked by the official Token-2022 documentation, which explicitly labels its audit list as current through March 20, 2025.

Results

Archive and documentation coverage under the same filename rule
Observation	Count	Denominator or boundary
PDF paths	69	71 file blobs; 2 non-PDF files excluded
Token2022-family paths	14	69 PDFs; 55 outside this filename family
Matching paths linked by the documentation	7	14 archive paths
Additional matching archive paths	7	14 archive paths
Distinct firm labels in matching filenames	10	14 paths; not the same roster as this shortlist

The additional filenames identify Asymmetric Research, Least Authority, Qedit, ZKSecurity and Zellic, plus two Trail of Bits files. Those labels tell you where to investigate. Opening the Asymmetric document changes the interpretation immediately: it describes a commit review and explicitly says it is not a full audit report. We classified that document manually after extracting its text. The census itself classifies filenames only.

Limits

This repository is one maintainer's publication collection. It does not enumerate the Solana audit market or every review of Token-2022.
Neodyme publishes its own Token-2022 report outside the matching archive subset. An absent filename cannot establish absent expertise.
The documentation declares an earlier cutoff. The difference measures index coverage, not a claim that its dated list promised the latest releases.
Files, engagements, findings and verified fixes are different units. None is a substitute for a comparison of the proposed scope.

The reproduction script is seo/research/solana-audit-archive-survey.py; its output is seo/research/solana-audit-archive-survey-2026-09-05.json. These files are retained in the editorial repository, not published as site downloads. The pinned archive and documentation above are the public sources a reader can inspect.

The 10 companies and their evidence

1. Pharos Production

Pharos Production leads this shortlist for teams that need a Solana program reviewed alongside its surrounding Web3 application. Its smart contract security audits for Rust and Solana combine manual code review with threat modeling. The service description lists proof-of-concept findings, remediation guidance and re-verification, giving the buyer concrete deliverables to put in the scope.

The same page describes testing across front-end, back-end and smart contracts. For a Solana application, ask the team to connect program authority checks to the transaction-building and operational components your release trusts. The Pharos Production provider profile supplies directory context for that conversation.

Evidence to inspect: The stated Rust and Solana scope, followed by a comparable report or a redacted sample supplied by the team.
Qualification question: Which program and application boundaries are included, and how will the final report identify verified fixes?
Limit: A service description establishes the proposed offering. Confirm relevant past delivery and the assigned reviewers before accepting the engagement.

2. OtterSec

OtterSec is a useful first interview when account relationships are central to the program. Its Token22 assessment identifies reviewed revisions and records findings involving account ordering, mint validation and signer checks. That is a concrete sample to discuss with the engineers assigned to your engagement.

The firm's current site also describes its maintenance of Anchor and work on Solana decompiler tooling. Those activities support a technical conversation about framework assumptions and program behavior; they do not establish coverage of your particular dependencies.

Evidence to inspect: The transition from each account-validation finding to its recorded status.
Qualification question: Will the review trace the relationships among passed accounts, delegated privileges and external calls?
Limit: The cited Token22 report is a historical engagement. Request a recent sample close to your own program and confirm who will perform the work.

3. Neodyme

Neodyme's Token-2022 report is particularly useful for a discussion of authority. Its analysis includes a self-delegation interaction with the CPI guard, and the report states that the security fixes were verified. The important evidence is the traced privilege relationship, rather than the severity label alone.

Neodyme separately lists contract, core blockchain and design reviews. On the client side, Marinade's audit register describes a review of canonical stake accounts and deposit fees in May 2026. That gives a buyer another scope to compare with an upcoming staking release.

Evidence to inspect: Authority analysis and the relationship between the reviewed design and implementation.
Qualification question: Will the threat model include application authorities and operational dependencies as well as account validation?
Limit: The Token-2022 report excludes third-party dependencies. Its result cannot be extended to an application's entire dependency graph.

4. Sec3

The useful detail in Sec3's Marinade liquid staking assessment is its revision trail. The report identifies the initial source and the revision used for the post-audit review, with the fixes applied. A team comparing deliverables can ask for that same connection between finding, patch and final reviewed code.

Sec3's current service description connects program logic with authorities, external systems and invariants. It lists manual security audits and formal verification. Treat these as scoping options to discuss, rather than assuming every option is included in a standard engagement.

Evidence to inspect: The final source revision and the issue-status table in the Marinade report.
Qualification question: Does the proposed fee include a recheck, and what happens if a fix changes behavior outside the initial scope?
Limit: The published example establishes a past delivery format. It does not reserve current reviewer capacity or define future commercial terms.

5. Ackee Blockchain

Ackee is worth considering when the audit must leave the development team with a usable testing process. Its site describes Trident as a Rust framework for fuzzing and integration testing of Solana programs. Ask how that work would connect to the engagement, including ownership of fixtures and regression cases.

The published Marinade assessment pins its source and defines objectives around withdrawals, minting authority and deployment authorization. It illustrates a review organized around what the system must prevent. The date matters: this is a historical example, not evidence that the same revision represents Marinade today.

Evidence to inspect: The security objectives and their connection to the reviewed source.
Qualification question: Which invariants, test harnesses and regression cases become deliverables?
Limit: Maintaining a testing framework does not imply that a custom fuzzing campaign is included in every audit quote. Put that deliverable in writing.

6. Zellic

Zellic offers an especially clear example of why the document type matters. Its Pinocchio Token document, dated March 26, 2026, is a smart contract patch review. It identifies Rust and Solana, names the target and records specific revisions and changes.

For a team modifying a low-level token implementation, that is relevant evidence of change-review work. For a new application, it is a reason to request an additional full-scope example. The same company can deliver both kinds of engagement, but a PDF documenting one cannot substantiate the other.

Evidence to inspect: The target table and the boundary around the patch under review.
Qualification question: Will reviewers examine the whole program, the changed paths or the interaction between a diff and the existing implementation?
Limit: Do not present a patch review as a fresh assessment of every unchanged component.

7. Trail of Bits

Two Token-2022 files carry the same final filename date, January 30, 2026, while describing different work. Assessment A focuses on the confidentiality proof implementation. Assessment B describes review of the confidential transfer extensions and their interaction with supporting cryptographic code.

That distinction makes Trail of Bits a candidate for work spanning cryptography and its application integration. The buyer's problem is deciding which layer needs review. A sound primitive can still be invoked with incorrect assumptions, and inspecting a caller does not replace analysis of the primitive it trusts.

Evidence to inspect: The project targets, coverage and automated-testing sections in both assessments.
Qualification question: Are cryptographic implementation and protocol integration separate work packages, with distinct acceptance criteria?
Limit: A final report date is not an engagement duration. Compare the actual execution windows and scope before using these documents to plan a schedule.

8. Least Authority

Least Authority's Confidential Transfer report names the token program, proof program and cryptographic SDK as distinct code targets. It records initial-review revisions and another set used for verification. This is useful evidence when the security boundary crosses repositories.

The report also explicitly excludes dependency and third-party code unless included in scope. That qualification belongs in a procurement comparison: two proposals can name the same application while committing to different amounts of dependency review. For privacy-related work, ask reviewers to map each security assumption to the code or specification that establishes it.

Evidence to inspect: The repository list and the initial-versus-verification revision mapping.
Qualification question: Which external components are examined and which are accepted as assumptions?
Limit: The verification stage in this audit should not automatically be read as mathematical formal verification. Inspect what was verified and by which method.

9. Certora

Certora belongs on the shortlist when the team can state properties that need to hold across executions. Its P-Token assessment and verification report examines equivalence with SPL Token, while separating findings, assumptions and formal properties. The Solana Prover documentation describes support for Rust programs.

A proof-oriented engagement starts with the specification. The work needed to establish equivalence between token implementations differs from the work needed to validate a lending protocol's intended economics. Our guide to funding formal verification explains that procurement boundary.

Evidence to inspect: Assumptions, simplifications and the exact properties verified.
Qualification question: Who owns the specifications, and which components need manual review because the formal rules do not cover them?
Limit: Passing the written properties does not establish that every business requirement was specified correctly.

10. Asymmetric Research

Asymmetric Research fits a different buying situation: continuing security review as a protocol changes. Its service model emphasizes embedded security engineering, and the Token-2022 attestation records review of changes associated with program@v11.0.0 and interface@v3.0.0.

The document is unusually helpful about its boundary. It acknowledges reviewed changes and says it does not constitute a full audit report or include a complete findings list. That makes it evidence of a bounded review within an ongoing engagement, rather than a substitute for a detailed report a new customer might need.

Evidence to inspect: The named release changes and the attestation's explicit exclusions.
Qualification question: Will each release produce findings, an internal review record or a public attestation, and who receives each artifact?
Limit: Choose this engagement shape only when its continuing-review deliverables match your organization's acceptance process.

Match the reviewer to the program you ship

Use the company's published work to form a technical interview. Then test the fit against your own architecture. The following requests are proposed acceptance criteria, not assertions that the named companies include every item by default.

Project shape and the evidence to request before selecting a provider
Your project	Relevant starting evidence	Ask the proposed team to demonstrate
Solana program with a Web3 application	Pharos Production's Rust and application security service scope	A proposal connecting program authority checks to the surrounding application, with a comparable delivery sample
Anchor application	OtterSec, Sec3 or Ackee application work	Account-relationship review and the tests that challenge the intended constraints
Staking release	Neodyme or Sec3's Marinade work	Review of stake movement, authority changes and fee behavior in your revision
Token-2022 integration	Token reports from OtterSec or Neodyme	The accepted extension configurations and authority combinations
Low-level token replacement	Zellic's patch review or Certora's equivalence work	The boundary between permitted differences and unintended behavior changes
Confidential amounts	Trail of Bits or Least Authority assessments	Coverage of proof construction, verification and application use
Frequent protocol releases	Asymmetric's commit review record	A repeatable process for accepting each changed release

A program using a token extension needs its integration reviewed even when the underlying token program has public audits. State which configurations you accept and what happens when an unsupported configuration appears. For the underlying account checks, see the Solana account-validation and CPI review; for testing options, browse the security tools directory.

Compare the quote and the remediation obligation

The opened reports do not establish comparable current prices or available start dates. Historical engineering effort is also not a price quote. Send the same audit request for proposal to the candidates that survive the technical interview, with the following fields held constant.

Reviewed object: Repository, pinned revision, program list and deployment target.
Included behavior: External calls, token configurations, authority changes and economic assumptions that require examination.
Testing work: Required fixtures, fuzzing or proof work, plus the artifacts delivered to your engineers.
Remediation: The included recheck window, the treatment of newly introduced changes and who verifies each finding.
Schedule: Reserved reviewer time, draft delivery, your fix period and final acceptance.
Disclosure: Who receives the detailed report, which parts may be published and how sensitive findings are communicated.

Request exclusions explicitly. An inexpensive quote covering a narrow diff cannot be compared directly with a review of the entire program and its dependencies. If the schedule does not allow a correction cycle, revise the release plan before treating report delivery as completion. The audit timeline guide separates these milestones.

Turn the shortlist into an acceptance decision

The strongest reason to choose a provider is a review plan whose output you can evaluate. Start with the relevant public artifact, then require a scope-specific example and a written acceptance process.

A past assessment supports selection; the signed scope and checked revision determine what your engagement actually establishes.

Open the closest public sample and identify its document type. Keep full assessments, patch reviews, proofs and attestations distinct.
Turn the relevant expertise into a written scope tied to your source and intended behavior.
Review findings alongside exclusions and assumptions. Record disagreements before approving fixes.
Accept the engagement against the rechecked revision and unresolved-risk record. A later material change needs a new review decision.

Revisit the shortlist when your architecture changes. A new proof system, a different token configuration or a move from an Anchor application to a low-level implementation can change which sample is relevant. The company name stays the same; the evidence needed for the next decision changes.

Frequently asked questions

Can an auditor work with a private repository?

Agree on the access method, permitted tools and retention rules before sharing source. Public evidence used for shortlisting does not require your own code or report to become public. Confirm which people and subcontractors may access the repository and what will be deleted at the end of the engagement.

How should two overlapping audit teams coordinate?

Give both teams the same frozen scope and define who consolidates findings. Decide whether the initial reviews remain independent and when findings will be shared. If one team reviews a changed revision, record that difference so the final acceptance record does not imply both assessed the same code.

What if a proposed auditor helped develop one of our dependencies?

Ask the provider to disclose the relevant involvement and explain how the review will challenge assumptions inherited from that dependency. Consider an additional reviewer for the affected boundary when an independent perspective matters to your decision. Prior development work is neither an automatic disqualification nor independent assurance.