Tokenomics de Solana

Promesse et périmètre

Cette analyse examine les mécanismes économiques documentés du SOL natif sur solana-mainnet. Le périmètre est limité aux valeurs par défaut définies dans le code pour l'inflation et la distribution des frais, telles que décrites dans des versions logicielles spécifiques. Il ne mesure pas les coûts réseau en direct, l'utilisation actuelle, l'émission nette ou les rendements individuels du staking. L'objectif est de clarifier comment les paramètres théoriques fonctionnent dans la base de code, en les distinguant des réalités observées sur le marché.

Valeurs par défaut du code d'inflation

Le paquet logiciel solana-inflation version 3.2.0 définit un taux d'inflation annuel total par défaut utilisant la formule max(0.015, 0.08*(1-0.15)^year). Cela représente une réduction multiplicative où le taux diminue de 15% de sa valeur précédente chaque année modèle jusqu'à atteindre un plancher terminal de 1.5%. Une année modèle est une unité abstraite dans ce calcul ; aucune origine calendaire n'est établie dans cette revue. Ce sont des paramètres de code, non une configuration mainnet observée ou une émission réalisée. Ils ne prédisent pas de dates futures, de changements de masse monétaire en circulation ou de retours pour les détenteurs de staking.

Ce package prend également en charge des configurations d'inflation désactivée, fixe et complète. Le modèle total par défaut diffère de ses fonctions séparées d'allocation aux validateurs et à la fondation, ce qui laisse le rendement réalisé d'un détenteur hors du calcul par défaut fourni.

Calcul hypothétique de l'inflation

Pour illustrer le mécanisme par défaut, Cryptosnif a effectué un calcul hypothétique basé sur la logique du code source. À l'année modèle 0, le taux est de 8%. À l'année modèle 1, le taux réduit à 6.8%. À l'année modèle 2, il réduit davantage à 5.78%. La réduction s'applique au taux précédent chaque année modèle. Cet exemple démontre le comportement mathématique des valeurs par défaut épinglées. Il ne reflète pas l'inflation mainnet d'aujourd'hui, ni ne sert de prévision pour l'émission réelle de tokens dans le temps.

Logique de brûlage et de distribution des frais

Le client Agave version 4.3.0 gère les frais de transaction via une arithmétique entière. Le brûlage de frais de base ordinaire est calculé comme floor(baseFee*50/100). Le montant de base non brûlé est ajouté à un dépôt collecteur avec l'intégralité des frais de priorité. Si le dépôt collecteur échoue, le montant complet destiné au collecteur est également brûlé. Selon les indicateurs de fonctionnalité, le destinataire peut être l'identité du leader ou un collecteur autorisé associé au compte de vote du leader. Cette version client examinée n'établit pas quelles fonctionnalités sont actuellement actives sur mainnet, ni ne confirme les versions déployées ou les structures de contrôle bénéficiaires.

Exemple hypothétique de frais

Les lamports sont les unités de frais entières utilisées dans cet exemple. En utilisant des entrées hypothétiques dans des plages sans débordement, nous examinons l'arithmétique. Supposons un frais de base de 5000 lamports et un frais de priorité de 1000 lamports. Avec un dépôt accepté, le frais total est de 6000 lamports. Le brûlage est de 2500 lamports (50% de la base), et le collecteur reçoit 3500 lamports (base restante plus priorité). Si le dépôt collecteur échoue, tous les 6000 lamports sont brûlés. Pour un frais de base impair de 5001 lamports avec un frais de priorité de 1000 lamports, le brûlage avec dépôt accepté est floor(5001*50/100)=2500 lamports, laissant 3501 lamports pour le collecteur. Ces chiffres sont purement illustratifs et ne représentent pas les frais réseau en direct ou des comparaisons de coûts avec d'autres chaînes.

Inconnues et limitations

Plusieurs points de données critiques restent inconnus. La masse monétaire en circulation actuelle, l'allocation initiale, la concentration des propriétaires bénéficiaires et les paramètres d'inflation mainnet actuels ne sont pas vérifiés ici. Les calendriers de vesting et de déblocage sont absents. Les observations indépendantes de l'utilisation, de la remédiation des incidents et de la liquidité localement exécutable sont en attente. La documentation décrit des règles mais ne mesure pas les coûts en direct ou l'émission nette. Différentes valeurs de frais ne peuvent pas établir un gagnant en termes de coût sans contexte plus large.

Conséquences et verdict

La distribution des frais documentée et la formule d'inflation par défaut fournissent un modèle économique dans les versions de code examinées. La configuration réseau actuelle et les retours pour les détenteurs restent non vérifiés, et la couverture des preuves est insuffisante pour un score global.

Mesurer l'émission nette nécessiterait des totaux d'émission et de frais brûlés sur la même période, avec une définition cohérente de la masse monétaire. Un brûlage d'une seule transaction et un taux par défaut annuel ne peuvent pas établir ce résultat. Le résultat d'un détenteur de staking nécessite également des preuves séparées sur l'allocation aux validateurs, les commissions et les récompenses observées. Ces mesures manquantes définissent ce qui pourrait changer le verdict.