Entorno principal de contratos inteligentes
NexusWASM es el entorno principal de contratos inteligentes de Orbitra L1. Los contratos se compilan desde Rust, C/C++ y otras cadenas de herramientas modernas a WebAssembly, se ejecutan en un entorno aislado determinista y solo alcanzan activos, estado y módulos de mercado a través de las capacidades que se les conceden. El cómputo y el almacenamiento se tarifican de forma explícita, y el acceso declarado al estado permite que VectorLanes ejecute contratos no relacionados en paralelo.
Cómo funciona
Capacidades
Cómputo medido
Almacenamiento medido
La ilustración muestra un contrato de NexusWASM sellado dentro de un entorno aislado. A su alrededor solo se sitúan las capacidades que declaró, entre ellas los módulos nativos de mercado; nada más es alcanzable. Dos medidores registran el cómputo y el almacenamiento por separado mientras se ejecuta la llamada, y el acceso al estado declarado por el contrato pasa al planificador, que lo ejecuta en paralelo con trabajo no relacionado.
El problema
En muchos entornos de contratos, cada contrato posee una autoridad ambiental. Puede llamar a cualquier otro contrato, mover cualquier activo que controle y tocar estado que nunca declaró. Ese modelo es fácil para empezar y difícil de proteger: una sola vía de llamada inesperada puede convertir un defecto pequeño en una tesorería vaciada, y revisar un solo contrato exige razonar sobre todo lo que podría alcanzar.
Esa apertura también limita el rendimiento. Un entorno de ejecución que no puede saber de antemano qué estado tocará una transacción debe ejecutar las transacciones una tras otra, o ejecutarlas de forma especulativa y revertirlas en caso de conflicto. La tarificación a menudo funde el cómputo, el almacenamiento y el crecimiento del estado a largo plazo en una unidad abstracta, de modo que el coste duradero del estado queda mal reflejado en lo que paga una transacción.
NexusWASM parte de los supuestos opuestos. La autoridad se concede, no es ambiental. El acceso al estado se declara, no se descubre. El cómputo y el almacenamiento se miden y se tarifican por separado. Las aplicaciones pueden así llamar a infraestructura de mercado real —los libros de órdenes de ApexMatch, las comprobaciones de riesgo de Aegis, los precios de Prism— sin heredar los riesgos de un modelo de ejecución abierto.
Secuencia operativa
Todo contrato —un enrutador de pagos, un registro de activos, la tesorería de un agente— sigue la misma ruta desde el compilador hasta la finalidad.
Rust, C/C++ u otro lenguaje que compile a WebAssembly se compila frente a las interfaces de NexusSDK, produciendo el módulo y un manifiesto de las capacidades que solicita.
Antes de que un módulo pueda ejecutarse, la red lo comprueba: solo se aceptan instrucciones deterministas, cada importación debe coincidir con una capacidad declarada, y los límites de recursos se registran junto al hash del código.
Cada capacidad solicitada —mantener un activo, llamar a un módulo de mercado, leer un feed de precios, invocar otro contrato— se vincula a la dirección del contrato. Lo que no se concede simplemente no existe para el contrato.
Toda transacción enumera el estado que va a leer y a escribir. El planificador determinista utiliza estos conjuntos para situar en carriles paralelos las transacciones que no entran en conflicto.
El módulo se ejecuta en un entorno aislado y medido. El cómputo se cobra a medida que se ejecutan las instrucciones, y el almacenamiento a medida que el estado se escribe y se conserva; cualquier acceso fuera de los conjuntos declarados aborta la llamada y revierte sus efectos.
Los resultados se confirman junto con las demás transiciones del bloque y adquieren carácter definitivo cuando un cuórum de QSE los certifica.
Arquitectura
NexusWASM separa lo que un contrato calcula de lo que se le permite alcanzar.
Ejecuta WebAssembly bajo reglas que dan a todos los validadores el mismo resultado. Todo lo que podría diferir entre máquinas —relojes, aleatoriedad, comportamiento numérico específico del host— queda excluido o lo aporta el protocolo como una entrada determinista.
El único puente entre un contrato y el resto de la red. Las funciones del host para activos, almacenamiento, identidad y módulos de mercado se exponen por capacidad, y cada llamada se comprueba frente a las concesiones del contrato.
Cuenta el cómputo a medida que se ejecutan las instrucciones y el almacenamiento a medida que el estado se escribe y se conserva, con un precio distinto para cada uno. Los límites por llamada impiden que un solo contrato monopolice un carril.
Convierte las lecturas y escrituras declaradas de cada transacción en un mapa de conflictos para el planificador determinista, de modo que los contratos independientes se ejecutan en carriles separados mientras los dependientes se ordenan.
Interfaces tipadas hacia ApexMatch, Aegis y Prism. Un contrato puede colocar una orden, solicitar una evaluación de riesgo o leer un precio con puntuación de confianza dentro de la misma transición que su propia lógica.
Los cambios de código son transiciones explícitas y versionadas bajo una política fijada en el despliegue: inmutable, con retardo temporal o sujeta a aprobación multiparte, por ejemplo. Cada versión conserva su hash de código y su manifiesto de capacidades.
Seguridad y control de fallos
NexusWASM mantiene un defecto dentro del contrato que lo contiene, y aplica ese límite en el propio entorno de ejecución, no por convención.
En los tres sistemas
Orbitra Prime
Inteligencia de negociación
Cuando una estrategia, una bóveda o un flujo de trabajo estructurado necesita lógica en cadena, se ejecuta como un contrato de NexusWASM y opera a través de las mismas vías de ApexMatch y Aegis que una orden colocada en Orbitra Prime.
Orbitra L1
Liquidación y cómputo
NexusWASM es el entorno de ejecución de contratos de la capa de ejecución de Orbitra L1. Se ejecuta sobre VectorLanes, se confirma en el estado compartido y entrega los resultados a QSE para su finalidad. EVM Capsule se sitúa junto a él como un dominio de compatibilidad aislado, nunca en su lugar.
Orbitra Realm
Aplicaciones y comercio
Las aplicaciones de Orbitra Realm —pagos, tokenización, juegos, servicios de agentes— se ejecutan de forma nativa como contratos de NexusWASM, compartiendo identidad, activos y liquidez con el resto de la red a través de las primitivas de NexusSDK y los permisos de VaultID.
Valor
Especificaciones
Terminología