Nexus coprocessors are specialized, enshrined execution engines that live inside NexusCore, the high-performance half of Nexus’s dual execution layer. Each coprocessor is an independent state machine with deterministic logic and dual interfaces:
Native APIs for high-frequency trading (HFT) and data-rich integrations
EVM precompiles for onchain composability
Combined with a dual-block architecture — a system with fast Core blocks at <200ms latency and slower EVM blocks — coprocessors deliver centralized exchange-like performance without sacrificing the programmability and composability of the EVM.
The Nexus Exchange, a central limit order book (CLOB) perpetuals engine, is the first coprocessor in the Nexus Layer 1, demonstrating that L1-native financial applications can be both fast and programmable with shared security and shared liquidity.
Over time, NexusCore will grow to host a catalog of L1-native engines (lending, vaults, oracles, RWAs, stablecoin, gas, bridging, etc.) that compose atomically with EVM contracts.
What this means for builders: bring novel strategies, markets, and products to an L1 designed to give your application powerful economic flywheels and access to high-frequency financial infrastructure. For traders and market makers: migrate to trade on Nexus with familiar CEX-like APIs. For researchers and partners: help define the next coprocessors to enshrine via upgrades to the Layer 1.
The performance/programmability trade-off
Most blockchains force builders into a difficult trade-off. Traditional L1s with single virtual machines offer rich programmability, but their limited throughput and high latencies — ranging from hundreds of milliseconds to several seconds — make them unsuitable for real-time functions like matching, risk checks, and liquidations.
On the other hand, app-chains provide tuned performance for specific domains, yet at the cost of fragmented liquidity, duplicated infrastructure, and weakened composability with the broader ecosystem.
This binary choice has effectively kept high-frequency, institutional-grade finance either siloed or entirely off-chain.
Unlocking its full potential requires a different approach: one that offers a high-frequency execution substrate for financial primitives; a general-purpose environment for rich logic, governance, and composability; and a mechanism to keep the two synchronized, atomic, and safe.
Figure 1: Nexus layered architecture with dual execution (EVM + Core and enshrined zk scalability.
The Nexus approach: dual execution with enshrined coprocessors
Nexus reimagines the execution layer by splitting it into two tightly synchronized environments.
The first, NexusEVM, supports general-purpose, Ethereum-compatible smart contracts and ensures composability with the broader ecosystem.
The second, NexusCore, is purpose-built for high-performance financial primitives, implemented as enshrined coprocessors designed to deliver deterministic speed and CeFi-like throughput.
Figure 2: Dual execution environments running in parallel.
For this, Nexus introduces a specialized dual-block blockchain architecture. Core blocks execute continuously at high frequency, targeting sub-200 millisecond confirmation times. EVM blocks, by contrast, execute on a fixed cadence — every N Core blocks — providing a steady rhythm for application logic, governance and interactions with NexusCore.
Crucially, cross-core messaging between these environments is both atomic and deterministic. This ensures that multi-core transactions either succeed entirely or revert in full, preserving system integrity and developer confidence.
The result is a unified L1 that combines CEX-like latency for financial operations with full EVM composability — without fragmenting liquidity or compromising the developer experience.
Figure 3: Core runs at high frequency; EVM executes on a fixed cadence.
What is a coprocessor?
A Nexus coprocessor is an enshrined, deterministic execution engine that runs within NexusCore. It operates with explicit state, functions as a pure and total machine, and exposes a well-defined I/O layer. In practical terms, this design introduces several foundational principles.
Each coprocessor maintains an independent state machine, with its own state schema and invariants, fully decoupled from other coprocessors. This separation allows for clean modularity and domain-specific correctness.
The execution model is strictly deterministic: operations are defined as pure functions over inputs and state. This structure not only ensures reliable reproducibility but also enables safe parallelism while preserving schedule-equivalence.
Each coprocessor exposes dual interfaces to serve both off-chain and onchain actors. Off-chain users and high-frequency trading systems interact via native APIs — REST, WebSocket, or CCXT-style interfaces — enabling CEX-like trading patterns and direct access to real-time data. Onchain smart contracts, meanwhile, can call coprocessor functions through EVM precompiles, allowing these interactions to occur within atomic, verifiable transactions.
To maintain predictable performance, Nexus enforces resource isolation at the validator level. Each coprocessor is allocated dedicated CPU and memory, ensuring that its execution remains unaffected by the load or behavior of other engines. This also means that adding more coprocessors can be done with horizontal scaling of validator computational resources–an important scalability property of the Nexus blockchain.
Figure 4: NexusCore as a home for multiple enshrined coprocessors.
Why enshrine?
By integrating core financial engines at the protocol layer, Nexus eliminates the overheads and determinism ambiguities of smart-contract-only designs for these workloads.
Enshrinement also supports shared security, unified accounting, cross-domain atomicity, and protocol-level revenue capture — capabilities that are hard to replicate in isolated app-chains or L2s.
Coprocessors execute with deterministic integer operations and strict ordering over inputs, avoiding nondeterminism (e.g., no floating point, no wall-clock reads, no randomness).
Deterministic scheduling (with a canonical dependency graph) allows parallel execution that yields the same result as sequential execution (schedule-equivalence), which is critical for safety in a replicated state machine.
Figure 5: A coprocessor’s layered state-machine model.
Case study: The Nexus Exchange as a flagship coprocessor
The first coprocessor deployed on NexusCore is the Nexus Exchange — a high-performance central limit order book (CLOB) for perpetual futures. Designed to meet the demands of high-frequency trading while remaining fully programmable, it will deliver sub-second latency with Core-level confirmation targets of under 200 milliseconds. Further, enshrinement of a complex and feature-rich Exchange trading system brings centralized exchange (CEX)-class features and market structure to a decentralized, verifiable substrate.
At its core, the Nexus Exchange provides deterministic order books with multiple order types — including limit, market, and conditional orders — executed through a high-performance matching engine. It also includes a real-time risk engine responsible for margining, funding, and liquidations.
To serve both off-chain trading systems and on-chain protocols, the Exchange exposes dual off and on-chain interfaces. Off-chain users and HFT firms can connect via native APIs — specifically, a REST and WebSocket interface compatible with the CCXT standard — which enable standard -low latency strategy execution. On-chain applications, meanwhile, can interact with the Exchange through EVM precompiles. This allows smart contracts to place orders, manage positions, and compose strategies directly with atomic transactions, unlocking new forms of programmable trading by composing the Exchange with the EVM.
Why L1-native matters
Building the Exchange as a first-class, protocol-native coprocessor unlocks advantages that general-purpose chains or siloed app-chains cannot replicate.
Performance and UX: As mentioned above, by embedding matching and risk logic directly into NexusCore, the system aims to achieve CEX-like execution and feature parity.
Composability: On-chain logic in NexusEVM composes seamlessly with the Exchange. Vaults, structured products, lending protocols, and automated strategies can all integrate directly, without bridging delays or liquidity fragmentation.
Shared liquidity: Instead of creating a closed venue, the Exchange functions as shared infrastructure for the ecosystem. Frontends, automated strategies, and third-party protocols all route into the same liquidity layer, aligning incentives and strengthening network effects.
Protocol-level economics: Fees and revenues generated by the Exchange accrue at the protocol layer, creating a sustainable economic loop that benefits validators, builders, and end-users alike.
Figure 6: The Exchange as shared native liquidity and infrastructure.
Beyond the exchange: The coprocessor catalog
The Nexus Exchange is simply the first coprocessor. We plan for NexusCore to become a home for a growing catalog of L1-native engines:
Native stablecoin and parallel high-frequency stablecoin transfers
Lending and credit primitives
Vaults Oracles and high-frequency information markets LSTs, RWAs, and bridging
Because these engines share the same NexusCore substrate and compose atomically with NexusEVM, builders can create advanced applications that compose all the various coprocessors with applications on the EVM.
To understand the value of Nexus’s coprocessor model, it’s useful to contrast it with the dominant alternatives in the blockchain execution landscape: traditional L1s and app-chains. Each presents strengths, but also structural limitations when it comes to supporting high-frequency, composable finance at scale.
Traditional L1s, built around a single virtual machine (typically the EVM), offer broad programmability, deep ecosystem support, and widely adopted tooling. These platforms have proven effective for a wide range of decentralized applications. However, they fall short for latency-sensitive use cases. The throughput and confirmation times of general-purpose VMs are fundamentally mismatched with the demands of high-frequency trading or real-time risk management. Modeling deterministic, low-latency engines within these environments is complex and inefficient. Moreover, simple feature parity with CeFi applications is simply computationally unfeasible within the EVM.
App-chains, by contrast, are tailored for performance within a specific application domain. This specialization can yield lower latencies and higher throughput. Yet the gains come with steep trade-offs if not coupled with an EVM core: liquidity becomes fragmented across chains; infrastructure is duplicated; composability with the broader ecosystem is weakened; and builders inherit the operational overhead of running and maintaining bespoke logic.
Nexus takes a different path by introducing enshrined coprocessors into a unified EVM-compatible L1 architecture, namely, the above-mentioned dual-core architecture. This design combines a special-purpose core with ultra-low latency — and an EVM core with full EVM composability. Builders benefit from a unified global state, shared liquidity, and atomic cross-domain transactions. At the same time, protocol-level fee capture and validator-aligned economics ensure that incentives remain coherent across stakeholders.
Of course, this architecture introduces its own trade-offs. Validators must meet higher hardware requirements — more compute, memory, and bandwidth — to support high-performance coprocessors. Developers also adopt a new cross-domain programming model, which requires familiarity with both EVM contracts and coprocessor interfaces.
But in return, the system offers something that neither traditional general-purpose L1s nor special-purpose app-chains can credibly deliver: a scalable, composable foundation for HFT-grade finance that doesn’t divide ecosystems. Nexus asks more from the base layer so it can deliver more to users and builders — speed, safety, and seamless composability — at the protocol level.
Closing: The L1 for verifiable, high-frequency finance
Coprocessors let Nexus be both a fast exchange substrate and a programmable platform. By enshrining financial engines inside NexusCore and composing them atomically with NexusEVM, we aim to deliver CEX-like performance without giving up what makes blockchains powerful: openness, composability, and shared liquidity.
The Nexus Exchange aims to prove the model, and future coprocessors aim to expand it.
For builders wanting to try out and build on top of the Nexus Exchange coprocessor, we’ll release integration guides, and reference implementations in the near future.
Daniel McGlynn
Daniel McGlynn
