In most blockchains today, the separation between the protocol and the application layer is clean and intentional. The base chain provides a virtual machine along with consensus, state storage, and transaction ordering. Everything else lives on top. Smart contracts simulate behavior inside this environment, constrained by the design of the virtual machine itself.
This model has served the industry well. It made blockchains general-purpose and modular. But it also introduced certain limits: performance ceilings, fragmented liquidity, and duplicated infrastructure. Applications often end up rebuilding the same primitives — DEXs, oracles, bridges, stablecoins — each with slightly different trade-offs, each living in a silo.
Nexus introduces a new approach that changes the architecture at the base layer. It allows the protocol itself to embed certain applications — making them native to the blockchain’s logic and available system-wide. This process is called enshrinement, and it represents a shift in how blockchains can be designed, deployed, and optimized.
The first enshrined Nexus coprocessor will go live soon as part of the Testnet III protocol.
Enshrinement as blockchain architecture
At its core, enshrinement means moving a piece of application logic from the smart contract layer into the protocol itself. Instead of being deployed by a user, it’s implemented directly in the blockchain’s execution logic. The application becomes a native part of the chain, tightly integrated with consensus and verified as part of block production.
In the Nexus architecture, these native components are called coprocessors. Coprocessors are verifiable computational modules that sit alongside the EVM inside the Nexus Layer 1. They are designed for specific use cases — like trading engines, lending protocols, or token issuance — and optimized accordingly. Importantly, they’re not exclusive. Any application on Nexus can access them and build on top of them.
Rather than being “pre-installed apps,” coprocessors function more like native system calls. They provide shared capabilities that developers can trust, verify, and compose with. They also remove the need to simulate complex logic inside the EVM, allowing key primitives to run faster, cheaper, and more securely.
Why now?
The concept of enshrinement isn’t entirely new — Ethereum has had internal precompiles and protocol upgrades that blur the line between application and infrastructure. But full enshrinement of financial applications at the L1 level is still rare. The reason is straightforward: it’s hard to do well.
For years, the prevailing wisdom was to keep base layers simple and push complexity to higher layers — layer twos, rollups, sidechains.
Nexus takes a different approach. We believe that in certain domains — especially finance — it’s worth embedding key logic directly into the L1. This can benefit the entire Nexus-connected ecosystem from the protocol level. There are good reasons for this shift.
First, many applications rely on the same core primitives. If these are reimplemented repeatedly as contracts, the result is duplication and inefficiency.
Second, user expectations have changed. Real-world financial users demand instant settlement, low slippage, deep liquidity, and reliable price feeds. Achieving this inside a general-purpose VM, without native optimization, is difficult.
Third, hardware and cryptography have improved. Enshrinement requires more computational resources, but validator performance is no longer the bottleneck it once was. Cloud computing is cheaper. Hardware is more available. Zero-knowledge proof systems are reaching production maturity. The assumptions that justified strict minimalism a decade ago no longer apply universally.
In other words, enshrinement is now possible in ways that weren’t feasible before — and increasingly necessary to support the kind of performant, composable applications developers and users are demanding.
The case for coprocessors
The benefits of enshrinement go beyond speed. By treating core applications as protocol-level components, the entire ecosystem gains leverage.
Take liquidity, for example. Today, on most blockchains, liquidity is fragmented across dozens of DEXs and trading pairs. Slippage is high. Cross-application composability is fragile. If a decentralized exchange is enshrined at the protocol level, it becomes a shared primitive — available to any developer, used by all apps, and governed by the chain itself. The result is deeper markets, better execution, and more reliable infrastructure.
Or consider lending. A native lending protocol can offer capital to any application on-chain without needing a custom integration. Credit lines, margin positions, and tokenized assets become system-level features rather than isolated silos.
Even something like token launches can benefit. An enshrined launchpad can provide standard tooling, automatic liquidity seeding, and transparent auction mechanisms — all verified by the protocol and accessible to every project.
The kinds of functionality outlined above are design goals. Nexus is building a chain where developers don’t have to reinvent primitives or compete for fragmented attention. Instead, they build on a shared foundation — optimized, secure, and available by default.
The trade-offs
None of this comes for free. Enshrining an application at L1 adds protocol surface area. It must be specified, audited, and formally verified. Bugs can’t be patched with an upgrade key. Governance decisions require community involvement. The process is slower by design.
There’s also a risk of perceived favoritism. If some applications are enshrined while others aren’t, developers may worry that the chain is no longer credibly neutral. Nexus addresses this by making enshrinement transparent and measured. Applications are selected based on clear criteria — frequency of use, ecosystem impact, composability — and the scope of what’s enshrined is deliberately limited.
Hardware requirements are another factor. Coprocessors increase the computational load on validators. But the architecture is built with this in mind. Nexus validators run multiple execution environments in parallel, and the protocol is supported by a dedicated compute network that generates zero-knowledge proofs of block execution.
This is where ZK comes into play. As the chain becomes more complex, ZK proofs ensure that anyone can still verify it efficiently. A universal proof — generated by the compute network and verified onchain — attests to the correctness of the entire system. This keeps the blockchain transparent, decentralized, and globally verifiable, even as it becomes more powerful.
What comes next?
The first enshrined coprocessor on Nexus will appear on Testnet III. It will be a financial primitive — chosen for its ability to support composability, attract liquidity, and reduce complexity for builders. This will serve as a model for future coprocessors, each introduced with care and clarity.
Mainnet will follow soon after, featuring the Nexus EVM and the production-ready compute network. While early mainnet will launch without enshrined applications, developers will be able to deploy contracts and build directly on the Nexus Layer 1. As the ecosystem matures, additional coprocessors will be proposed, evaluated, and integrated.
The long-term roadmap includes further ZK infrastructure, including the ability to generate a single universal proof that verifies all execution and state transitions on Nexus. This proof will make it possible for anyone with minimal hardware to verify the entire blockchain in seconds — regardless of how many applications are enshrined or how complex they become.
A new layer one philosophy
The decision to enshrine applications is ultimately about making a blockchain more expressive, more useful, and more accessible. It challenges the assumption that neutrality requires minimalism. Instead, Nexus offers a model where the protocol actively supports the things developers rely on most — while maintaining trust, transparency, and verifiability at every layer.
