SseRex: Solana Bytecode Symbolic Execution

• SseRex is a symbolic execution framework for Solana smart contracts that operates at the bytecode level to detect security vulnerabilities.
• It lifts deployed ELF files containing sBPF bytecode to an intermediate representation, enabling Solana-specific checks like missing owner, signer, and key validations.
• Empirical evaluation on over 8,700 contracts revealed critical bug classes with an 87% true-positive rate, demonstrating its practical security analysis capability.

Searching arXiv for SseRex and related Solana smart-contract analysis papers. SseRex is a bytecode-level symbolic execution framework designed specifically for Solana’s smart contract ecosystem. It targets the Solana-specific bug classes that arise from Solana’s account model and stateless execution context, namely missing owner checks, missing signer checks, missing key checks, and unsafe or arbitrary cross-program invocations. The framework operates on deployed ELF files containing sBPF bytecode, lifts them to an intermediate form, prepares a Solana-aware symbolic state, explores paths that lead to critical actions, and evaluates Solana-tailored vulnerability oracles. In an evaluation on 8,714 bytecode-only contracts, it identified potential bugs in 467 different contracts, and an additional study of 120 open-source Solana projects supported its use on real-world codebases (Cloosters et al., 17 Mar 2026).

1. Problem setting and Solana-specific bug classes

SseRex is motivated by the observation that existing automated analysis approaches do not address the unique and complex account model of Solana (Cloosters et al., 17 Mar 2026). In Solana, programs receive all context via instruction inputs; there is no implicit msg.sender. Every account’s metadata, including owner, is_signer, is_writable, is_executable, lamports, and serialized data, is provided by the runtime. Which validations are necessary depends on program-specific logic.

This execution model creates several bug classes that differ from the usual EVM-centric analysis setting. Missing signer checks can enable unauthorized actions when an attacker supplies the correct public key but does not control the corresponding private key. Missing owner checks can cause a program to trust state stored in accounts that it does not own. Missing key checks can permit substitution of critical system or program accounts without verifying the expected public key. Unsafe or arbitrary CPI can arise when the callee program or the account metas used in a CPI are attacker-controlled and insufficiently validated (Cloosters et al., 17 Mar 2026).

The framework focuses on four classes of Solana-specific vulnerabilities.

Class	Validation absent or insufficient	Typical effect
Missing owner checks	owner(a) == program_id not enforced for trusted data accounts	Counterfeit state may be trusted
Missing signer checks	is_signer not asserted for authority accounts	Unauthorized sensitive operations
Missing key checks	Expected pubkey not matched	Substitution of critical accounts
Arbitrary CPI	CPI target or account metas not properly validated	Delegated execution to attacker-chosen programs

This classification reflects the fact that Solana programs must explicitly validate owners, signers, public keys, PDAs, and CPI targets. A plausible implication is that bytecode analysis for Solana must reason about account provenance and authority, not merely about arithmetic or control-flow bugs.

2. Formal model of accounts, state, and safety conditions

SseRex formalizes a Solana account as a tuple

$$a = \bigl(\mathrm{pubkey}(a),\,\mathrm{owner}(a),\,\mathrm{lamports}(a),\,\mathrm{data}(a),\,\mathrm{is\_signer}(a),\,\mathrm{is\_writable}(a),\,\mathrm{is\_executable}(a)\bigr).$$

Program-derived addresses are modeled as

$$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$

where $p$ is the program id and $\vec{s}$ are seeds (Cloosters et al., 17 Mar 2026).

The symbolic execution state is written as

$$\sigma = \langle \mathrm{ip},\, R,\, M,\, S,\, H,\, \mathcal{A},\, \mathsf{PC} \rangle,$$

where $\mathrm{ip}$ is the instruction pointer, $R$ registers, $M$ memory, $S$ stack, $H$ heap, $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$0 the account set in the instruction context, and $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$1 the path condition. Single-step execution advances this state through instruction semantics, while branch predicates accumulate into $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$2 (Cloosters et al., 17 Mar 2026).

Two critical actions are central. The first is an account write event, meaning an instruction sequence modifies data(a) or lamports(a). The second is a CPI event

$$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$3

representing an invocation to a target program id with account metas $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$4 and instruction data $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$5 (Cloosters et al., 17 Mar 2026).

The framework identifies checks along a path through predicates such as check_owner, check_key, check_signer, and derive_pda. It treats an account as checked if any of the following holds: $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$6 The last disjunct encodes implicit runtime owner enforcement: only the owner can write an account, so a successful write is itself evidence of ownership in the Solana runtime model (Cloosters et al., 17 Mar 2026).

Authority is represented through a trusted signer predicate: $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$7 The analysis then searches for feasible, gracefully exiting paths that violate safety properties for missing owner checks, missing signer checks, missing key checks, and arbitrary CPI. For example, arbitrary CPI is characterized by a feasible path with a CPI whose target is not protected by key or owner validation and for which no trusted signer is established (Cloosters et al., 17 Mar 2026).

3. Architecture and execution engine

SseRex operates at bytecode level and does not require source code. It dumps ELF files with sBPF bytecode, lifts them in Binary Ninja to an intermediate language with Solana calling conventions, and then loads that representation into a symbolic executor built on SENinja (Cloosters et al., 17 Mar 2026). This design permits analysis of bytecode-only deployments and Anchor-based programs.

The runtime model includes Solana syscalls and APIs relevant to security analysis. The framework models invoke for CPI, logging, account data borrow and mutation, and instruction sysvar access. CPI is treated as a critical action rather than inlined, while account reads and writes are tracked as events that later feed into the vulnerability oracles (Cloosters et al., 17 Mar 2026).

The exploration process is organized around three strategies. CPI exploration restricts attention to paths that statically can reach the CPI syscall. Main exploration identifies function-dispatch switch trees, a common Rust and Anchor compilation pattern, and drives execution toward the leaves where core logic resides. Random exploration is retained to improve coverage in less structured code regions (Cloosters et al., 17 Mar 2026). Strategy scheduling is round-robin, with each strategy allowed up to 10 minutes per contract and with strategies skipped when their target is unreachable.

This organization reflects a specifically Solana-aware symbolic execution workflow: lifting sBPF, materializing a symbolic instruction context with accounts and metadata, driving path search toward critical actions such as writes and CPI, and then deciding whether the relevant accounts were adequately validated before normal termination.

4. State-space control and tractability mechanisms

Practical symbolic execution on Solana bytecode is difficult because account deserialization, metadata branching, variable-length buffers, and logging routines induce severe path explosion. SseRex introduces several engineering mechanisms specifically to make symbolic execution tractable (Cloosters et al., 17 Mar 2026).

The first mechanism is static path pruning. The framework uses control-flow and caller graphs to retain states that can dominate or reach targets, or that can return to callers that lead to targets. Error-handling paths that panic or abort and cannot reach targets are pruned. This is particularly important because Solana programs often include extensive abort logic and formatting-heavy failure paths (Cloosters et al., 17 Mar 2026).

The second mechanism is state merging during deserialization. SseRex identifies the account-deserialization loop and merges boolean metadata branches such as is_signer, is_writable, and is_executable into conditional memory expressions. This avoids an exponential blowup in the number of states (Cloosters et al., 17 Mar 2026).

The third mechanism is hybrid symbolic data lengths. During deserialization, account data buffers are laid out with a constant maximum size in order to avoid symbolic pointers. Afterward, lengths become symbolic variables constrained by maximum bounds. This retains tractable constraints for the length checks common in Anchor-generated code (Cloosters et al., 17 Mar 2026).

The fourth mechanism is string-formatting skip. The framework detects format and log sequences leading to logging syscalls and bypasses the formatting functions. The paper notes that these routines otherwise introduce hard string constraints that stall SMT solving (Cloosters et al., 17 Mar 2026).

Taken together, these mechanisms suggest that SseRex’s practicality depends less on a new symbolic execution calculus than on a Solana-specific set of reductions that remove irrelevant path structure while preserving paths relevant to critical actions.

5. Detection logic and exploit construction

The framework reports missing owner checks when a path writes to accounts, reaches graceful exit, and has read or used one or more accounts that are not checked by owner, key, PDA derivation, or implicit write, while no authority check is present (Cloosters et al., 17 Mar 2026). It reports missing signer checks when sensitive operations occur without verifying a signer. Sensitive operations include account writes and CPI constructions affecting privileges.

For arbitrary CPI, SseRex checks whether the CPI target is attacker-controlled and whether the path lacks constant key validation, owner validation, or a trusted signer. It also evaluates validation of the accounts used in the CPI account metas, including signer, writable, and owner-related properties when these appear in the CPI construction (Cloosters et al., 17 Mar 2026).

Missing signer checks receive an additional robustness test. To guard against implicit branching on is_signer, SseRex replays the path with all signer flags set to false while preserving prior constraints. If the critical action still occurs, the missing signer check is confirmed (Cloosters et al., 17 Mar 2026). This replay step is a distinctive part of the framework’s oracle design.

The framework can also synthesize exploit transactions for reported vulnerabilities. Its outputs include the vulnerability type, the critical actions reached, the implicated accounts and fields, a summary of the path condition, and, when possible, a concrete exploit transaction consistent with the discovered constraints (Cloosters et al., 17 Mar 2026). This moves the system beyond purely diagnostic reporting into executable feasibility evidence.

The framework assumes trusted runtime metadata and Solana’s rollback semantics. It also assumes the runtime guarantee that only the owner can write an account. Attacks outside these assumptions, and vulnerabilities such as integer overflows, type confusion, or deep reentrancy, are omitted or limited by platform constraints (Cloosters et al., 17 Mar 2026).

6. Empirical results and case studies

SseRex was evaluated on 8,714 deployed Solana contracts, of which 3,763 were Anchor-based, or 43.2% (Cloosters et al., 17 Mar 2026). The large-scale analysis produced the following results.

Finding category	Contracts
Unchecked account writes	374
Missing Owner Check	117
Missing Signer Check	241
Combined MOC/MSC	33
Arbitrary CPI	100
Total reported	467

A manual inspection of 30 anonymous contracts found 26 true bugs, yielding an 87% true-positive rate (Cloosters et al., 17 Mar 2026). The evaluation also reports mean basic block coverage of approximately 33%, with standard deviation $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$8, and notes that in 239 contracts with complete relevant coverage, unreachable code averaged $$\mathrm{pda}(p,\vec{s}) = \mathrm{DerivePubkey}(p,\vec{s}),$$9 with standard deviation $p$0 (Cloosters et al., 17 Mar 2026).

The case studies illustrate the bug classes in concrete settings. In the Neodyme workshop contracts, SseRex reported a missing owner check on a counterfeit-wallet drain pattern, a missing signer check on withdrawals, and an arbitrary CPI target issue in the ACPI level (Cloosters et al., 17 Mar 2026). In the Anchor Contract Transparency Program dataset, only four vulnerabilities were reported across 120 projects, with one manually confirmed example in sol-did, where a resize function lacked validation and allowed arbitrary resizing and rent draining under certain conditions (Cloosters et al., 17 Mar 2026).

Additional case studies include Censo Solana Wallet, where two missing-signer-check vulnerabilities were found, one enabling unauthorized wallet termination and another enabling unauthorized migration that changes the rent-return recipient (Cloosters et al., 17 Mar 2026). In Elusiv, the framework found a missing signer check in compute_base_commitment_hash, though the paper describes the practical risk as low in context. The Wormhole historical key-check issue is discussed as an example that requires a contract-specific oracle because a generic missing-key-check oracle cannot infer the intended system account key from bytecode alone (Cloosters et al., 17 Mar 2026).

7. Limitations, scope, and significance

SseRex’s scope is deliberately Solana-specific. It is designed for bytecode-only analysis of deployed contracts, including Anchor-based programs, and it emphasizes owner, signer, key, PDA, and CPI validation rather than the vulnerability classes more commonly foregrounded in EVM analysis (Cloosters et al., 17 Mar 2026). This specificity is also its main limitation.

The framework does not infer business logic intent. Bytecode-level analysis cannot determine which constant keys were intended by developers or whether a multi-authority policy was intended. The paper therefore notes that some reported behaviors may be technically vulnerable but practically constrained by deployed state or by contract-specific logic (Cloosters et al., 17 Mar 2026). Integer overflows and type confusion are treated as out of scope, and bounded time budgets imply bounded soundness under coverage limits.

The stated future directions include better PDA modeling and seed provenance tracking, refined authority schemas, inter-procedural data-flow summaries, improved CPI tracking, scalable path prioritization, concolic integration, and automated generation of transaction chains that establish exploit preconditions (Cloosters et al., 17 Mar 2026).

Within the literature represented by the paper, SseRex is characterized as the first practical symbolic execution framework for Solana bytecode and as the first symbolic execution vulnerability detection approach for Solana-specific bugs such as missing owner checks, missing signer checks, missing key checks, and arbitrary cross-program invocations (Cloosters et al., 17 Mar 2026). This suggests a methodological shift in Solana security analysis: vulnerability detection must be organized around account trust, runtime metadata, and CPI authority propagation, rather than around generic smart-contract abstractions alone.