XerisCoin
Whitepaper Técnico

1Introducción

El panorama actual de L1 se bifurca en dos campos: cadenas de alto rendimiento que sacrifican descentralización por velocidad, y cadenas más lentas de proof-of-work que ofrecen seguridad robusta a costa de programabilidad. Ninguno de los dos campos aborda dos requisitos emergentes que creemos definirán la próxima década de computación on-chain: orquestación nativa de agentes de IA autónomos y tokenización conforme a regulaciones de activos del mundo real con vinculaciones de contratos Ricardianos.

XerisCoin toma un enfoque diferente. En lugar de optimizar para una sola propiedad de consenso, el protocolo apila tres mecanismos — Proof-of-History para ordenamiento local, Proof-of-Work Scrypt para producción de bloques y Proof-of-Stake para elección de líder — en un pipeline que se completa dentro de una ventana de slot de 4 segundos. El resultado es una cadena que sigue siendo minable en hardware comercial (Scrypt es memory-hard y resistente a ASIC con nuestra parametrización), proporciona resistencia económica a Sybil mediante staking y mantiene ordenamiento determinístico de slots sin depender de un reloj externo.

El set de instrucciones se extiende más allá de transferencias y llamadas a contratos para incluir operaciones de primera clase para registro de agentes, delegación jerárquica, oráculos de datos, atestación de hardware y verificación de pruebas de conocimiento cero. Estas no son precompiles añadidas — son variantes nativas de instrucciones procesadas por el mismo runtime que maneja transferencias de tokens, sujetas a contabilidad de tarifas idéntica y 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. Las etapas no son independientes — cada una alimenta restricciones a la siguiente, creando un modelo de seguridad por capas donde un atacante debe comprometer simultáneamente el ordenamiento proof-of-history, la elección de líder ponderada por stake y la minería proof-of-work memory-hard para producir un bloque fraudulento.

2.1Proof-of-History (PoH)

PoH proporciona ordenamiento local encadenando hashes SHA-256 iterativamente, donde cada entrada de hash incluye la salida del cómputo anterior. A diferencia de implementaciones determinísticas de PoH, XerisCoin mezcla entropía de 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. Esta es una decisión de diseño deliberada (documentada como H-1): la cadena PoH se usa estrictamente para asignación local de slots y no puede ser pre-computada por un adversario que no controle el reloj del validador a resolución de nanosegundos. El hash PoW se compromete a la punta de la cadena PoH, vinculando ambas capas.

La salida de PoH determina los límites de los slots. Cada slot mapea a exactamente una oportunidad de bloque. Los validadores usan conteos de tick de PoH para sincronizarse sin requerir paso de mensajes estilo BFT para 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 minería basada en ASIC en relación con hardware de propósito general. Los parámetros de Scrypt se iteraron a través de tres generaciones durante el desarrollo; en la red actual el conjunto de parámetros v1.2 está activo desde génesis (los conjuntos anteriores se conservan en el nodo solo para replay histórico):

Los parámetros v1.2 representan un balance entre dureza de memoria y el timeout de minería de 3.9 segundos que asegura que los bloques se produzcan dentro de la ventana de slot. Un minero que no encuentra un nonce válido dentro de 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), por lo que una solución proof-of-work no puede reutilizarse entre padres o timestamps distintos. Los saltos de slot hacia adelante están además 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) — impidiendo que un proponente adelante artificialmente 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 proporciona ventaja económica al líder electo mientras preserva la liveness de la cadena: si el líder falla en producir 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 un conjunto de validadores elegibles filtrando por cuentas con al menos 1,000 XRS staked. Los validadores elegibles son ordenados por clave pública para consenso entre nodos, luego una selección aleatoria ponderada por stake — sembrada desde 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 sembró la elección de líder desde el hash de PoH, que era susceptible a manipulación ya que PoH se computa localmente. Usar el hash del bloque anterior — que requiere PoW para producir — hace que la predicción del líder dependa de minar el bloque precedente. El sorteo ponderado usa rejection sampling sin sesgo (corrección XWC-42), de modo que ningún validador obtiene ventaja por 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 — es decir, desde 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 permanezca sin estado, y desde el slot 2 debe coincidir con la entrada del proponente en el registro de claves PQ on-chain.

La capacidad de transacciones está limitada a 40,000 por bloque, con cada transacción conteniendo hasta 16 instrucciones, 64 claves de cuenta y 8 KB de datos de instrucción por instrucción. Estos límites estructurales se aplican tanto en la admisión al mempool como nuevamente dentro de la validación de consenso (corrección XWC-15), de modo que 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 de extremo a extremo: cada transacción entrante se sanitiza y debe llevar exactamente su conteo declarado de firmantes (XWC-18), las transacciones sin fondos están limitadas a 10,000 entradas en el pool (XWC-19), las transacciones re-encoladas reingresan con prioridad plana sin boost por longitud de datos (XWC-20), las transacciones de propuestas en vuelo se reservan para prevenir admisión duplicada durante la ventana de minado-commit (XWC-17) y los resultados de admisión se reportan al emisor en lugar de tragarse silenciosamente (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 mapea 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 aplicación explícita de 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 son descartadas del bloque sin ejecución.

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 transacciones que referencian blockhashes más antiguos que 150 slots (~10 minutos). La deduplicación de firmas del lado del servidor con ventanas TTL proporciona una defensa secundaria 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 forzado en runtime de 500,000,000 XRS (MAX_EMISSION_SUPPLY). Las recompensas de minería, staking y atestación se extraen — y están conjuntamente limitadas — por ese único presupuesto de emisión de 500M, de modo que ninguna combinación de flujos de recompensas puede empujar el supply total más allá de 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 rastrea 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 de 7%. Solo las cuentas con un mínimo de 100 XRS staked son elegibles. Las recompensas se acumulan al balance líquido — no se auto-componen, requiriendo re-staking explícito para componer.

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 vía agotamiento de cola. Durante el unbonding, los tokens no ganan recompensas de staking y no cuentan hacia el peso de elección de líder — pero permanecen sujetos a slashing durante todo el período de unbonding (ver §4.3).

La atestación de light client proporciona una recompensa adicional de 0.01 XRS por prueba válida, reclamable dentro de una ventana de 200 slots (~13 minutos) después de la creación del bloque. Los atestadores deben tener al menos 100 XRS staked, están limitados a una recompensa cada 10 bloques y las atestaciones se deduplican por (block_slot, validator_pubkey) para prevenir doble reclamación. Estas recompensas también cuentan contra el 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 — es castigable con slashing. Cualquiera puede enviar evidencia vía la instrucción SlashReport: dos headers canónicamente firmados 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), de modo que la evidencia nunca puede forjarse a partir de headers que la propia 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) vía la instrucción ContractDeploy e invocadas vía ContractCall. Los contratos no son bytecode arbitrario — son instancias parametrizadas de tipos definidos por el protocolo. Esto elimina por construcción una clase entera de vulnerabilidades de contratos inteligentes (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 manipulación del ratio de precio inicial vía depósitos de polvo. 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 creación de nuevos tokens. El creador recibe una recompensa fija de 1% (100 bps) y el protocolo recolecta 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 vía agentes delegados u órdenes condicionales se rechaza (corrección XWC-07). Los controles de vesting — períodos de cliff, porcentajes de desbloqueo diario y restricciones de venta máxima, todos computados en milisegundos (corrección XWC-70) — están embebidos en los parámetros de lanzamiento para prevenir dumping inmediato.

LimitOrder / DcaOrder. Órdenes permanentes que escrow el token de entrada y se ejecutan cuando un keeper confirma que la tasa objetivo se ha alcanzado. Las órdenes limit soportan una tarifa de keeper configurable (por defecto 10 bps). Las órdenes DCA extienden esto con ejecución basada en intervalos — cada tick es ejecutado independientemente por keeper, soportando estrategias como acumulación diaria sobre 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, resistiendo manipulación de precio en un solo bloque (corrección XWC-63). Las órdenes disparadas y expiradas se ejecutan en un orden canónico determinístico en todos los nodos (corrección XWC-62), la liquidación del escrow es atómica — una orden nunca se marca ejecutada a menos que sea completamente financiable (corrección XWC-08) — y las órdenes auto-expiran después de un slot especificado, reembolsando el balance escrowed al cancelar.

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:

Las transferencias de tokens RWA están restringidas a direcciones en la whitelist de cumplimiento, forzadas a nivel del runtime — no por convención. El campo de jurisdicción permite que el tooling downstream aplique lógica regulatoria específica de la localidad sin modificar el protocolo base. El historial de distribución se mantiene on-chain para rastreo auditable de procedencia.

6Protocolo XERIS ARI

El protocolo Autonomous Runtime Infrastructure (ARI) proporciona soporte on-chain de primera clase para la operación de agentes de IA. En lugar de tratar a los agentes como cuentas opacas controladas externamente, ARI crea una jerarquía de delegación forzada por el protocolo con controles de gasto, whitelists de operaciones e interruptores de emergencia.

AgentRegistry. Un dueño registra un agente vía 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 el agente puede ejecutar. El dueño retiene un interruptor de emergencia unilateral que revoca inmediatamente toda autoridad delegada. Las métricas de vida (total de transacciones, total gastado) se rastrean on-chain.

IdentityRegistry. Identidad persistente para agentes y dispositivos con puntuación de reputación categórica. Las identidades soportan adjuntos de credenciales, 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 rastrea independientemente de su reputación en "precisión de datos".

SubDelegate. Los agentes pueden delegar autoridad a sub-agentes, sujeto a restricciones de profundidad máxima y 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 previene cadenas de delegación sin límite que podrían oscurecer la responsabilidad.

CapabilityRegistry. Un marketplace on-chain para descubrimiento de servicios de agentes. Los agentes publicitan capacidades por categoría (trading, liquidez, feed_de_datos, computación), precio por unidad, capacidad concurrente y metadata de región/SLA. Los snapshots de reputación se cachean para ordenamiento eficiente. Esto habilita un ecosistema componible donde los agentes pueden descubrir y transaccionar con los servicios de otros agentes programáticamente.

TaskBoard. Sistema de bounties on-chain donde los publicadores de tareas ponen recompensas en escrow y la finalización es confirmada por el publicador, verificadores designados o condiciones verificadas por oráculo. Las tareas tienen 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, determinísticamente entre nodos (barrido XWC-62).

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

7Primitivas Criptográficas

XerisCoin emplea un stack criptográfico por capas diseñado para los requisitos de seguridad actuales y compatibilidad futura con modelos de amenazas post-cuánticos.

Firmas híbridas de bloque. Cada header de bloque en o después del slot 1 lleva tanto una firma Ed25519 como 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. Este es un diseño híbrido permanente, no una transición: forjar un bloque requiere romper Ed25519 y el supuesto de lattice simultáneamente, 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 usada por los precompiles de Ethereum y zkSync). Los envíos de pruebas incluyen metadata y nullifiers — el conjunto de nullifiers previene doble gasto en protocolos preservadores de privacidad sin revelar el grafo de transacciones. El tamaño de la prueba se rastrea para estimación de 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, las codificaciones deben consumir su entrada exactamente (no maleables, corrección XWC-16), y cada bloque puede contener como máximo 64 verificaciones Groth16 — aplicado idénticamente por la validación de consenso y el productor de bloques (corrección XWC-15) — acotando 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 permanecen 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 rastrea con un contador de rotación y slot de última rotación, y 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 — 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 — aplicado en toda vía incluyendo evidencia de slashing (corrección XWC-53) y reconstruido localmente por fork durante 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 personalizado identificado por los magic bytes XRS1. El tamaño máximo de mensaje es 5 MB, acomodando bloques completos a capacidad de transacciones pico. La red soporta hasta 3,000 conexiones de peers por nodo, con protección contra ataques de eclipse basada en subnet limitando 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, estado de staking y cola de unbonding. Nuevos nodos pueden comenzar desde el snapshot más reciente en lugar de reproducir desde génesis, reduciendo el tiempo de sincronización proporcionalmente 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), de modo que un fork no puede tomar prestada autoridad de un estado que él mismo no contiene.

Canales de estado. El contrato StateChannelRegistry habilita 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 hard forks restringiendo nuevas reglas de consenso a números de slot. Cuando una actualización del protocolo se finaliza, el slot de activación se embebe en el binario del nodo. Los bloques antes del slot de activación continúan validándose bajo las reglas originales, preservando la integridad del ledger sin requerir reinicios coordinados. En la red actual, los ejemplos incluyen firmas híbridas post-cuánticas (slot 1), vinculación al registro PQ (slot 2) y el preimage v2 de PoW.

Gobernanza on-chain. El contrato de Gobernanza soporta creación de propuestas, votación ponderada por stake y conteo on-chain. Los períodos de votación son configurables con un mínimo forzado por el protocolo de 21,600 slots (~24 horas), y la aprobación requiere tanto quórum como 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 activa.

DisputeRegistry. Para decisiones subjetivas que no pueden ser resueltas solo por código, el protocolo proporciona un mecanismo de arbitraje on-chain. Las partes en disputa publican bonos, envían evidencia y un fallo es emitido por validadores autorizados. Los reembolsos de bonos son idempotentes — una resolución nunca puede acreditar dos veces a una parte (corrección XWC-69).

AApéndice

A.1 — Glosario

A.2 — Constantes del Protocolo