XerisCoinXerisCoin
Whitepaper técnicoWhitepaper técnico

1Introducción

Las L1 actuales se dividen en dos grupos: cadenas de alto rendimiento que sacrifican descentralización por velocidad, y cadenas proof-of-work más lentas, con seguridad sólida y programabilidad limitada. Ninguno de los dos grupos aborda dos requisitos nuevos que esperamos definan la próxima década de la computación on-chain: orquestación nativa de agentes de IA autónomos y tokenización de activos del mundo real conforme a la regulación, con vinculación a contratos ricardianos.

XerisCoin apila tres mecanismos en un único pipeline que se completa dentro de una ventana de slot de 4 segundos: Proof-of-History para el ordenamiento local, Proof-of-Work Scrypt para la producción de bloques y Proof-of-Stake para la elección de líder. La cadena sigue siendo minable en hardware comercial (Scrypt es memory-hard y resistente a ASIC con nuestra parametrización), ofrece resistencia económica a Sybil mediante staking y mantiene un ordenamiento determinístico de slots sin depender de un reloj externo.

Además de transferencias y llamadas a contratos, el set de instrucciones incluye operaciones para registro de agentes, delegación jerárquica, oráculos de datos, atestación de hardware y verificación de pruebas de conocimiento cero. Son variantes nativas de instrucción procesadas por el mismo runtime que las transferencias de tokens, con la misma contabilidad de tarifas y la misma protección contra replay.

2Arquitectura de consenso

El consenso de XerisCoin opera como un pipeline de tres etapas dentro de cada slot de 4 segundos. Cada etapa impone restricciones a la siguiente. Para producir un bloque fraudulento, un atacante debe comprometer a la vez el ordenamiento proof-of-history, la elección de líder ponderada por stake y la minería proof-of-work memory-hard.

2.1Proof-of-History (PoH)

PoH proporciona ordenamiento local encadenando hashes SHA-256, donde cada entrada de hash incluye la salida del anterior. A diferencia de las implementaciones determinísticas de PoH, XerisCoin mezcla entropía con resolución de nanosegundos del reloj monotónico del validador (Instant::elapsed().subsec_nanos(), endurecido en XWC-27 desde la fuente original de reloj de pared) en el preimage del hash. Es así por diseño (documentado como H-1): la cadena PoH se usa solo para la asignación local de slots y un adversario que no controle el reloj del validador con resolución de nanosegundos no puede precomputarla. El hash PoW se compromete a la punta de la cadena PoH y vincula ambas capas.

La salida de PoH determina los límites de los slots. Cada slot corresponde exactamente a una oportunidad de bloque. Los validadores usan conteos de tick de PoH para sincronizarse sin paso de mensajes estilo BFT para el acuerdo de slot.

2.2Proof-of-Work (Scrypt)

La producción de bloques requiere resolver un puzzle proof-of-work Scrypt dentro de la ventana de slot. Scrypt fue seleccionado por su propiedad memory-hard, que eleva el costo de la minería con ASIC frente al hardware de propósito general. Los parámetros de Scrypt pasaron por tres generaciones durante el desarrollo. En la red actual el conjunto v1.2 está activo desde génesis (los anteriores se conservan en el nodo solo para replay histórico):

Los parámetros v1.2 equilibran la dureza de memoria con el timeout de minería de 3.9 segundos que mantiene la producción de bloques dentro de la ventana de slot. Un minero que no encuentra un nonce válido en 3.9 segundos pierde el slot.

El preimage de PoW lleva una etiqueta de dominio (XRS_POW_V2) y se compromete al hash del bloque padre y al timestamp de PoH con campos de longitud prefijada (corrección XWC-05). Una solución proof-of-work no puede reutilizarse entre padres o timestamps distintos. Los saltos de slot hacia adelante están acotados por el tiempo PoH transcurrido: un bloque puede avanzar como máximo los slots justificados por su delta de PoH más una tolerancia de dos slots (corrección XWC-10). Esto impide que un proponente adelante artificialmente la lógica dependiente de slots, como el unbonding.

Los validadores que no son líderes también pueden intentar minar el mismo slot, pero a 4 veces el objetivo de dificultad (corrección C-2). Esto da ventaja económica al líder electo y preserva la liveness de la cadena: si el líder no produce un bloque, un no-líder aún puede llenar el slot a un costo computacional mayor.

2.3Proof-of-Stake (elección de líder)

La elección de líder es determinística y ponderada por stake. Para cada slot, el protocolo construye el conjunto de validadores elegibles con las cuentas que tienen al menos 1,000 XRS en stake. Los validadores elegibles se ordenan por clave pública para el consenso entre nodos. Un sorteo aleatorio ponderado por stake, sembrado con un hash con separación de dominio del hash del bloque anterior y el número de slot, determina al líder.

Este diseño (corrección C-1) reemplazó un esquema anterior que sembraba la elección de líder con el hash de PoH, que era manipulable porque PoH se computa localmente. Como el hash del bloque anterior requiere PoW para producirse, predecir al líder implica minar el bloque precedente. El sorteo ponderado usa rejection sampling sin sesgo (corrección XWC-42) para eliminar el sesgo de módulo.

3Estructura de bloque y modelo de transacción

Cada bloque contiene un header fijo y un payload de transacciones de longitud variable. El header se compromete al conjunto de transacciones mediante una raíz de Merkle, permitiendo verificación ligera sin descargar el cuerpo completo del bloque.

Desde HYBRID_SIG_ACTIVATION_SLOT = 1 (el primer bloque minado), cada header debe llevar una firma híbrida: una firma Ed25519 y una firma CRYSTALS-Dilithium3 sobre un único mensaje canónico, con separación de dominio y vinculado al chain-id. Un bloque es válido solo si ambas verifican (ver §7). La clave pública Dilithium se almacena inline en el header para que la validación no requiera estado. Desde el slot 2 debe coincidir con la entrada del proponente en el registro de claves PQ on-chain.

La capacidad está limitada a 40,000 transacciones por bloque. Cada transacción admite hasta 16 instrucciones, 64 claves de cuenta y 8 KB de datos de instrucción por instrucción. Estos límites se aplican en la admisión al mempool y de nuevo dentro de la validación de consenso (corrección XWC-15). Un productor malicioso no puede empaquetar instrucciones sobredimensionadas directamente en un bloque. La raíz de Merkle usa separación de dominio estilo RFC 6962 con un centinela etiquetado para capas impares (inmune a la ambigüedad de transacciones duplicadas de CVE-2012-2459) y falla cerrada ante cualquier transacción sin firmar.

El mempool mantiene un máximo de 100,000 transacciones pendientes con deduplicación de firmas O(1) vía HashSet (corrección LOW-2). La admisión está endurecida: cada transacción entrante se sanitiza y debe llevar exactamente su conteo declarado de firmantes (XWC-18), las transacciones sin fondos se limitan a 10,000 entradas en el pool (XWC-19), las transacciones reencoladas reingresan con prioridad plana, sin boost por longitud de datos (XWC-20), las transacciones de propuestas en vuelo se reservan para evitar admisión duplicada durante la ventana de minado-commit (XWC-17) y los resultados de admisión se reportan al emisor (XWC-21).

3.1Set de instrucciones

XerisCoin define un set de instrucciones tipado vía el enum XerisInstruction, que comprende 54 variantes (índices 0–53). Cada variante corresponde a una operación específica procesada por el runtime. El legacy SystemInstruction::Transfer compatible con Solana está deshabilitado desde génesis a favor de la variante nativa NativeTransfer, con verificación explícita del firmante. Variantes representativas:

3.2Modelo de tarifas y protección contra replay

Las tarifas de transacción están activas desde el primer bloque (FEE_ACTIVATION_SLOT = 1). La tarifa base es 0.001 XRS (1,000,000 lamports) por transacción, recolectada por el proponente del bloque. Los firmantes deben tener al menos el monto de la tarifa en su cuenta. Las transacciones de cuentas sin fondos se descartan del bloque sin ejecutarse.

La protección contra replay usa una ventana de expiración de blockhash de 150 bloques (correcciones C-3 y C-4). Cada transacción referencia un blockhash reciente. El runtime rechaza las transacciones cuyo blockhash tenga más de 150 slots de antigüedad (~10 minutos). La deduplicación de firmas en el servidor con ventanas TTL es una segunda defensa contra replay dentro de la ventana de validez.

4Economía del token

XerisCoin (XRS) tiene un tope duro de supply total de 700,000,000 tokens: una pre-asignación de tesorería de 200,000,000 XRS más un presupuesto de emisión impuesto en runtime de 500,000,000 XRS (MAX_EMISSION_SUPPLY). Las recompensas de minería, staking y atestación salen de ese único presupuesto de 500M y están limitadas conjuntamente por él, así que el supply total no puede superar los 700M.

4.1Cronograma de emisión

La recompensa base de bloque es 10 XRS (BASE_BLOCK_REWARD), con halving cada 25,000,000 bloques. A 4 segundos por slot, cada época de halving abarca aproximadamente 3.17 años, y la serie geométrica suma exactamente el presupuesto de emisión de 500M. La fórmula de halving usa aritmética de desplazamiento de bits con protección contra overflow (el conteo de desplazamiento está limitado a 63):

El supply de emisión restante se contabiliza en runtime. Cuando las emisiones acumuladas (minería, staking y atestación combinadas) se aproximan al presupuesto de emisión de 500M, las recompensas de bloque se reducen al balance restante (corrección L-10). Esto previene la sobre-emisión por errores de redondeo en la aritmética de halving y garantiza que el tope de supply total de 700M se mantenga.

4.2Recompensas de staking

Las recompensas de staking se distribuyen cada 900 bloques (~1 hora) a una tasa anual fija del 7%. Solo las cuentas con al menos 100 XRS en staking son elegibles. Las recompensas se acumulan en el balance líquido y no se capitalizan automáticamente. Capitalizarlas requiere un re-staking explícito.

El unstaking entra en un período de unbonding de 151,200 slots (~7 días). La cola de unbonding está limitada a 10,000 entradas globales y 10 entradas pendientes por cuenta (corrección M-8) para prevenir denegación de servicio por agotamiento de la cola. Durante el unbonding, los tokens no ganan recompensas de staking ni cuentan para el peso de elección de líder, pero siguen sujetos a slashing durante todo el período (ver §4.3).

La atestación de light client da una recompensa adicional de 0.01 XRS por prueba válida, reclamable dentro de una ventana de 200 slots (~13 minutos) tras la creación del bloque. Los atestadores deben tener al menos 100 XRS en staking, están limitados a una recompensa cada 10 bloques, y las atestaciones se deduplican por (block_slot, validator_pubkey) para evitar la doble reclamación. Estas recompensas también se descuentan del presupuesto de emisión de 500M (L-10).

4.3Slashing

La equivocación del proponente (firmar dos headers de bloque distintos para el mismo slot) se castiga con slashing. Cualquiera puede enviar evidencia con la instrucción SlashReport: dos headers firmados canónicamente y demostrablemente distintos en el mismo slot de violación. El runtime re-verifica ambas firmas bajo el esquema activo en ese slot (híbrido Ed25519 + Dilithium3 post-activación), y la clave Dilithium inline debe coincidir con la entrada del infractor en el registro PQ on-chain (corrección XWC-53). La evidencia no puede forjarse a partir de headers que la admisión de bloques habría rechazado.

El stake activo se consume primero, luego las entradas de unbonding de más antigua a más reciente. Cada ofensa única aplica slashing como máximo una vez sin importar cómo se codifique o re-etiquete la evidencia (corrección XWC-30), y los reportes de valor cero o auto-referenciales se rechazan.

5Sistema de contratos inteligentes

XerisCoin define 23 primitivas de contrato tipadas (22 de ellas desplegables por usuarios), que se despliegan con la instrucción ContractDeploy y se invocan con ContractCall. Los contratos son instancias parametrizadas de tipos definidos por el protocolo. No se admite bytecode arbitrario. Esto elimina por construcción una clase de vulnerabilidades (reentrancy, delegatecall no verificado, colisiones de almacenamiento).

5.1Primitivas DeFi

Swap (AMM). Market maker automatizado de producto constante con seguimiento de shares de LP. Los pools imponen un bloqueo mínimo de liquidez en la inicialización (corrección C-5, siguiendo el patrón de Uniswap V2) para prevenir la manipulación del ratio de precio inicial con depósitos dust. Los pools con tokens de entrada y salida idénticos se rechazan en la creación, y toda la validación se ejecuta antes de debitar cualquier balance (corrección XWC-67).

Launchpad. Curva de bonding de lanzamiento justo para crear nuevos tokens. El creador recibe una recompensa fija del 1% (100 bps) y el protocolo cobra un 0.77% (77 bps) tanto en compras como en ventas. Los precios de compra y venta derivan de un único invariante de producto constante sobre reservas virtuales, de modo que las dos vías no pueden arbitrarse entre sí (corrección XWC-68). Cuando la curva de bonding alcanza su umbral objetivo de liquidez, el contrato finaliza desplegando un pool Swap sembrado con el XRS acumulado y el inventario no vendido de la curva, con contabilidad explícita de supply. Los métodos del ciclo de vida del launchpad solo pueden invocarse por la vía directa de nivel superior. La invocación indirecta mediante agentes delegados u órdenes condicionales se rechaza (corrección XWC-07). Los controles de vesting están embebidos en los parámetros de lanzamiento para prevenir el dumping inmediato: períodos de cliff, porcentajes de desbloqueo diario y restricciones de venta máxima, todos calculados en milisegundos (corrección XWC-70).

LimitOrder / DcaOrder. Órdenes permanentes que ponen en escrow el token de entrada y se ejecutan cuando un keeper confirma que se ha alcanzado la tasa objetivo. Las órdenes limit admiten una tarifa de keeper configurable (por defecto 10 bps). Las órdenes DCA extienden esto con ejecución por intervalos: cada tick lo ejecuta un keeper de forma independiente, lo que permite estrategias como la acumulación diaria en horizontes de tiempo configurables.

ConditionalOrderBook. Órdenes permanentes evaluadas cada bloque contra fuentes de condición configurables (feed de oráculo, umbral de precio, condición de tiempo). Los triggers de precio leen una mediana con ventana móvil de observaciones de precio por bloque en lugar del ratio de reservas instantáneo, lo que resiste la manipulación de precio en un solo bloque (corrección XWC-63). Las órdenes disparadas y expiradas se ejecutan en un orden canónico y determinista en todos los nodos (corrección XWC-62). La liquidación del escrow es atómica: una orden se marca como ejecutada solo si es completamente financiable (corrección XWC-08). Las órdenes expiran automáticamente tras un slot especificado y reembolsan el balance en escrow al cancelarse.

5.2Protocolo Alexandria (activos del mundo real)

El Protocolo Alexandria implementa contratos inteligentes Ricardianos: tokens on-chain vinculados a documentos legales off-chain mediante compromiso de hash criptográfico. Cada token RWA almacena:

El runtime restringe las transferencias de tokens RWA a direcciones de la whitelist de cumplimiento. El campo de jurisdicción permite que el tooling downstream aplique lógica regulatoria local sin modificar el protocolo base. El historial de distribución se mantiene on-chain para auditar la procedencia.

6Protocolo XERIS ARI

El protocolo Autonomous Runtime Infrastructure (ARI) da soporte on-chain a la operación de agentes de IA. ARI sitúa a los agentes en una jerarquía de delegación impuesta por el protocolo, con controles de gasto, whitelists de operaciones e interruptores de emergencia.

AgentRegistry. Un dueño registra un agente con RegisterAgent, especificando límites de gasto por transacción, topes de gasto diarios (medidos en ventanas de 21,600 slots, es decir, 24 horas), una whitelist de contratos con los que el agente puede interactuar y una whitelist de tipos de instrucción que puede ejecutar. El dueño conserva un interruptor de emergencia unilateral que revoca de inmediato toda la autoridad delegada. Las métricas acumuladas (total de transacciones, total gastado) se registran on-chain.

IdentityRegistry. Identidad persistente para agentes y dispositivos con puntuación de reputación por categorías. Las identidades admiten credenciales adjuntas, relaciones jerárquicas padre-hijo (una identidad de organización puede ser padre de identidades de agentes individuales) y un historial de transacciones verificado. La reputación es por categoría: la reputación de un agente de trading en "provisión de liquidez" se registra por separado de su reputación en "precisión de datos".

SubDelegate. Los agentes pueden delegar autoridad a sub-agentes, sujetos a restricciones de profundidad máxima y a reducciones de gasto por nivel. Un agente de trading con un límite de 50 XRS/tx puede delegar a un sub-agente en profundidad 2 con un límite de 10 XRS/tx. El límite de profundidad evita cadenas de delegación sin fin que podrían desdibujar la responsabilidad.

CapabilityRegistry. Un marketplace on-chain para el descubrimiento de servicios de agentes. Los agentes anuncian capacidades por categoría (trading, liquidez, data_feed, computación), precio por unidad, capacidad concurrente y metadata de región/SLA. Los snapshots de reputación se cachean para ordenar con eficiencia.

TaskBoard. Sistema de bounties on-chain donde quien publica una tarea pone la recompensa en escrow y la finalización la confirma el publicador, verificadores designados o condiciones verificadas por oráculo. Las tareas llevan tags de categoría, requisitos de habilidades y umbrales mínimos de reputación que restringen quién puede reclamarlas. Las verificaciones de expiración de tareas se evalúan en orden de consenso, de forma determinista entre nodos (barrido XWC-62).

Heartbeats y dispositivos. Un registro de liveness de agentes (AgentHeartbeat) mantiene el estado operativo on-chain, y un registro de atestación de hardware registra los dispositivos atestados. El registro de dispositivos lo gestiona el protocolo: no puede alcanzarse mediante llamadas genéricas a contratos ni ser desplegado por usuarios (corrección XWC-65).

7Primitivas criptográficas

XerisCoin usa un stack criptográfico por capas que cubre los requisitos de seguridad actuales y anticipa los modelos de amenazas post-cuánticos.

Firmas híbridas de bloque. Cada header de bloque desde el slot 1 lleva una firma Ed25519 y una firma Dilithium3 (ML-DSA-65, nivel de seguridad NIST 3) sobre un único mensaje canónico, con separación de dominio y vinculado al chain-id. Un bloque es válido solo si ambas verifican. El diseño híbrido es permanente: forjar un bloque requiere romper Ed25519 y el supuesto de lattice a la vez, y no existe un fallback solo clásico al que un adversario pueda degradar.

ZkVerifierRegistry. Almacena claves de verificación Groth16 en la curva BN254 (la misma curva pairing-friendly que usan los precompiles de Ethereum y zkSync). Los envíos de pruebas incluyen metadata y nullifiers. El conjunto de nullifiers previene el doble gasto en protocolos que preservan la privacidad sin revelar el grafo de transacciones. El tamaño de la prueba se registra para estimar tarifas. La verificación está estrictamente acotada: las pruebas están limitadas a 512 bytes, las claves de verificación a 16 KB, las entradas públicas a 64 por prueba, y las codificaciones deben consumir su entrada exactamente (no maleables, corrección XWC-16). Cada bloque puede contener como máximo 64 verificaciones Groth16, aplicado por igual en la validación de consenso y en el productor de bloques (corrección XWC-15), lo que acota el trabajo de pairing en el peor caso por slot de 4 segundos. Los marcadores de atestación PQ auto-declarados se almacenan en un namespace separado de las pruebas verificadas criptográficamente (corrección XWC-64). Las primitivas de transferencia confidencial Schnorr/Pedersen siguen implementadas en el nodo como código de reserva, deshabilitadas en el dispatcher a la espera de una re-habilitación endurecida.

PqKeyRegistry. Mapea claves públicas Ed25519 a claves post-cuánticas Dilithium3 con validación exacta de longitud de clave (claves públicas de 1,952 bytes, corrección XWC-14). La rotación de claves se registra con un contador de rotación y el slot de la última rotación. Cambiar una clave registrada requiere un mensaje de rotación firmado por la clave Dilithium actual, vinculado al chain-id y a un nonce monotónico, de modo que un compromiso solo de Ed25519 no puede sustituir la clave PQ de una víctima (corrección XWC-06). Desde el slot 2 (PQ_REGISTRY_BINDING_ACTIVATION_SLOT), la admisión de bloques requiere que la clave Dilithium inline del header coincida con la entrada del proponente en el registro. Esto se aplica en todas las rutas, incluida la evidencia de slashing (corrección XWC-53), y se reconstruye localmente por fork durante los reorgs (corrección XWC-66). Las estadísticas de adopción PQ en toda la red se mantienen on-chain.

8Arquitectura de red

Los nodos se comunican sobre un protocolo TCP propio identificado por los magic bytes XRS1. El tamaño máximo de mensaje es 5 MB, suficiente para bloques completos a capacidad máxima de transacciones. La red admite hasta 3,000 conexiones de peers por nodo, con protección contra ataques eclipse por subnet que limita las conexiones a 8 peers por subnet /24.

Sincronización basada en snapshots. El ledger produce checkpoints automáticos cada 10,000 bloques, serializando el conjunto completo de balances, el estado de staking y la cola de unbonding. Los nodos nuevos pueden arrancar desde el snapshot más reciente en lugar de reproducir desde génesis, lo que reduce el tiempo de sincronización en proporción a la edad de la cadena.

Fork choice y reorgs. Los forks en competencia se resuelven reproduciendo el historial de transacciones propio de cada fork. El peso del fork se deriva de la distribución de stake reproducida del propio fork y no de la cadena canónica (corrección XWC-04), y el registro de claves post-cuánticas se reconstruye igualmente de forma local al fork durante la evaluación del reorg (corrección XWC-66). Un fork no puede tomar prestada autoridad de un estado que no contiene.

Canales de estado. El contrato StateChannelRegistry permite interacciones off-chain de alta frecuencia con liquidación on-chain. Las partes depositan en un canal, intercambian mensajes firmados off-chain y liquidan el estado final on-chain. Un período de desafío configurable (por defecto 1,000 slots) permite a cualquier parte disputar una liquidación enviada con un estado firmado más reciente.

9Actualizaciones del protocolo y gobernanza

Actualizaciones activadas por slot. XerisCoin evita los hard forks condicionando las nuevas reglas de consenso a números de slot. Cuando se finaliza una actualización del protocolo, el slot de activación se embebe en el binario del nodo. Los bloques anteriores al slot de activación se siguen validando bajo las reglas originales. No hace falta un reinicio coordinado. En la red actual, los ejemplos incluyen las firmas híbridas post-cuánticas (slot 1), la vinculación al registro PQ (slot 2) y el preimage v2 de PoW.

Gobernanza on-chain. El contrato de Gobernanza admite la creación de propuestas, la votación ponderada por stake y el recuento on-chain. Los períodos de votación son configurables con un mínimo impuesto por el protocolo de 21,600 slots (~24 horas), y la aprobación requiere quórum y mayoría del peso de stake votado. Cada staker puede votar una vez por propuesta, ponderado por su stake activo al momento de votar. El resultado de una propuesta aprobada se registra on-chain. La aplicación de parámetros se despliega mediante el mecanismo de actualizaciones activadas por slot descrito arriba. La delegación de votos está planificada pero aún no está activa.

DisputeRegistry. Para decisiones subjetivas que el código por sí solo no puede resolver, el protocolo ofrece arbitraje on-chain. Las partes en disputa depositan bonos y envían evidencia, y validadores autorizados emiten un fallo. Los reembolsos de bonos son idempotentes: una resolución no puede acreditar dos veces a una parte (corrección XWC-69).

AApéndice

A.1 Glosario

A.2 Constantes del protocolo