Neo’s Future Takes Shape: Community Developer Unveils Ambitious Multi-Layer Prototype

Groundbreaking Experimental Projects Push Neo’s Boundaries

In early May, Jimmy Liao, a key figure in Neo’s development community and founder of R3E Network, released two experimental code repositories that offer a fascinating glimpse into what Neo’s future might hold. These aren’t official releases or binding roadmaps—they’re passion projects from someone deeply embedded in Neo’s technical ecosystem, exploring possibilities rather than making promises. The larger project, called neo-n4, imagines an entirely new multi-layered network architecture that would dramatically expand Neo’s scalability by supporting multiple Layer-2 blockchains. The second, neo-lang, introduces a programming language designed specifically for writing smart contracts on Neo. Both projects carry prominent disclaimers making it clear they’re independent community research rather than official Neo Foundation initiatives, yet they’ve generated considerable interest because of Liao’s technical credentials and the sophistication of the work itself.

The timing is particularly interesting. These projects arrive at a moment when blockchain scalability remains one of the industry’s most pressing challenges, and when Neo itself is navigating its evolution toward a fourth major version. Liao’s work doesn’t emerge from nowhere—it builds on emerging technical foundations within Neo’s core development while simultaneously pushing forward with creative solutions to problems the blockchain hasn’t officially announced it will tackle in exactly this way. It’s the kind of work that happens when talented developers see possibilities and decide to build prototypes to explore them, sharing their research with the broader community to spark discussion and potentially influence the platform’s direction.

Neo-n4: Reimagining Network Architecture with Multiple Layers

The neo-n4 project is technically impressive in scope and ambition. Liao envisions a three-tier system where Neo N3 or the forthcoming Neo 4 would serve as the foundational Layer-1 settlement layer—the ultimate source of security and truth. Above that would sit an optional gateway component that aggregates cryptographic proofs from multiple Layer-2 chains, creating efficiency through consolidation. The top tier would consist of individual Layer-2 chains, each running Neo 4 core technology as their execution engine. This architecture takes inspiration from ZKsync’s Elastic Chain concept, which pioneered similar patterns in the Ethereum ecosystem, but rebuilds everything using Neo’s native technologies: dBFT 2.0 consensus for fast finality, NEP-17 token standards, the NeoVM execution environment, and NeoFS for storing data that doesn’t need to live on the most expensive storage layer.

The prototype isn’t just a concept document or whitepaper—it’s backed by substantial working code. The repository contains 820 tests spread across 26 distinct projects, demonstrating serious engineering effort. There are 19 smart contracts split between functions that run on the main Layer-1 (13 contracts in what Liao calls the “NeoHub”) and contracts native to Layer-2 chains (6 contracts). Additionally, there are 15 off-chain software libraries, 8 plugins for Neo nodes, and 3 command-line tools for developers and operators. The smart contracts handle critical functions like registering new chains in the network, managing a shared bridge that allows assets to move between layers, settling batches of transactions from Layer-2s back to Layer-1, bonding mechanisms for sequencers (the entities that order transactions on Layer-2s), and an “optimistic challenge window” that gives observers time to flag fraudulent activity.

Liao organized the development work into phases, several of which are marked complete. The early phases covered a basic sidechain proof of concept, the NeoHub shared bridge system, batch settlement mechanisms, and the optimistic challenge window—foundational pieces that prove the concept can work. Phase six, focused on developer command-line tooling, is also done. Still in progress are phases four and five, which tackle some of the most technically demanding aspects: implementing zero-knowledge validity proofs using a RISC-V processor architecture as the proving system, and aggregating proofs from multiple Layer-2 chains into efficient bundles. The scaffolding for these advanced features exists, showing the direction even if the implementation isn’t finished.

The project also introduces “Neo Connect,” a cross-chain messaging system that would allow communication in all directions: from Layer-1 down to Layer-2s, from Layer-2s back up to Layer-1, and even between different Layer-2 chains. It uses batched Merkle proofs—efficient cryptographic structures that prove data integrity without requiring every validator to check every transaction. Recognizing that different applications have different security and cost requirements, neo-n4 proposes a tiered data availability model. High-security applications like decentralized finance would use Layer-1 settlement for maximum security. Applications with moderate security needs could use NeoFS, Neo’s decentralized storage system, for lower costs. And for scenarios where minimal cost matters most, a data availability committee—a semi-trusted group—could provide the cheapest option. The repository includes extensive documentation, architectural diagrams, and operator guides, though Liao hasn’t announced any third-party security audit, which would be essential before any production use.

How Neo-n4 Relates to Official Neo 4 Development

Understanding where neo-n4 fits in the broader Neo development picture requires some context. The project explicitly assumes that Neo 4 core already exists as a working foundation and builds a Layer-2 scaling architecture on top of it. This isn’t an alternative to Neo 4—it’s a possible next step after Neo 4. The fourth development phase specifically targets compatibility with NeoVM 2 and RISC-V-based zero-knowledge proofs, which aligns perfectly with the direction Neo co-founder Erik Zhang outlined in his draft Neo 4 roadmap released in September 2025.

There’s been tangible progress on these foundational technologies. On April 15, Zhang announced that a NeoVM-compatible RISC-V virtual machine solution had successfully passed full MainNet state validation—meaning it correctly processed all historical Neo blockchain data using the new architecture. This confirmed the design had moved from theory to proven implementation. Liao contributed to that effort, sharing an architecture diagram just days earlier showing how PolkaVM, a RISC-V-based virtual machine, could integrate into Neo’s C# node software. The neo-n4 announcement followed just 19 days after that milestone.

The relationship between the projects is collaborative but distinct. Zhang’s work represents the canonical, official development of Neo 4 protocol fundamentals—the base layer that will eventually power the network. Liao’s neo-n4 explores what a sophisticated multi-Layer-2 scaling architecture could look like if built on top of those foundations. Importantly, Zhang’s official draft roadmap didn’t explicitly propose a multi-Layer-2 architecture of this type, making neo-n4 a forward-looking proposal rather than implementation of announced plans. It’s the kind of work that could influence official direction if it proves compelling, or could live as a community-built scaling solution, or might simply serve as valuable research that informs other approaches. Liao’s dual role as both R3E founder and Neo core developer means he has deep knowledge of Neo’s technical direction, but his repositories carry clear disclaimers that they represent exploration and prototyping, not commitments from the Neo project itself.

Neo-Lang: A Purpose-Built Contract Language

While neo-n4 grabbed headlines for its architectural ambition, the second repository Liao released tackles a different challenge: making it easier and more efficient to write smart contracts for Neo. Neo-lang is a domain-specific language—meaning it’s designed for one particular purpose rather than being a general-purpose programming language. It targets Neo N3 (the current version) and uses a .neo file extension to distinguish its source code files. The language includes 10 built-in types optimized for blockchain use, struct declarations for organizing complex data, event handling for applications to react to contract activity, a package system for code organization and reuse, and direct access to Neo’s native contracts including the Oracle (for bringing off-chain data onto the blockchain) and Notary (for certain transaction signing patterns).

Liao claims the language achieves 30% savings on opcodes compared to current approaches—opcodes being the basic instructions that execute on Neo’s virtual machine, with fewer opcodes generally meaning lower gas costs and faster execution. However, the neo-lang repository is clearly at an earlier stage than neo-n4. While it contains a comprehensive language reference document and a compiler binary, it lacks the test suites, example contracts, and benchmark data that would allow independent verification of the claimed efficiency gains and demonstrate the language in realistic scenarios.

The contrast with R3E’s more mature neo-solidity project is instructive. Neo-solidity, which reached version 0.15.0 in late March, brings Solidity—Ethereum’s dominant smart contract language—to Neo. It ships with over 700 tests, example decentralized finance contracts demonstrating real-world patterns, and 95% completion on Hardhat integration, allowing developers to use Ethereum’s popular development tools with Neo. Both projects compile to the same Neo N3 bytecode, but serve fundamentally different developer audiences. Neo-solidity offers a migration path for the massive pool of Ethereum developers familiar with Solidity, lowering the barrier to building on Neo by letting them use skills they already have. Neo-lang takes the opposite approach: designing a language from scratch to fit Neo’s specific architecture, potentially unlocking optimizations and patterns that aren’t possible when adapting a language designed for a different blockchain’s model. Neither approach is inherently superior—they represent different strategic bets on developer adoption.

R3E Network’s Remarkable Productivity

These two repositories represent the latest output in what’s been an extraordinarily productive period for R3E Network throughout 2026. Since February alone, the team has shipped a remarkable array of developer infrastructure: the neo-solidity compiler that brings Solidity to Neo; a JavaScript SDK for decompiling Neo smart contracts, allowing developers to understand and audit existing contracts more easily; a Trusted Execution Environment-powered oracle system that’s already deployed to Neo MainNet, providing secure off-chain data feeds; and SDK releases for JavaScript, Rust, and Swift, enabling developers to build applications in some of the industry’s most popular programming languages.

Neo-n4 represents a significant escalation in ambition compared to these previous releases. Where the earlier projects focused on individual developer tools and utilities—valuable infrastructure that makes building on Neo easier—neo-n4 tackles network-level architecture. It proposes fundamental changes to how the Neo ecosystem could scale, moving beyond single-chain limitations toward a coordinated network of interconnected chains. This is infrastructure that would affect every participant in the ecosystem if adopted, from validators to wallet providers to end users. The scope and implications are vastly larger than even a sophisticated development tool.

Whether any components of neo-n4 will find their way into official Neo development remains genuinely uncertain. Liao’s position gives him unique insight—as a Neo core developer, he understands the technical direction and constraints of the official project; as R3E founder, he has the independence and resources to pursue experimental directions without waiting for committee consensus. This makes his work particularly valuable as informed exploration that could identify promising paths forward or reveal unforeseen complications. But the repository’s own disclaimers make the status clear: this is research and prototyping, not a roadmap commitment. It’s a proposal and proof-of-concept that the community and core developers can evaluate, discuss, and potentially incorporate, reject, or use as inspiration for alternative approaches. In open-source blockchain development, this kind of independent technical exploration often plays a crucial role in ecosystem evolution, sometimes more influential than official pronouncements precisely because it demonstrates working code rather than just describing possibilities. Time will tell whether neo-n4’s multi-Layer-2 vision becomes Neo’s scaling future or remains a fascinating might-have-been.