Como Funciona o Gas na Solana e na TON (vs Gas Nativo do Ethereum)

Gas é a taxa que uma blockchain cobra por computação e espaço em bloco, e cada cadeia a fatura na sua própria moeda nativa: o Ethereum mede cada operação em unidades de gas pagas em ETH, divididas desde o EIP-1559 em uma base fee queimada e uma gorjeta ao validador; a Solana cobra uma base fee fixa em lamports de SOL por assinatura, mais uma priority fee opcional ofertada por unidade de computação; e a TON cobra Toncoin como gas de computação, como storage fees semelhantes a um aluguel sobre o estado que um contrato mantém e como forward fees sobre as mensagens internas que uma transação dispara. A consequência é idêntica nas três: manter um token nunca basta para movimentá-lo, porque a conta que paga também precisa manter a moeda nativa daquela cadeia. Cada cadeia tem uma saída de emergência — um paymaster ERC-4337 na EVM e, na Solana e na TON, o fato de que a conta que paga a taxa pode ser um signatário diferente do usuário, o que permite a um relayer patrociná-la. A WATS é uma implementação desse padrão: um paymaster ERC-4337 nas cadeias EVM, compartilhado pela extensão do Chrome, pelo app móvel e pela WATS, de modo que ali toda ação é cobrada em um único token, ATS, no lugar do gas nativo da cadeia — o que muda o token que paga, não o que a cadeia cobra. Solana e TON são cadeias totalmente suportadas na mesma carteira, e as transações nelas pagam suas próprias taxas nativas em SOL e Toncoin.

O modelo do Ethereum: gas pago na moeda nativa

Toda blockchain pública precisa precificar seu recurso escasso — espaço em bloco e execução — e o faz com taxas. No Ethereum e em outras cadeias EVM, esse preço é chamado de gas, e é sempre pago na moeda nativa da rede, ETH. Cada operação que a EVM realiza tem um custo de gas definido — alguns fixos, outros que escalam com o contexto, como escritas em armazenamento ou o tamanho do calldata; uma transferência simples é 21.000 de gas, enquanto uma chamada de contrato custa mais dependendo do trabalho que faz. Seu total é essa quantidade de gas multiplicada por um preço de gas por unidade, cotado em gwei (um bilionésimo de um ETH).

Desde o EIP-1559, esse preço se divide em uma base fee do protocolo que é queimada e se ajusta com o congestionamento, mais uma priority fee opcional (uma gorjeta) que vai para o validador para priorizar sua transação. A restrição chave para os usuários é simples: para mover qualquer token ERC-20, você ainda precisa de ETH na mesma conta para pagar o gas. Tenha USDC mas nenhum ETH e você fica travado. Para um passo a passo mais aprofundado dessa mecânica, veja taxas de gas de cripto explicadas. A Solana e a TON resolvem o mesmo problema de precificação, mas com primitivas diferentes.

Taxas da Solana: lamports, base fee, priority fees e unidades de computação

A Solana denomina as taxas em lamports, a menor unidade de SOL (um SOL é 1.000.000.000 de lamports). As taxas têm duas partes. A base fee é uma cobrança fixa e determinística por assinatura — a partir de 2026 são 5.000 lamports por assinatura — então uma transação típica de um único signatário paga 5.000 lamports independentemente do que faça. Metade da base fee é queimada e metade vai para o validador.

A segunda parte é a priority fee, e é aqui que entram as unidades de computação (CUs) da Solana. Cada instrução consome unidades de computação até um limite por transação, e uma transação pode ofertar um preço por unidade de computação — cotado em micro-lamports, um milionésimo de lamport — via uma instrução de compute-budget. A priority fee é igual ao limite de CU que você solicita multiplicado por esse preço, e atua como a gorjeta que faz você ser agendado à frente de outros quando uma conta muito requisitada ou toda a rede está congestionada. Diferentemente do Ethereum, a base fee não é uma taxa de mercado que flutua com a demanda; o mercado vive inteiramente na priority fee.

Fundamentalmente, a Solana separa a conta que assina a ação significativa da conta que paga. O fee-payer é simplesmente o primeiro signatário da transação, e seu saldo em SOL é debitado pela taxa. Essa conta não precisa ser você — qualquer coisa que você autorize pode ser paga por um signatário diferente. Essa única escolha de design é o que torna os padrões de relayer possíveis na Solana.

Taxas da TON: gas, armazenamento e forward fees em Toncoin

A TON (The Open Network) tem novamente um formato diferente, refletindo sua arquitetura de modelo de atores e passagem de mensagens, na qual os contratos inteligentes se comunicam enviando mensagens uns aos outros. As taxas são pagas em Toncoin e se dividem em vários componentes. As gas fees pagam pela computação, medida em unidades de gas de forma muito parecida com a EVM. As storage fees são incomuns e importantes: os contratos são cobrados aluguel ao longo do tempo pelo estado que ocupam on-chain, então uma conta paga lentamente por persistir dados em vez de pagar uma única vez.

Depois há as forward fees, que cobrem o custo de enviar mensagens internas entre contratos — porque uma única ação do usuário na TON frequentemente se desdobra em uma cadeia de mensagens, cada salto carrega um custo de encaminhamento. Na prática, uma carteira anexa algum Toncoin a uma transação para cobrir o gas mais o encaminhamento, e o valor não utilizado é normalmente devolvido. O resultado é o mesmo atrito familiar: para fazer qualquer coisa na TON, você precisa de Toncoin no lugar certo. Para uma comparação lado a lado dos três modelos de execução, veja EVM vs Solana vs TON.

Padrões de fee-payer e relayer: o análogo do paymaster

Na EVM, a resposta emergente para "tenho tokens mas nenhum ETH para gas" é a abstração de conta. O ERC-4337 introduz um paymaster: um contrato que concorda em patrocinar o gas da operação de um usuário, opcionalmente cobrando dele em um token ERC-20. O EIP-7702, introduzido na atualização Pectra, permite ainda que uma conta comum controlada externamente assine uma autorização apontando seu campo de código para uma implementação de contrato inteligente e assim adote o comportamento de smart account de forma reversível — a delegação permanece até ser reapontada ou removida — ampliando onde esses padrões se aplicam. O ERC-4337 e seu contrato EntryPoint são estritamente padrões da EVM — eles não rodam na Solana nem na TON. Se a mecânica é nova para você, o que é um paymaster a percorre.

A Solana e a TON alcançam o mesmo resultado com primitivas nativas em vez de um padrão formal. Na Solana, como o fee-payer é apenas o primeiro signatário, um serviço de relayer pode coassinar e pagar a taxa em SOL de uma transação que o usuário autorizou, e depois acertar as contas com o usuário como quiser — inclusive cobrando dele em um token diferente. Na TON, um relayer ou contrato patrocinador semelhante pode anexar o Toncoin necessário e encaminhar a mensagem pretendida pelo usuário, de modo que o usuário nunca precisa de Toncoin. O rótulo difere — paymaster, fee-payer, relayer — mas a função é idêntica: desacoplar o token que você mantém do token nativo que a cadeia exige para as taxas.

Por que um único token de taxa entre cadeias é difícil

Junte esses três modelos e o problema do usuário multi-cadeia fica óbvio. Para ser autossuficiente você precisa manter ETH em cada cadeia EVM, SOL na Solana e Toncoin na TON — cada um um saldo separado que você precisa adquirir, recarregar e monitorar. O patrocínio de taxas resolve o problema de "nenhuma moeda nativa nesta conta" em uma única cadeia, mas o patrocinador ainda precisa de uma forma de ser reembolsado, e um token em uma cadeia não é nativamente gastável em outra.

É aí que um padrão de token cross-chain importa. O padrão OFT (Omnichain Fungible Token) da LayerZero, a partir de 2026, permite que um único token mantenha uma oferta unificada em muitas cadeias, em vez de depender de cópias wrapped específicas de cada cadeia. Um caminho mais simples para o mesmo resultado é manter o token de taxas em um só lugar e deixar o resto com um paymaster: nas redes EVM o usuário sempre paga nesse único token e, nos bastidores, o patrocinador fornece a moeda nativa que a rede exige. Cadeias fora desse arranjo continuam cobrando suas próprias taxas nativas, e o OFT ainda mantém o token em si como uma oferta única, em vez de cópias por cadeia.

Como a WATS usa isso

A WATS aplica exatamente esse padrão. Em cadeias EVM ela usa um paymaster ERC-4337, de modo que toda transferência, swap ou stake nessas redes é cobrada em um único token, ATS, no lugar do gas nativo. Solana e TON são cadeias totalmente suportadas na mesma carteira — enviar, receber, fazer swap, bridge; um app, uma identidade — e as transações ali pagam suas próprias taxas nativas em SOL e Toncoin. O próprio ATS fica na BSC (BNB Chain): você não mantém um saldo por rede, porque a taxa de qualquer rede EVM é debitada desse saldo único. O ATS arrecadado é queimado e a oferta cai de 100M rumo a um piso de 30M.000.000 em direção a um piso de 30.000.000. Nas redes EVM, um paymaster ERC-4337 liquida o gás nativo nos bastidores. O ATS arrecadado é queimado e a oferta cai de 100M rumo a um piso de 30M. A custódia não muda: suas chaves continuam com você e a WATS nunca detém uma chave. A WATS é a primeira e única carteira a combinar isso. Vale dizer com todas as letras, porque a mecânica acima deixa isso claro: isto não é um desconto. A cadeia continua cobrando o que cobra; o paymaster apenas fornece o ETH que a rede exige e cobra de você em ATS no lugar.

Portanto, a lição prática de três modelos de taxa diferentes é uma única mudança de hábito. Se você transita regularmente entre cadeias EVM, Solana e TON, você pode parar de recarregar ETH em cada cadeia EVM que usa: deposite ATS uma vez na WATS, e o paymaster cobre a moeda nativa que cada transação EVM de fato consome, enquanto sua atividade na Solana e na TON segue pagando em SOL e Toncoin no mesmo app. A mecânica completa está na página de taxa ATS.