Ensamblado fuera de la cadena.
Verificado en paralelo.
Confirmado en orden.
Toda blockchain grande obliga a cada nodo a reejecutar cada transacción contra un estado global. Zycord saca la ejecución fuera de la cadena: un pago lo construye el monedero, una llamada a un contrato la ejecuta el secuenciador del contrato a partir del intent firmado del usuario, y en ambos casos el resultado llega completo con todo lo que leyó y escribió. Cualquier máquina lo comprueba solo a partir de los bytes, y un único bucle lo confirma — o lo omite, y se lo factura a quien depositó por él.
La transacción es un certificado
No pide “ejecuta esto”. Declara “leí esto, escribí aquello, y aquí está la prueba”. Cualquiera recalcula y compara.
program sobre los reads produce exactamente los writes, y el deposit cubre el peor caso. Sin disco, sin historia.reads declarados siguen cumpliéndose cuando al certificado le llega su turno en el bloque?Dos verbos, dos etapas
Todo el diseño consiste en separar estas dos preguntas — y responder cada una en el lugar más barato.
¿Es válido?
Se responde mirando solo el certificado. Miles a la vez, en cualquier máquina.
- Las firmas Ed25519 estrictas cuadran
- La reejecución coincide con los writes
- El depósito cubre el peor caso
- Inválido: nunca entra en un bloque honesto
¿Es aplicable?
Se responde en la posición del certificado dentro del bloque, comparando bytes contra la tabla de estado.
- Los reads siguen cumpliéndose → los writes se confirman
- Read obsoleto o desbordamiento → omisión, el depositante paga una comisión fija
- Depósito sin fondos o gastado → descartado, no se cobra nada
- El bloque sigue siendo válido en todos los casos
Cuatro resultados, y quién paga
Un problema con un certificado es un resultado, nunca un motivo para rechazar el bloque. Cada resultado se carga a una parte que eligió el riesgo, y una firma se cobra como mucho una vez.
Aplicado
Toda lectura declarada se cumple, así que los writes se registran y la comisión se liquida al coste real: la comisión base se quema y la comisión de prioridad se paga al productor.
Omitido
Una lectura ya no se cumple, o un delta saldría del rango de 256 bits. No se escribe nada. Se quema del depósito una comisión de omisión fija de 0,01 ZCD y el resto se devuelve. El id se marca como visto, así que ningún productor puede volver a incluirlo.
Descartado
La celda de depósito no tiene fondos o ya está gastada, así que no hay nada que cobrar. El certificado se transporta pero no se cobra, y no se marca como visto.
El usuario nunca paga una omisión
El depositante eligió las lecturas, así que el depositante responde por ellas. En un fill, ese es un secuenciador: el que se declaró para el contrato cuya lectura falló, o en otro caso aquel cuyo depósito nombra el fill. El pago del usuario a cada secuenciador se liquida solo cuando el fill se aplica. Los fallos a los que no hay nadie a quien cargar — un fill fuera del orden del pipeline, un fence que se ha movido, un certificado forzado cuyas lecturas no se cumplen — hacen inválido el bloque en su lugar, porque el productor era quien podía haberlo sabido.
El recorrido, del nacimiento al libro mayor
El monedero construye un pago, o firma un intent
Un pago no necesita servidor: el monedero pone una guarda sobre una celda de un solo uso que posee, la debita, la marca como gastada, acredita la dirección nueva del beneficiario y envía el cambio a una nueva propia. Una llamada a un contrato secuenciado es en cambio un intent firmado: qué llamar, límites sobre el resultado, lo que se paga al secuenciador y los pagadores de un solo uso que lo financian.
El secuenciador ejecuta y confirma
Ejecuta el intent sobre su propia vista — la punta de la cadena más cada fill que ya ha construido —, responde con un recibo firmado en milisegundos y publica el resultado como un fill depositado desde su propio saldo. Una llamada que cruza contratos vinculados a distintos secuenciadores la cofirma cada uno y llega como un único fill atómico.
Cada nodo verifica en paralelo
Cada certificado se comprueba a partir de sus bytes al llegar, antes de retransmitirlo: firmas, reejecución contra los reads declarados, el depósito. Sin estado, sin historia, cualquier núcleo, cualquier máquina.
El productor ordena
Un minero de proof of work elige certificados válidos y resuelve el bloque; tras la transición a proof of stake, en su lugar lo firma el staker sorteado para el slot. No ejecuta nada de lo que recibe y recuerda los ids vistos dentro de la ventana del TTL, porque incluir uno dos veces hace inválido el bloque. Al final de su bloque puede ejecutar intents abiertos del camino forzado.
Fold secuencial
Primero los fills, en el orden del pipeline; luego todos los demás certificados por (deposit address, seq, id); luego los certificados forzados por id. El productor no elige nada de ello. Para cada certificado: ¿siguen cumpliéndose los reads declarados?
Estado: celdas, direcciones, acceso tipado
Una celda es un entero de 256 bits en un slot. Las celdas ausentes se leen como cero. La concurrencia no se descubre en tiempo de ejecución: se declara, slot a slot.
Direcciones de un solo uso y persistentes
Una dirección de un solo uso se gasta una vez: el certificado que la debita la marca como gastada, para siempre. Los monederos dan a cada pago entrante una nueva, que es el camino sin contención. Una dirección persistente es reutilizable — una cuenta — y es donde deben ir las recompensas de minería: una dirección de un solo uso quema todas las recompensas que guarda en cuanto se gasta, así que el nodo rechaza una como dirección de pago. Los contratos tienen su propio tipo de dirección, por el que ninguna clave puede firmar.
Activos nativos, sin máquina
Desde el bloque 0: TRANSFER de hasta 32 movimientos, ISSUE con un tope de suministro, MINT con guarda sobre ese tope, RETIRE de hasta 64 direcciones de un solo uso. Un crédito a una celda nueva es la propina. Diez mil propinas en un bloque son diez mil sumas: cero conflictos, sin secuenciador, sin máquina.
La máquina y sus secuenciadores
Los deltas con guarda disuelven la contención de los pagos. Lo que queda es lógica que debe leer el estado exacto para decidir qué escribir — un libro de órdenes, un creador de mercado — y ahí el contrato elige su serializador.
La cEVM
Un dialecto de la máquina virtual de Ethereum, de modo que Solidity, sus compiladores y sus auditores se trasladan. El almacenamiento se declara: SLOAD y SSTORE son exactos, y seis opcodes nuevos dan la disciplina con guarda y conmutativa. NUMBER y TIMESTAMP leen la baliza de época, constante durante un día; los opcodes sin nada a lo que referirse se eliminan. El código viaja en el certificado. Un token, un bote de propinas y un escrow, escritos con deltas primero, están predesplegados cuando se abre la máquina.
Secuenciado o abierto
El registro de cada contrato nombra una clave de secuenciador. Si no es cero, el camino exacto del contrato necesita la firma de esa clave; si es cero, cualquiera puede tomarlo y el contrato solo está protegido por su código. Los deltas con guarda nunca están restringidos: un token secuenciado sigue aceptando cada transferencia de cualquiera. Un directorio indica dónde responde cada secuenciador — descubrimiento, no autorización.
Intents, fills, recibos
El intent es toda la autorización del usuario, válida durante una ventana de como máximo 8 bloques: el secuenciador puede cambiar cuándo se ejecuta, nunca lo que hace. El id del fill es el hash del intent, así que dos fills de un mismo intent comparten id y solo uno puede cobrarse. Un recibo es una preconfirmación, la promesa del secuenciador hasta que el fill se aplica; dos recibos que se contradicen son una prueba que cualquiera puede comprobar a partir de los bytes, y los usuarios se marchan.
Pipelines, el fence, la cosecuenciación
La cadena guarda el último seq aplicado para cada secuenciador y contrato, y un fill solo entra en el siguiente, así que un pipeline se confirma en el orden en que lo firmó su secuenciador. Cada contrato guarda además un contador fence: un certificado forzado que fija su estado, o un cambio de secuenciador, lo mueve, y ningún fill construido sobre el estado sorteado puede entrar — no se cobra a nadie, y el secuenciador reconstruye. Una llamada entre secuenciadores es un único fill con la firma de cada secuenciador, atómico por construcción.
El camino forzado: la inclusión es la aplicación
Un contrato cuya única puerta es su secuenciador sería una cárcel si el secuenciador censurara, cobrara de más o desapareciera. Cada usuario tiene una puerta lenta que no necesita el permiso de nadie.
Cada bloque se pliega en tres clases, en un orden que el productor no elige
El usuario firma un intent abierto — un intent sin secuenciador nombrado, financiado por los propios pagadores de un solo uso del usuario — y lo retransmite a la red. El productor, que tiene el estado al final de su bloque, ejecuta los intents abiertos que elige contra ese estado y añade los resultados como los últimos certificados del bloque. No hay cola, arrendamiento, cuota ni plazo. El pago del intent cubre las comisiones, así que el productor gana lo que ganaría un secuenciador.
Una llamada fallida igualmente entra
Una llamada forzada que revierte, rompe sus límites o se queda sin gas entra como FORCED_FAILED: sus pagadores pagan, no se escribe nada más. Quien retransmite intents que no pueden tener éxito paga por cada uno, así que no puede dejar sin espacio a uno correcto.
Mueve el fence
Un certificado forzado que fija una celda del estado de un contrato hace avanzar el contador fence de ese contrato, así que cada fill construido sobre el estado que sorteó se reconstruye. Uno que solo lee, pone guardas o suma deltas deja el fence intacto, igual que uno que falla. El secuenciador pierde latencia, nada más.
Acotado por construcción
Como máximo 16 certificados forzados por bloque, cada uno con como máximo 4.000 unidades de derivación de presupuesto paralelo (200.000 de gas de la máquina): como mucho un tercio del techo paralelo de génesis. La regla para los autores de contratos es que una retirada quepa en ese presupuesto.
Quién hace qué
Ningún rol es necesario para la seguridad. Si todos los secuenciadores desaparecen, los contratos siguen vivos mediante sus métodos de delta y el camino forzado, por el que los usuarios retiran fondos y un contrato puede vincularse a un nuevo secuenciador.
Monedero
- Hace
- Construye pagos como certificados; firma intents para contratos
- Ve
- El estado público que necesita leer
- Confía en
- Nadie
Secuenciador
- Hace
- Ejecuta intents para sus contratos, firma recibos, publica fills
- Se confía en él para
- Solo la disponibilidad. Si miente, su fill se omite y paga su propio depósito
- Captura
- El flujo de órdenes de su propia aplicación, explícitamente
Nodo verificador
- Hace
- Comprueba cada certificado a partir de sus bytes, retransmite, sincroniza
- Necesita
- Núcleos. Estado solo para ejecutar el fold
- Coste
- La verificación se reparte entre todos los núcleos que tiene; el fold es un bucle sobre la memoria
Productor de bloques
- Hace
- Mina con RandomX, ordena certificados válidos, ejecuta intents abiertos al final de su bloque
- Ve
- Bytes y estado, no significado
- Gana
- El 94% del subsidio, más las comisiones de prioridad de lo que se aplica
Camino forzado
- Hace
- Una puerta sin permisos: un intent abierto, ejecutado por el productor
- Coste
- El precio forzado cada vez, y latencia
- Garantiza
- Que ningún operador sea una prisión
La red: dos mercados de gas
Una cadena que cobra todo en una sola subasta hace que la verificación de una prueba compita con una escritura de estado. Aquí cada recurso tiene su propio precio.
Gas paralelo
Paga la verificación: firmas, bytes, unidades de derivación — pruebas pesadas, esquemas poscuánticos.
Gas secuencial
Paga el fold: lecturas, escrituras, inserciones en el registro de gastadas, inserciones en el conjunto de vistos. El único bucle que cada nodo ejecuta en orden.
Solo paga lo que se aplica, y solo lo que se aplica mueve el precio
La comisión base se quema y la comisión de prioridad paga al productor, en los certificados que se aplican y solo en esos; la comisión de un certificado omitido se quema íntegra. Si una omisión pagara al productor, quien ensambla el bloque se beneficiaría de organizar los fallos de otros. Quemarla lo invierte: una omisión ocupa espacio y no gana nada. Y solo el gas aplicado mueve las comisiones base, así que llenar bloques con certificados que entran en conflicto entre sí no puede expulsar a nadie por precio.
Eras: lo que funciona hoy, y lo que viene después
Una era es una altura compilada en una versión, o una condición medida en la cadena. Un bloque por debajo de una puerta que lleva lo que esa puerta habilita es inválido; una era nueva nunca cambia lo que significa un bloque anterior.
Era 0 — minar y pagar
Activa desde el bloque 0, 7 de octubre de 2026. Proof of work bajo las reglas de Nakamoto, activos nativos, direcciones de un solo uso y persistentes, los dos mercados de comisiones, el reparto del subsidio 94/3/3 y la tesorería, que acumula y que ningún certificado puede debitar; una vía de gasto, si llega a haberla, vendrá con una actualización posterior, no antes de la altura 259.200.
Era 1 — la máquina
Altura 80.640, hacia el 4 de noviembre de 2026, en el binario de lanzamiento. La cEVM y su biblioteca estándar, registros de contrato con secuenciador y administrador, intents, fills y cosecuenciación, el directorio y el camino forzado.
Era 2 — proof of stake
Las fianzas se abren en la época 182, hacia el 7 de abril de 2027: el stake se pone en fianza, se retira de ella o se delega en una pool, desde una fianza mínima de 1.000 ZCD. Una vez que el stake activo mantiene el 10% del suministro durante 30 épocas, y a más tardar desde la época 273, empieza una rampa de 90 épocas: los bloques siguen minándose, cada uno firmado además por un staker sorteado por stake, que se lleva k/180 de la parte del productor. Su propia versión, mediante hard fork.
La transición
El primer bloque de la época posterior a la 90.ª que supera la compuerta — el 90% de sus bloques firmados, un stake activo de al menos el 10% del suministro. La minería termina; el staker sorteado firma cada slot de 5 segundos, y una época de 17.280 slots paga lo que antes pagaba un día. Un bloque es definitivo por profundidad, 120 bloques o 10 minutos. Solo se castiga la doble firma, y nunca a un delegador.
Más allá de la verificación completa
Una dirección, no una especificación. Cuando el volumen diario se acerque a lo que verifica un nodo corriente, una era posterior podrá sortear un subconjunto de stakes para verificar cada certificado en lugar de hacerlo todos los nodos, mientras el estado y el fold siguen siendo uno y todo certificado sigue siendo atómico. Hasta entonces, cada nodo lo verifica todo.
La red vista desde arriba
Cuatro capas que no se solapan: quién construye, quién verifica, quién ordena y la puerta que nadie puede cerrar. Cada una escala con un recurso distinto.
Monederos y secuenciadores
Web2 corriente: websockets, colas, autoescalado. Los monederos construyen los pagos por sí mismos; los secuenciadores ejecutan intents y responden en milisegundos. Se confía en ellos para la disponibilidad, nunca para la seguridad, y nunca son custodios de datos — el estado siempre puede reconstruirse solo a partir de la cadena.
Retransmisión y verificación
Cada nodo comprueba cada certificado a partir de sus bytes antes de retransmitirlo. Los bloques viajan como una cabecera más una lista de hashes que el receptor en su mayoría ya tiene; los cuerpos son datos de la cadena. Un nodo se sincroniza hacia el trabajo más verificado, no hacia la mayor altura declarada.
Productor y fold
Un minero de proof of work ordena certificados y resuelve el bloque o, tras la transición a proof of stake, el staker sorteado para el slot lo firma; cada nodo ejecuta el fold, que compara, suma y escribe. El orden del fold lo fijan las reglas, así que la única elección del productor es qué incluir.
El camino forzado
Intents abiertos, ejecutados por el productor al final de su bloque. La inclusión es la aplicación — el mecanismo que hace que la red sobreviva a cualquier operador, incluido el autor.