Whitepaper V4.1
11. Arquitectura del bridge y el invariante de conservación del suministro
El bridge nunca debe crear un segundo suministro económico de IONON. El invariante es:
El IONON económico canónico en circulación entre todas las representaciones ≤ 100,000,000.
El mecanismo exacto depende de las capacidades del ERC-20 desplegado y del módulo de token final de IONON Network. Un diseño de burn-and-mint es aceptable sólo si el contrato de Ethereum realmente soporta una ruta de quema segura y auditable que no pueda ser abusada. En caso contrario, el bridge debe usar una representación de lock/escrow-and-mint, donde la cantidad bloqueada en Ethereum prueba la representación nativa máxima que puede existir.
El controlador del bridge debe incluir:
- registro de token canónico específico por cadena;
- unicidad de mensajes y protección contra replay;
- umbrales de finalidad;
- límites de ritmo y techos globales de emisión/representación;
- separación validador/relayer;
- disyuntor y pausa en la capa del bridge sin requerir un token base pausable;
- monitorización independiente;
- procedimientos de reconciliación de emergencia;
- comprobaciones del invariante antes de emitir/liberar;
- retención de transacciones y pruebas;
- panel público de estado del bridge.
La infraestructura Axelar GMP/Interchain e IBC son candidatas para el transporte interoperable. El producto puede seguir marcándose como “IONON Bridge” mientras se utilizan mensajería y transporte probados por debajo. Construir un bridge custodial propietario sin auditar sólo por marca aumentaría, no reduciría, el riesgo sistémico.
11.1 Máquina de estados del bridge
Todo movimiento transfronterizo debe modelarse como una máquina de estados y no como un par de transacciones débilmente acopladas:
Requested → Policy-checked → Source-finalized → Proof-observed → Destination-authorized → Mint/Release → Reconciled.
Ninguna transición es implícita. Cada estado lleva un identificador único de transferencia, IDs de cadena de origen/destino, cantidad, identidad del token, bloque de origen/punto de control de finalidad, referencia de prueba o atestación, conjunto de firmantes/validadores, versión de política y marcas de tiempo.
Una acción fallida en destino no debe causar una segunda liberación en origen. Una reorganización o un mensaje duplicado no debe crear una segunda emisión. La intervención de emergencia puede detener nuevas transiciones del bridge, pero nunca debe reescribir la historia completada de la cadena de origen.
11.2 Presupuesto de riesgo del bridge
El bridge debe lanzarse con límites deliberadamente conservadores: topes por transferencia, techos móviles por hora/día, techos por ruta y un techo global de suministro representado. Los límites sólo pueden aumentarse tras fiabilidad observada y aprobación de gobernanza. Es el mismo principio usado en el resto de IONON: la autonomía crece con la evidencia, no con el optimismo.
11.3 Reconciliación monetaria
En cada punto de control, el servicio de reconciliación debe probar:
Ethereum libre + Ethereum en escrow + representación canónica en IONON Network + cualquier ajuste contable en tránsito aprobado = tope económico de 100M, sujeto a las reglas de representación definidas.
Un panel público debe distinguir suministro del token, escrow del bridge, circulante en cada dominio y transferencias en tránsito, de modo que los saldos envueltos/en escrow nunca se contabilicen dos veces en las afirmaciones de suministro circulante.