---
title: "Tokens canónicos, nativos y envueltos"
description: "Guía basada en la verificación para distinguir la identidad del token, los activos nativos del emisor, las representaciones designadas por protocolos, los wrappers en la misma cadena, el respaldo, el reembolso y el valor de salida ejecutable."
image: "https://wiki.fcontext.com/og.png"
---
> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Tokens canónicos, nativos y envueltos
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
Canónico y envuelto no son clases de tokens opuestas. Canónico describe el mapeo o la ruta designados por un ecosistema concreto; envuelto describe un mecanismo de representación. Un token puenteado designado por un protocolo puede ser a la vez envuelto, mientras que WETH es un wrapper en la misma cadena y el USDC nativo del emisor en una cadena compatible puede utilizar quema y emisión controladas por el emisor, sin custodia en un puente.
Empiece por la identidad, no por el símbolo: `chainId`, marcador de activo nativo o contrato del token, implementación del proxy y bloque. Después determine quién lo emite o designa, qué activo u obligación lo respalda, quién puede emitirlo, quemarlo, pausarlo o actualizarlo y si un tenedor admisible puede realmente desenvolverlo, reembolsarlo, puentearlo o venderlo. La solvencia, la disponibilidad del reembolso y la liquidez de mercado son cuestiones distintas.
## Cómo funciona
1. Fije la instantánea: cadena, `chainId`, marcador nativo o dirección del token, bloque y hora, decimales, implementación del proxy o `codeHash`, y versión de la documentación del emisor o protocolo. El nombre, símbolo, logotipo o listado de la cartera no constituyen identidad.
2. Clasifique en dos ejes. El estatus de identidad puede ser nativo de la cadena, nativo del emisor, designado por el protocolo o de terceros. El mecanismo puede ser un wrapper en la misma cadena, un derecho contra un puente lock-and-mint, una transferencia burn-and-mint, un wrapper custodiado, una participación de vault o un recibo de una red de liquidez. Un mismo token puede reunir varias etiquetas.
3. Trace el linaje exacto y el grafo de autoridades: activo de origen, contraparte remota registrada, contrato de custodia o quema, mensajero o certificador, emisor en destino, administrador del proxy, roles de emisión y quema, facultad de pausa o lista de bloqueo, timelock, límites y plan de migración.
4. Reconstruya el libro de respaldo y obligaciones en unidades brutas y visibles. En lock-and-mint, concilie la custodia admisible para el par con la oferta pendiente de la representación y los derechos en tránsito. En burn-and-mint del emisor, concilie las ofertas por cadena y la obligación del emisor; no invente una custodia de puente inexistente.
5. Verifique el ciclo de reembolso ejecutable: elegibilidad, dirección, aprobaciones, desenvoltura o quema, prueba o certificación, finalización o reclamación, gas en cada cadena, comisiones, límites, pausas y recuperación ante fallos. Una prueba pequeña solo acredita esa ruta y esa instantánea.
6. Compare las rutas de salida. Registre por separado el bid ejecutable y la profundidad del DEX, el deslizamiento, las comisiones de protocolo y LP, el gas, la demora y la aceptación por custodios o exchanges, sin confundirlos con la cobertura de reservas. Un token respaldado puede cotizar bajo la paridad y un precio líquido no demuestra respaldo.
7. Concilie recibos, eventos, saldos, oferta, custodia, derechos pendientes y allowances restantes. Mantenga separados los saldos nativos, envueltos, puenteados y nativos del emisor; vigile implementación, roles, mapeo, migración, pausas, divulgaciones de reservas y liquidez; dimensione la exposición según la peor salida ejecutable verosímil.
## Ejemplos desarrollados
- **La cobertura debe incluir los derechos pendientes.** La custodia admisible para el par es de `2,500.000000 units`, la oferta emitida en destino es de `2,400.000000 units` y los derechos bloqueados pero aún no emitidos ascienden a `100.000000 units`. Las obligaciones económicas son `2,400 + 100 = 2,500`, por lo que la cobertura ajustada es `2,500 / 2,500 = 100%`. Omitir los derechos pendientes arroja `2,500 / 2,400 = 104.1666666667%`, un superávit engañoso. Ni siquiera una cobertura correcta demuestra seguridad contractual o liquidez inmediata.
- **El mismo símbolo puede representar derechos distintos.** Un tenedor posee `2,500 units` de cada uno de dos contratos. El contrato nativo del emisor tiene un bid ejecutable de `$0.998`, con valor de `2,500 * 0.998 = $2,495`; el contrato de un puente de terceros tiene un bid de `$0.920`, con valor de `2,500 * 0.920 = $2,300`. La diferencia es de `$195`, pese a coincidir el nombre y los decimales.
- **Envuelto no implica cruce de cadenas.** Una cartera parte de `5.000 ETH`, deposita `3.000 ETH` en un contrato WETH de la misma cadena y paga `0.002 ETH` de gas. Termina con `1.998 ETH` y `3.000 WETH`; la relación entre reserva y oferta del wrapper es `3 / 3 = 100%`; y la exposición económica es `1.998 + 3.000 = 4.998 ETH` antes del riesgo contractual. Sumar de nuevo la reserva la contabilizaría dos veces.
- **La salida de mercado y el reembolso diferido son distintos.** Para `10,000 tokens`, el bid del DEX es `$0.985`, el impacto de precio `0.60%`, la comisión de LP o protocolo `0.10%` y el gas `$12`. Con ese orden, los ingresos netos son `10,000 * 0.985 * (1 - 0.006 - 0.001) - 12 = $9,769.05`. Un reembolso admisible entrega `$9,987` netos de comisiones en `7 days`; con una tasa anual simple de oportunidad del `8%`, el valor presente es `9,987 / (1 + 0.08 * 7 / 365) = $9,971.7009519641`, es decir, `$202.6509519641` más. No es un arbitraje garantizado y omite riesgo de impago, finalidad, fiscalidad y precio.
## Riesgos
- Utilizar una cadena, marcador nativo o contrato de token incorrectos.
- Confiar en un símbolo, nombre, icono o listado de cartera falsificados.
- Interpretar mal decimales, unidades brutas, oferta o semántica del saldo.
- Pasar por alto una implementación de proxy, administrador o actualización de código.
- Aceptar un registro, par, router o mapeo de gateway obsoleto.
- Perder el control por comprometerse un rol de emisor, emisión, quema o certificación.
- Tratar reservas mezcladas, pignoradas o gravadas como respaldo admisible para el par.
- Contabilizar dos veces custodia, oferta representativa y derechos pendientes como valores separados.
- Omitir depósitos, quemas, retiros, comisiones o mensajes fallidos en tránsito.
- Suponer que tokens con comisión por transferencia, rebase o hooks siguen la contabilidad estándar.
- Sufrir una congelación del emisor, pausa del puente, lista de bloqueo, límite o censura.
- Conceder una allowance excesiva o aprobar al spender de puente equivocado.
- Confundir finalidad de origen, validez del mensaje o estado de ejecución en destino.
- Depender de relayers, secuenciadores, probadores, certificadores o datos no disponibles.
- Afrontar repetición, doble emisión, quema fallida, reorganización de origen o errores contables.
- Descubrir que el tenedor no puede acceder al reembolso directo del emisor o del puente.
- Sufrir liquidez fragmentada, pérdida de paridad, deslizamiento, MEV o profundidad insuficiente.
- Omitir gas, comisiones, demora, coste de oportunidad o aceptación del custodio.
- Quedar atrapado en un contrato obsoleto o una migración incompleta al token nativo.
- Combinar riesgos correlacionados de cadena, puente, emisor, oráculo, interfaz, RPC, fiscalidad, sanciones y custodia.
## Errores comunes
- Canónico siempre significa nativo del emisor, oficial, trustless y seguro.
- Envuelto siempre significa que el token cruzó una cadena.
- Los tokens con el mismo símbolo y decimales representan derechos fungibles.
- Una etiqueta uno-a-uno, el saldo de un contrato o la cifra de oferta prueban el reembolso.
- El respaldo de reservas garantiza valor en efectivo inmediato uno-a-uno en cualquier mercado y cuenta.
## Temas relacionados
- [Puente canónico](/es/crypto/canonical-bridge/)
- [Verificación de tokens puenteados](/es/crypto/bridge-token-verification/)
- [Token envuelto](/es/crypto/wrapped-token/)
## Fuentes
- [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consultado: 2026-08-12)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consultado: 2026-08-12)
- [WETH9.sol](https://github.com/gnosis/canonical-weth/blob/master/contracts/WETH9.sol) - Gnosis (consultado: 2026-08-12)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultado: 2026-08-12)
- [Bridged token addresses](https://docs.optimism.io/app-developers/reference/tokens/tokenlist) - Optimism Documentation (consultado: 2026-08-12)
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Docs (consultado: 2026-08-12)
- [Cross-Chain Transfer Protocol](https://developers.circle.com/cctp) - Circle Docs (consultado: 2026-08-12)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consultado: 2026-08-12)
Source: https://wiki.fcontext.com/es/crypto/canonical-vs-wrapped-token/index.mdx