Comment fonctionne le gas sur Solana et TON (face au gas natif d'Ethereum)

Le modèle d'Ethereum : gas payé dans la pièce native

Chaque blockchain publique doit tarifer sa ressource rare — l'espace de bloc et l'exécution — et elle le fait avec des frais. Sur Ethereum et les autres chaînes EVM, ce prix s'appelle le gas, et il est toujours payé dans la pièce native du réseau, l'ETH. Chaque opération que l'EVM effectue a un coût en gas fixe ; un simple transfert coûte 21 000 gas, tandis qu'un appel de contrat coûte davantage selon le travail qu'il réalise. Votre total correspond à cette quantité de gas multipliée par un prix du gas par unité, coté en gwei (un milliardième d'un ETH).

Depuis l'EIP-1559, ce prix se divise en un base fee de protocole qui est brûlé et s'ajuste avec la congestion, plus un frais de priorité optionnel (un pourboire) qui va au validateur pour prioriser votre transaction. La contrainte clé pour les utilisateurs est simple : pour déplacer n'importe quel token ERC-20, il vous faut toujours de l'ETH dans le même compte pour payer le gas. Détenez de l'USDC mais pas d'ETH, et vous êtes bloqué. Nous couvrons cela plus en détail dans les frais de gas crypto expliqués. Solana et TON résolvent le même problème de tarification, mais avec des primitives différentes.

Les frais Solana : lamports, base fee, frais de priorité et compute units

Solana libelle les frais en lamports, la plus petite unité de SOL (un SOL vaut 1 000 000 000 lamports). Les frais comportent deux parties. Le base fee est une charge forfaitaire et déterministe par signature — en 2026, c'est 5 000 lamports par signature — de sorte qu'une transaction typique à signataire unique paie 5 000 lamports quoi qu'elle fasse. La moitié du base fee est brûlée et l'autre moitié va au validateur.

La seconde partie est le frais de priorité, et c'est là qu'interviennent les compute units (CU) de Solana. Chaque instruction consomme des compute units jusqu'à une limite par transaction, et une transaction peut enchérir un prix par compute unit via une instruction de compute-budget. Le frais de priorité est égal à la limite de CU que vous demandez multipliée par ce prix, et il agit comme le pourboire qui vous fait programmer avant les autres lorsqu'un compte très sollicité ou l'ensemble du réseau est congestionné. Contrairement à Ethereum, le base fee n'est pas un taux de marché qui flotte avec la demande ; le marché vit entièrement dans le frais de priorité.

Point crucial, Solana sépare le compte qui signe l'action significative du compte qui paie. Le fee-payer est simplement le premier signataire de la transaction, et c'est son solde en SOL qui est débité des frais. Ce compte n'a pas à être vous — tout ce que vous autorisez peut être payé par un signataire différent. Ce seul choix de conception est ce qui rend les schémas de relayer possibles sur Solana.

Les frais TON : gas, stockage et forward fees en Toncoin

TON (The Open Network) prend encore une forme différente, reflétant son architecture à modèle d'acteurs et à passage de messages où les contrats intelligents communiquent en s'envoyant des messages. Les frais sont payés en Toncoin et se décomposent en plusieurs composantes. Les frais de gas paient le calcul, mesuré en unités de gas un peu comme l'EVM. Les frais de stockage sont inhabituels et importants : les contrats sont facturés un loyer au fil du temps pour l'état qu'ils occupent on-chain, de sorte qu'un compte paie lentement pour la persistance des données plutôt que de payer une seule fois.

Il y a ensuite les forward fees, qui couvrent le coût de l'envoi de messages internes entre contrats — car une seule action utilisateur sur TON se déploie souvent en une chaîne de messages, chaque saut portant un coût de transmission. En pratique, un wallet attache un peu de Toncoin à une transaction pour couvrir le gas plus la transmission, et la valeur inutilisée est généralement restituée. Le résultat est la même friction familière : pour faire quoi que ce soit sur TON, il vous faut du Toncoin placé au bon endroit. Pour une comparaison directe des trois modèles d'exécution, voir EVM face à Solana et TON.

Schémas de fee-payer et de relayer : l'analogue du paymaster

Sur l'EVM, la réponse émergente à "j'ai des tokens mais pas d'ETH pour le gas" est l'abstraction de compte. ERC-4337 introduit un paymaster : un contrat qui accepte de sponsoriser le gas de l'opération d'un utilisateur, éventuellement en le facturant dans un token ERC-20 à la place. En 2026, l'EIP-7702 permet en outre aux comptes ordinaires détenus en externe d'adopter temporairement un comportement de smart account, élargissant les contextes où ces schémas s'appliquent. ERC-4337 et son contrat EntryPoint sont strictement des standards EVM — ils ne fonctionnent pas sur Solana ni sur TON. Si la mécanique vous est nouvelle, qu'est-ce qu'un paymaster vous la détaille.

Solana et TON parviennent au même résultat avec des primitives natives plutôt qu'un standard formel. Sur Solana, parce que le fee-payer n'est que le premier signataire, un service relayer peut co-signer et payer les frais en SOL d'une transaction que l'utilisateur a autorisée, puis se faire régler par l'utilisateur comme il l'entend — y compris en le facturant dans un token différent. Sur TON, un relayer ou un contrat sponsor similaire peut attacher le Toncoin requis et transmettre le message souhaité par l'utilisateur, de sorte que l'utilisateur n'a jamais besoin de Toncoin lui-même. L'étiquette diffère — paymaster, fee-payer, relayer — mais la fonction est identique : découpler le token que vous détenez du token natif que la chaîne exige pour les frais.

Pourquoi un seul token de frais à travers les chaînes est difficile

Réunissez ces trois modèles et le problème de l'utilisateur multichaîne devient évident. Pour être autonome, vous devez maintenir de l'ETH sur chaque chaîne EVM, du SOL sur Solana et du Toncoin sur TON — chacun un solde distinct que vous devez acquérir, recharger et surveiller. Le sponsoring des frais règle le problème de "pas de pièce native dans ce compte" sur une seule chaîne, mais un sponsor a toujours besoin d'un moyen d'être remboursé, et un token sur une chaîne n'est pas nativement dépensable sur une autre.

C'est là qu'un standard de token cross-chain importe. Le standard OFT (Omnichain Fungible Token) de LayerZero, en 2026, permet à un seul token de maintenir une offre unifiée à travers de nombreuses chaînes plutôt que de s'appuyer sur des copies wrapped propres à chaque chaîne. Combinez un token de frais OFT avec un paymaster sur l'EVM et un sponsoring de fee-payer/relayer sur Solana et TON, et vous obtenez une conception cohérente : l'utilisateur paie toujours dans un seul token, et en coulisses le sponsor fournit la pièce native dont chaque chaîne a réellement besoin.

Comment WATS utilise cela

Le WATS Hot Wallet applique exactement ce schéma. Sur les chaînes EVM, il utilise un paymaster ERC-4337, et sur Solana et TON, il utilise un fee-payer/relayer équivalent — l'analogue du paymaster décrit ci-dessus — de sorte que chaque transfert, swap ou staking est facturé dans un seul token, ATS, et vous n'avez jamais besoin de SOL ni de Toncoin pour transiger. Parce que ATS est un OFT LayerZero, un seul solde fonctionne à travers l'EVM, Solana et TON, et l'ATS collecté au titre des frais est brûlé, réduisant l'offre de 100 000 000 vers un plancher de 30 000 000. WATS est non-custodial — vous détenez vos clés et WATS n'en détient jamais aucune — et c'est le premier et le seul wallet à combiner des frais en token unique ERC-4337 plus OFT, facturés à la place du gas natif à chaque transfert, avec ce burn. Vous pouvez lire la mécanique sur la page Hot Wallet.