
Imagine isto. Você tem USDC parado na Polymarket, e quer XMR para armazenamento discreto e privado. Você vai para rabbit.io, cria uma ordem para trocar USDC na Polygon por XMR, pega o endereço de depósito, envia os tokens — e nada acontece.
A carteira que você usa na Polymarket assinou a transação. O Polygonscan mostra um check verde, o endereço correto e a quantidade certa. Mas o serviço de swap não vê o depósito.
À primeira vista, isso parece bizarro. A blockchain é compartilhada por todos. Se o explorador mostra uma transferência recebida, por que o serviço não pode simplesmente apertar um botão e creditar os tokens?
Mas isso é algo com que você pode se deparar em qualquer exchange ou serviço de swap. A razão é que exchanges e serviços de swap não leem um explorador de blocos da mesma forma que você. Eles usam sistemas automatizados de contabilização de depósitos. E esses sistemas precisam entender não apenas que algo se moveu on‑chain, mas que esse movimento representa um depósito genuíno, final, suportado e seguro.
É exatamente aí que começa o problema sobre o qual quero falar hoje.
Em redes EVM, existem dois tipos de endereços.

Ambos os tipos podem receber, manter e enviar moedas e tokens. Para um usuário comum, eles parecem quase idênticos: apenas uma longa sequência começando com 0x. Mas para qualquer sistema que precise contabilizar o que acontece dentro das transações, a diferença é significativa.
Permita‑me ilustrar isso com Ethereum.
Se você envia ETH de uma carteira normal, é uma transferência direta: o endereço A enviou fundos para o endereço B. Essa operação é fácil de encontrar na aba principal Transactions.

Mas se o ETH chega a partir de um contrato inteligente, ele pode aparecer como uma Internal Transaction. O saldo do destinatário realmente aumenta, mas a transferência ocorreu como parte da lógica de execução do contrato, de acordo com as regras escritas naquele contrato.

Creditar automaticamente fundos que chegam por meio de tais transações nem sempre é a decisão correta. É difícil contestar a necessidade de primeiro verificar de que tipo de contrato os fundos vieram e o que exatamente aconteceu dentro da transação.
Sim — e esse é um ponto importante.
Todo token ERC‑20 — USDT, USDC, WBTC, LINK e assim por diante — se move entre endereços segundo as regras do contrato inteligente que o define. Quando você envia USDC, você chama o contrato desse token. O contrato atualiza sua tabela interna de saldos e grava um evento Transfer na blockchain.
Para tokens, essa é a mecânica normal. Sistemas de depósito são construídos para processar essas transferências. Então qual é a diferença fundamental entre esse tipo de transferência de token, que normalmente passa sem problema, e outra que não pode ser processada automaticamente?
A resposta está em quem é listado como remetente no evento de transferência do token.
Se o USDC for debitado do seu endereço EOA regular e enviado para o endereço de uma exchange ou serviço de swap, tudo provavelmente ocorrerá bem. Problemas podem surgir quando os tokens são debitados do endereço de uma bridge, vault, router, carteira inteligente, multisig ou contrato de plataforma de negociação.
Por que digo que problemas podem surgir? Porque as regras para lidar com depósitos provenientes de contratos inteligentes variam entre os serviços.
Coinbase, por exemplo, diz que suporta depósitos de ETH e ERC‑20 via contratos inteligentes, mas não suporta depósitos equivalentes de SOL e tokens SPL na Solana. Bybit observa em seu FAQ que depósitos por contratos inteligentes não são suportados para todas as moedas, exceto ETH. Crypto.com alerta que a maioria dos depósitos de tokens nativos de cadeias EVM vindos de contratos inteligentes não é creditada automaticamente.
Em outras palavras, a indústria ainda não tem uma regra única sobre quais transferências baseadas em contrato devem contar como depósitos normais, quais exigem processamento manual e quais não devem ser aceitas de forma alguma.
O que piora é que os usuários podem nem perceber que seus tokens estão sendo enviados a partir de algo diferente de uma EOA.
Se eu não firmei nenhum contrato com ninguém, como contratos inteligentes podem ter algo a ver com minhas transações?
Infelizmente, um contrato inteligente realmente pode aparecer na cadeia sem qualquer ação direta de sua parte. Aqui estão três cenários comuns em que ele surge sem aviso.
O primeiro cenário é ao sacar fundos de um mercado de previsões, agregador de DEX, protocolo de empréstimo ou outro dApp. Esses aplicativos frequentemente mantêm ativos não no seu endereço regular, mas dentro de um contrato — mesmo que sua carteira Web3 não deixe isso óbvio e você pense que os ativos sempre permaneceram sob seu controle.
Para ser preciso, eles podem ser exibidos no seu saldo, mas não estão totalmente sob seu controle direto. Mover esses tokens é possível apenas sob os termos do contrato inteligente.
Então você clica em Withdraw, o app envia fundos para o endereço certo — mas o remetente on‑chain acaba não sendo sua EOA. É o contrato da plataforma.
O segundo cenário envolve uma bridge.
Bridges costumam entrar em jogo quando se saca de exchanges ou serviços de pagamento que executam suas próprias blockchains internas, como Hyperliquid, dYdX, Paradex, Payy Network e outros. No banco de dados dessa blockchain interna, os tokens podem ter estado no seu endereço, então você supõe que está os enviando daquele endereço — não de um contrato inteligente.
Mas quando você os move para outra blockchain, como Arbitrum, Polygon ou Ethereum, o destinatário pode receber os tokens de um endereço totalmente diferente. Seu endereço na rede de destino nunca chegou a segurar esses tokens. Eles foram mantidos pelo contrato da bridge ou por infraestrutura relacionada à bridge, enquanto a cadeia interna representava seu saldo do outro lado.
Nada disso significa que toda transferência desse tipo será necessariamente perdida. Mas significa que ela pode não parecer uma simples transferência para o sistema automatizado da exchange ou serviço de swap receptor.
O terceiro cenário envolve carteiras com account abstraction.
Elas são genuinamente úteis: permitem agrupar pagamentos, pagar gas em stablecoins, ter um terceiro cobrindo suas taxas de gas, configurar condições personalizadas de recuperação de carteira e usar outras funcionalidades convenientes. Mas essa conveniência muitas vezes é alcançada transformando sua carteira em um contrato inteligente.
Vale notar: os desenvolvedores de uma das carteiras desse tipo mais populares — OKX Wallet — apontam explicitamente que tais carteiras são contratos inteligentes e não podem ser importadas em outro app via seed phrase ou chave privada.
Para o usuário, parece sua carteira pessoal. Para o serviço receptor, o remetente pode ser um contrato inteligente.
A razão mais simples é técnica. Um scanner automatizado de depósitos pode não rastrear eventos de blockchain não padronizados.
Essa limitação poderia ser corrigida. Mas ela não surgiu por acidente. Por trás dela está uma preocupação de segurança mais profunda.
Você não pode confiar em todo evento Transfer só porque ele parece legítimo em um explorador. A história das criptos já inclui ataques de depósito falso, onde um atacante cria a aparência de um depósito e o destinatário o trata equivocadamente como real.
A pesquisa DEPOSafe, publicada há seis anos, encontrou mais de 7.000 contratos potencialmente vulneráveis a tais ataques. Esses contratos não desapareceram. Eles ainda estão implantados no Ethereum. E nos últimos seis anos, quase certamente novos contratos vulneráveis foram adicionados, inclusive em outras redes.
A essência desses ataques é confiar no sinal errado.
O destinatário vê um evento que parece tokens chegando e assume que os fundos agora são seus. Mas a lógica do contrato pode tornar o resultado real bem diferente: os fundos podem ser devolvidos, queimados, redirecionados para outro lugar ou nunca chegar realmente a ficar sob o controle do destinatário da maneira que o sistema de depósitos esperava.
Portanto, a cautela demonstrada por exchanges e serviços de swap não é burocracia, nem preguiça em lidar com transações complicadas. Contratos inteligentes são complexos, e distinguir um depósito confiável de um ataque de depósito falso nem sempre é simples.
A interface do app de onde você está enviando às vezes não dá nenhuma pista sobre de que tipo de endereço os fundos realmente sairão. Você muitas vezes só pode avaliar isso depois do fato, verificando o que aconteceu no explorador.
Se você está enviando um ativo nativo como ETH, AVAX, BNB ou HYPE, verifique onde a transferência recebida aparece. Se ela surgir em Transactions, provavelmente está tudo bem. Mas se o movimento estiver nas abas Internal Transactions ou Internal Transfers, isso já é um cenário baseado em contrato.

Se você está enviando um token ERC‑20, abra Token Transfers e olhe o campo From. Visite o endereço listado ali. No Etherscan e em exploradores similares, contratos inteligentes normalmente têm uma aba Contract, código verificado, um nome de contrato ou um rótulo. O endereço também pode ficar marcado como Contract, Bridge, Router, Proxy, Safe, Vault, EntryPoint, Settlement, e assim por diante.

Tudo isso só fica visível depois que uma transação já existe. Então, antes de enviar um valor significativo a partir de uma nova plataforma, faça primeiro uma pequena transferência de teste para você mesmo e verifique se ela veio de um endereço de contrato inteligente. Se não veio, transferências subsequentes dessa plataforma muito provavelmente ocorrerão como transações ou transferências de token ordinárias.
Também há casos em que você pode identificar um envio por contrato inteligente com antecedência. O mais óbvio é quando sua carteira permite pagar gas em stablecoins. Sem lógica de contrato inteligente, isso não seria possível.
Mais um sinal útil: se você sacou fundos de um app por meio de uma bridge, o remetente na rede de destino pode ser um contrato de bridge ou infraestrutura relacionada, e não sua própria EOA.
A primeira possibilidade: a transferência é processada automaticamente. Uma transferência vinda de um contrato inteligente não precisa ser um problema em si. Muitos contratos bem conhecidos e confiáveis estão em listas brancas por exchanges e serviços de swap, e scanners automatizados de depósito podem lidar corretamente com essas transferências.
A segunda possibilidade: o depósito não é processado automaticamente, mas pode ser encontrado e tratado manualmente. Dito isso, o crédito pode não chegar tão rápido quanto você gostaria, já que o processamento manual seguro exige uma revisão cuidadosa do contrato inteligente e da estrutura interna da transação.
Um usuário no Bitcointalk compartilhou recentemente que a HTX deu a ele um prazo de 40 dias úteis para creditar manualmente 15.759 USDT enviados da Polymarket.
A terceira possibilidade: após revisar a transação, o destinatário decide que os riscos são altos demais e recusa creditar os tokens. Nesse caso, eles podem devolver os fundos a você.
Finalmente, há uma quarta possibilidade: os fundos chegam ao destinatário, mas o contrato inteligente impede que o destinatário use ou mova os tokens da maneira esperada. Nesse caso, até um reembolso pode ser impossível — não por desonestidade do destinatário, mas por como o contrato do remetente está estruturado.
É exatamente por isso que, antes da sua primeira transferência para uma exchange ou serviço de swap, vale a pena dedicar um momento para descobrir quem será o remetente on‑chain real.
Se você não tem certeza se a transação será uma transferência simples do seu próprio endereço, encontre uma transação de saída anterior no seu histórico e confirme no explorador de blocos que ela não se originou de um contrato inteligente. Se não houver histórico de transações para checar, envie primeiro um valor de teste para ter certeza de que tudo vai transcorrer bem.
No rabbit.io, mesmo que você cometa um erro e nos envie ativos cripto a partir de um contrato inteligente, fique tranquilo: faremos todo o possível para processar a transferência o mais rápido possível — ou, na pior das hipóteses, devolver os fundos a você.