ERC-20, SPL e Jetton respondem a uma única pergunta de três maneiras: onde fica guardado o número que registra o seu saldo. A Ethereum mantém o saldo de todos os detentores em um único contrato de token compartilhado, a Solana em uma conta de token separada por detentor, e a TON em um contrato separado por detentor. Essa diferença explica as aprovações, as taxas e a maioria dos modos de falha, e também por que o mesmo ticker é um token diferente em cada rede. Carteiras que cobrem as três, como a WATS — que abrange EVM, Solana e TON, mas não o Bitcoin nativamente —, precisam falar as três gramáticas.
O que é, de fato, um "padrão de token"
Um padrão de token é uma interface acordada: nomes de funções, formatos de mensagem e eventos com os quais carteiras e exchanges contam. Abaixo dele há código comum, e a forma como cada rede executa esse código define o que um token pode ser.
ERC-20, SPL e Jettons não são três dialetos da mesma coisa. Eles respondem a uma única pergunta de três maneiras: onde fica o número que diz "você tem 500 tokens"? A Ethereum guarda isso em um único contrato compartilhado, a Solana em uma conta separada por detentor, a TON em um contrato separado por detentor — modelos de armazenamento que explicam quase toda peculiaridade prática, sobre a arquitetura comparada em EVM, Solana e TON.
ERC-20 na Ethereum: um contrato guarda o saldo de todo mundo
Um token ERC-20 é um único contrato inteligente em um único endereço, mantendo um registro que mapeia endereços para números. Você não "guarda" o token; o contrato guarda uma anotação de que o seu endereço tem direito a um valor.
Uma transferência é uma chamada ao contrato do token, que diminui uma linha e aumenta outra. Seu endereço não precisa de preparo nenhum: você pode receber qualquer ERC-20 em um endereço que nunca tocou naquele token.
Isso explica por que você pode ter uma fortuna em um token e mesmo assim não conseguir movimentá-la: chamar um contrato custa gas, pago por padrão no token nativo da rede. Em 2026, esse padrão não é absoluto — um paymaster ERC-4337 permite que alguém que não seja o dono da conta pague, e a EIP-7702 permite que um terceiro envie e pague a transação do tipo 4 que define a delegação de uma conta, embora o patrocínio posterior dependa do que o código delegado implementa. A rede continua cobrando pelo trabalho; apenas o pagador muda.
SPL na Solana: contas de token, rent e o mint
A Solana divide a tarefa em duas. Uma conta de mint define o token — oferta, casas decimais e qual autoridade pode emitir ou congelar. Os saldos ficam em contas de token separadas. O Token Program é dono dos dados dessa conta, enquanto a conta indica um detentor como seu proprietário e autoridade de gasto; nada limita você a uma conta por mint.
Por isso as carteiras padronizaram a associated token account, derivada do seu endereço de carteira, do mint e do id do token program. Ela precisa existir e estar financiada: a isenção de rent trava uma quantia pequena e reembolsável de SOL na conta para mantê-la viva.
Receber um novo token SPL é, portanto, um evento on-chain, ainda que a maioria das transferências já inclua a criação da conta. Em 2026, o Token-2022 acrescenta taxas de transferência opcionais, saldos confidenciais e transfer hooks; como o id do seu program é uma semente de derivação, seus mints derivam uma associated token account diferente da dos mints legados.
Jettons na TON: cada detentor ganha o próprio contrato
A TON leva essa separação ao extremo. Um jetton tem um contrato master com metadados e oferta, e cada detentor ganha o próprio contrato de jetton wallet, que armazena apenas o saldo dele naquele único token.
As transferências são mensagens assíncronas, não chamadas a um registro compartilhado: o contrato da sua jetton wallet envia uma mensagem ao do destinatário, que credita o saldo. Como a TON é fragmentada em shards, isso se resolve ao longo de blocos consecutivos, e não em um único passo atômico.
Cada mensagem precisa carregar TON suficiente para a computação que dispara adiante, incluindo o deploy da jetton wallet do destinatário, se necessário; anexe pouco demais e ela pode fazer bounce ou travar. Essa orientação (TEP-74, em 2026) permite que a TON escale horizontalmente e derruba código de transferência ingênuo, escrito pensando na EVM.
Aprovações, taxas e modos de falha: onde os três divergem
As aprovações são a divergência mais nítida. O ERC-20 tem o padrão de allowance: você concede a um contrato permissão para movimentar até certa quantidade dos seus tokens, e isso persiste até ser revogado — motivo pelo qual uma assinatura descuidada pode esvaziar uma carteira meses depois; veja aprovações de token e permit explicados e como revogar aprovações de token.
A Solana não é o antídoto: um approve de SPL define um delegate na sua conta de token que sobrevive à transação, e o setAuthority pode reatribuir a conta por completo — ambos vetores conhecidos de drainers. Uma transação Solana lista todas as contas que vai tocar, mas isso restringe apenas a transação assinada, não permissões permanentes. A TON não tem allowance nos moldes do ERC-20.
As taxas também divergem: a EVM precifica gas por unidade de computação, a Solana cobra uma taxa base fixa por assinatura mais uma priority fee opcional, e a TON cobra por mensagem. O mesmo vale para os modos de falha: na EVM, tokens presos em um contrato incapaz de lidar com eles; na Solana, uma conta de token inexistente; na TON, valor anexado insuficiente.
Por que o mesmo ticker não é o mesmo token entre redes
Dois ativos que compartilham um ticker não compartilham nada tecnicamente. USDC na Ethereum é um endereço de contrato; na Solana, um endereço de mint; na TON, uma stablecoin emitida nativamente como o USDT fica por trás do próprio jetton master. Cada um é um objeto on-chain separado, com oferta própria, e uma versão em bridge é ainda outro direito distinto.
Enviar entre ecossistemas — um token EVM para um endereço Solana ou TON — costuma ser irrecuperável; enviei cripto para a rede errada, como recuperar detalha o que dá para salvar. De EVM para EVM costuma ser mais tolerante: uma conta de propriedade externa, inclusive uma delegada sob a EIP-7702, é controlada pela mesma chave no endereço idêntico em todas as redes, e uma smart account no estilo ERC-4337 ainda não implantada na rede de destino normalmente pode ser reimplantada lá com a mesma factory e o mesmo init code. Os formatos de endereço são uma pista, abordada em formatos de endereço cripto explicados; se uma oferta canônica se move ou se um novo direito é emitido é a diferença entre tokens omnichain e tokens wrapped ou em bridge.
O que isso significa para a sua carteira (e como a WATS lida com isso)
Uma carteira multi-chain precisa falar as três gramáticas, e você nunca deveria perceber a diferença — mas as taxas vazam, porque cada rede espera o próprio token nativo de gas. Em 2026, essa exigência é negociável, se a carteira for construída para isso.
A WATS Hot Wallet faz exatamente isso: cada ação — transferências, swaps, staking — é cobrada em um único token, ATS, em vez do gas nativo da rede, por meio de um paymaster ERC-4337 na EVM e de um fee-payer e relayer equivalentes na Solana e na TON, já que o ERC-4337 é exclusivo da EVM. O ATS é um OFT da LayerZero, então um único saldo funciona em EVM, Solana e TON. Isso não muda o que a rede cobra — a taxa em ATS acompanha o custo de rede em tempo real — muda apenas em qual token esse custo é liquidado. O ATS arrecadado é queimado, de 100 milhões rumo a um piso de 30 milhões. Segue sendo não custodial: você guarda suas chaves e a WATS nunca guarda uma chave. A WATS é a primeira e única carteira a combinar ERC-4337 e taxas em token único via OFT, cobradas no lugar do gas nativo, com essa queima.
Perguntas frequentes
Por que receber um token SPL custa algo na Solana, mas não na Ethereum?
Na Ethereum, seu saldo é apenas uma linha dentro do próprio contrato do token, então receber é gratuito para o destinatário e não exige preparo. Na Solana, na primeira vez que você recebe um determinado mint, precisa existir uma conta de token para ele, e manter essa conta on-chain exige um pequeno depósito de isenção de rent em SOL, recuperável quando a conta é fechada. Na prática, a transação do remetente costuma criar e financiar essa conta no mesmo passo, então o custo recai sobre o remetente e o destinatário nunca o vê.
O que torna uma transferência de jetton na TON diferente de uma transferência ERC-20?
Um jetton dá a cada detentor um contrato inteligente próprio que armazena apenas o saldo dele. Uma transferência é uma mensagem assíncrona do contrato da sua jetton wallet para o do destinatário, resolvida ao longo de blocos consecutivos e não em uma única chamada atômica. Cada mensagem precisa carregar TON suficiente para pagar o trabalho que dispara, ou pode fazer bounce.
USDC na Ethereum é o mesmo token que USDC na Solana?
Não. São objetos on-chain separados, com endereços, ofertas e padrões separados, mesmo compartilhando um ticker e um emissor. Enviar um para um endereço da outra rede normalmente é irrecuperável, e versões em bridge de um ticker são distintas das emitidas nativamente.