Passer au contenu principal
Économisez de l’argent, améliorez les performances : Obtenez des estimations précises des frais prioritaires basées sur les conditions réelles du réseau. Ne payez que ce dont vous avez besoin pour la vitesse souhaitée.

Qu’est-ce que les frais prioritaires ?

Sur Solana, les frais prioritaires permettent à vos transactions d’avancer dans la file d’attente du validateur en cas de congestion du réseau. Pensez-y comme des voies express pour vos transactions.

Frais de base vs Frais prioritaires

Les frais de base sont des coûts fixes pour le traitement des transactionsLes frais prioritaires sont des paiements optionnels pour un traitement plus rapide

Comment ça fonctionne

Vous définissez un prix par unité de calcul - les prix plus élevés sont traités en premier en cas de congestion du réseau

Pourquoi utiliser les frais prioritaires

Les frais prioritaires font maintenant partie intégrante des transactions Solana, aidant à garantir des temps de confirmation fiables et des performances optimales du réseau.

Confirmation Fiable

Assurez-vous que vos transactions se confirment rapidement et de manière fiable, même pendant des conditions de réseau variables

Avantage Concurrentiel

Restez compétitif dans les opérations sensibles au temps comme le trading, le minting et les interactions DeFi

Expérience Utilisateur

Fournissez un traitement cohérent et rapide des transactions pour une meilleure expérience utilisateur

Efficacité du Réseau

Aidez à optimiser l’allocation des ressources du réseau et les performances générales

Explication des niveaux de priorité

Notre API propose six niveaux de priorité basés sur l’activité récente du réseau :
Frais observés les plus bas - Basés sur les frais minimaux observés dans les slots récentsIdéal pour : les transactions non urgentes lorsque l’optimisation des coûts est prioritaireRemarque : peut entraîner des délais de confirmation plus longs
25e percentile - Option économique offrant des délais de confirmation raisonnablesIdéal pour : les opérations standard pour lesquelles la rapidité n’est pas essentielleRemarque : bon équilibre entre coût et fiabilité
75e percentile - Frais plus élevés pour un traitement plus rapideIdéal pour : les opérations urgentes et les scénarios concurrentielsRemarque : traitement prioritaire pendant les périodes d’activité du réseau
Partie supérieure de la distribution, avec une marge supplémentaire - Frais premium pour une vitesse maximaleIdéal pour : les opérations critiques, les stratégies MEV et les transactions urgentesRemarque : ce niveau se situe au-dessus du 95e percentile des frais observés et les valeurs aberrantes ne sont pas exclues. Considérez-le comme une cible d’inclusion, et non comme une mesure de ce que paie le réseau
Maximum observé - Frais les plus élevés observés dans les slots récents, sans filtrage des valeurs aberrantesIdéal pour : les situations d’urgence uniquementAvertissement : une seule offre extrême dans la fenêtre d’analyse suffit à définir cette valeur. Elle atteint régulièrement des milliards de micro-lamports par unité de calcul ; utilisez-la avec prudence

Calcul des estimations

Les estimations sont calculées à partir des frais payés dans les slots récents (jusqu’à 150, valeur contrôlée par lookbackSlots). Deux éléments sont à prendre en compte lorsque vous comparez ces chiffres à vos propres mesures sur la blockchain :
  • Les transactions sans vote qui ne définissent aucun prix par unité de calcul sont comptabilisées comme nulles. Une grande partie des transactions sans vote d’un slot classique ne contient aucune instruction SetComputeUnitPrice. Elles sont intégrées à la distribution comme des échantillons sans frais, ce qui explique pourquoi min et low renvoient fréquemment 0. Si vous calculez les percentiles uniquement sur les transactions ayant un prix défini, vos chiffres seront supérieurs aux nôtres à tous les niveaux.
  • Les valeurs aberrantes ne sont pas exclues pour veryHigh et unsafeMax. Quelques transactions proposant des montants extrêmes dans la fenêtre d’analyse peuvent augmenter considérablement ces deux niveaux. De plus, veryHigh inclut une marge supplémentaire au-dessus du 95e percentile afin de rester une cible d’inclusion viable.
N’utilisez pas veryHigh ou unsafeMax comme statistiques des frais du réseau. Ces deux niveaux accordent délibérément davantage de poids à la partie supérieure de la distribution et dépassent ce que la plupart des transactions paient réellement.
Calcul du coût : frais de priorité totaux = Prix par unité de calcul × Unités de calcul consomméesUne transaction classique utilise entre 200 000 et 400 000 unités de calcul. Au niveau Medium actuel (environ 40 000 microlamports par unité), cela représente entre 0,000008 et 0,000016 SOL de frais de priorité. Vérifiez toujours les conditions actuelles du réseau pour obtenir des estimations précises.

Portée : estimations globales ou propres aux comptes

Les données que vous transmettez déterminent ce que mesure l’API.
  • Transmettez une transaction sérialisée - l’estimation est limitée aux comptes accessibles en écriture que votre transaction verrouille. Cette méthode est recommandée lorsque vous définissez les frais d’une transaction à envoyer.
  • Transmettez accountKeys - l’estimation est limitée à ces comptes. Incluez les comptes accessibles en écriture que votre transaction verrouillera, car ce sont les comptes pour lesquels vous êtes en concurrence.
  • Ne transmettez aucun des deux - vous obtenez une estimation globale couvrant toute l’activité récente du réseau, et non des frais adaptés à votre transaction.
Une estimation globale ne correspond pas aux frais à payer. Sans transaction ni accountKeys, la réponse décrit les conditions à l’échelle du réseau, y compris la congestion de comptes auxquels votre transaction n’accède jamais.Solana calcule les frais de priorité par compte accessible en écriture. Par conséquent, payer un niveau veryHigh global revient généralement à payer beaucoup trop sans améliorer le taux d’inclusion de votre transaction. Transmettez toujours une transaction ou les accountKeys accessibles en écriture lorsque l’estimation sert à définir les frais d’une transaction que vous êtes sur le point d’envoyer.

Méthodes d’implémentation

Serialized Transaction (Recommended)

Méthode principale - Analyse votre transaction exacte pour une précision maximaleIdéal pour : la plupart des applications et des cas d’usage en productionAvantages :
  • Analyse propre à chaque instruction
  • Précision maximale
  • Prêt pour la production
  • Prend en compte la complexité de la transaction

Account Keys (Advanced)

Cas d’usage spécialisés - Estimations basées sur les schémas d’utilisation des comptesIdéal pour : l’analyse préalable aux transactions, les opérations par lots et les architectures spécialiséesAvantages :
  • Analyse des schémas au niveau des comptes
  • Utile pour la planification et la recherche
  • Analyse des comptes par lots

Exemple de démarrage rapide

Référence de l’API

getPriorityFeeEstimate

Documentation complète de l’API avec tous les paramètres et formats de réponse

Surveillance du réseau en temps réel

Conseil de pro : surveillez les conditions du réseau pour optimiser votre stratégie de frais de priorité. Dans des conditions normales, utilisez des niveaux de priorité plus faibles. En cas de congestion, envisagez des niveaux plus élevés pour les opérations urgentes.Vous pouvez consulter les conditions actuelles du réseau à l’aide des explorateurs Solana ou de la méthode RPC getRecentPerformanceSamples.

Assistance et ressources

Discord Community

Obtenez de l’aide auprès de la communauté et de l’équipe Helius

Direct Support

Assistance pour les questions sur les frais de priorité et leur optimisation