Solana

Version: 1.0 David Cervigni (using LLM based on conversation)

Executive Summary

This section contains an executive summary of the identified threats and their mitigation status

There are 8 unmitigated threats without proposed operational controls.

Threat IDCVSSAlways valid?
Solana.
RENT_EXPLOITATION_AMPLIFICATION
8.8 (High) Yes
Solana.
CONSENSUS_TAKEOVER_51_PERCENT
8.1 (High) Yes
Solana.
VALIDATOR_DOS
7.5 (High) Yes
Solana.
RUNTIME_BUG_SEALEVEL
7.1 (High) Yes
Solana.
SNAPSHOT_POISONING
6.8 (Medium) Yes
Solana.
STATE_BLOAT_CENTRALIZATION
6.5 (Medium) Yes
Solana.
RENT_INDUCED_DATA_LOSS
5.7 (Medium) Yes
Solana.
LEADER_CENSORSHIP
3.8 (Low) Yes

Threats Summary

This section contains an executive summary of the threats and their mitigation status

There are a total of 8 identified threats of which 8 are not fully mitigated by default, and 8 are unmitigated without proposed operational controls.

Threat IDCVSSValid when (condition)Fully mitigatedHas Operational
countermeasures
Solana.
RENT_EXPLOITATION_AMPLIFICATION
8.8 (High) Always valid No
Solana.
CONSENSUS_TAKEOVER_51_PERCENT
8.1 (High) Always valid No
Solana.
VALIDATOR_DOS
7.5 (High) Always valid No
Solana.
RUNTIME_BUG_SEALEVEL
7.1 (High) Always valid No
Solana.
SNAPSHOT_POISONING
6.8 (Medium) Always valid No
Solana.
STATE_BLOAT_CENTRALIZATION
6.5 (Medium) Always valid No
Solana.
RENT_INDUCED_DATA_LOSS
5.7 (Medium) Always valid No
Solana.
LEADER_CENSORSHIP
3.8 (Low) Always valid No

Solana - scope of analysis

Overview

NOTE: This is an example threat model created based on specific instructions and conversation context.

This document outlines potential threats to the Solana blockchain platform. Solana is a high-performance Layer 1 blockchain utilizing a unique Proof-of-History (PoH) timing mechanism combined with Proof-of-Stake (PoS) consensus (Tower BFT) to achieve high throughput and low transaction fees. It uses the Sealevel runtime for parallel smart contract execution (primarily in Rust, C, C++).

This threat model focuses on the core protocol, consensus mechanisms, state management (including the rent mechanism), validator operations, and network bootstrapping (snapshotting), considering potential vulnerabilities and attack vectors.

Solana security objectives

Consensus Security:

Transaction Security:

State Security:

Operational Security:

Network Health:

Network Bootstrapping:

State Management:

Data Security:

Diagram: Details:

Blockchain State Integrity (STATE_INTEGRITY)

Prevent unauthorized modification or corruption of the blockchain state (account balances, smart contract data). Ensure state transitions are valid according to processed transactions.

Priority: High

Attack tree:


Data Confidentiality (Limited Scope) (DATA_CONFIDENTIALITY)

While a public blockchain, ensure that mechanisms intended to provide confidentiality (e.g., within specific future applications or protocols built on Solana) are effective. Primarily focused on preventing leaks beyond intended transparency.

Priority: High


Network Availability and Liveness (NETWORK_AVAILABILITY)

Ensure the Solana network remains operational, processes transactions in a timely manner, and is resilient to Denial-of-Service (DoS) attacks or widespread outages.

Priority: High

Attack tree:


Network Consensus Integrity (NETWORK_INTEGRITY)

Ensure the integrity of the consensus mechanism, preventing malicious actors from controlling the network, censoring transactions unfairly, or causing invalid state transitions (e.g., preventing 51%+ attacks).

Priority: High

Attack tree:


Rent Mechanism Safety (RENT_MECHANISM_SAFETY)

Ensure the rent mechanism functions as intended to curb state growth without causing unintentional loss of legitimate, funded account data.

Priority: High

Attack tree:


Snapshot Trustworthiness (SNAPSHOT_TRUSTWORTHINESS)

Ensure the integrity and availability of ledger snapshots used for bootstrapping new or recovering nodes, preventing synchronization with invalid state.

Priority: High

Attack tree:


Transaction Validity and Ordering (TRANSACTION_VALIDITY)

Ensure that only valid transactions are processed according to protocol rules and that the order of transactions is reliably established and resistant to manipulation.

Priority: High

Attack tree:


Validator Decentralization (VALIDATOR_DECENTRALIZATION)

Maintain sufficient decentralization among validators to prevent collusion, censorship, and single points of failure, despite high hardware requirements.

Priority: High

Attack tree:


Solana Threat Actors

Actors, agents, users and attackers may be used as synonymous.

A staked validator or colluding group of validator[...] (MALICIOUS_VALIDATOR)
Description:

A staked validator or colluding group of validators attempting to disrupt consensus, censor transactions, double spend, or execute other attacks enabled by their privileged position.

In Scope as threat actor:

Yes


An attacker without staked validation power attemp[...] (EXTERNAL_NETWORK_ATTACKER)
Description:

An attacker without staked validation power attempting network-level attacks like DoS, partitioning, or exploiting RPC node vulnerabilities.

In Scope as threat actor:

Yes


An attacker specifically targeting the state mecha[...] (STATE_LEVEL_ATTACKER)
Description:

An attacker specifically targeting the state mechanism, potentially exploiting smart contract vulnerabilities to manipulate state or leveraging the rent mechanism maliciously.

In Scope as threat actor:

Yes


A compromised entity (validator, infrastructure pr[...] (SNAPSHOT_PROVIDER_ATTACKER)
Description:

A compromised entity (validator, infrastructure provider) that generates or hosts ledger snapshots, attempting to distribute malicious or invalid snapshots.

In Scope as threat actor:

Yes


An attacker attempting to exploit or destabilize t[...] (ECONOMIC_MANIPULATOR)
Description:

An attacker attempting to exploit or destabilize the network through economic means, such as manipulating fee markets, spamming the network to increase costs, or exploiting staking/slashing mechanics.

In Scope as threat actor:

Yes


An end-user interacting with Solana (wallets, dApp[...] (RESOURCE_OWNER_USER)
Description:

An end-user interacting with Solana (wallets, dApps) who might make mistakes (e.g., draining rent SOL) or be targeted by phishing/social engineering.

In Scope as threat actor:

Yes


Assumptions

HIGH_PERFORMANCE_HARDWARE

Validators require significant computational resources (CPU, RAM, NVMe SSDs, bandwidth), which impacts decentralization and operational costs.

PUBLIC_NETWORK_EXPOSURE

The Solana network operates over the public internet and is exposed to standard network-level attacks.

SNAPSHOT_RELIANCE

New or recovering nodes primarily rely on downloading state snapshots rather than syncing the entire history from genesis due to performance constraints.

COMPLEX_INTERNALS

Solana's architecture (PoH, Sealevel, Turbine, etc.) introduces significant complexity compared to simpler blockchain designs, potentially increasing the attack surface or likelihood of implementation bugs.

ECONOMIC_INCENTIVES_WORK

The security model relies heavily on PoS economic incentives (stake, slashing) to motivate validators to act honestly.


Solana Analysis

Solana's design prioritizes high throughput and low fees, achieved through innovations like Proof-of-History and parallel transaction processing (Sealevel). This focus introduces specific threat vectors related to the complexity of these mechanisms, the high hardware requirements for validators (potentially impacting decentralization), reliance on snapshots for synchronization, and the unique aspects of its state management, particularly the rent mechanism. Common blockchain threats like consensus attacks and DoS are also relevant, adapted to Solana's PoS/PoH context. This threat model explores these areas to identify potential weaknesses and corresponding mitigations.


Solana Attack tree


Solana Threats

Note This section contains the threat and mitigations identified during the analysis phase.

Consensus Takeover (51% Stake Attack) (CONSENSUS_TAKEOVER_51_PERCENT)

Threat actors:
Threat Description

An attacker (or colluding group) acquires sufficient stake (typically >33% for liveness attacks, >51% for safety/reorg attacks in PoS) to manipulate consensus, potentially censoring transactions, double-spending (via state manipulation/reorgs), or halting the chain.

Impact

Loss of network finality, potential for double spends, transaction censorship, and complete network halt, severely undermining trust and usability.
NETWORK_INTEGRITY
TRANSACTION_VALIDITY
NETWORK_AVAILABILITY

CVSS
Environmental score: 8.1 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H

Counter-measures for CONSENSUS_TAKEOVER_51_PERCENT

POS_ECONOMIC_INCENTIVES Proof-of-Stake Economic Incentives

Requires attackers to acquire significant, costly stake. Dishonest behavior risks slashing (loss of stake), making attacks economically irrational for large stakeholders.

Countermeasure in place? Public and disclosable?

TOWER_BFT_CONSENSUS Tower BFT Consensus Mechanism

Solana's PoS consensus algorithm (Tower BFT) is designed to achieve finality quickly and make reversing confirmed blocks progressively harder and more costly due to increasing lockout periods for validators.

Countermeasure in place? Public and disclosable?

STAKE_DISTRIBUTION_MONITORING Stake Distribution Monitoring

Monitoring the distribution of stake across validators and entities helps identify potential centralization risks that could make a 51% attack more feasible. Encouraging stake delegation to smaller validators.

Countermeasure in place? Public and disclosable?

Malicious Snapshot Distribution (SNAPSHOT_POISONING)

Threat actors:
Threat Description

A compromised snapshot provider distributes a snapshot representing an invalid or manipulated state of the ledger. Nodes syncing from this snapshot start with incorrect data.

Impact

New or recovering nodes may fail to sync correctly, operate on invalid state, potentially approve invalid transactions based on the false state, or be unable to participate in the network. Can hinder network growth and recovery.
SNAPSHOT_TRUSTWORTHINESS
STATE_INTEGRITY
NETWORK_AVAILABILITY

CVSS
Base score: 6.8 (Medium)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H

Counter-measures for SNAPSHOT_POISONING

SNAPSHOT_HASH_VERIFICATION Snapshot Hash Verification

Operators should download snapshots only from trusted sources and verify the hash of the downloaded snapshot against a known-good hash published by multiple reputable sources or the foundation.

Countermeasure in place? Public and disclosable?

CONSENSUS_ROOTED_SNAPSHOTS Consensus-Rooted Snapshots

Snapshots are typically generated at specific slots/epochs whose state root hash has been agreed upon by network consensus. Syncing nodes verify the snapshot's root hash against the consensus-validated state.

Countermeasure in place? Public and disclosable?

DIVERSE_SNAPSHOT_SOURCES Diverse Snapshot Sources

Relying on multiple independent and reputable snapshot providers reduces the risk of a single compromised provider causing widespread issues.

Countermeasure in place? Public and disclosable?


Accidental Account Deletion via Rent Mechanism (RENT_INDUCED_DATA_LOSS)

Threat actors:
Threat Description

A user or application unintentionally allows an account's SOL balance to fall below the rent-exempt minimum. After a period, the Solana runtime garbage collects the account, deleting its state (e.g., token balance, NFT data, application state).

Impact

Permanent loss of data or assets stored within the reclaimed account. Can break applications relying on that account's state or lead to loss of user funds/NFTs.
RENT_MECHANISM_SAFETY
STATE_INTEGRITY

CVSS
Base score: 5.7 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:H/A:N

Counter-measures for RENT_INDUCED_DATA_LOSS

RENT_EXEMPT_MINIMUM_MAINTENANCE Maintain Rent-Exempt Minimum Balance

Users and developers must ensure accounts intended to persist maintain sufficient SOL balance to be rent-exempt. Wallets often prevent users from withdrawing the entire balance.

Countermeasure in place? Public and disclosable?

ACCOUNT_CLOSURE_FUNCTIONALITY Explicit Account Closure

Users can explicitly close accounts (especially empty token accounts) to reclaim the locked rent-exempt SOL, reducing the number of potentially vulnerable accounts.

Countermeasure in place? Public and disclosable?

DAPP_RENT_MANAGEMENT dApp Rent Management Logic

Developers of dApps must carefully manage the SOL balances of data accounts created by their programs to prevent accidental drainage below the rent threshold.

Countermeasure in place?Public and disclosable?


Rent Mechanism Amplifying Exploit Impact (RENT_EXPLOITATION_AMPLIFICATION)

Threat actors:
Threat Description

An attacker exploits an unrelated vulnerability (e.g., smart contract bug, private key compromise) to drain SOL from target accounts. The rent mechanism then causes these accounts (and their associated state/assets) to be permanently deleted when they become non-rent-exempt, amplifying the damage beyond just the SOL loss.

Impact

Turns reversible SOL theft (potentially) into irreversible data/asset loss by triggering garbage collection of critical accounts, causing greater disruption or permanent loss for users/applications.
RENT_MECHANISM_SAFETY
STATE_INTEGRITY

CVSS
Base score: 8.8 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

Counter-measures for RENT_EXPLOITATION_AMPLIFICATION

Reference to Solana.RENT_INDUCED_DATA_LOSS.RENT_EXEMPT_MINIMUM_MAINTENANCE Maintain Rent-Exempt Minimum Balance

Users and developers must ensure accounts intended to persist maintain sufficient SOL balance to be rent-exempt. Wallets often prevent users from withdrawing the entire balance.

Countermeasure in place? Public and disclosable?

SMART_CONTRACT_AUDITS Smart Contract Security Audits

Rigorous security audits of dApps/programs help prevent the initial vulnerabilities that attackers could exploit to drain rent SOL.

Countermeasure in place?Public and disclosable?

USER_SECURITY_PRACTICES User Security Best Practices

Protecting private keys through secure storage (hardware wallets) and avoiding phishing prevents attackers from gaining direct control to drain SOL.

Countermeasure in place?Public and disclosable?


Denial of Service against Validators (VALIDATOR_DOS)

Threat actors:
Threat Description

An attacker floods validators with excessive network traffic (transaction spam, invalid consensus messages) or targets their infrastructure (network links, hardware) to overwhelm their resources, causing them to fall out of sync, fail to participate in consensus, or shut down.

Impact

Reduced network throughput, increased transaction latency, potential temporary network halts if a sufficient number of validators are affected. Degrades user experience and network reliability.
NETWORK_AVAILABILITY

CVSS
Base score: 7.5 (High)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Counter-measures for VALIDATOR_DOS

VALIDATOR_INFRA_HARDENING Validator Infrastructure Hardening

Validators employ robust hardware, high-bandwidth connections, DDoS mitigation services, and secure network configurations to withstand attacks.

Countermeasure in place?Public and disclosable?

GULF_STREAM_AND_TURBINE Gulf Stream and Turbine Protocols

Solana's transaction forwarding (Gulf Stream) and block propagation (Turbine) protocols are designed to handle high traffic volumes efficiently, providing some resilience against naive spam.

Countermeasure in place? Public and disclosable?

TRANSACTION_FEES_AND_PRIORITIZATION Transaction Fees and Prioritization

While low, transaction fees impose a cost on spamming. Prioritization mechanisms (currently evolving) aim to give important transactions precedence over spam.

Countermeasure in place? Public and disclosable?


State Bloat Leading to Increased Centralization (STATE_BLOAT_CENTRALIZATION)

Threat actors:
Threat Description

Sustained high network usage leads to rapid growth of the active blockchain state (accounts database). This increases the hardware requirements (RAM, NVMe IOPS/capacity) for validators to maintain performance.

Impact

Rising hardware costs price out smaller validators, leading to increased centralization of stake and validation power among larger, well-funded entities. This weakens censorship resistance and resilience.
VALIDATOR_DECENTRALIZATION
NETWORK_AVAILABILITY

CVSS
Base score: 6.5 (Medium)
Vector:CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:L

Counter-measures for STATE_BLOAT_CENTRALIZATION

RENT_MECHANISM Rent Mechanism for State Storage

Requires accounts to pay for storage via locked SOL (rent exemption) or ongoing fees, incentivizing cleanup of unused state and slowing net growth.

Countermeasure in place? Public and disclosable?

CLOUDBREAK_OPTIMIZATION Cloudbreak Accounts Database Optimization

Solana's state database architecture (Cloudbreak) is designed for horizontal scaling and efficient concurrent access on SSDs to handle large state sizes. Continuous optimizations are necessary.

Countermeasure in place? Public and disclosable?

HARDWARE_ADVANCEMENTS Reliance on Hardware Advancements

Solana's design implicitly relies on Moore's Law-like improvements in hardware (CPU, RAM, storage, network) to keep pace with state growth over the long term.

Countermeasure in place? Public and disclosable?


Transaction Censorship by Leader (LEADER_CENSORSHIP)

Threat actors:
Threat Description

The validator currently assigned as the leader (block producer) intentionally refuses to include specific valid transactions in the blocks they produce.

Impact

Targeted users or applications may be unable to get their transactions confirmed, preventing them from interacting with the blockchain. Can be used to unfairly target competitors or specific activities.
NETWORK_INTEGRITY
TRANSACTION_VALIDITY
NETWORK_AVAILABILITY

CVSS
Base score: 3.8 (Low)
Vector:CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:L

Counter-measures for LEADER_CENSORSHIP

LEADER_ROTATION Leader Rotation Schedule

Leaders rotate frequently (every few slots). Censorship by one leader is temporary, as the next leader may include the transaction.

Countermeasure in place? Public and disclosable?

STAKE_WEIGHTED_QOS Stake-Weighted QoS / Prioritization Fees

Mechanisms (evolving) that use stake weight or priority fees can make it harder for leaders to ignore high-value/staked transactions without economic consequence or detection. Transactions can also be submitted to upcoming leaders via Gulf Stream.

Countermeasure in place? Public and disclosable?

NETWORK_MONITORING_CENSORSHIP Network Monitoring for Censorship

External monitoring can detect patterns of consistent censorship by specific validators, potentially leading to social slashing or stake withdrawal by delegators.

Countermeasure in place? Public and disclosable?


Parallel Execution Runtime Vulnerability (RUNTIME_BUG_SEALEVEL)

Threat actors:
Threat Description

An attacker discovers and exploits a bug in the Sealevel runtime, potentially causing incorrect state updates due to race conditions, bypassing transaction isolation guarantees, or causing validator crashes when processing specific parallelizable transactions.

Impact

Potential for incorrect state updates (e.g., double crediting/debiting), validator crashes leading to reduced network availability, or bypass of smart contract logic.
STATE_INTEGRITY
TRANSACTION_VALIDITY
NETWORK_AVAILABILITY

CVSS
Base score: 7.1 (High)
Vector:CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:H

Counter-measures for RUNTIME_BUG_SEALEVEL

CODE_AUDITS_RUNTIME Runtime Code Audits and Fuzzing

Rigorous auditing, formal verification (where applicable), and extensive fuzz testing of the Sealevel runtime implementation to identify and fix bugs.

Countermeasure in place? Public and disclosable?

TRANSACTION_STATE_DECLARATION Explicit State Declaration in Transactions

Transactions must declare upfront which accounts they read/write. This simplifies parallelization logic and reduces the chances of unexpected state conflicts that could trigger bugs.

Countermeasure in place? Public and disclosable?

INCREMENTAL_FEATURE_ROLLOUT Incremental Rollout and Testing

New runtime features or significant changes are typically tested extensively on testnets and rolled out incrementally with monitoring.

Countermeasure in place? Public and disclosable?

Requests For Information

    Operational Security Hardening Guide

    SeqCountermeasure Details

    Testing guide

    This guide lists all testable attacks described in the threat model

    SeqAttack to testPass/Fail/NA

    Keys classification