Saltar al contenido
Financial Context Wiki

Cómo verificar un token recibido después de usar un bridge

Un token bridged debe verificarse por identidad, linaje, modelo de respaldo, autoridades, contabilidad en tránsito, condiciones de reembolso y valor de salida ejecutable.

Actualizado

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.

Verificación de tokens bridged
0 / 5
0 elementos revisados; 5 elementos pendientes

Completar esta revisión no demuestra que un activo, una transacción o un sistema sean seguros.

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

Fuentes

Navegación

Buscar en la wiki...