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 subsec_nanos() 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 sistema del validador a resolución de nanosegundos.

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. El protocolo ha evolucionado los parámetros de Scrypt a través de tres épocas:

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.

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 y un bloque propuesto dentro de los últimos 100 slots (la ventana de actividad). Los validadores elegibles son ordenados por clave pública para consenso entre nodos, luego una selección aleatoria ponderada usando el hash del bloque anterior como entropía 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.

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.

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. 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, reemplazando un escaneo O(n) anterior).

3.1Set de Instrucciones

XerisCoin define un set de instrucciones tipado vía el enum XerisInstruction. Cada variante mapea a una operación específica procesada por el runtime. El legacy SystemInstruction::Transfer compatible con Solana fue retirado en el slot 1,052,200 a favor de la variante nativa NativeTransfer con aplicación explícita de firmante.

3.2Modelo de Tarifas y Protección contra Replay

Las tarifas de transacción se activan en el slot 1,030,000. 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 de emisión duro de 700,000,000 tokens. El supply está particionado entre una pre-asignación de tesorería y emisiones de minería, con las recompensas de staking y atestación contadas contra el mismo tope.

4.1Cronograma de Emisión

La recompensa base de bloque es 342.5 XRS, halving cada 730,000 bloques. A 4 segundos por slot, cada época de halving abarca aproximadamente 34 días. La fórmula de halving usa aritmética de desplazamiento de bits con protección contra overflow:

El supply de emisión restante se rastrea en runtime. Cuando el supply minado acumulado se aproxima al tope 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.

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 (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.

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. Las atestaciones se deduplican por (block_slot, validator_pubkey) para prevenir doble reclamación. Estas recompensas también cuentan contra el tope de emisión de 700M (L-10).

5Sistema de Contratos Inteligentes

XerisCoin define 25 primitivas de contrato tipadas desplegadas 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.

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.777% (77 bps). Cuando la curva de bonding alcanza su umbral objetivo de liquidez, el contrato finaliza automáticamente desplegando un pool Swap con la liquidez acumulada. Los controles de vesting — incluyendo períodos de cliff, porcentajes de desbloqueo diario y restricciones de venta — 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). Las órdenes auto-expiran después de un slot especificado y reembolsan 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 escrow recompensas, los reclamantes apuestan reputación y los verificadores (o condiciones verificadas por oráculo) confirman finalización. Las tareas tienen tags de categoría, requisitos de habilidades y umbrales mínimos de reputación. Las recompensas escrowed cuentan contra el tope de emisión.

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.

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.

PqKeyRegistry. Mapea claves públicas Ed25519 a claves post-cuánticas CRYSTALS-Dilithium al nivel de seguridad de 128 bits. La rotación de claves se rastrea con un contador de rotación y slot de última rotación. Las estadísticas de adopción PQ en toda la red se mantienen para monitorear el progreso de migración. Este registro habilita una vía de migración gradual: los usuarios que registren claves PQ pueden opcionalmente proporcionar firmas duales (Ed25519 + Dilithium) durante el período de transición, con el protocolo forzando firmas solo-PQ después de un slot de activación especificado por gobernanza.

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.

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. Ejemplos incluyen activación de tarifas (slot 1,030,000), retiro de transferencias legacy (slot 1,052,200) y Scrypt v1.2 (slot 1,052,478).

Gobernanza on-chain. El contrato de Gobernanza soporta creación de propuestas, votación ponderada por tokens y ejecución on-chain. Las propuestas requieren un stake mínimo para enviar, períodos de votación configurables y umbrales de quórum. La delegación de votos es soportada — un staker puede delegar su peso de voto a otra dirección sin transferir tokens. Los locks de gobernanza rastrean el monto bloqueado por dirección para prevenir doble votación.

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 se emite un fallo (por árbitros designados o voto de gobernanza). Los bonos se redistribuyen según el resultado del fallo.

AApéndice

A.1 — Glosario

A.2 — Constantes del Protocolo