---
title: "Cómo verificar un token recibido después de usar un bridge"
description: "Un token bridged debe verificarse por identidad, linaje, modelo de respaldo, autoridades, contabilidad en tránsito, condiciones de reembolso y 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.
# Cómo verificar un token recibido después de usar un bridge
> Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
## Respuesta directa
Un token recibido mediante bridge no queda verificado por nombre, símbolo, icono, precio mostrado ni evento `Transfer`. La identidad comienza por chain o domain y contrato del token o marcador de activo nativo, e incluye implementation o beacon vigente del proxy, issuer o bridge, route y versión desplegada, activo de origen y snapshot de bloque.
Después se clasifica el claim: supply nativo del issuer, representación designada por un bridge, wrapped token de tercero, receipt de liquidez o intent, o counterfeit. Cada categoría tiene distinto issuer, activo, derecho de reembolso y fallo. Una representación canónica no es automáticamente issuer-native, y el registry del issuer no prueba reservas o liquidez de un bridge de terceros.
La verificación requiere cuatro libros: identidad y autoridad; reservas y claims pendientes; mensajes in-flight; y reembolso o salida de mercado ejecutable. Un saldo puede ser estado contractual real y aun representar el activo equivocado, un claim infracubierto, un token congelado o una posición invendible al precio mostrado.
## Cómo funciona
Símbolos, nombres y decimals son metadata ERC-20, no autenticación del issuer. Un counterfeit puede copiarlos, emitir eventos normales, publicar source verificado y sembrar un pool. Verificar source solo vincula el código mostrado al bytecode de una address. Con proxy, usuarios interactúan y mantienen balances en el proxy, mientras implementation o beacon aporta la lógica; admin y upgrade path son hechos separados.
Clasifique el modelo contable antes de calcular coverage. En lock-and-mint se concilia escrow elegible con todas las representaciones respaldadas y claims in-flight válidos. En burn-and-mint del issuer, supply se transfiere entre domains y quizá no exista escrow persistente por route. Un liquidity bridge adelanta inventory o crea un claim de solver/LP; su pool no es respaldo automático. Las reservas compartidas se cuentan una vez entre chains y versiones.
Para un alcance lock-and-mint definido sirve `coverage = eligible reserves / supported outstanding claims`. Las reservas elegibles deben ser el activo correcto, controlado por la custodia prometida, libre de cargas y no pignorado de nuevo. Los claims pueden incluir circulación multichain y multiversión más locks finalizados aún no minted, menos burns ya reflejados en supply. Un ratio superior a uno no prueba código, admins, finality, acceso a reembolso o depth.
La autoridad modifica el claim. Revise roles de mint/burn, mappings de remote token, validators/attesters, proxy admin, implementation, timelock, caps, pause, freeze, denylist y migration powers. También importan decimals, fee-on-transfer, rebasing, hooks/callbacks, returns no estándar y lógica upgradeable: el importe solicitado puede diferir del escrow o balance recibido.
Reembolso y venta son salidas distintas. El reembolso por issuer o bridge puede exigir cuenta elegible, direction soportada, mínimo/máximo, queue, proof/attestation, finality, gas, fee y contratos activos. La salida DEX exige route ejecutable para ese tamaño, fee, depth, price impact, minimum output y timestamp. Un pequeño quote cercano a un dólar no prueba respaldo ni salida de un holder grande.
Una migration puede dividir identidad y liquidez. Una representación deprecated puede seguir cotizando tras preferirse otra, y la conversión puede tener cap, ser unidireccional, demorarse o cerrarse. Verifique mappings old-to-new, ratio, deadline y estado de reembolso oficiales; no cambie por un mensaje de soporte o un símbolo que diga upgrade.
Use este flujo:
1. Fije chain/domain, proxy o marcador nativo, implementation/beacon, admin, decimals, bloque/hora, issuer/bridge, route/version y origin asset.
2. Cruce registries de issuer y bridge en ambos sentidos; verifique remote-token mapping, deployment, replacement/deprecation y derechos issuer-native o solo bridge.
3. Clasifique como burn-and-mint del issuer, lock-and-mint, shared reserve, wrapper de tercero, receipt de liquidity/intent u otro modelo documentado.
4. Reconstruya en raw units reserves, supply de todas las chains/versiones, claims in-flight finalizados, burns/releases pending y fees; defina elegibilidad y evite doble conteo.
5. Revise mint, burn, pause, freeze, denylist, cap, validator/attester, proxy admin, implementation/upgrades y comportamiento transfer/rebase/hook.
6. Pruebe reembolso real y salida de mercado para el tamaño: eligibility, limits, queue, proof, finality, gas, fees, route, depth, minimum output y activo recibido.
7. Concilie receipt fuente, delta real de escrow o burn, mensaje, receipt destino, balance exacto, supply, fees y salida neta; monitorice upgrades/migration y pare ante discrepancias.
## Ejemplos
- **Metadata no determina unidades ni identidad.** El raw amount `123,456,789` se muestra como `123.456789` con `6 decimals`, pero como `0.000000000123456789` con `18 decimals`: diferencia de escala `10^12`. El mismo símbolo no vuelve idénticos los contratos o claims.
- **Fee-on-transfer crea déficit inmediato.** Se solicita un lock de `1,000-token`. Una fee de `1%` elimina `10`, así que escrow recibe `990`; bridge descuenta otra fee de `2-token`. Mint correcto: `1,000 - 10 - 2 = 988`. Minted `998` contra `990` de escrow elegible crea déficit de `8-token`.
- **Shared reserves exigen denominator de sistema.** Escrow elegible `12.0 million`; circulación B `10.5 million`, C `0.4 million` y claim mint in-flight finalizado `0.6 million`. Claims=`10.5 + 0.4 + 0.6 = 11.5 million`; coverage=`12 / 11.5 = 1.0434782609`, o `104.34782609%`. Solo B daría `12 / 10.5 = 1.1428571429` y exageraría coverage.
- **Capacidad de reembolso y valor DEX difieren.** Un holder tiene `100,000 tokens`. La vía oficial solo reembolsa `60,000` ahora con fee `0.20%`: paga `60,000 * (1 - 0.002) = 59,880` underlying y deja `40,000` en queue. DEX vende todo a `0.972` antes de fee `0.30%`: gross `97,200`, fee `291.60`, net `96,908.40`, antes de gas/MEV. Un icono `$1` no prueba ninguno.
## Riesgos
- La misma address en chain/domain equivocado se confunde con el activo.
- Symbol, name o icon copiado oculta otro contrato.
- Se confunden proxy, implementation o beacon.
- Source verificado se confunde con respaldo del issuer.
- No se revisan implementation, admin o upgrade history vigentes.
- Sigue en uso una versión deprecated.
- Counterfeit crea eventos normales y liquidez artificial.
- Wrapped/LP receipt de tercero se confunde con issuer-native supply.
- Se aplica modelo lock/burn/mint/reserve/liquidity equivocado.
- Eligible reserves incluyen activos frozen, borrowed, pledged o distintos.
- La misma reserve se cuenta por cada chain.
- Se omiten claims de otras chains, legacy o in-flight.
- Burns, mints y snapshots usan tiempos incompatibles.
- Se compromete autoridad de mint, burn, attester, validator o upgrade.
- Pause, freeze, denylist o rate limits impiden transfer o exit.
- Decimals, raw units, fee-on-transfer, rebase o hooks rompen accounting.
- Reorg o finality insuficiente invalida evidencia de backing.
- Se ignoran eligibility, cap, queue, deadline, finality o fee.
- Depth, state drift, slippage, MEV o fees hacen inejecutable el quote.
- Migration, replacement, refund y receipts finales se concilian mal o son phishing.
## Errores comunes
- **Mismo nombre e icono significa mismo activo.** La identidad comienza con chain/domain y contrato exacto o marcador nativo.
- **Los tokens official/canonical bridge siempre son issuer-native.** Designación del bridge y derechos de mint/reembolso del issuer son distintos.
- **Coverage cercano o superior a uno prueba seguridad y reembolso inmediato.** No dice nada por sí solo de código, autoridad, finality, liquidity o eligibility.
- **La etiqueta verified del explorer prueba endorsement e inmutabilidad.** No verifica issuer claims, reserves, proxy admin o upgrades futuros.
- **Pantalla DEX de un dólar permite salir a un dólar.** El proceeds real depende de dirección, tamaño, route, depth, fees, gas, MEV y timing.
## Temas relacionados
- [Tokens canónicos, nativos y wrapped](/es/crypto/canonical-vs-wrapped-token/)
- [Puente canónico](/es/crypto/canonical-bridge/)
- [Puente entre cadenas](/es/crypto/cross-chain-bridge/)
## Fuentes
- [USDC contract addresses](https://developers.circle.com/stablecoins/usdc-contract-addresses) - Circle Developers (consulta: 2026-08-13)
- [CCTP technical guide](https://developers.circle.com/cctp/references/technical-guide) - Circle Developers (consulta: 2026-08-13)
- [Routes](https://docs.wormhole.com/products/connect/concepts/routes/) - Wormhole Docs (consulta: 2026-08-13)
- [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consulta: 2026-08-13)
- [ERC-20: Token Standard](https://eips.ethereum.org/EIPS/eip-20) - Ethereum Improvement Proposals (consulta: 2026-08-13)
- [ERC-1967: Proxy Storage Slots](https://eips.ethereum.org/EIPS/eip-1967) - Ethereum Improvement Proposals (consulta: 2026-08-13)
- [USDC Terms](https://www.circle.com/legal/usdc-terms) - Circle (consulta: 2026-08-13)
- [Uniswap v3 Core](https://uniswap.org/whitepaper-v3.pdf) - Uniswap (consulta: 2026-08-13)
Source: https://wiki.fcontext.com/es/crypto/bridge-token-verification/index.mdx