{"schemaVersion":"1.0.0","presentationVersion":"cryptosnif-2","identity":{"id":"solana-mainnet","name":"Solana","symbol":"SOL","network":"solana-mainnet","contract":null,"family":"platform","aliases":["Solana"],"providers":{"coingecko":"solana"}},"version":"pilot-1","methodVersion":"0.1.0","methodStatus":"candidate","updatedAt":"2026-10-03T12:00:00Z","readiness":"pilot","verdict":"Documented promise. Independent verification pending.","promise":"The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation.","established":"The linked primary document is available. Its existence establishes what the project describes, while the operational checks remain open.","unknowns":"Current ownership concentration, privileged control powers, independently measured usage, incident remediation and locally executable liquidity remain unverified in this pilot.","consequences":"The evidence coverage is insufficient for an overall score. A documented mechanism alone cannot establish current resilience or expected returns.","wouldChange":"Reproducible network observations, current control maps, documented supply rules and independent incident records would allow the pending checks to be evaluated.","score":{"methodVersion":"0.1.0","status":"unrated","total":null,"partial":null,"coverage":0,"dimensions":[{"id":"technology","score":null,"coverage":0},{"id":"usage","score":null,"coverage":0},{"id":"economics","score":null,"coverage":0},{"id":"governance","score":null,"coverage":0},{"id":"resilience","score":null,"coverage":0},{"id":"liquidity","score":null,"coverage":0}],"missingEssential":["identity","supply","control"],"unknown":["identity","usage","token-role","supply","concentration","value-capture","control","security","governance","accountability","incidents","continuity","execution"],"criticalRisks":[]},"risks":[{"id":"coverage","severity":"high","message":"The current checks do not establish the project’s overall quality."}],"sources":[{"id":"solana-mainnet-documentation","assetId":"solana-mainnet","kind":"project","url":"https://solana.com/docs","claim":"The project publishes the mechanism described above.","observedAt":"2026-10-03T12:00:00Z","expiresAt":"2026-11-02T12:00:00Z","status":"verified","license":"original-summary"}],"corrections":[],"editorialArticle":{"contentId":"solana","locale":"en","version":"editorial-3-candidate","reviewedAt":"2026-10-04T20:56:20.384Z","sections":[{"heading":"Promise and Scope","body":"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.","evidenceIds":[]},{"heading":"Instruction Execution and Atomicity","body":"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.","evidenceIds":["sol-transactions"]},{"heading":"Fee Mechanics and Version-Pinned Calculations","body":"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.","evidenceIds":["sol-fees","sol-fee-distribution"]},{"heading":"Hypothetical Fee Calculation Example","body":"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.","evidenceIds":["sol-fee-distribution"]},{"heading":"Default Inflation Parameters","body":"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.","evidenceIds":["sol-inflation"]},{"heading":"Inflation Rate Illustration","body":"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.","evidenceIds":["sol-inflation"]},{"heading":"Feature Activation CLI and Readiness Checks","body":"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.","evidenceIds":["sol-feature-activation-cli"]},{"heading":"Unknowns and Limitations","body":"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.","evidenceIds":["sol-feature-activation-cli"]},{"heading":"Consequences and Verdict","body":"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.","evidenceIds":[]}],"sources":[{"id":"sol-feature-activation-cli","title":"Agave v4.3.0: pinned feature activation CLI","url":"https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/cli/src/feature.rs","summary":"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.","observedAt":"2026-10-04T20:49:32.885Z","sha256":"c86ede94111a431391d1fa78f6d485ebe2516c743c391ab34d22e2f9141e971d"},{"id":"sol-fees","title":"Solana documentation: transaction fees","url":"https://solana.com/docs/core/fees","summary":"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.","observedAt":"2026-10-04T20:49:33.470Z","sha256":"74d412e5f13f34905db9f2e2a89b46e59ce6bddba5c2eec826a863e29571f309"},{"id":"sol-transactions","title":"Solana documentation: transactions","url":"https://solana.com/docs/core/transactions","summary":"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.","observedAt":"2026-10-04T20:49:33.499Z","sha256":"7a548186f39a719651621e614984d7603ab6305108181ef92eab7d63198d7649"},{"id":"sol-inflation","title":"Solana SDK 3.2.0: pinned inflation model","url":"https://raw.githubusercontent.com/anza-xyz/solana-sdk/94164111ad1e39677f2cf95b16c0b208f466b6c3/inflation/src/lib.rs","summary":"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.","observedAt":"2026-10-04T20:49:32.887Z","sha256":"0ee7728aa0e22ae15f189f23dd69b478ee697b0e4eab90e59e4d06a380d4f06f"},{"id":"sol-fee-distribution","title":"Agave v4.3.0: pinned transaction fee distribution","url":"https://raw.githubusercontent.com/anza-xyz/agave/v4.3.0/runtime/src/bank/fee_distribution.rs","summary":"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.","observedAt":"2026-10-04T20:49:32.898Z","sha256":"78c933830667e2c6c155820ecf2b799a77cf4227e1634d37ef04737e13c2811b"}],"review":{"scope":"documentation","changes":["{\"section\":0,\"originalEvidenceIds\":[],\"correctedEvidenceIds\":[],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":1,\"originalEvidenceIds\":[1],\"correctedEvidenceIds\":[\"sol-transactions\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":2,\"originalEvidenceIds\":[2,5],\"correctedEvidenceIds\":[\"sol-fees\",\"sol-fee-distribution\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":3,\"originalEvidenceIds\":[5],\"correctedEvidenceIds\":[\"sol-fee-distribution\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":4,\"originalEvidenceIds\":[4],\"correctedEvidenceIds\":[\"sol-inflation\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":5,\"originalEvidenceIds\":[4],\"correctedEvidenceIds\":[\"sol-inflation\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":6,\"originalEvidenceIds\":[0],\"correctedEvidenceIds\":[\"sol-feature-activation-cli\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":7,\"originalEvidenceIds\":[],\"correctedEvidenceIds\":[\"sol-feature-activation-cli\"],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":8,\"originalEvidenceIds\":[],\"correctedEvidenceIds\":[],\"reason\":\"Each passage manually matched to the named primary source; numeric IDs are not converted by index.\"}","{\"section\":1,\"from\":\"all state changes revert\",\"to\":\"their instruction state changes revert\"}","{\"section\":3,\"from\":\"a base fee of 5000 lamports\",\"to\":\"a base fee of 5000 lamports (the integer fee unit in this example)\"}","{\"section\":4,\"from\":\"staking yield, which is what a holder actually receives after validator commissions and other factors\",\"to\":\"a staking holder's yield\"}","{\"section\":4,\"from\":\"max(0.015, 0.08 * (1 - 0.15)^year)\",\"to\":\"max(0.015, 0.08*(1-0.15)^year)\"}","{\"section\":5,\"from\":\"This is not a reduction of 15 percentage points.\",\"to\":\"The percentage applies to the preceding rate each model year.\"}","{\"section\":6,\"from\":\"95% of stake and 95% of RPC nodes have adopted the relevant versions\",\"to\":\"at least 95% of stake and 95% of RPC nodes (query-interface servers) report the same feature set as the CLI\"}"]}}}