Por qué los servicios cripto no siempre detectan transferencias de contratos inteligentes

Imagínate esto. Tienes USDC en Polymarket y quieres XMR para un almacenamiento silencioso y privado. Vas a rabbit.io, configuras una orden para intercambiar USDC en Polygon por XMR, obtienes la dirección de depósito, envías los tokens - y no pasa nada.

La billetera que usaste en Polymarket firmó la transacción. Polygonscan muestra una marca verde, la dirección correcta y la cantidad adecuada. Pero el servicio de swap no ve el depósito.

A primera vista, esto parece extraño. La blockchain la comparte todo el mundo. Si el explorador muestra una transferencia entrante, ¿por qué el servicio no puede simplemente pulsar un botón y acreditar los tokens?

Pero esto es algo con lo que puedes encontrarte en cualquier exchange o servicio de intercambio cripto. La razón es que los exchanges y los servicios de swap no leen un explorador de bloques como tú. Usan sistemas automáticos de contabilidad de depósitos. Y esos sistemas necesitan entender no solo que algo se movió on-chain, sino que ese movimiento representa un depósito legítimo, final, soportado y seguro.

Ahí es exactamente donde comienza el problema del que quiero hablar hoy.

Dos direcciones que parecen iguales

En redes EVM existen dos tipos de direcciones.

1. Una dirección de usuario. Oficialmente se llama EOA, o Externally Owned Account (Cuenta Poseída Externamente): una dirección cuyas transacciones se firman fuera de la máquina virtual. Controlarla requiere una clave privada.
2. Una dirección de contrato inteligente. Las transferencias desde esta dirección son producidas por código ejecutado on-chain. En otras palabras, la dirección está gobernada por el algoritmo escrito en el contrato inteligente.

Ambos tipos pueden recibir, mantener y enviar monedas y tokens. Para un usuario corriente, parecen casi idénticos: solo una larga cadena que empieza por 0x. Pero para cualquier sistema que tenga que contabilizar lo que sucede dentro de las transacciones, la diferencia es significativa.

Permíteme ilustrarlo con Ethereum.

Si envías ETH desde una billetera normal, es una transferencia directa: la dirección A envió fondos a la dirección B. Esa operación es fácil de encontrar en la pestaña principal Transactions.

Pero si ETH llega desde un contrato inteligente, puede aparecer como una Internal Transaction. El saldo del receptor realmente aumenta, pero la transferencia ocurrió como parte de la lógica de ejecución del contrato, de acuerdo con las reglas escritas en ese contrato.

Acreditar automáticamente fondos que llegan a través de tales transacciones no siempre es la decisión correcta. Es difícil argumentar en contra de primero verificar de qué tipo de contrato provinieron los fondos y qué exactamente ocurrió dentro de la transacción.

¡Pero USDC siempre se transfiere a través de un contrato!

Sí — y este es un punto importante.

Cada token ERC-20 —USDT, USDC, WBTC, LINK, etc.— se mueve entre direcciones bajo las reglas del contrato inteligente que lo define. Cuando envías USDC, llamas al contrato de ese token. El contrato actualiza su tabla interna de saldos y escribe un evento Transfer en la blockchain.

Para los tokens, esta es la mecánica normal. Los sistemas de depósito están diseñados para procesar estas transferencias. Entonces, ¿cuál es la diferencia fundamental entre este tipo de transferencia de token, que usualmente se procesa sin problema, y otra que no puede ser procesada automáticamente?

La respuesta está en quién aparece como remitente en el evento de transferencia del token.

Si USDC se debita de tu dirección EOA normal y se envía a la dirección de un exchange o servicio de swap, es probable que todo vaya bien. Los problemas pueden surgir cuando los tokens se debitan desde la dirección de un bridge, vault, router, smart wallet, multisig o contrato de una plataforma de trading.

¿Por qué digo que los problemas pueden surgir? Porque las reglas para manejar depósitos provenientes de contratos inteligentes varían entre servicios.

Coinbase, por ejemplo, indica que soporta depósitos de ETH y ERC-20 vía contratos inteligentes, pero no soporta depósitos equivalentes de SOL y tokens SPL en Solana. Bybit señala en su FAQ que los depósitos desde contratos inteligentes no son compatibles para todas las monedas excepto ETH. Crypto.com advierte que la mayoría de los depósitos de tokens nativos de cadenas EVM desde contratos inteligentes no se acreditan automáticamente.

En otras palabras, la industria aún no tiene una regla única sobre qué transferencias basadas en contratos deberían contarse como depósitos normales, cuáles requieren procesamiento manual y cuáles no deben ser aceptadas en absoluto.

Lo que empeora esto es que los usuarios pueden no darse cuenta siquiera de que sus tokens están siendo enviados desde algo que no es una EOA.

¿De dónde consigue un usuario común un contrato inteligente?

Si no he contratado nada con nadie, ¿cómo pueden los contratos inteligentes tener algo que ver con mis transacciones?

Desafortunadamente, un contrato inteligente puede aparecer en la cadena sin que hayas hecho nada directamente. Aquí hay tres escenarios comunes donde aparece sin aviso.

El primer escenario es retirar fondos de un mercado de predicciones, un agregador DEX, un protocolo de préstamo u otra dApp. Estas aplicaciones a menudo mantienen activos no en tu dirección regular, sino dentro de un contrato —incluso si tu billetera Web3 no lo deja claro y piensas que los activos han permanecido contigo todo el tiempo.

Para ser precisos, pueden mostrarse en tu balance, pero no están totalmente bajo tu control directo. Mover esos tokens solo es posible bajo los términos del contrato inteligente.

Así que haces clic en Retirar, la app envía fondos a la dirección correcta —pero el remitente en la cadena resulta no ser tu EOA. Es el contrato de la plataforma.

El segundo escenario involucra un bridge.

Los bridges suelen entrar en juego al retirar desde exchanges o servicios de pago que ejecutan sus propias blockchains internas, como Hyperliquid, dYdX, Paradex, Payy Network y otros. En la base de datos de esa cadena interna, los tokens pueden haber estado en tu dirección, por lo que asumes que los envías desde esa dirección —no desde un contrato inteligente.

Pero cuando los mueves a otra blockchain, como Arbitrum, Polygon o Ethereum, el receptor puede recibir los tokens desde una dirección completamente distinta. Tu dirección en la red de destino nunca tuvo esos tokens. Fueron retenidos por el contrato del bridge o la infraestructura relacionada con el bridge, mientras la cadena interna representaba tu saldo en el otro lado.

Nada de esto significa que necesariamente cada transferencia de este tipo se pierda. Pero sí significa que puede no parecer una transferencia simple para el sistema automático del exchange o servicio de swap receptor.

El tercer escenario involucra las billeteras con account abstraction.

Son genuinamente útiles: te permiten agrupar pagos, pagar gas en stablecoins, que un tercero cubra tus tarifas de gas, configurar condiciones personalizadas de recuperación de billetera y usar otras funciones convenientes. Pero esa conveniencia a menudo se logra convirtiendo tu billetera en un contrato inteligente.

Cabe destacar: los desarrolladores de una de las billeteras más populares de este tipo —OKX Wallet— señalan explícitamente que tales billeteras son contratos inteligentes y no pueden importarse en otra app vía frase semilla o clave privada.

Para el usuario, parece su billetera personal. Para el servicio receptor, el remitente puede ser un contrato inteligente.

Por qué los exchanges y servicios de swap desconfían de estas transferencias

La razón más simple es técnica. Un escáner automático de depósitos puede no rastrear eventos no estándar de la blockchain.

Esta limitación podría arreglarse. Pero no surgió por accidente. Detrás de ella hay una preocupación de seguridad más profunda.

No puedes confiar en todo evento Transfer solo porque se vea bien en un explorador. La historia cripto ya incluye ataques de depósito falsos, donde un atacante crea la apariencia de un depósito y el receptor lo trata erróneamente como real.

La investigación DEPOSafe, publicada hace seis años, encontró más de 7.000 contratos potencialmente vulnerables a tales ataques. Esos contratos no han ido a ninguna parte. Todavía están desplegados en Ethereum. Y en los últimos seis años, casi con seguridad se han añadido nuevos contratos vulnerables, incluso en otras redes.

La esencia de estos ataques es confiar en la señal equivocada.

El receptor ve un evento que parece tokens llegando y asume que los fondos ya son suyos. Pero la lógica del contrato puede hacer que el resultado real sea muy distinto: los fondos pueden ser devueltos, quemados, redirigidos a otro lugar o nunca llegar realmente a estar bajo el control del receptor de la forma que el sistema de depósitos esperaba.

Así que la precaución mostrada por exchanges y servicios de swap no es burocracia ni pereza para tratar con transacciones incómodas. Los contratos inteligentes son complejos, y distinguir un depósito fiable de un ataque de depósito falso no siempre es sencillo.

Cómo saber si estás enviando desde un contrato inteligente

La interfaz de la app desde la que envías a veces no te da ninguna pista sobre qué tipo de dirección será la que realmente envíe los fondos. A menudo solo puedes evaluarlo a posteriori, comprobando qué ocurrió en el explorador.

Si estás enviando un activo nativo como ETH, AVAX, BNB o HYPE, verifica dónde aparece la transferencia entrante. Si aparece bajo Transactions, probablemente estés bien. Pero si el movimiento está en la pestaña Internal Transactions o Internal Transfers, eso ya es un escenario basado en contrato.

Si envías un token ERC-20, abre Token Transfers y mira el campo From. Visita la dirección indicada allí. En Etherscan y exploradores similares, los contratos inteligentes suelen tener una pestaña Contract, código verificado, un nombre de contrato o una etiqueta. La dirección también puede estar etiquetada como Contract, Bridge, Router, Proxy, Safe, Vault, EntryPoint, Settlement, etc.

Todo esto solo es visible una vez que ya existe una transacción. Así que antes de enviar una cantidad significativa desde una plataforma nueva, haz primero una transferencia de prueba a ti mismo y comprueba si vino desde una dirección de contrato inteligente. Si no fue así, las transferencias posteriores desde esa plataforma muy probablemente se procesarán como transacciones ordinarias o transferencias de tokens.

También hay casos donde puedes detectar un envío desde un contrato inteligente por adelantado. El más obvio es cuando tu billetera te permite pagar gas en stablecoins. Sin lógica de contrato inteligente, eso no es posible.

Una señal de advertencia más: si retiraste fondos de una app a través de un bridge, el remitente en la red de destino puede ser un contrato de bridge o infraestructura relacionada con el bridge, no tu propia EOA.

Qué puede pasar si envías desde un contrato inteligente

La primera posibilidad: la transferencia se procesa automáticamente. Que una transferencia provenga de un contrato inteligente no tiene por qué ser un problema en sí. Muchos contratos conocidos y confiables están en listas blancas por exchanges y servicios de swap, y los escáneres automáticos de depósitos pueden manejar correctamente estas transferencias.

La segunda posibilidad: el depósito no se procesa automáticamente, pero puede ser encontrado y gestionado manualmente. Dicho esto, el abono puede no llegar tan rápido como quisieras, ya que el procesamiento manual seguro requiere una revisión cuidadosa del contrato inteligente y de la estructura interna de la transacción.

Un usuario en Bitcointalk compartió recientemente que HTX le dio un plazo de 40 días hábiles para acreditar manualmente 15.759 USDT enviados desde Polymarket.

La tercera posibilidad: tras revisar la transacción, el receptor decide que los riesgos son demasiado altos y rechaza acreditar los tokens. En ese caso, pueden devolver los fondos a ti.

Finalmente, hay una cuarta posibilidad: los fondos llegan al receptor, pero el contrato inteligente impide que el receptor use o mueva los tokens de la manera esperada. En ese caso, incluso un reembolso puede ser imposible —no porque el receptor sea deshonesto, sino por cómo está estructurado el contrato del remitente.

Precisamente por eso, antes de tu primera transferencia a un exchange o servicio de swap, vale la pena tomarte un momento para averiguar quién será el remitente real on-chain.

Si no estás seguro de si la transacción será una transferencia simple desde tu propia dirección, busca una transacción saliente previa en tu historial y confirma en el explorador de bloques que no se originó desde un contrato inteligente. Si no hay historial de transacciones para comprobar, envía primero una cantidad de prueba para asegurarte de que todo funcione sin problemas.

En rabbit.io, incluso si cometes un error y por accidente nos envías criptoactivos desde un contrato inteligente, ten la seguridad de que haremos todo lo posible para procesar la transferencia lo más rápido posible —o, en el peor de los casos, devolverte los fondos.