cryptosnifSolana (SOL)
solana-mainnet · Native asset · pilot-1Unrated · 0% Evidence coverage
Documented promise. Independent verification pending.
The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns.
Inspect the evidenceThe source review explains documented mechanisms. Independent network checks remain pending.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Established facts
The linked primary document is available. Its existence establishes what the project describes, while the operational checks remain open.
The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation. [1]
What remains unknown
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.
Each check earns its result.
| Check | Weight | Result |
|---|---|---|
| Exact asset identityEssential | 3% | Verification pending |
| Observable use | 15% | Verification pending |
| Economic role of the token | 10% | Verification pending |
| Supply mechanismsEssential | 10% | Verification pending |
| Ownership concentration | 8% | Verification pending |
| Value capture | 7% | Verification pending |
| Control powersEssential | 10% | Verification pending |
| Security verification | 7% | Verification pending |
| Decision process | 8% | Verification pending |
| Accountability | 7% | Verification pending |
| Incident history | 6% | Verification pending |
| Operational continuity | 4% | Verification pending |
| Execution conditions | 5% | Verification pending |
Family-specific checks: Validator independence, upgrades, execution and fees.
Inspect the evidence
Sources behind this analysis
Agave v4.3.0: pinned feature activation CLI
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 with 95% of stake and 95% of RPC nodes in the collected version statistics. The CLI exposes an explicit force path that bypasses this local sanity check. That override does not prove that arbitrary users can activate arbitrary features or compel every validator to adopt a rule: transaction authorization, feature accounts, signatures and deployed client behavior require separate checks. This code observation identifies a change-control mechanism. The present holders of activation keys, actual activated features, network adoption and independence of operators remain unverified. No network transaction or activation was performed by Cryptosnif.
Inspect the primary source ↗Solana documentation: transaction fees
Solana documentation describes fees paid in SOL with a base fee and an optional prioritization fee. It states that the base fee is divided 50% burned and 50% to the validator, while the prioritization fee goes entirely to the validator. These documented rules do not measure live costs, utilization or net issuance.
Inspect the primary source ↗Solana documentation: transactions
Solana documentation describes transactions containing instructions, the individual operations that programs execute. Execution is atomic: all instructions succeed or their state changes revert. This technical property does not prove independent audits of applications, absence of bugs, or present network reliability.
Inspect the primary source ↗Solana SDK 3.2.0: pinned inflation model
The solana-inflation 3.2.0 source, matched to its package commit, defines a default total annual rate of max(0.015, 0.08*(1-0.15)^year). It also supports disabled, fixed and full inflation configurations. The default total model differs from the separate validator/foundation allocation functions. These are code parameters, not observed mainnet configuration, realized issuance, calendar dates, net supply change or a staking holder's yield. A model year has no calendar origin established in this review. Original Cryptosnif calculation (platform-mechanisms-1) gives default total annual inflation rates 8%, 6.8% and 5.78% at model years 0, 1 and 2, with a 1.5% floor. The reduction is 15% of the rate each model year until the floor, not a reduction of 15 percentage points. This illustrates defaults only, not today's mainnet inflation, a future dated forecast, circulating supply or staking returns.
Inspect the primary source ↗Agave v4.3.0: pinned transaction fee distribution
Agave v4.3.0 computes the ordinary base-fee burn with integer arithmetic at 50%, adds the unburned base portion and the entire priority fee to a collector deposit, then attempts that deposit. A failed deposit is also burned. Depending on a feature flag, the recipient is the leader identity or a permitted collector associated with the leader's vote account. This reviewed client version does not establish current feature activation, deployed versions, live transaction cost, total issuance or beneficial control. Illustrative inputs stay within non-overflowing fee amounts. Original Cryptosnif arithmetic (platform-mechanisms-1) assumes a hypothetical base fee 5000 lamports and priority fee 1000 lamports with accepted deposit: total 6000, burned 2500, collector 3500 lamports. With a failed collector deposit, all 6000 lamports are burned. With odd base fee 5001 and priority 1000 the accepted-deposit burn is floor(5001*50/100)=2500 and collector 3501. These hypothetical inputs do not establish fees on the live network or a comparison of cost against Ethereum.
Inspect the primary source ↗[1] Solana primary documentationProject claim
The project publishes the mechanism described above.
Observed 2026-10-03 · Valid until 2026-11-02
Inspect the primary source ↗Only original summaries are distributed. Licensed raw market data stays private.
What would change this verdict
Reproducible network observations, current control maps, documented supply rules and independent incident records would allow the pending checks to be evaluated.
No correction recorded for pilot-1. Future revisions retain their sources and prior verdicts.