R3E Network has deployed its neo-n4 elastic network prototype to the Neo N3 TestNet, marking the first live deployment of Jimmy Liao’s independent multi-L2 architecture. The project, which uses the “neo-n4” name, is a separate effort from Erik Zhang’s canonical Neo 4 protocol work. Zhang’s work focuses on a RISC-V VM evolution of Neo’s core execution layer, while Liao’s neo-n4 is an L2 scaling layer built on top of Neo N3. The neo-n4 project is not affiliated with or endorsed by Neo Global Development, the Neo Foundation, or the neo-project organisation.

Five core settlement contracts are now operational on TestNet, moving the project from the exploratory code repository NNT covered in May to a functional on-chain prototype. The repository now spans Phases 0-6, with live contracts replacing what were previously undeployed specifications.

Liao, a Neo core developer and R3E Network founder, framed the project’s intent on the day of deployment:

“Same thesis as Neo X and SpoonOS: Neo N4 isn’t about launching a new chain. It’s about building chain-native apps on top of N3, application-centric, serving users better in the AI era.”

What this architecture is designed to enable

The elastic network model is designed to let different applications run on their own dedicated chains while sharing Neo N3 as a common settlement and security layer. A gaming application could run on a chain optimised for high throughput and low latency, while a DeFi application runs on a separate chain with stricter security guarantees, but both would share the same bridge for asset movement and the same governance framework. Users and assets could move between these chains without each application needing to build its own bridge or security infrastructure from scratch. The approach is similar to multi-rollup architectures being explored on Ethereum, adapted for Neo’s protocol stack.

Deployed contracts

Five L1 settlement contracts were deployed to Neo N3 TestNet, each serving a distinct role in the elastic network architecture:

  • RollupHub: Chain registry, batch submission, and forced inclusion.
  • SharedBridge: Asset escrow handling deposits and withdrawals across layers.
  • GovernanceController: Council-based governance with proposals and timelock mechanisms.

Two additional contracts handle proof verification: ZkVerifier for proof routing and Sp1Groth16Verifier for committee attestation verification using SP1 v6.2.1 Groth16/BN254 pairing.

Architecture overview

The neo-n4 architecture follows a three-tier design adapted from the ZKsync Elastic Chain pattern, rebuilt on Neo’s stack using dBFT 2.0 consensus, NEP-17 token standards, and NeoFS for data availability.

At the base layer, NeoHub sits on Neo N3 and coordinates settlement across multiple L2 chains. Each L2 chain maintains its own execution environment while sharing the bridge infrastructure for asset movement between layers. An optional Gateway aggregation layer sits between L1 and L2, handling proof aggregation.

The system supports three proof paths: multisig attestation, optimistic rollup with a fraud-proof window, and ZK validity proofs via SP1 RISC-V. Seven elastic chain templates, spanning DEX, gaming, DeFi, social, NFT, payment, and enterprise use cases, are included as research prototypes for validation and testing.

Validation results

Pre-deployment testing covered 1,475 of 1,478 tests across 338 VM tests, 55 integration tests, and 1,082 unit tests, achieving 99.8% coverage. Post-deployment smoke testing returned 12 of 12 tests passing, with all five contract deployments successful and six inter-contract links verified.

RPC validation recorded 11 of 14 successful checks, with three parameter-format issues noted as non-blocking. Genesis state has been prepared for the first L2 chain.

Scope and caveats

The repository now contains 38 .NET test projects, 16 core off-chain libraries, eight node plugins, five L1 contract projects with 10 L2 native contracts, seven CLI tools, and four SDK sources across .NET, TypeScript, Rust, and Python.

Despite the breadth of the deployment, the project carries significant caveats. No phase in the implementation status matrix is marked as production-ready. The repository has not undergone a disclosed security audit, and several production requirements, including HSM/KMS signer integration and a reviewed NeoFS backend, remain unresolved. Real SP1 proofs are opt-in via manual workflow; standard CI uses fast compatibility checks only.

The seven elastic chain templates are explicitly described as research prototypes, not planned production chains.

Looking ahead

The TestNet deployment moves neo-n4 from theoretical architecture to operational prototype, though it remains firmly in the research and exploration phase. Since NNT’s May coverage, R3E Network has completed Phases 4-6, adding NeoVM2/SP1 RISC-V validity proofs, Gateway aggregation, and CLI tooling, on top of the Phases 0-3 that were already in place.

No MainNet deployment timeline has been disclosed. The project continues as independent exploratory engineering work by R3E Network.

The full deployment results and repository can be found at the link below:
https://github.com/r3e-network/neo-n4

Tags: ,