Solana SIMD 547 : des frais de base basés sur les ressources, entièrement brûlés — potentiellement plus de 1 500 SOL brûlés quotidiennement.
Solana SIMD 547 : des frais de base basés sur les ressources, entièrement brûlés — potentiellement plus de 1 500 SOL brûlés quotidiennement.
La conception de Solana, axée sur des "frais bas, débit élevé", lui a permis de devenir une plateforme de premier plan pour le trading on-chain, les applications grand public et les paiements en temps réel. Mais à mesure que l'activité économique du réseau s'intensifie, une question récurrente refait surface sur le marché plus large des cryptomonnaies : SOL devrait-il capter davantage de valeur de l'usage gourmand en ressources, sans nuire à l'expérience utilisateur qui a rendu Solana compétitif dès le départ ?
Une nouvelle proposition communautaire, SIMD 547, explore une réponse possible : introduire des frais de base basés sur les ressources, tarifés par "unités de coût", et brûler intégralement ces frais. L'idée gagne du terrain car elle cible directement la tokenomique de SOL — plus précisément, l'écart entre le brûlage actuel relativement faible des frais et l'émission continue du réseau.
Voici ce que propose la proposition, pourquoi elle est importante, et ce qu'elle pourrait signifier pour les développeurs, les traders et les utilisateurs de tous les jours.
1) Pourquoi le brûlage des frais de Solana semble-t-il "trop faible" aujourd'hui ?
Dans le modèle de frais actuel de Solana, le coût d'une transaction est globalement constitué de :
- Frais de base (basés sur la signature ; actuellement 5 000 lamports par signature), plus
- Frais de priorisation (optionnels ; définis via des instructions de budget de calcul). Vous payez des frais même si une transaction échoue. Consultez la documentation sur la structure des frais de Solana. (solana.com)
Crucial pour la tokenomique :
- 50 % des frais de base sont brûlés, et les 50 % restants vont au validateur qui produit le bloc.
- 100 % des frais de priorisation vont aux validateurs (aucun n'est brûlé). Les détails sont également résumés dans la même documentation sur la structure des frais. (solana.com)
En ce qui concerne la tokenomique, il est crucial de noter :
- 50% des frais de base sont brûlés, et les 50% restants vont au validateur qui produit le bloc.
- 100% des frais de priorisation vont aux validateurs (rien n'est brûlé). Les détails sont également résumés dans la même documentation sur la structure des frais. (solana.com)
Dans la discussion SIMD 547, le proposant soutient que le brûlage actuel via les frais de base est économiquement infime, estimant environ 648 SOL/jour brûlés par ce mécanisme dans des hypothèses de débit élevé — négligeable par rapport à une inflation estimée à ~60 000 SOL/jour. (github.com)
Cet écart est la motivation : si SOL est censé refléter l'activité du réseau, certains membres de la communauté souhaitent que la dynamique de brûlage du protocole évolue davantage avec la consommation réelle des ressources, et pas seulement avec les signatures.
2) Ce que SIMD 547 propose (en langage clair)
La suggestion centrale de SIMD 547 est simple :
- Chaque transaction se voit attribuer un "coût" estimé, basé sur plusieurs dimensions de ressources (pas seulement le calcul).
- Ajouter de nouveaux frais de base calculés à partir de ce coût, tarifés à : 0,1 lamport par unité de coût demandée, et en brûler 100 %. (github.com)
Si vous avez besoin d'un rappel rapide, un lamport est la plus petite unité de SOL (1 lamport = 0,000000001 SOL). Voir la référence terminologique de Solana pour les lamports. (solana.com)
"Unités de coût" vs "Unités de calcul"
De nombreux utilisateurs connaissent les unités de calcul car elles apparaissent dans l'ajustement des frais de priorité. Mais le "coût" dans le planificateur de Solana est plus large : il prend en compte des éléments tels que les verrous d'écriture et la taille des données des comptes chargés, pas seulement le calcul. Ceci est reflété dans l'explication des frais et de la planification des transactions dans la documentation sur la structure des frais (voir comment le terme "coût" est utilisé dans la planification des transactions). (solana.com)
Dans le fil SIMD 547, l'auteur souligne également que les unités de coût incluent le calcul ainsi que d'autres ressources implicitement demandées (données chargées, heap, verrous d'écriture, etc.). (github.com)
3) Impact du brûlage attendu : "Significatif, mais pas magique"
L'un des points les plus discutés est la quantité supplémentaire de SOL qui serait effectivement brûlée.
Dans le fil, un membre de la communauté a partagé des agrégats récents des limites d'unités de calcul demandées par jour, concluant qu'aux niveaux d'utilisation actuels, le mécanisme générerait probablement environ 1 500 à 1 800 SOL/jour de brûlage supplémentaire, avec une possibilité de plus lors des pics de demande. (github.com)
C'est matériellement plus que le brûlage actuel des frais de base, mais encore insuffisant en soi pour rendre Solana un actif de manière fiable déflationniste dans des conditions normales — surtout si des frais plus élevés réduisent la demande. Ce compromis est au centre du débat.
4) Qui paie plus ? Les fabricants vs les utilisateurs finaux (et pourquoi la proposition s'en soucie)
Un objectif clé de la conception est d'éviter de perturber la structure du marché à haute fréquence tout en facturant davantage pour les transactions gourmandes en ressources.
Dans la présentation de SIMD 547, le proposant affirme que bon nombre des mises à jour à haute fréquence (souvent associées aux mises à jour des fabricants/oracles) ont tendance à demander relativement peu d'unités de coût, de sorte que les frais supplémentaires pourraient être plafonnés à une augmentation de quelques pour cent dans ces flux de travail. (github.com)
Cependant, pour les utilisateurs ordinaires qui soumettent actuellement des transactions avec des frais de priorité faibles ou nuls, l'augmentation relative peut sembler spectaculaire. Le fil de discussion présente des exemples montrant des hausses en pourcentage à trois chiffres, y compris un scénario avec une augmentation de +639 % lors du passage d'une transaction à frais minimaux à une transaction qui paie également les nouveaux frais de base basés sur les ressources. (github.com)
Constat pratique
- Si vous dépendez déjà des frais de priorité (par exemple, pour le trading concurrentiel), l'impact incrémental peut être modeste en termes de pourcentage.
- Si vous envoyez généralement des transactions "bon marché" (en particulier dans des contextes de faible urgence), votre sensibilité au coût pourrait être plus élevée.
C'est pourquoi la proposition est controversée : elle améliore l'accumulation de valeur pour les détenteurs de SOL par le brûlage, mais elle pourrait également remodeler l'expérience utilisateur "par défaut et bon marché" que de nombreux utilisateurs associent à Solana.
5) La dépendance à Alpenglow : pourquoi le timing est important
SIMD 547 n'est pas présenté comme quelque chose qui peut être activé immédiatement.
La discussion note explicitement que les coûts de vote des validateurs sont importants jusqu'à ce qu'Alpenglow soit activé, et que le mécanisme est censé s'activer après Alpenglow. (github.com)
Alpenglow lui-même est une proposition majeure de refonte du consensus, formalisée sous le nom de SIMD 0326, remplaçant le consensus actuel basé sur Proof-of-History + TowerBFT par Alpenglow (Votor) pour de meilleures performances et une meilleure résilience. Voir le document SIMD 0326. (github.com)
Donc, en pratique, SIMD 547 doit être lu comme faisant partie d'une feuille de route plus large : d'abord changer le consensus et les mécanismes de vote, puis revisiter les leviers de tokenomique qui seraient douloureux selon les hypothèses actuelles.
6) Questions en suspens que la communauté débattra probablement
Même les partisans reconnaissent généralement que les détails sont importants. Sur la base du fil de discussion et des mécanismes de frais actuels de Solana, attendez-vous à des débats sur :
- Ressources demandées vs utilisées : facturer sur le "coût demandé" est simple et prévisible, mais peut surcharger les transactions mal configurées (similaire à la façon dont les frais de priorité dépendent de la limite demandée d'UC). (solana.com)
- Expérience utilisateur au niveau de l'application : les portefeuilles et les dApps pourraient avoir besoin d'une meilleure estimation des frais et d'une ventilation plus claire ("combien pour le brûlage, combien pour le pourboire, combien pour la base").
- Économie du spam et des attaques par déni de service (DoS) : un brûlage plus important pourrait dissuader certains comportements abusifs, mais il peut aussi pénaliser les cas d'utilisation légitimes de haute complexité (routage DeFi, interactions avancées avec les programmes).
- Tokenomique vs adoption : en 2025-2026, la tendance de l'industrie a été vers des marchés de frais plus durables et une capture de valeur plus claire — mais les réseaux qui vont trop loin peuvent pousser l'activité vers des alternatives.
Pour les lecteurs qui souhaitent la discussion principale, le meilleur point de départ est le fil de discussion communautaire original SIMD 547. (github.com)
7) Ce que les utilisateurs et les constructeurs peuvent faire maintenant
Même si SIMD 547 est encore en discussion et n'est pas actif, c'est un bon moment pour se préparer :
Pour les équipes de dApp
- Auditez les transactions qui demandent habituellement des limites élevées "par sécurité". La documentation de Solana explique comment les frais de priorité dépendent des limites d'unités de calcul demandées dans la documentation sur la structure des frais. (solana.com)
- Suivez la fréquence à laquelle vos utilisateurs dépendent des flux "sans frais de priorité" ; ce sont ceux qui sont les plus exposés à un nouveau composant de brûlage obligatoire.
Pour les traders et les utilisateurs avancés
- Si vous utilisez l'automatisation, commencez à modéliser les frais comme (frais de base de signature + frais de priorité + brûlage potentiel basé sur les ressources), au lieu de considérer le brûlage comme une erreur d'arrondi.
- Si vous regroupez des actions, déterminez si des transactions moins nombreuses mais plus lourdes deviendraient moins attrayantes que des interactions plus granulaires.
Pour tout le monde : l'auto-garde reste importante
Les débats sur les mécanismes de frais et la tokenomique ont tendance à accroître l'expérimentation on-chain (nouveau routage, nouvelles stratégies MEV, nouveaux bots). C'est aussi le moment où les tentatives de phishing et les approbations malveillantes augmentent.
Si vous détenez du SOL à long terme ou interagissez fréquemment avec la DeFi Solana, un portefeuille matériel comme OneKey peut vous aider en gardant les clés privées hors ligne et en exigeant des approbations de transaction explicites — utile lorsque la composition des transactions (et les détails des frais) devient plus complexe.
Conclusion
SIMD 547 est une proposition axée sur la tokenomique qui tente de trouver un équilibre difficile : augmenter le brûlage de SOL d'une manière qui évolue avec la consommation des ressources, tout en évitant une augmentation brute des frais qui pourrait perturber les validateurs et la fourniture de liquidités à haute fréquence.
Si elle est mise en œuvre comme proposé, les estimations de la communauté suggèrent qu'elle pourrait ajouter environ 1 500 à 1 800 SOL/jour de brûlage supplémentaire aux niveaux d'utilisation actuels — encore modeste par rapport à l'émission, mais plus négligeable. (github.com)
Pour l'instant, le point le plus important n'est pas le chiffre exact — c'est la direction : Solana explore activement comment aligner les ressources du réseau, les marchés des frais et la capture de valeur de SOL, probablement en tandem avec des changements de protocole plus importants comme Alpenglow. (github.com)
