Auditing a Solana Perps DEX at Production Scale
TL;DR: Fidesium audited Adrena – a Solana-native perpetual futures DEX run by the Autonom Foundation – across two engagements covering ~36,000 lines of Rust, 122 instructions, and a live version migration. The engagement produced 14 actionable findings (1 Critical, 3 High, 8 Medium, 2 Low), 43 recommendations, and a full regression test suite with runnable tests for every finding. Here’s how our Four-Pass Framework, purpose-built Solana fuzzing harness, and test-first methodology made it possible.
Why security needs to be a first-class engineering discipline on Solana
Solana DeFi is unforgiving. CPIs erode trust boundaries, and the account model rewards state-machine thinking. And when the product is a perpetuals DEX, the search space of things that could quietly go wrong is large.
Adrena, built by the Autonom Foundation, is one of the more mature perps protocols on Solana. Over the Q1 2026 audit window Fidesium reviewed the protocol across two engagements, developed a purpose-built test framework alongside the findings, and helped guide a version migration (v38 to v39) where the protocol hardened its oracle ingestion, fee accounting, and governance surfaces.
The client: Adrena & Autonom Foundation
Adrena is a Solana-native perpetual futures DEX. It offers leveraged long/short exposure on a set of supported custodies, with cross-collateral risk management, an LP-backed liquidity model, and a multi-provider oracle architecture that composes Autonom, Switchboard, and Chaos Labs feeds. The product has been live on Solana mainnet, actively trading, and the team at Autonom has a demonstrated record of shipping substantial upgrades without serious downtime or user-visible regressions.
Adrena team’s approach to scope was mature. They asked for a full audit of the active codebase and a follow-on review specifically focused on the in-flight migration. We wrote tests, so that remediation could be verified mechanically. They asked us to look at characterization of existing behaviour, not just counterfactuals.
The engagement in numbers
- ~36,000 lines of Rust across the Anchor program.
- 122 instructions enumerated and classified by access tier (admin, user-gated, permissionless).
- Two engagements: initial audit and a follow-on review around the v38 to v39 migration.
- 14 actionable findings: 1 Critical, 3 High, 8 Medium, 2 Low, plus 43 recommendations and positive observations across the two reports.
Most large protocols of this size yield more Criticals. Adrena yielded one, and it was a governance timelock gap rather than a solvency bug. That reflects how carefully the Autonom team has reasoned about admin blast radius.
Our approach: the Four-Pass Framework
Fidesium’s Solana audit methodology is organised around a Four-Pass Framework that we apply before a human auditor reads a single line of business logic. The idea is to build up a complete, mechanical understanding of the shape of the protocol first, so that the bug-hunting phase operates against a fully enumerated attack surface rather than an ad-hoc one.
Pass 1) Protocol Mapping
For Adrena, that produced an instruction matrix categorising all 122 handlers by who can invoke them and under what preconditions. This is the input to everything that follows: permissionless instructions are high-priority attack surface, admin-gated instructions are where governance risk lives, and migration instructions get their own tier
Pass 2) Token Flow Diagrams
Value movement inside the protocol is traced end-to-end. For a perps DEX this means liquidity deposits and withdrawals, position collateral in and out, realised and unrealised PnL, borrow fees, exit fees, referrer fees, and more.. Each path is annotated. The output of this pass is a set of conservation invariants. Those invariants become the assertions later fuzzers check.
Pass 3) CPI Surface Analysis
On Solana, this is the single most dangerous surface. Oracle integrations get a dedicated sub-pass because they are themselves CPI consumers with their own staleness, confidence, and consensus semantics. For Adrena this produced a complete map of the multi-oracle ingestion pipeline, the Ed25519 signature verification flow, and the interactions between provider fallback and min_agree consensus.
Pass 4) Cross-Verification
The final pass looks for internal consistency bugs. Operator semantics match across accrual and consumption (did += on one side pair with checked_sub on the other? Is wrapping_add used anywhere a value must stay bounded?). Denomination boundaries are traced (USD-to-token and token-to-USD conversion is a place where a hidden price assumption is made). This is where a meaningful fraction of the Mediums came from on Adrena Underpinning. These four passes are a set of named sub-methodologies we apply wherever they matter:
- A mutation matrix for each account struct showing which fields are written by which instructions.
- A per-handler checklist covering common invariants and actions(e.g. signer verification, account validation, etc)
- Binary Equivalence Verification including Docker-based reproducible builds plus ELF forensics.
None of these are clever in isolation. The value is in running them systematically on every engagement.
Sample finding
We’re going to walk through one of the higher-severity findings, because it illustrates the kind of issue that structured enumeration surfaces. (The full report contains more, we’re not going to reproduce exploit details here).
Oracle Staleness Laundering
Adrena supports Switchboard price batches signed by an oracle operator; the program verifies Ed25519 signature and records the price. There are two places where “freshness” is checked. At ingestion, to reject batches that are too old to be trustworthy, and at usage, to reject stored prices.
At ingestion, the check was parameterized in a way that a caller could influence, and the stored timestamp was written as the current clock time rather than the timestamp the oracle itself had signed over. The assumption on price age allowed older signatures to be laundered.
Adrena’s remediation: the ingestion path now enforces a hard ceiling on how far in the past a signed batch’s timestamp may be and a matching ceiling on how far in the future it may be. Internally, Fidesium wrote characterisation tests (both property-based and transaction-level) covering both bounds, so that any future regression in the ingestion logic will fail the test suite in the earliest phases of review.
The test suite we built
Every finding generated at least one runnable test. The correspondence between a finding ID in the report and a test in the codebase is mechanical. Remediation review is “does the test that previously failed now pass.”
The suite has three layers, each with a different scope and speed tradeoff:
- Layer 1: Proptest modules over pure functions: PnL calculations, borrow rate logic, funding zero-sum properties, and more. Fast, deterministic, with shrinking counterexamples. ~87 properties across 12 core modules.
- Layer 2: Stateful transaction-level fuzzers: full position lifecycles, liquidation corridors, and cross-collateral scenarios. Each property drives real Solana transactions against the compiled program inside our fuzz harness. ~60 properties plus integration scenarios.
- Layer 3: Coverage-guided state-machine fuzzer: drives exploration over an 82-operation vocabulary (open/close/liquidate longs and shorts, add/remove liquidity, fee mutations, etc.) checked against global invariants after every step. Runs in both fuzzer-friendly and production-faithful execution modes.
We also generated mainnet-fork “loaded gun” PoCs that reproduce the higher-severity findings against the deployed binary with real account state. These are deliberately scoped: we reserve mainnet-fork PoCs for Medium-or-higher findings with measurable on-chain impact, because they take real time.
The Fidesium LiteSVM Anchor Harness
A lot of the speed and ergonomics of the test suite above comes from an
internal framework.
This framework is a reusable infrastructure layer for coverage-guided fuzzing and property testing of Solana programs. The design goals are the things an audit team needs and an off-the-shelf Solana test runner does not give you. A non exhaustive list follows:
- Our fuzzer can run millions of operation sequences without flake. We track and reset only the state that actually changed
- Anchor-idiomatic account fabrication without going through #[account(init)]
We are not going to go into the internals here. The short version is that the harness is what let us ship the three-layer test suite above in the time budget of the engagement, rather than spending the first three weeks rebuilding a fuzzing infrastructure and then running out of runway.
Why this approach works
Audits fail in a variety of ways. The most common are the auditor finding fewer issues than existed, because the search was pattern-matching, or the auditor finding the issues but the remediation regressing, because the findings were prose paragraphs rather than runnable tests.
The Four-Pass Framework addresses the first, the test-first model addresses the second: by building a regression lock for every finding, remediation review becomes mechanical and future refactors inherit the guardrails. We can help the Adrena team ship v40 with the same confidence on the issues in this report that they had on the day we delivered it.
And our harness addresses the speed constraint that usually forces a tradeoff between the two. Rebuilding fuzzing infrastructure per engagement costs multiple weeks making you either skip the tests or skip the breadth. We’d rather skip neither.
What this says about Adrena
We think the protocol team deserves the credit. Most of the findings above are the kind of issue a team already thinking hard about correctness makes. They are compositional. The code is readable, the state is well-normalised, the math library is conservative, and the oracle architecture is exceptionally sophisticated.
Autonom’s remediation behaviour was equally notable and showed a mature engineering process. Findings were triaged. A follow-on review was commissioned proactively. Post-audit discoveries during the v38 to v39 migration were handled transparently.
What next
If you’re building a perps protocol, a structured product, or any leverage-bearing DeFi primitive on Solana, the time to engage with security is when the first #[account] struct is defined. Adrena did this well, the result is a protocol that is auditable, upgradeable, and trustworthy.
If you’re trading, Adrena is live on Solana mainnet. Try it.
If you’re building on Solana and want an audit that ships runnable tests alongside the report, reach out to us at fidesium.xyz. Our Solana audit framework, our Four-Pass methodology, and the fuzz harness that powered the Adrena engagement are available to every client.
If you’re at an earlier stage; whiteboard, architecture, tokenomics; we work up-funnel too. We’d rather catch a design issue on a napkin than a missed invariant on mainnet.
The best time to make your protocol auditable was the day you opened the repository. The second best time is today.
