--- title: "Puente canónico" description: "Una guía de verificación de puentes designados por el protocolo, respaldo de activos, estados de mensajes entre dominios, retiros optimistas y con pruebas de validez, controles de actualización, comisiones y comparación con puentes rápidos." 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. # Puente canónico > Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas. ## Respuesta directa Un puente canónico es la ruta de activos o mensajes designada por un rollup o ecosistema de cadena concreto. Suele conectar contratos que bloquean en escrow o queman un activo en una cadena, transmiten un mensaje reconocido por el protocolo y acuñan, desbloquean o liberan el activo correspondiente en la otra. La palabra canónico es una etiqueta del ecosistema, no una norma universal, garantía criptográfica ni prueba de autenticidad de un sitio y una dirección. Su seguridad no es una fórmula aditiva. Depende conjuntamente de la finalidad de la cadena de origen, disponibilidad de datos, verificación de estados o mensajes, contabilidad del puente, ejecución en destino, protección contra replay, poderes de actualización y pausa, y una vía de salida utilizable. Un puente rápido puede pagar antes al usuario con liquidez y liquidar después por la ruta canónica, pero esto añade supuestos sobre proveedor de liquidez, solver, verificador y ejecución, en vez de acelerar gratis la misma máquina de estados. ## Cómo funciona 1. Fija la instantánea de la ruta: `chainId` de origen y destino, dirección, stack y versión del rollup, direcciones de bridge, portal, messenger, inbox o gateway, direcciones de tokens, destinatario, importe, referencias de bloque y documentación oficial. Nunca dependas solo de un resultado de búsqueda o de la etiqueta oficial. 2. Resuelve el modelo de seguridad y control. Registra reglas de fault proof optimista o validity proof, modo de disponibilidad de datos, sequencer y ruta forzada, implementación del proxy, administrador o consejo de seguridad, timelock, estado de pausa, límites de tasa y retraso de actualización. Canónico no significa inmutable. 3. Clasifica el registro del activo. Distingue valor nativo de tokens ERC-20 e identifica el mecanismo lock-and-mint, burn-and-release o burn-and-mint. Verifica el par registrado de tokens, unidades brutas, decimales, gateway personalizado y compatibilidad con activos fee-on-transfer, rebasing o sujetos a listas de bloqueo. 4. Construye la máquina de estados de mensajes específica de la dirección. Un depósito puede pasar por aprobación, escrow o quema en origen, finalidad de origen, derivación o relay y acuñación o desbloqueo en destino. Un retiro puede exigir quema o escrow en destino, inclusión del mensaje, compromiso de estado, prueba, impugnación o aceptación de la prueba, finalización y liberación en origen. 5. Sigue por separado tres relojes: inclusión de la transacción, liquidación del protocolo o finalidad del estado, y disponibilidad del activo para usarlo o retirarlo. Registra hash de la transacción de origen, hash del mensaje o retiro, referencia de output o prueba y cada transacción de relay, prove, finalize, claim, retry o refund. 6. Construye el registro económico. Separa principal transferido, gas en origen y destino, gas de prueba o finalización, comisión del protocolo o relayer, comisión del proveedor de liquidez, slippage y coste de oportunidad de la espera. Compara un puente rápido con la ruta canónica como derechos y modelos de confianza diferentes. 7. Concilia la ruta terminada con recibos, eventos, saldos en escrow, oferta de la representación, derechos pendientes, saldos del destinatario y allowances restantes. Espera la finalidad exigida, conserva gas de emergencia, prueba las rutas permissionless o forzadas cuando proceda y detente en vez de repetir un depósito cuyo estado de mensaje no puedas explicar. ## Ejemplos desarrollados - **Registro de depósito de activo nativo.** Un usuario empieza con `5.0000 ETH`, deposita `2.5000 ETH` y paga `0.0042 ETH` de gas en origen. La wallet de origen termina con `5.0000 - 2.5000 - 0.0042 = 2.4958 ETH`; el escrow aumenta en `2.5000 ETH`; y, tras un relay correcto uno a uno, la representación en destino aumenta en `2.5000 ETH`. La razón de respaldo es `2.5000 / 2.5000 = 100%`. El escrow y la representación son respaldo y derecho, no `5 ETH` de nuevo valor económico. - **Unidades brutas y mapeo del token.** Un usuario deposita `1,250.000000 USDC`. El contrato de origen verificado usa `6 decimals`, por lo que el importe bruto es `1,250 * 10^6 = 1,250,000,000`. Con un mapeo verificado uno a uno y sin comisión del token, el escrow de origen y la acuñación en destino varían cada uno en `1,250,000,000 raw units`, que se muestran como `1,250.000000 USDC` remotamente. Un token con el mismo símbolo en otra dirección no es evidencia intercambiable. - **Los relojes de retiro son distintos.** Supón que un deployment registra un retiro en `2026-08-01 12:00:00 UTC` y aplica un periodo de impugnación de `604,800-second = 7-day` desde ese inicio definido por el protocolo. El umbral temporal es `2026-08-08 12:00:00 UTC`; una transacción de prove o finalize, el gas y la política elegida de confirmación de la cadena de origen pueden añadir más tiempo. Este ejemplo parametrizado no afirma que todos los puentes esperen siete días, y la finalidad de la transacción de destino no libera por sí sola los fondos de origen. - **Cotización de ruta rápida frente al coste de espera.** Para `10,000 USDC`, un puente rápido cobra `0.08%` más `3 USDC`, sin contar gas ni slippage. El coste es `10,000 * 0.0008 + 3 = 11 USDC` y los ingresos inmediatos son `9,989 USDC`. Frente a una espera canónica hipotética de `7-day`, el precio anualizado simple del acceso anticipado es `(11 / 9,989) * (365 / 7) = 5.7420305193%`. La comparación no es una rentabilidad ni una tasa libre de riesgo y excluye riesgos de solver, liquidez, impago y liquidación. ## Riesgos - Usar una interfaz de phishing o un dominio de documentación sin verificar. - Seleccionar la cadena de origen o destino y el `chainId` incorrectos. - Enviar a un bridge, portal, messenger, gateway o destinatario falsificados. - Aceptar un token con el mismo símbolo pero con un mapeo de contraparte registrado distinto. - Interpretar mal decimales, unidades brutas o comportamiento no estándar del token al transferir. - Confundir activos nativos, tokens de gas envueltos y representaciones transferidas por puente. - Exponer una allowance excesiva o aprobar al spender incorrecto. - No detectar una actualización de proxy, compromiso del administrador, actuación del consejo de seguridad o cambio del timelock. - Encontrar una pausa, denylist, límite de tasa o ruta de retiro congelada. - Tratar un recibo de origen como prueba de ejecución correcta en destino. - No financiar suficientemente el gas de ejecución, retry, prove, claim o refund en destino. - Perder un mensaje por caducidad del retry, gestión incorrecta del refund o aliasing de direcciones. - Ignorar una reorganización de la cadena de origen o una finalidad insuficiente. - Depender de un sequencer que censura o no está disponible sin una ruta forzada operativa. - Perder la disponibilidad de datos necesaria para probar, reconstruir o abandonar el estado. - Aceptar una raíz de estado, prueba de mensaje, nullifier o condición de replay inválidos. - Depender de proposers, provers, challengers o finalizers permissioned que no están disponibles. - Interpretar mal un parámetro de impugnación, vencimiento o aceptación de prueba tras una actualización. - Sufrir insolvencia del escrow, desviación contable, depeg del token o iliquidez en destino. - Añadir riesgos de puente rápido, agregador, verificador, LP, solver, slippage, impuestos y sanciones. ## Errores comunes - Canónico es una norma universal y significa automáticamente trustless o libre de riesgo. - Una transacción correcta en origen o un saldo mostrado en la UI demuestran liquidación definitiva. - Todos los retiros de rollups tienen el mismo periodo de espera de siete días. - El escrow de origen y las representaciones de destino pueden sumarse como TVL independiente. - Un puente rápido es simplemente el mismo puente canónico con un ajuste de velocidad. ## Temas relacionados - [Puente entre cadenas](/es/crypto/cross-chain-bridge/) - [Rollup](/es/crypto/rollup/) - [Mecanismo de salida de rollup](/es/crypto/rollup-escape-hatch/) ## Fuentes - [Bridges](https://ethereum.org/developers/docs/bridges/) - Ethereum.org (consultado: 2026-08-12) - [Standard Bridges](https://specs.optimism.io/protocol/bridges.html) - OP Stack Specification (consultado: 2026-08-12) - [Withdrawals](https://specs.optimism.io/protocol/withdrawals.html) - OP Stack Specification (consultado: 2026-08-12) - [Arbitrum Nitro: A Second-Generation Optimistic Rollup](https://docs.arbitrum.io/nitro-whitepaper.pdf) - Offchain Labs (consultado: 2026-08-12) - [L1 to L2 messaging](https://docs.starknet.io/learn/protocol/messaging) - Starknet Documentation (consultado: 2026-08-12) - [StarkGate](https://docs.starknet.io/learn/protocol/starkgate) - Starknet Documentation (consultado: 2026-08-12) - [Bridging assets](https://docs.zksync.io/zksync-protocol/rollup/bridging-assets) - ZKsync 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-bridge/index.mdx