Solana (SOL)

Identity: solana-mainnet / solana-mainnet / native

Version: pilot-1 / Method: 0.1.0 / Updated: 2026-10-03T12:00:00Z

Verdict: Documented promise. Independent verification pending.

Score: unrated / Coverage: 0%

The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation.

The linked primary document is available. Its existence establishes what the project describes, while the operational checks remain open.

Current ownership concentration, privileged control powers, independently measured usage, incident remediation and locally executable liquidity remain unverified in this pilot.

The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns.

Reproducible network observations, current control maps, documented supply rules and independent incident records would allow the pending checks to be evaluated.

Promise and Scope

This dossier examines native SOL on the solana-mainnet network. The focus is strictly on documented mechanisms: instruction execution, version-pinned fee calculations, default inflation parameters, and the Agave feature-activation command-line interface (CLI). We analyze how these components are defined in code and documentation. This review does not assess live network performance, current validator uptime, or real-time transaction costs. It also excludes any evaluation of independent operational security or audit status.

Sources: 

Instruction Execution and Atomicity

Solana transactions consist of instructions, which are the individual operations that programs execute. A key technical property described in the documentation is atomicity. This means that within a single transaction, either all instructions succeed and their state changes are applied, or they fail and their instruction state changes revert. While this mechanism ensures internal consistency for a specific transaction, it does not prove that applications are free from bugs, nor does it guarantee the overall reliability of the network. Independent audits of specific smart contracts remain outside the scope of this observation.

Sources: https://solana.com/docs/core/transactions

Fee Mechanics and Version-Pinned Calculations

Fees on Solana are paid in SOL and comprise a base fee and an optional prioritization fee. Documentation states that the base fee is split evenly, with 50% burned and 50% allocated to the validator. The prioritization fee goes entirely to the validator. These rules describe the intended distribution logic but do not measure live costs or net issuance. In the Agave v4.3.0 client, the base-fee burn is calculated using integer arithmetic at 50%. The unburned portion and the full priority fee are added to a collector deposit. If this deposit fails, the entire amount is burned. Depending on a feature flag, the recipient may be the leader identity or a permitted collector associated with the leader's vote account.

Sources: https://solana.com/docs/core/fees, https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/runtime/src/bank/fee_distribution.rs

Hypothetical Fee Calculation Example

To illustrate the arithmetic without implying live network values, we present a hypothetical scenario based on original Cryptosnif calculations. Assume a base fee of 5000 lamports (the integer fee unit in this example) and a priority fee of 1000 lamports. The total fee is 6000 lamports. Under normal conditions with an accepted deposit, 2500 lamports are burned (50% of the base), and 3500 lamports go to the collector (2500 remaining base plus 1000 priority). If the collector deposit fails, all 6000 lamports are burned. In a case with an odd base fee of 5001 lamports and a priority fee of 1000 lamports, the burn calculation uses floor division: floor(5001 * 50 / 100) equals 2500 lamports burned. The collector receives 3501 lamports. These inputs are illustrative only and do not establish actual fees on the mainnet or provide a basis for cost comparison against other networks like Ethereum.

Sources: https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/runtime/src/bank/fee_distribution.rs

Default Inflation Parameters

The solana-inflation package version 3.2.0 defines a default total annual inflation rate formula: max(0.015, 0.08*(1-0.15)^year). This model supports disabled, fixed, and full inflation configurations. It is crucial to distinguish these code defaults from observed mainnet configuration. The formula represents a theoretical schedule, not realized issuance, calendar dates, or net supply changes. Furthermore, total inflation differs from a staking holder's yield. A model year in this context has no established calendar origin in this review.

Sources: https://raw.githubusercontent.com/anza-xyz/solana-sdk/94164111ad1e39677f2cf95b16c0b208f466b6c3/inflation/src/lib.rs

Inflation Rate Illustration

Applying the default formula yields specific rates for hypothetical model years. At model year 0, the rate is 8%. At model year 1, it drops to 6.8%. At model year 2, it is 5.78%. The reduction is 15% of the previous rate each year until it hits the 1.5% floor. The percentage applies to the preceding rate each model year. These figures illustrate the mathematical behavior of the default settings. They do not predict future inflation, circulating supply, or returns for stakers on the live network.

Sources: https://raw.githubusercontent.com/anza-xyz/solana-sdk/94164111ad1e39677f2cf95b16c0b208f466b6c3/inflation/src/lib.rs

Feature Activation CLI and Readiness Checks

The Agave v4.3.0 feature CLI checks a cluster's genesis identity and queries account state before constructing a signed feature-activation transaction. Its ordinary readiness check compares reported software feature sets against statistics showing at least 95% of stake and 95% of RPC nodes (query-interface servers) report the same feature set as the CLI. The CLI exposes an explicit force path that bypasses this local sanity check. However, this override does not prove that arbitrary users can activate features or compel every validator to adopt a rule. Transaction authorization, feature accounts, signatures, and deployed client behavior require separate verification. This observation identifies a change-control mechanism but does not confirm who holds activation keys or which features are currently active.

Sources: https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/cli/src/feature.rs

Unknowns and Limitations

Several critical elements remain unverified in this pilot review. Current ownership concentration, privileged control powers, independently measured usage, incident remediation history, and locally executable liquidity are unknown. The presence of a force override in the CLI does not equate to unrestricted administrator power, as consensus rules and validator adoption are distinct layers. Similarly, documented fee splits do not reflect live economic outcomes. No network transaction or activation was performed by Cryptosnif during this analysis.

Sources: https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/cli/src/feature.rs

Consequences and Verdict

The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience, security, or expected returns. The distinction between code defaults and live deployment is significant; inferring net supply or staking yield from formulas is invalid. For comparisons, different fee inputs cannot establish a cost winner without normalized, measured data. The verdict remains pending independent verification. Reproducible network observations, current control maps, documented supply rules, and independent incident records would allow the pending checks to be evaluated.

Sources: 

Source: https://solana.com/docs
Claim: The project publishes the mechanism described above.
Observed: 2026-10-03T12:00:00Z
Expires: 2026-11-02T12:00:00Z