NewsCryptoR3E Network Deploys Multi-L2 Elastic Network Prototype to Neo N3 TestNet

R3E Network Deploys Multi-L2 Elastic Network Prototype to Neo N3 TestNet

Author: CryptoNewsNet·

Key Takeaways

  • •R3E Network's neo-n4 prototype achieved its first live deployment on Neo N3 TestNet with five operational settlement contracts, though it is independent of and unendorsed by Neo Global Development, the Neo Foundation, or the neo-project organisation.
  • •The elastic network model allows applications to run on dedicated L2 chains while relying on Neo N3 as a shared settlement, security, and governance layer, an approach adapted from Ethereum's multi-rollup architectures.
  • •The three-tier architecture, rebuilt from the ZKsync Elastic Chain pattern on Neo's stack, supports three proof paths—multisig attestation, optimistic rollup, and ZK validity proofs via SP1 RISC-V—and includes seven research templates covering use cases such as gaming, DeFi, and payments.
  • •Validation was largely successful, with 1,475 of 1,478 pre-deployment tests passing at 99.8% coverage, 12 of 12 post-deployment smoke tests succeeding, and genesis state prepared for the first L2 chain, though three non-blocking RPC parameter-format failures remain.
  • •Significant caveats persist: no phase is marked production-ready, no security audit has been disclosed, key production requirements like HSM/KMS signer integration and a reviewed NeoFS backend are unresolved, and no MainNet deployment timeline has been announced.
R3E Network Deploys Multi-L2 Elastic Network Prototype to Neo N3 TestNet

R3E Network Deploys Multi-L2 Elastic Network Prototype to Neo N3 TestNet

R3E Network has deployed its neo-n4 elastic network prototype to the Neo N3 TestNet, marking the first live deployment of the independent multi-L2 architecture built by Neo core developer Jimmy Liao. Although it carries the "neo-n4" name, the project is separate from Erik Zhang's canonical Neo 4 protocol work: Zhang's effort targets a RISC-V VM evolution of Neo's core execution layer, whereas Liao's neo-n4 is an L2 scaling layer built on top of Neo N3. The neo-n4 project is not affiliated with, and has not been endorsed by, Neo Global Development, the Neo Foundation, or the neo-project organisation.

With five core settlement contracts now operational on TestNet, the project has moved beyond the exploratory code repository that Neo News Today (NNT) covered in May and become a functional on-chain prototype. The repository now spans Phases 0-6, with live contracts replacing what had previously existed only as undeployed specifications.

Liao, the founder of R3E Network, 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.” The reference points to Neo X, Neo's EVM-compatible sidechain, and SpoonOS, an AI-agent framework in the Neo ecosystem, as earlier expressions of the same application-centric thesis.

What the Elastic Network Model Enables

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

Contracts Deployed to TestNet

Five L1 settlement contracts were deployed to Neo N3 TestNet, each with 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 routes proofs, while Sp1Groth16Verifier verifies committee attestations 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 and rebuilt on Neo's own stack, combining dBFT 2.0 consensus, NEP-17 token standards, and NeoFS for data availability.

NeoHub sits at the base layer on Neo N3, coordinating settlement across multiple L2 chains. Each L2 chain maintains its own execution environment while sharing the bridge infrastructure used to move assets between layers. Between L1 and L2 sits an optional Gateway aggregation layer that handles 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

TestNet deployments of this kind let a contract suite run in a public environment without mainnet assets at stake. Pre-deployment testing covered 1,475 of 1,478 tests—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; the three remaining failures were parameter-format issues flagged 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.

The deployment nonetheless 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. A disclosed security audit is a customary prerequisite for production deployment of infrastructure of this kind. Real SP1 proofs are opt-in via a manual workflow, while standard CI runs only fast compatibility checks. The seven elastic chain templates are explicitly described as research prototypes, not planned production chains.

Looking Ahead

The TestNet deployment takes neo-n4 from theoretical architecture to operational prototype, though the project remains firmly in a 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 previously existing Phases 0-3.

No MainNet deployment timeline has been disclosed, and the work continues as independent exploratory engineering by R3E Network. Indicators to watch include resolution of the three non-blocking RPC parameter-format failures, movement of real SP1 proofs from the manual opt-in workflow into standard CI, and whether the prepared genesis state advances to a live first L2 chain on TestNet; any step toward production would also require the outstanding security audit, HSM/KMS signer integration, and a reviewed NeoFS backend flagged as unresolved.

The full deployment results and repository are available at: https://github.com/r3e-network/neo-n4