Les utilisateurs pourraient payer en USDC tandis qu'un sponsor paie en ETH

EIP-8141, connue sous le nom de Frame Transactions, est une proposition à l'état de brouillon pour un nouveau type de transaction Ethereum. Elle découpe une transaction en « frames » programmables capables de vérifier l'approbation d'un utilisateur, de sélectionner un payeur et d'exécuter l'appel prévu.

La Meta EIP de Hegotá indique que les Frame Transactions sont prévues pour inclusion, et Vitalik Buterin a partagé une mise à jour récente sur l'avancement de la proposition. La spécification reste un brouillon, et Hegotá n'est pas encore activée. Comme pour toute EIP, l'inclusion dans le calendrier d'un fork ne garantit pas l'activation ; les propositions peuvent encore évoluer ou être abandonnées avant la livraison d'une mise à niveau du réseau.

A lot of important progress on Frames (EIP-8141) has been quietly happening over the last few months. Highly recommend reading this, also the updated EIP

— vitalik.eth (@VitalikButerin) September 5, 2026

Avec cette modification, un utilisateur pourrait effectuer une transaction sans détenir personnellement d'ETH, à condition que son portefeuille, l'application et un sponsor prennent tous en charge le format. Le sponsor pourrait facturer l'utilisateur en USDC ou dans un autre jeton ERC-20, ou l'application pourrait couvrir les frais dans le cadre de son service.

L'espace de bloc Ethereum resterait payé en ETH. Les Frame Transactions modifient qui fournit et gère cet ETH, et non le marché des frais sous-jacent.

À quoi pourrait ressembler une transaction payée en jetons

L'EIP inclut un exemple dans lequel un sponsor paie les frais réseau et reçoit un paiement en ERC-20 de l'utilisateur. Un portefeuille détenant de l'USDC mais pas d'ETH pourrait, en principe, soumettre un swap ou un transfert selon la séquence suivante :

Comment un paiement de gaz en ERC-20 pourrait fonctionner

1. Approbation – Le portefeuille de l'utilisateur valide l'ensemble complet des actions que la transaction doit effectuer.
2. Accord de paiement – Un sponsor accepte de couvrir le gaz en ETH en échange d'un paiement en ERC-20, ou subventionne l'action.
3. Exécution – Le paiement en jeton et le transfert, le mint ou le swap prévu sont traités dans le même flux de transaction.

Regrouper ces étapes en une seule transaction évite d'obliger l'utilisateur à acquérir de l'ETH avant que l'action prévue puisse commencer. Pour les nouveaux utilisateurs, cela supprime un obstacle courant : un portefeuille peut contenir des jetons mais manquer de l'actif natif nécessaire pour les déplacer. Cela ne supprime pas les coûts de transaction ; cela les présente sous une forme que le portefeuille ou l'application peut afficher plus clairement.

Le paiement du gaz devient une décision produit

Les Frame Transactions offriraient aux portefeuilles et aux applications plusieurs façons de gérer le même coût. Il s'agit de modèles de mise en œuvre possibles, et non de fonctionnalités exigées par l'EIP :

Façons possibles pour une application de gérer le gaz

• Sponsorisé par l'application : une application pourrait payer les frais afin que l'onboarding ou une fonctionnalité limitée semble sans gaz.
• Payé en jeton : un sponsor pourrait coter les frais en USDC ou dans un autre jeton pris en charge tout en finançant les frais Ethereum en ETH.
• Hybride : une application pourrait subventionner certaines actions et facturer aux utilisateurs d'autres actions via des frais basés sur un jeton.

Une transaction présentée comme sans gaz est toujours financée par une application, un sponsor ou un prélèvement en jeton distinct. EIP-8141 pourrait offrir aux applications un moyen standard de subventionner ce coût ou de le récupérer dans un actif que l'utilisateur détient déjà.

Ce qui change par rapport aux outils antérieurs de comptes intelligents

Ethereum prend déjà en charge certaines formes d'abstraction de compte. L'EIP-7702 de Pectra a donné aux comptes détenus de l'extérieur (EOA) l'accès à des fonctionnalités de comptes intelligents telles que le traitement par lots des transactions, le parrainage et des options de récupération améliorées. Avant cela, ERC-4337 avait introduit une architecture distincte de mempool et de bundler pour les transactions à abstraction de compte, et le parrainage de type paymaster existe déjà dans les portefeuilles et applications construits sur ces couches.

EIP-8141 franchit une étape différente : elle introduit un format de transaction dédié dans lequel les règles de validation et de paiement peuvent être incluses nativement au niveau du protocole. La proposition est conçue pour prendre en charge des schémas de paiement de frais alternatifs sans dépendre d'un relais tiers centralisé, même si des portefeuilles et des applications individuels peuvent toujours recourir à des prestataires de services.

La flexibilité du gaz n'est qu'une utilisation de cette même structure programmable. La proposition vise également à prendre en charge la rotation de clés, les limites de dépense, la récupération sociale et des systèmes de signature alternatifs. Les applications de confidentialité potentielles de Hegotá montrent pourquoi les Frame Transactions sont envisagées pour des usages au-delà du paiement flexible du gaz.

Les paiements programmables nécessitent des règles de sécurité claires

Le brouillon avertit que le code de validation personnalisé doit lier une approbation à l'ensemble complet des frames qu'il autorise. Sinon, une approbation pourrait être réutilisée avec un ensemble différent d'actions ultérieures.

Cela ne signifie pas que les Frame Transactions sont intrinsèquement dangereuses. Cela signifie que les portefeuilles devront montrer aux utilisateurs ce qu'autorise une signature, si une application paie les frais, et quel jeton sera débité. Ces détails sont essentiels lorsqu'une même transaction combine validation, paiement et exécution.

Les sponsors assument également un risque pratique. Dans l'exemple ERC-20 de l'EIP, un utilisateur pourrait réduire son solde de jetons avant que la transaction sponsorisée n'atteigne un bloc. La proposition inclut des règles de solvabilité du paymaster et de mempool public, car un sponsor a besoin de protection avant de pouvoir financer le gaz pour de nombreux utilisateurs.

Ce que ce changement pourrait signifier pour l'ETH

Les Frame Transactions déplaceraient la gestion de l'ETH vers les portefeuilles, les sponsors et les applications. Un utilisateur pourrait voir des frais en USDC ou aucun frais direct, mais le compte payeur a toujours besoin d'ETH pour régler la transaction sur Ethereum.

Cela ne fait pas de la proposition un catalyseur automatique de la demande en ETH. Son effet à plus long terme dépend de la capacité des flux de portefeuille simplifiés à attirer davantage d'utilisateurs et de la valeur que les applications y verront pour couvrir ou traiter les coûts de gaz de cette manière.

Le test, c'est l'adoption, pas la spécification

Avant que cette fonctionnalité ne change l'expérience quotidienne des portefeuilles, Hegotá doit être activée avec EIP-8141 incluse. Les portefeuilles et applications compatibles devront ensuite fournir une tarification claire, une logique de remboursement et des aperçus de transaction — le même type de travail d'outillage qui a suivi les déploiements antérieurs d'abstraction de compte, où la prise en charge est arrivée progressivement across les portefeuilles plutôt que d'un coup.

La proposition n'aura d'importance que si les utilisateurs peuvent effectuer une transaction en toute sécurité avec les actifs déjà présents dans leur portefeuille, sans avoir d'abord à acquérir de l'ETH uniquement pour payer le gaz.

Cet article est fourni à titre d'information uniquement et ne constitue pas un conseil financier.