2. Qué cambió respecto al whitepaper anterior

El whitepaper bilingüe anterior fue un borrador de arquitectura importante, pero ahora queda sustituido. Describía el proyecto como una Agentic Settlement Network y recogía ideas perdurables como la primitiva Order, Agent OS, Policy Engine, Universal Router y la dirección post-cuántica. También contenía supuestos económicos y de estado que ya no son canónicos: usaba la etiqueta de token ION, describía una preventa del 40 % en cuatro rondas, incluía grandes bonificaciones de tokens, trataba la futura emisión de iUSD y AIX como arquitectura programada y describía la cadena soberana como una fase condicional posterior.

Esta v4.0 consolida la revisión completa del proyecto y restablece esos puntos sin borrar la historia del proyecto. Adopta el nombre de token canónico IONON, trata el acuerdo anterior de family-and-friends como una propuesta no financiada y no como una venta completada, elimina la distribución basada en bonificaciones, sustituye las rondas genéricas de bonding curve por un mecanismo Genesis de Uniswap CCA, adopta la asignación actual 40/30/10/7/6/5/2, trata los 30M como un programa máximo de distribución faseada y no como circulación programada, y traslada la red IONON Network —ya probada— a la arquitectura de migración, manteniendo Ethereum como mercado Genesis y ancla de liquidez.

El principio rector es simple: ninguna afirmación pública debe ir por delante de la evidencia reproducible. Cuando el proyecto tiene una implementación interna que aún no es verificable externamente, este documento lo dice.

2.1 Revisión profunda: cómo convergió la arquitectura

El canon v4 es el resultado de una secuencia de correcciones de diseño, no de una reescritura cosmética. Las siguientes decisiones se mantienen como arquitectura vinculante salvo que un futuro proceso de gobernanza, legal o de ingeniería las modifique explícitamente:

1. Normalización BCK/BCKMoney. El modelado económico anterior bajo la etiqueta de trabajo BCK/BCKMoney se entiende, en el contexto de este proyecto, como referido a IONON. V4 mantiene, por tanto, un único activo económico Genesis: IONON.
2. Ethereum primero. IONON inicia la formación de mercado en Ethereum porque el token, los monederos, los exploradores, la infraestructura de Uniswap v4 y la liquidez externa ya existen allí.
3. IONON Network después. La red soberana no se abandona ni se subordina. La dirección confirma un entorno de pruebas desplegado que ha completado las pruebas iniciales con éxito. La migración económica se produce sólo después de que se cumplan un paquete público de evidencia, la revisión del bridge y las puertas operativas.
4. El bridge como sistema de conservación. El bridge no es meramente una función de UX. Es una frontera monetaria. En ningún momento el IONON económico canónico entre Ethereum e IONON Network puede superar el suministro fijo de 100M.
5. La CCA sustituye al programa heredado de preventa/bonding curve. La antigua estructura de precio fijo con bonificaciones queda retirada para Genesis. Se prefiere la Continuous Clearing Auction de Uniswap porque ofrece pujas explícitas de presupuesto/precio máximo, descubrimiento continuo de precio y una vía integrada hacia un pool de liquidez v4.
6. No hubo venta family-and-friends completada. La anterior conversación de apoyo familiar nunca se financió. No se recibieron ingresos. Por tanto, no se trata como una venta externa consumada en la historia económica v4.
7. La asignación no es circulación. La partida de 30M de Phased Network Distribution es una envolvente máxima de programa, no una promesa de vender 30M. Los tramos futuros pueden permanecer inactivos indefinidamente.
8. La reserva condicional no es suministro aditivo. Hasta 10M de la Conditional Network Reserve se encuentran dentro de la asignación de 40M de la DAO Treasury; no es una octava partida de tokenomics.
9. gIONON es representación de gobernanza, no un segundo suministro. Aproximadamente 3M IONON han sido descritos por la dirección y la página pública actual del token como envueltos para gobernanza. El wrapper de gobernanza crea representación de voto del IONON depositado; no aumenta el tope económico de 100M.
10. La utilidad precede a la narrativa financiera. Tarjetas, identidad de agentes, políticas, monedero, enrutamiento, software empresarial, IONON Intelligence y servicios de operadores deben crear utilidad e ingresos independientemente de la demanda especulativa del token.
11. El token no es la arquitectura. La primitiva del sistema es una acción económica autorizada: identidad, autoridad delegada, política, simulación, aprobación, ejecución, liquidación y evidencia.
12. La liquidación estable y la reputación futuras son capas separadas. USDC y los rails regulados pueden servir la liquidación estable en Genesis. Cualquier futuro activo estable o de reputación nativo de IONON requiere una decisión separada de gobernanza, legal, de reservas y de seguridad.
13. La credibilidad pública es un grafo, no una insignia. La procedencia de Team Finance, Ethereum, Etherscan, ENS, Aragon, Wyoming, USPTO, GitHub, la revisión de seguridad, CoinGecko/CMC y la reputación de monederos deben resolver todos al mismo registro canónico.
14. La documentación es infraestructura. docs.ionon.ai se convierte en la fuente pública autoalojada y versionada; docs@ionon.ai es una identidad de correo operativa, no el nombre de host del sitio web.

2.2 Jerarquía de verdad de V4

Cuando las fuentes discrepan, v4 aplica la siguiente prioridad en lugar de elegir la página que suene más sólida:

Estado on-chain e instrumentos legales firmados → registros verificados de despliegue/fuente → registro canónico → registros de gobernanza → documentación publicada → superficies públicas de marketing.

Una página de marketing nunca puede prevalecer sobre un contrato. Un perfil de explorador desactualizado nunca puede prevalecer sobre el bytecode verificado. Una hoja de ruta nunca puede convertir un entorno de prueba en producción. A la inversa, una implementación interna del proyecto puede ser real sin ser aún pública; en ese caso permanece como MANAGEMENT-CONFIRMED o TEST hasta que se publique evidencia reproducible.

2.3 Limpieza de superficies públicas identificada en el rastreo de octubre de 2026

Un rastreo reciente de ionon.ai identificó varias contradicciones que deben tratarse como defectos de control antes de Genesis en lugar de repetirse en v4:

• la página del token aún publica la dirección histórica de gIONON 0x9913... mientras la dirección identifica 0xbDde...8034 como el wrapper canónico;
• las páginas de token/preventa aún presentan 850K como distribuidos a $1.25 con lenguaje de bonificación, aunque el acuerdo familiar asociado nunca se financió;
• la portada/superficie de identidad aún contiene Contract 0x… (TBA at TGE) aunque el contrato canónico de Ethereum ya existe;
• la página del DAO dice que la tenencia directa de IONON otorga poder de voto, mientras la arquitectura del token usa gIONON como representación de gobernanza;
• la página de la red muestra 955 nodos activos mientras reporta simultáneamente cero cadenas y cero transacciones, lo que requiere una explicación respaldada por telemetría o su retirada;
• algunas páginas describen fases futuras de la red y mecanismos de bridge como si las decisiones finales de despliegue ya fueran hechos de producción;
• algunas páginas usan la nomenclatura heredada Dilithium/Falcon que debe reconciliarse con la terminología actual del NIST y la implementación exacta realmente desplegada;
• algunas páginas dicen “created and patented”, mientras la evidencia documental suministrada a este proyecto prueba una marca de servicio registrada en EE. UU.; las afirmaciones de patente requieren evidencia de patente separada;
• las afirmaciones generales de que los tokens del ecosistema son “utility tokens” no deben sustituir al análisis legal específico por jurisdicción de cómo se ofrece y usa un token o una transacción.

V4 trata, por tanto, el propio sitio web como un objeto que debe reconciliarse con el registro canónico antes de poder servir como evidencia para la verificación por terceros.

Referencias

Referencias del whitepaper