cryptosnifSolana (SOL)
solana-mainnet · Actif natif · pilot-1Non noté · 0% Couverture des preuves
Promesse documentée. Vérification indépendante en attente.
Les preuves disponibles sont insuffisantes pour attribuer une note globale. La description du mécanisme demande une vérification de son fonctionnement actuel.
Consulter les preuvesLa revue des sources explique les mécanismes documentés. Les contrôles indépendants du réseau restent à réaliser.
Promesse et périmètre
Ce dossier examine le SOL natif sur le réseau solana-mainnet. Le focus est strictement limité aux mécanismes documentés : exécution des instructions, calculs de frais épinglés par version, paramètres d'inflation par défaut et l'interface en ligne de commande (CLI) d'activation de fonctionnalités Agave. Nous analysons comment ces composants sont définis dans le code et la documentation. Cette revue n'évalue pas les performances du réseau en direct, la disponibilité actuelle des validateurs ou les coûts de transaction en temps réel. Elle exclut également toute évaluation de la sécurité opérationnelle indépendante ou du statut d'audit.
Exécution des instructions et atomicité
Les transactions Solana consistent en des instructions, qui sont les opérations individuelles que les programmes exécutent. Une propriété technique clé décrite dans la documentation est l'atomicité. Cela signifie que au sein d'une seule transaction, soit toutes les instructions réussissent et leurs changements d'état sont appliqués, soit elles échouent et leurs changements d'état d'instruction sont annulés. Bien que ce mécanisme assure une cohérence interne pour une transaction spécifique, il ne prouve pas que les applications sont exemptes de bugs, ni ne garantit la fiabilité globale du réseau. Les audits indépendants de contrats intelligents spécifiques restent hors du périmètre de cette observation.
Mécanique des frais et calculs épinglés par version
Les frais sur Solana sont payés en SOL et comprennent un frais de base et un frais de priorisation optionnel. La documentation indique que le frais de base est divisé équitablement, avec 50% brûlés et 50% alloués au validateur. Le frais de priorisation va entièrement au validateur. Ces règles décrivent la logique de distribution prévue mais ne mesurent pas les coûts en direct ou l'émission nette. Dans le client Agave v4.3.0, la brûlure du frais de base est calculée à l'aide d'une arithmétique entière à 50%. La portion non brûlée et la totalité du frais de priorité sont ajoutées à un dépôt collecteur. Si ce dépôt échoue, la totalité du montant est brûlée. Selon un indicateur de fonctionnalité, le destinataire peut être l'identité du leader ou un collecteur autorisé associé au compte de vote du leader.
Exemple hypothétique de calcul de frais
Pour illustrer l'arithmétique sans impliquer de valeurs réseau en direct, nous présentons un scénario hypothétique basé sur les calculs originaux de Cryptosnif. Supposons un frais de base de 5000 lamports (l'unité de frais entière dans cet exemple) et un frais de priorité de 1000 lamports. Le total des frais est de 6000 lamports. Dans des conditions normales avec un dépôt accepté, 2500 lamports sont brûlés (50% du frais de base), et 3500 lamports vont au collecteur (2500 restants du frais de base plus 1000 de priorité). Si le dépôt collecteur échoue, tous les 6000 lamports sont brûlés. Dans un cas avec un frais de base impair de 5001 lamports et un frais de priorité de 1000 lamports, le calcul de la brûlure utilise la division plancher : floor(5001 * 50 / 100) égale 2500 lamports brûlés. Le collecteur reçoit 3501 lamports. Ces entrées sont purement illustratives et n'établissent pas les frais réels sur le mainnet ni ne fournissent une base pour une comparaison de coût avec d'autres réseaux comme Ethereum.
Paramètres d'inflation par défaut
Le package solana-inflation version 3.2.0 définit une formule par défaut pour le taux d'inflation annuel total : max(0.015, 0.08*(1-0.15)^year). Ce modèle supporte des configurations d'inflation désactivée, fixe et complète. Il est crucial de distinguer ces valeurs par défaut du code de la configuration observée sur le mainnet. La formule représente un calendrier théorique, pas une émission réalisée, des dates calendaires ou des changements nets de l'offre. De plus, l'inflation totale diffère du rendement d'un détenteur de staking. Une année modèle dans ce contexte n'a pas d'origine calendaire établie dans cette revue.
Illustration du taux d'inflation
L'application de la formule par défaut donne des taux spécifiques pour des années modèles hypothétiques. À l'année modèle 0, le taux est de 8%. À l'année modèle 1, il baisse à 6.8%. À l'année modèle 2, il est de 5.78%. La réduction est de 15% du taux précédent chaque année jusqu'à atteindre le plancher de 1.5%. Le pourcentage s'applique au taux précédent chaque année modèle. Ces chiffres illustrent le comportement mathématique des paramètres par défaut. Ils ne prédisent pas l'inflation future, l'offre en circulation ou les rendements pour les stakers sur le réseau en direct.
CLI d'activation de fonctionnalités et vérifications de préparation
Le CLI de fonctionnalité Agave v4.3.0 vérifie l'identité de genèse d'un cluster et interroge l'état du compte avant de construire une transaction signée d'activation de fonctionnalité. Sa vérification de préparation ordinaire compare les ensembles de fonctionnalités logicielles rapportés contre des statistiques montrant qu'au moins 95% du stake et 95% des nœuds RPC (serveurs d'interface de requête) rapportent le même ensemble de fonctionnalités que le CLI. Le CLI expose un chemin de force explicite qui contourne cette vérification locale de bon sens. Cependant, cette dérogation ne prouve pas que des utilisateurs arbitraires peuvent activer des fonctionnalités ou contraindre chaque validateur à adopter une règle. L'autorisation de transaction, les comptes de fonctionnalité, les signatures et le comportement du client déployé nécessitent une vérification séparée. Cette observation identifie un mécanisme de contrôle des changements mais ne confirme pas qui détient les clés d'activation ou quelles fonctionnalités sont actuellement actives.
Inconnues et limitations
Plusieurs éléments critiques restent non vérifiés dans cette revue pilote. La concentration actuelle de la propriété, les pouvoirs de contrôle privilégiés, l'utilisation mesurée indépendamment, l'historique de remédiation des incidents et la liquidité localement exécutable sont inconnus. La présence d'une dérogation de force dans le CLI n'équivaut pas à un pouvoir administratif illimité, car les règles de consensus et l'adoption par les validateurs sont des couches distinctes. De même, les divisions de frais documentées ne reflètent pas les résultats économiques en direct. Aucune transaction réseau ou activation n'a été effectuée par Cryptosnif lors de cette analyse.
Conséquences et verdict
La couverture des preuves est insuffisante pour un score global. Un mécanisme documenté seul ne peut établir la résilience actuelle, la sécurité ou les rendements attendus. La distinction entre les valeurs par défaut du code et le déploiement en direct est significative ; inférer l'offre nette ou le rendement de staking à partir de formules est invalide. Pour les comparaisons, différents intrants de frais ne peuvent établir un gagnant en termes de coût sans données normalisées et mesurées. Le verdict reste en attente de vérification indépendante. Des observations réseau reproductibles, des cartes de contrôle actuelles, des règles d'approvisionnement documentées et des registres d'incidents indépendants permettraient d'évaluer les vérifications en attente.
Faits établis
Le document primaire ci-dessous est accessible et décrit la promesse du projet. Les contrôles indépendants de fonctionnement restent à réaliser.
The Solana documentation presents a network for applications and transactions. Documentation describes the proposed mechanisms; current operation requires independent observation. [1]
Ce qui reste inconnu
La concentration des détenteurs, les pouvoirs de contrôle, l’usage actuel, les incidents et la liquidité locale restent à vérifier.
Les preuves disponibles sont insuffisantes pour attribuer une note globale. La description du mécanisme demande une vérification de son fonctionnement actuel.
Chaque contrôle demande ses preuves.
| Contrôle | Poids | Résultat |
|---|---|---|
| Identité exacte de l’actifEssentiel | 3% | Vérification en attente |
| Usage observable | 15% | Vérification en attente |
| Rôle économique du token | 10% | Vérification en attente |
| Mécanismes d’offreEssentiel | 10% | Vérification en attente |
| Concentration des détenteurs | 8% | Vérification en attente |
| Captation de valeur | 7% | Vérification en attente |
| Pouvoirs de contrôleEssentiel | 10% | Vérification en attente |
| Vérification de la sécurité | 7% | Vérification en attente |
| Processus de décision | 8% | Vérification en attente |
| Responsabilités | 7% | Vérification en attente |
| Historique des incidents | 6% | Vérification en attente |
| Continuité du fonctionnement | 4% | Vérification en attente |
| Conditions d’exécution | 5% | Vérification en attente |
Contrôles propres à la famille: Indépendance des validateurs, mises à jour, exécution et frais.
Consulter les preuves
Les sources de cette analyse
Les titres et résumés des sources sont en anglais.
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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗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.
Consulter la source primaire ↗[1] Solana documentation primaireAffirmation du projet
The project publishes the mechanism described above.
Observation 2026-10-03 · Valide jusqu’au 2026-11-02
Consulter la source primaire ↗Seuls les résumés originaux sont distribués. Les données de marché brutes sous licence restent privées.
Ce qui modifierait ce verdict
Des observations reproductibles du réseau, une cartographie des pouvoirs et une vérification des règles d’offre permettraient de compléter les épreuves.
Aucune correction enregistrée pour pilot-1. Les révisions conservent leurs sources et les verdicts précédents.