Entre los usuarios de criptomonedas existe una creencia muy extendida: si introduces la dirección correcta, eliges la red adecuada y tienes suficiente token nativo para cubrir la comisión, la transacción se procesará. En la gran mayoría de los casos, esa creencia es cierta.
Pero cada blockchain tiene sus propias reglas ocultas: normas que solo aparecen en situaciones muy específicas. Y cuando lo hacen, una transacción puede fallar aunque, desde tu perspectiva, todo se haya hecho correctamente.
Esto fue exactamente lo que nos ocurrió cuando un cliente de nuestro servicio de intercambio, Rabbit.io, cambió LTC por SOL. La cantidad era mínima: menos de 0.0003 SOL, que al precio actual está por debajo de tres céntimos. En muchos de mis artículos anteriores he mencionado que no imponemos límites inferiores en los swaps. Sí, a menudo procesamos cantidades extremadamente pequeñas también.
Cuando intentamos enviar el SOL solicitado, surgió un problema. La dirección era correcta. La red era Solana Mainnet. Nuestro saldo era suficiente. La comisión estaba contemplada. Sin embargo, la transacción seguía fallando una y otra vez.
La explicación resultó ser inesperada, incluso para nosotros. Y cuando la compartimos con el cliente, él tampoco lo creyó al principio. El incidente me hizo preguntarme: ¿cuántas trampas ocultas similares existen en distintas blockchains?
Decidí investigar y compilar los ejemplos más interesantes: casos que podrían sorprender incluso a mí, a pesar de que proceso un amplio rango de intercambios de criptomonedas a diario.
1. Solana. Pagar "alquiler" — incluso por el SOL nativo
Por qué esto sorprende
Mucha gente ha oído que en Solana, para recibir tokens SPL —como USDT, USDC y otros— en una dirección que nunca ha tenido esos tokens antes, la dirección necesita una pequeña cantidad de SOL. Estrictamente hablando, eso no es del todo exacto, pero hay algo de verdad en ello.
Cada token se almacena en una Cuenta de Token Asociada (ATA) separada, y crear esa cuenta cuesta aproximadamente 0.002 SOL. Sin embargo, incluso si el destinatario tiene cero SOL, los tokens aún pueden ser recibidos —porque es el remitente quien paga la creación del ATA, no el destinatario.
Lo que es mucho menos conocido es que un requisito similar a veces puede aplicarse a transferencias del propio SOL nativo. Eso fue precisamente lo que nos pasó cuando intentamos enviar la pequeña cantidad solicitada por nuestro cliente.
Cómo funciona el mecanismo
En Solana, una cuenta no es solo una cadena de caracteres que representa una dirección. Es un registro real almacenado en el estado actual de la blockchain. Ese registro ocupa espacio en disco en los nodos validadores —y el almacenamiento no es gratuito.
Este mecanismo se conoce como exención de alquiler (rent exemption). Para que una cuenta exista, su saldo debe superar un determinado mínimo —efectivamente el coste de dos años de alquiler de almacenamiento.
Este valor no está fijado para siempre, pero en este momento, para una cuenta del sistema básica (una cartera normal), el mínimo es 890,880 lamports, o 0.00089088 SOL.
Si una dirección aún no existe on-chain (es decir, su saldo es cero), la primera transacción que intente crear la cuenta con un monto por debajo de este umbral será rechazada.
Eso fue exactamente lo que ocurría en nuestro caso. Estábamos enviando algo menos de 0.0003 SOL a una dirección recién creada —aproximadamente tres veces por debajo del umbral requerido. Nuestro cliente se negó a creer que existiera tal regla. Y, para ser justos, nos costó encontrar una declaración clara de ello en la documentación oficial de Solana. La única confirmación indirecta que hallamos estaba en la descripción del método RPC getMinimumBalanceForRentExemption, que implica esta regla —aunque no la expone de forma explícita.
Hay una matización importante aquí. Anteriormente habíamos enviado cantidades tan pequeñas a clientes muchas veces sin problemas. Por experiencia práctica, sabíamos que Solana permite transferencias de sumas arbitrariamente pequeñas.
Y eso es cierto —pero solo si la cuenta receptora ya existe. Si es la segunda, tercera o centésima transacción entrante, la dirección puede recibir incluso 1 lamport. Pero cuando una cuenta se crea por primera vez, se aplica la comprobación de exención de alquiler.
2. XRP Ledger y Stellar. La dirección existe — pero la cuenta no
El problema que encontramos en Solana es en realidad un caso específico de un patrón más amplio. En varias redes, una dirección como objeto criptográfico y una cuenta como entrada en el libro distribuido son dos cosas distintas. Sin un saldo inicial mínimo, la cuenta simplemente no existe.
En el XRP Ledger, cada cuenta nueva debe recibir una reserva mínima de 1 XRP. En los primeros días de la red, este requisito era mucho mayor — 200 XRP al lanzamiento, luego reducido a 50 XRP, luego 20 XRP, luego 10 XRP. A medida que el precio de XRP aumentó, la reserva se fue reduciendo gradualmente hasta el actual 1 XRP.
Esta reserva permanece bloqueada permanentemente en la cuenta. No puede gastarse. No puede usarse para pagar comisiones de transacción. Algunos exploradores del XRP Ledger incluso muestran el saldo total y la reserva bloqueada por separado, para que los propietarios de billeteras vean claramente cuánto XRP está realmente disponible para gastar.
La red Stellar sigue una lógica similar. Una dirección no existe en el libro hasta que recibe un saldo mínimo. Una cuenta Stellar requiere al menos 1 XLM para activarse y mantenerse operativa.
Tal vez recuerdes que escribí sobre un error que convirtió 1,000 USDC en 1 XLM. La situación descrita en ese artículo fue precisamente un ejemplo de este mecanismo en acción: una transacción de token, aunque esté correctamente firmada por el remitente, no puede acreditarse al destinatario a menos que se cumplan ciertos prerequisitos.
Una característica distintiva tanto del XRP Ledger como de Stellar es que una cuenta no puede recibir tokens a menos que haya optado explícitamente por interactuar con ese activo específico. Esta es una decisión deliberada de diseño por parte de los desarrolladores, y tiene sus ventajas.
En otras redes, las direcciones de ballenas y celebridades a menudo se llenan de tokens spam recién creados, dando la ilusión de que el propietario los compró. En XRP Ledger y Stellar, tal spam es imposible —porque recibir un activo requiere autorización previa.
3. Lightning Network. Existe liquidez — pero no hay ruta
La Lightning Network es una red de canales de pago diseñada para enviar bitcoin sin registrar cada transferencia en la blockchain. A diferencia de las transacciones on-chain regulares, un pago Lightning no es validado por todos los nodos de la red ni confirmado por mineros en un bloque. En su lugar, viaja a través de una cadena de nodos intermedios.
Y aquí es donde aparece toda una clase de errores no obvios.
Cómo funciona el enrutamiento
Para que un pago viaje de Alicia a David pasando por los nodos intermedios Bob y Carol, cada segmento de la ruta debe tener suficiente liquidez en la dirección requerida.
La red conoce la capacidad total de cada canal, pero no cómo se distribuye el saldo entre las dos partes. Esto puede llevar a situaciones como la siguiente:
- David tiene suficiente liquidez entrante en su canal con Carol.
- Pero en el canal entre Bob y Carol, casi todo el saldo está del lado de Carol. Bob no puede reenviar el pago en su dirección.
Como resultado, el pago de Alicia a David falla con un error de "ruta no encontrada" —aunque Alicia tenga fondos suficientes, David tenga un canal activo capaz de recibir el pago y formalmente exista una ruta en el grafo de la red.
La trampa oculta del límite de comisiones
Hay otra matización especialmente complicada. En LND, una de las implementaciones de nodos Lightning más utilizadas, el límite de comisión por enrutamiento por defecto está establecido en 0 satoshis.
Esto significa que el nodo solo intentará encontrar rutas completamente gratuitas —que, en una red real, prácticamente no existen. Los usuarios que nunca cambiaron este ajuste por defecto pueden ver repetidamente un error de "ruta no encontrada", aunque el pago podría tener éxito si permitieran una pequeña comisión de enrutamiento.
Esto no es un fallo. Al contrario, los desarrolladores de LND optaron deliberadamente por no decidir por los usuarios cuál es la comisión máxima que están dispuestos a pagar. Si se hubiera establecido un límite positivo por defecto, los usuarios podrían descubrir más tarde que se les descontaron comisiones de enrutamiento sin darse cuenta.
Otras razones para un error de "ruta no encontrada":
- El nodo del destinatario está desconectado y sus canales están inactivos.
- La factura ha expirado. Las facturas Lightning tienen un periodo de validez limitado, a menudo alrededor de una hora.
- El monto es demasiado grande. Los pagos grandes son más difíciles de enrutar que los pequeños.
- Un intento previo ha "atascado" la liquidez. Los contratos HTLC con bloqueos temporales pueden retener la capacidad del canal hasta que expiren.
Nos encontramos con todos estos problemas al intercambiar bitcoin a través de la Lightning Network. Pueden parecer inusuales en comparación con las transacciones blockchain tradicionales, pero cada uno de estos problemas tiene solución. Por eso, en Rabbit.io puedes tanto enviar como recibir bitcoin por Lightning sin preocuparte por estas trampas.
4. USDT y USDC. Listas negras con arquitecturas diferentes
USDT y USDC son stablecoins gestionadas de forma centralizada. Sus contratos inteligentes incluyen funciones de lista negra: los emisores —Tether y Circle— pueden añadir una dirección a una lista negra en cualquier momento, tras lo cual las operaciones con esos tokens en esa dirección se vuelven imposibles.
Esto es un hecho conocido. Lo que se entiende menos es que los mecanismos de restricción en USDT y USDC son fundamentalmente distintos —y esa diferencia tiene importantes consecuencias prácticas.
USDC (Circle): ambas direcciones bloqueadas
En el contrato de USDC, la comprobación de lista negra se aplica tanto al emisor como al receptor. Si la dirección receptora está en la lista negra, la transacción será rechazada por el contrato inteligente. El remitente simplemente pierde una pequeña cantidad de gas, mientras que los USDC permanecen en su billetera.
Desde la perspectiva del remitente, este es un modelo más seguro: los fondos no desaparecen en una dirección congelada.
USDT (Tether): solo el emisor está bloqueado
En el contrato de USDT (TetherToken), la función transfer contiene la siguiente comprobación: require(!isBlackListed[msg.sender]). Esto significa que solo se verifica al remitente frente a la lista negra. La dirección receptora no se valida durante la transferencia.
En la práctica, esto conduce a las siguientes consecuencias:
- Puedes enviar USDT con éxito a una dirección en la lista negra.
- La transacción se procesará sin errores.
- La blockchain registrará la transferencia.
- Pero los fondos quedarán congelados como resultado.
Nadie, ni el destinatario ni nadie más, podrá mover posteriormente esos tokens —las transacciones salientes desde una dirección en la lista negra están prohibidas. Solo el emisor, Tether, puede intervenir, usando la función destroyBlackFunds para borrar efectivamente los tokens de la dirección en la lista negra.
En este caso particular, podría argumentarse que es mejor que una transacción correctamente construida falle de inmediato. El enfoque implementado en el contrato de USDC parece más transparente y justo que el modelo de USDT, donde la transacción tiene éxito —solo para que después quede claro que la transferencia fue en realidad inútil.
Mis recomendaciones:
- Al trabajar con USDT, comprueba la dirección de la contraparte frente a datos de sanciones o listas negras antes de enviar. Una dirección que estaba "limpia" ayer puede no estarlo hoy; su estatus puede cambiar en el peor momento.
- Si es posible, considera usar USDT en la blockchain Liquid, donde Tether no tiene la capacidad de congelar direcciones individuales.
Dicho esto, incluso las transferencias de USDT a veces pueden fallar de forma rotunda —incluso cuando todos los datos de la transacción parecen correctos. En la Parte II de este artículo cubriré esos casos, junto con restricciones de transacción menos conocidas en las redes Bitcoin, Ethereum y Tron.
Se publicará aquí exactamente en una semana.
