﻿---
title: "Frais de priorité Ethereum"
description: "Guide pratique des frais de priorité EIP-1559, plafonds, prix effectif du gas, incitation à l'inclusion, estimation, remplacement et rapprochement du reçu."
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Frais de priorité Ethereum

> À des fins éducatives uniquement ; ceci ne constitue pas un conseil de transaction, de sécurité ou d'investissement. Les frais et l'inclusion dépendent de la chaîne, du type de transaction, du bloc et du comportement du portefeuille, du RPC, du relais, du builder et du validateur.

<a id="answer"></a>

## Réponse directe

Sur Ethereum, les frais de priorité, ou pourboire, sont le montant par unité de gas d'exécution qui reste au destinataire des frais du bloc après destruction des frais de base par le protocole. Dans une transaction EIP-1559 de type 2, `maxPriorityFeePerGas` n'est qu'un plafond : les frais de priorité effectifs par gas sont `min(maxPriorityFeePerGas, maxFeePerGas - baseFeePerGas)`, et le prix effectif du gas est égal aux frais de base plus ces frais de priorité effectifs.

Un pourboire concurrentiel plus élevé peut améliorer la probabilité d'une inclusion rapide, sans garantir le bloc suivant, un ordre précis ou la réussite de l'exécution. La transaction doit rester valide, son plafond total doit couvrir les frais de base du bloc d'inclusion et les builders ou validateurs peuvent considérer les flux privés, bundles, MEV, politiques locales et autres contraintes. Les termes et règles diffèrent sur les autres chaînes et L2 ; ne transposez pas la formule Ethereum sans vérifier le réseau.

<a id="mechanism"></a>

## Fonctionnement

1. Fixez la chaîne, le type de transaction, l'expéditeur, le nonce, la calldata prévue, la limite de gas, la tête actuelle et la voie d'envoi. Les transactions de type 2 exposent `maxPriorityFeePerGas` et `maxFeePerGas` ; les transactions historiques exposent un seul `gasPrice`, dont la partie supérieure aux frais de base devient la priorité effective après EIP-1559.
2. Estimez les conditions au lieu de copier un pourboire fixe. Un portefeuille ou RPC peut utiliser les blocs récents, la demande en attente et `eth_feeHistory` ; ses centiles de récompense décrivent les frais de priorité effectifs historiques pondérés par le gas consommé, pas une promesse pour le bloc suivant.
3. Définissez deux plafonds distincts. `maxPriorityFeePerGas` limite le pourboire demandé, tandis que `maxFeePerGas` limite frais de base plus pourboire. Le gas inutilisé et la marge de plafond inutilisée ne sont pas facturés du seul fait de leur autorisation.
4. Pour un bloc candidat, exigez `maxFeePerGas >= baseFeePerGas`. Calculez ensuite `effectivePriorityFeePerGas = min(maxPriorityFeePerGas, maxFeePerGas - baseFeePerGas)` et `effectiveGasPrice = baseFeePerGas + effectivePriorityFeePerGas`.
5. Considérez le pourboire comme une incitation à l'inclusion, pas un contrat d'ordre. Un builder peut optimiser la valeur totale du bloc, les bundles et les contraintes de validité au lieu de trier chaque transaction publique par pourboire ; un pourboire nul ou faible peut être inclus, tandis qu'un pourboire élevé peut attendre ou échouer.
6. Après inclusion, rapprochez reçu et bloc. Notez `gasUsed`, `effectiveGasPrice` du reçu, `baseFeePerGas` du bloc, le statut, le hash du bloc et la profondeur de confirmation. Les frais d'exécution valent `gasUsed * effectiveGasPrice` et la part prioritaire `gasUsed * (effectiveGasPrice - baseFeePerGas)`.
7. Si la transaction reste en attente, réévaluez le plafond de frais de base et la voie avant remplacement. Le remplacement à expéditeur et nonce identiques dépend des politiques du client et du pool, exige souvent la hausse de plusieurs champs et crée une course ; l'action Annuler d'un portefeuille ne peut inverser une transaction déjà incluse.

<a id="example"></a>

## Exemples calculés

- **Pourboire sous les deux plafonds.** Le gas consommé est `70,000`, les frais de base `25 gwei`, la priorité maximale `3 gwei` et les frais maximaux `40 gwei`. La priorité effective est `min(3, 40 - 25) = 3 gwei` et le prix effectif `28 gwei`. Les frais d'exécution sont `70,000 * 28 gwei = 0.001960 ETH`, répartis entre `0.001750 ETH` détruits et `0.000210 ETH` crédités comme priorité.
- **Le plafond total s'impose.** Conservez les plafonds à `3/40 gwei`, mais portez les frais de base du bloc à `38 gwei`. La priorité effective tombe à `min(3, 40 - 38) = 2 gwei`, donc le prix effectif est `40 gwei`. Avec des frais de base de `41 gwei`, la transaction ne peut être incluse sous ce maximum de `40 gwei`, même si le pourboire demandé est élevé.
- **L'estimation ne garantit rien.** Si les centiles récents de `eth_feeHistory` suggèrent `2 gwei`, cette observation est un point de départ. Un surcroît de demande, un bundle privé, la vue limitée d'un RPC ou la politique d'un builder peuvent changer l'inclusion ; vérifiez le reçu réel plutôt que de traiter l'estimation comme un engagement de service.

<a id="risks"></a>

## Risques

- Utiliser la mauvaise chaîne, le mauvais jeton de frais, le mauvais type de transaction ou confondre wei, gwei et ETH.
- Traiter `maxPriorityFeePerGas` comme le montant nécessairement payé.
- Oublier qu'une hausse des frais de base réduit le pourboire effectif ou rend la transaction inéligible sous `maxFeePerGas`.
- Supposer que le plus haut pourboire visible garantit la première place ou le prochain bloc.
- Dépendre d'estimations obsolètes du portefeuille, RPC ou historique lorsque la demande évolue vite.
- Surpayer en raison de valeurs par défaut agressives ou d'une confusion entre plafonds et coût réel.
- Croire qu'un pourboire élevé répare une calldata invalide, un manque de gas, un revert, une échéance expirée ou un contrat malveillant.
- Ignorer relais privés, bundles, MEV, censure et politiques des builders ou validateurs.
- Remplacer le mauvais nonce, manquer la règle de hausse du pool ou envoyer des transactions de valeur concurrentes.
- Lire une mention en attente comme vérité globale ou une confirmation comme finalité.
- Appliquer la formule Ethereum à un L2 ou une autre chaîne ayant des composantes et destinataires différents.

<a id="misconceptions"></a>

## Idées reçues

- **Les frais de priorité maximaux sont toujours payés.** C'est un plafond ; le plafond total peut réduire le pourboire effectif.
- **Un pourboire supérieur garantit le succès.** Il peut améliorer la compétitivité, sans garantir ordre, exécution ni finalité.
- **Les frais maximaux s'ajoutent aux frais de base et au pourboire.** Pour le gas de type 2, ils constituent le plafond couvrant les deux.
- **Le gas inutilisé ou la marge du plafond est dépensé.** La facturation réelle utilise le gas du reçu et le prix effectif.
- **Tous les réseaux utilisent le mécanisme Ethereum.** Les L2 et autres chaînes peuvent avoir d'autres marchés, politiques de séquenceur et destinataires.

<a id="related"></a>

## Sujets associés

- [Frais de base EIP-1559](/fr/crypto/eip1559-base-fee/)
- [Gas et frais de transaction](/fr/crypto/gas-fee/)
- [Mempools et pools de transactions](/fr/crypto/mempool/)
- [Remplacement d'une transaction Ethereum](/fr/crypto/mempool-replacement/)
- [Nonce de compte](/fr/crypto/nonce-crypto/)

<a id="sources"></a>

## Sources

- [Ethereum gas and fees: technical overview](https://ethereum.org/developers/docs/gas/) - Ethereum.org (consulté le 2026-08-21)
- [Transactions](https://ethereum.org/developers/docs/transactions/) - Ethereum.org (consulté le 2026-08-21)
- [EIP-1559: Fee market change for ETH 1.0 chain](https://eips.ethereum.org/EIPS/eip-1559) - Ethereum Improvement Proposals (consulté le 2026-08-21)
- [eth_feeHistory](https://ethereum.github.io/execution-apis/api/methods/eth_feeHistory/) - Ethereum Execution APIs (consulté le 2026-08-21)

Source: https://wiki.fcontext.com/fr/crypto/priority-fee/index.mdx
