
El mismo token, otra cadena: stablecoins nativas y puenteadas
Tú y un amigo tenéis 500 USDC cada uno, en redes distintas. Un exchange acepta tu depósito, pero no el suyo. Mismo ticker, mismo logo… ¿qué está pasando?
La respuesta corta: «USDC» o «USDT» no es un único token. Es una familia de contratos separados en blockchains separadas, y no todos sus miembros se emiten de la misma forma. Veamos por qué importa y cómo comprobar cuál tienes.
Un nombre, muchos contratos
Un token en Ethereum, Polygon, Base o Solana es un programa (un contrato inteligente o, en Solana, un «mint») que vive en esa única cadena. Una cadena no puede ver los contratos de otra. Así que cuando una stablecoin está disponible «en diez cadenas», hay al menos diez contratos distintos, cada uno con su propia dirección, su propio suministro y sus propias reglas.
Incluso los detalles cambian: en BNB Smart Chain, los USDT y USDC que lista SSP Wallet usan 18 decimales, mientras que las versiones de Ethereum usan 6.
Si te resulta nueva la idea de que los tokens viven dentro de una cadena y necesitan su moneda nativa para pagar comisiones, monedas frente a tokens explica lo básico.
Nativa o puenteada: ¿quién respalda realmente el token?
Hay dos grandes formas en que una stablecoin llega a una cadena.
Emitida de forma nativa. El propio emisor despliega el contrato y acuña y canjea tokens directamente en esa cadena. Tu derecho apunta directamente a las reservas del emisor, bajo sus condiciones. Qué respalda a las stablecoins explica cuáles son esas reservas.
Puenteada. Alguien bloquea los tokens originales en un contrato de una cadena, y un puente acuña un token «envuelto» equivalente en otra. Ese token no se puede canjear directamente con el emisor. Es un pagaré sobre lo que esté bloqueado en el puente, así que suma el riesgo del puente al del emisor. Si el puente se vacía o sus claves se ven comprometidas, el token puenteado puede perder su respaldo mientras el nativo no se ve afectado. Por qué siguen hackeando los puentes y tokens envueltos profundizan en ambos temas.
Las dos versiones a menudo conviven. En Polygon, por ejemplo, USDC llegó primero a través de un puente. Cuando Circle empezó más tarde a emitir USDC de forma nativa allí, el antiguo token puenteado pasó a llamarse USDC.e, y ambos siguieron circulando como tokens distintos.
Por qué la dirección del contrato es la identidad
Los nombres, tickers y logos son solo etiquetas. Cualquiera puede desplegar un contrato de token y llamarlo «USDC», con seis decimales y un logo azul. Los estafadores hacen exactamente eso y envían imitaciones por airdrop a las billeteras, con la esperanza de que alguien intente usarlas.
Lo único que no se puede copiar es la dirección del contrato. En una cadena dada, exactamente una dirección es el USDC del emisor (o, si existen varias, una es la nativa y las demás son versiones puenteadas con sus propias direcciones). Dos tokens con nombres idénticos pero direcciones distintas son activos distintos, sin más.
Por eso los exchanges y los servicios de pago pueden abonar una versión y no otra. Cada servicio decide qué contratos admite y en qué redes. Si envías una versión puenteada, o el token correcto en la red equivocada, puede que el depósito no se abone automáticamente. Antes de enviar, comprueba tres cosas: la red, el token y el contrato exacto que acepta el destinatario.
Cómo comprobar un contrato de token
- Empieza por el emisor. Los grandes emisores publican su dirección de contrato oficial para cada cadena compatible. Compárala carácter por carácter, no solo los primeros y últimos.
- Usa un explorador de bloques. Busca la dirección en el explorador de la cadena. Comprueba que esté verificado, que el nombre y los decimales coincidan y que su historial parezca el de una gran stablecoin, no el de un contrato creado la semana pasada.
- Desconfía de las direcciones que llegan por respuestas, anuncios o mensajes directos. Son una vía habitual para contratos falsos.
- Pregunta al destinatario. Si pagas a un exchange o a una empresa, usa la red y el token que indican en su página de depósito, no los que supones.
Cómo lo gestiona SSP
SSP Wallet incluye una lista de tokens integrada para cada cadena EVM compatible y para Solana. Contiene stablecoins de uso habitual: por ejemplo, USDT y USDC en Ethereum, USDT y el USDC emitido de forma nativa en Polygon, USDC en Base, USDT en Avalanche, USDT y USDC en BNB Smart Chain, y el mint de USDC de Circle en Solana. Las listas son cortas, así que no están todas las versiones de todas las stablecoins.
Para cualquier otro, puedes añadir un token personalizado pegando su dirección de contrato (o la dirección del mint en Solana). SSP obtiene el nombre, el símbolo y los decimales del token y lo añade solo a esa cadena. Ten en cuenta que el nombre y el símbolo vienen del propio token, lo que significa que una imitación se llamará «USDC» sin problema. Lo que importa es la dirección que pegas, así que tómala del emisor o del explorador.
Una vez añadido un token, SSP Wallet muestra su dirección de contrato, decimales y red en los detalles del token, con un botón para copiar, y el contrato también aparece en los detalles de las transacciones. En la parte de aprobación, SSP Key muestra el contrato del token (o el mint de Solana) de una transferencia de tokens antes de que la apruebes. Si el teléfono no reconoce el token —por ejemplo, uno que solo importaste en la extensión del navegador—, SSP Key muestra la cantidad en unidades brutas y lo etiqueta como token desconocido, en lugar de fiarse de un nombre que no puede verificar.
El resumen honesto
«USDC» y «USDT» son familias de contratos separados. Algunos los emite de forma nativa el propio emisor; otros son pagarés puenteados que dependen además de que el puente aguante. El ticker dice muy poco: la red más la dirección del contrato te dicen lo que realmente tienes.
Antes de enviar stablecoins, confirma la red y el contrato exacto que acepta el destinatario, y comprueba los contratos desconocidos con la lista publicada por el emisor y un explorador. SSP ayuda incluyendo las stablecoins habituales, mostrando las direcciones de contrato y marcando los tokens no reconocidos en SSP Key, pero no puede decidir por ti qué versión abonará un exchange.


