NEO 4 Roadmap: A Blockchain Platform for the Real World

Created: September 28, 2025
Updated: October 19, 2025

1. Ecosystem

The core vision of NEO 4 is to drive large-scale blockchain adoption in real-world applications, building a sustainable and impactful ecosystem. The future ecosystem will focus on asset tokenization, financial infrastructure, cross-chain interoperability, and emerging applications.

1.1 Real World Assets (RWA)

Promote tokenization of real estate, bonds, bills, intellectual property, and other tangible assets.
Collaborate with regulators and financial institutions to ensure compliance and liquidity.
Establish trusted asset evaluation and auditing mechanisms to provide transparency and confidence for investors.

1.2 Digital Asset Treasury (DAT)

Partner with listed companies and multinational enterprises to build NEO-based digital asset treasury solutions.
Develop enterprise-grade tools for asset management, reducing the cost and risk of cross-border capital operations.
Leverage smart contracts to improve transparency, supporting automated scenarios such as dividend distribution and bond interest payments.

1.3 Stablecoin

Support issuance and integration of multiple types of stablecoins (fiat-backed, commodity-backed, and algorithmic).
Enable key use cases such as payments, cross-border settlements, and DeFi liquidity provision.
Build a compliance-friendly stablecoin ecosystem as an entry point for enterprises and mainstream users into Web3.

1.4 Decentralized Exchange (DEX)

Develop high-performance, low-latency decentralized exchange infrastructure.
Create cross-chain bridge solutions to connect with Ethereum, Bitcoin, and other major blockchains, expanding liquidity sources.
Explore compliant DEX models that balance KYC/AML requirements with privacy protection.

1.5 Gaming

Establish a cross-game interoperability layer to allow assets to flow seamlessly across different titles.
Collaborate with game developers to integrate NFTs into in-game economies.
Advance GameFi models, positioning gaming as a gateway to DeFi and NFT adoption.

2. Technology

NEO 4 will continue to advance its underlying technology to provide an efficient, secure, and cost-effective infrastructure for ecosystem applications.

2.1 Consensus & Networking

Dynamic Block Interval: Flexibly adjust block production speed based on network load and transaction volume, improving throughput and efficiency. #4241

2.2 Execution Layer

NeoVM 2: The next-generation virtual machine.
- Fully compatible with the RISC-V instruction set for broader hardware support.
- Fine-grained gas metering for fairer fee calculations.
- Lower costs and higher performance to attract developers and applications.
Built-in Standardized Token Interfaces: Unified APIs to reduce development friction. #4240 #4344
Contract Charging Mechanism: Allow developers to define their own charging models, enabling sustainable business models. #4238
Post-Quantum Cryptography: Research and integration of quantum-resistant primitives to ensure long-term security. #4239

2.3 Application Layer

Whitelist of Free Contracts: Selected contracts can be executed without fees, promoting adoption of stablecoins for payments and settlements. #4201
Account Abstraction: An account abstraction (AA) framework that unifies externally owned accounts and contract accounts, enabling programmable signatures, fee abstraction, and enhanced flexibility for users and developers. In parallel, a zero-knowledge (ZK)-based account recovery mechanism will be implemented to allow secure and privacy-preserving key restoration and permission management. This design aims to provide a foundation for keyless wallets, enterprise-grade account controls, and compliance-friendly identity systems in the Neo ecosystem. #4253
zk-KYC: Zero-knowledge identity verification to balance compliance and user privacy.
zk-Oracle: A privacy-preserving oracle system for secure off-chain data integration.

2.4 Economic Model

NEO Staking Mechanism:
- Decouple staking rewards from governance voting.
- Flexible interest rates: lower for flexible staking, higher for fixed-term staking.
GAS Treasury Allocation:
- A portion of newly generated GAS is allocated to the Treasury.
- The split ratio is parameterized and adjustable through governance.
- Treasury funds are used for ecosystem incentives, R&D, and community growth.

3. Governance

The governance framework of NEO 4 is designed to balance technical decision-making, financial management, and community oversight, ensuring long-term sustainable development.

3.1 Enhanced Role of the NEO Council

Dynamically adjust the number of council members.
Decide on consensus node admission and exit rules.
Manage core network parameters.
Provide strategic guidance and coordinate ecosystem resources.

3.2 Development Workflow

Core developers submit proposals.
The Council discusses, votes, and makes decisions.
Approved proposals follow the full lifecycle: development → testing → review → merging.

3.3 Rights of NEO Holders

Ultimate Supervisory Power: NEO holders hold the highest accountability authority over the ecosystem.
Referendum Power: Holders can dissolve or re-elect the Council via on-chain referenda.
Future exploration of Layer-2 governance to grant greater community participation.

4. Future Outlook

NEO 4 represents not just a technical upgrade but a major step toward real-world adoption at scale. Through RWAs, stablecoins, cross-chain DEXs, and GameFi, NEO aims to become the bridge between Web2 and Web3. Looking ahead, with the integration of zero-knowledge technologies and post-quantum security, the NEO ecosystem is poised to expand across finance, commerce, entertainment, and public services—bringing blockchain closer to mainstream society.

4.1 Long-Term Vision

In the long run, NEO 4 will serve as a foundational platform for a new generation of decentralized applications and digital economies. By continuously improving interoperability, scalability, and developer accessibility, NEO will empower enterprises, institutions, and individuals to build trustless, transparent, and efficient systems for the real world.

4.2 Backward Compatibility

NEO 4 is designed with complete backward compatibility to ensure a smooth and disruption-free transition. All existing tokens, smart contracts, and applications deployed on NEO 3 will continue to function seamlessly on NEO 4 without the need for migration or redeployment. The execution layer, contract interfaces, and system-level APIs are carefully maintained to preserve functionality and data integrity. This guarantees that developers and users can immediately enjoy NEO 4’s improved performance, enhanced security, and extended scalability — while fully protecting their existing assets and infrastructure investments.

Sep 28 '25 07:09 erikzhang

LFG!! 🚀💯

Sep 28 '25 13:09 HugoBrynner

Thanks for putting together this draft. I agree that we need to build something that goes beyond hype and speculation: a platform that is actually used in the real world everyday life. We’re already seeing the first steps of blockchain RWA adoption here and there. I agree there is still a long road ahead, but also NEO has to make up significant ground compared to other ecosystems in terms of real usage. We need to build something that will be used.

In my view the stablecoins are especially important, as are reliable bridges to larger networks (maybe through NeoX - particularly Ethereum L1 & L2's). We also need to actively convince existing projects to build on N3 so they can leverage these new features. For a later discussion: maybe we need a Flamingo 2.0 (something that the NF made and was taken over by the community).

I support the idea of allocating part of GAS to a foundation treasury, but transparency on how those funds are used will be crucial to build trust. The Neo Foundation itself should also be more present and engage in open discussions like this and I feel like this is a good start. With all the ants together we can go way further. A more engaged and empowered community would add value.

We need to fully commit to the vision of the Smart Economy: Let's be realistic, pragmatic and focused on the execution.

I’m not deeply technical, so I’ll leave those details to others, but I’m glad this discussion has been opened and I hope it sparks a productive conversation that balances vision with pragmatic delivery.

Sep 28 '25 15:09 NwKdOnTheBlockchain

How does another infrastructure redesign drive NEO any further towards these goals?

NEO is missing real-world applications, IMHO, not because of a lack of features or abilities (Flamingo proved complex things can be built effectively and quickly on NEO), but a lack of Builders.

Now for the Ecosystem Development (that's supposed to actually bring builders). Why do we need to wait for NEO4 to implement those? They sound great, but why are they not on NEO3 or NEO-X?

Sep 28 '25 16:09 PazBazak

How does another infrastructure redesign drive NEO any further towards these goals?

NEO is missing real-world applications, IMHO, not because of a lack of features or abilities (Flamingo proved complex things can be built effectively and quickly on NEO), but a lack of Builders.

Now for the Ecosystem Development (that's supposed to actually bring builders). Why do we need to wait for NEO4 to implement those? They sound great, but why are they not on NEO3 or NEO-X?

We are not going to wait. Ecosystem development is also underway.

Sep 28 '25 16:09 erikzhang

How does another infrastructure redesign drive NEO any further towards these goals?

NEO is missing real-world applications, IMHO, not because of a lack of features or abilities (Flamingo proved complex things can be built effectively and quickly on NEO), but a lack of Builders.

Now for the Ecosystem Development (that's supposed to actually bring builders). Why do we need to wait for NEO4 to implement those? They sound great, but why are they not on NEO3 or NEO-X?

We are not going to wait. Ecosystem development is also underway.

Underway? How will you achieve all those promises and projects, clearly it could not be done for N3, so what's the new strategy?

I'm genuinely asking because I care, Neo is missing so many things to succeed, None of them is technical.

Before we talk about Neo4, and tech upgrade, let's focus on how do we build an active community and attract users.

We should have an open conversation about that instead.

Sep 28 '25 18:09 PazBazak

One of the biggest things to me is to not copy existing blockchain tech. We need to invent new tech that is better. One plus side we have is NeoFS, no blockchain I've seen has anything like it (note: I don't know every blockchain). We need to start with NeoFS and build around it. If we think of our blockchain as a company we need to make a product that is dynamic and expandable at scale that incorporates into everything finance. If we keep using bad business models or choices then N4 will fail.

Sep 28 '25 20:09 cschuchardt88

How does another infrastructure redesign drive NEO any further towards these goals? NEO is missing real-world applications, IMHO, not because of a lack of features or abilities (Flamingo proved complex things can be built effectively and quickly on NEO), but a lack of Builders. Now for the Ecosystem Development (that's supposed to actually bring builders). Why do we need to wait for NEO4 to implement those? They sound great, but why are they not on NEO3 or NEO-X?

We are not going to wait. Ecosystem development is also underway.

The new design should compatible with current infras/contracts. Dapps does not have to afraid of migration.

Sep 29 '25 02:09 steven1227

Hi Erik

What’s really crucial here is the element of trust within the community. For many years, there have been empty promises regarding the U.S. markets. We understand the geopolitical factors and the perceptions around NEO, but the reality is that a lot of promises have been made and not fulfilled. DHF tends to appear only when the market heats up to promote the value of NEO, and that’s just not acceptable.

You really need a concerted effort to change the perception of NEO, especially because of the Chinese narrative that unfortunately works against you. With the U.S. markets opening up and Binance allowing NEO in the U.S., that’s an opportunity, but the trust problem still remains your biggest hurdle.

I’m not a technical person, but I know that even the best technology won’t succeed if people don’t trust the product. So a trust campaign and consistent transparency are crucial. Many users have left the project, and leadership needs to step up visibly to build credibility, particularly in the U.S. market. Right now, it feels like the project lacks direction and accountability, and that’s what needs to change.

In short, focus on being honest and transparent with the community. You need strong, accountable leadership that treats this as a business and not just a community-led project. Best of luck, and I truly hope NEO 4 can become everything it’s meant to be.

Thanks!

Sep 29 '25 05:09 CryptoKent77

Siacoin, filecoin. They both are working what NeoFS could be

One of the biggest things to me is to not copy existing blockchain tech. We need to invent new tech that is better. One plus side we have is NeoFS, no blockchain I've seen has anything like it (note: I don't know every blockchain). We need to start with NeoFS and build around it. If we think of our blockchain as a company we need to make a product that is dynamic and expandable at scale that incorporates into everything finance. If we keep using bad business models or choices then N4 will fail.

Sep 29 '25 05:09 HugoBrynner

Hi Erik,

I saw your post on Twitter and it prompted me to write.

As you may recall, I was vocal about this back then. Had NEO focused on strengthening its core N2 technology—specifically the GAS system and bug fixes—instead of pursuing numerous other initiatives, it might have prevented the developer exodus to the Ethereum ecosystem in 2019-2020.

Seeing the current discussions, I feel compelled to raise similar concerns six years later. I don't believe the ecosystem needs another over-engineered version of NEO. What it truly needs is for N3 to be exceptionally fast, reliable, and cheap.

Instead of dictating technological solutions and steering applications in specific directions—which risks missing the market window by the time products are built—why not establish and achieve key performance objectives?

The notable exceptions to this, of course, are the adoption of RISC-V and ZK privacy primitives. I completely agree that NEO should not try to bootstrap the entire developer experience from scratch in 2025. The investment is too large, the timeline is too long, and the talent is too scarce. Embracing RISC-V is a smart, forward-thinking move to tap into a thriving, pre-existing ecosystem.

To define these objectives, I suggest benchmarking against current market leaders like Solana, Sui, and Miden. If an application has a fundamentally better option on those platforms, why would it choose NEO? The targets should be in the ballpark of:

Fast: ~150ms finality, similar to what's targeted by Solana's Alpenglow upgrade.
Reliable: The network must be robust enough to handle extreme load. For instance, during a recent surge on Solana for a pump.fun launch, transaction failures in some blocks reached 32%. A fair benchmark would be a CI test that simulates this level of surge capacity without the network failing.
Cheap: This is challenging, as some blockspace is nearly free (e.g., Base, BNB) and now we have stablecoin dedicated chains (e.g.,Plasma, Tempo). Drawing from the Ethereum community's expectations, contract deployments should cost less than $1, and transactions should be under $0.01 with sponsoring options, similar to Sui's gas model.

I am certain NEO could rise again by adopting the best ideas and code from the wider ecosystem, but this requires execution by a solid internal engineering team. You have incredible talent in Shanghai, including yourself. Tapping into this local talent will be more cost-effective, foster greater commitment, and accelerate development. Crucially, please ensure that several of these hires are experienced QA engineers to guarantee quality meets the high standards of companies like Alibaba or Tencent.

Wishing you and the team all the best.

Sep 29 '25 14:09 canesin

What Neo got wrong was locking itself in a basement to develop N3, no marketing, no shilling, no community engagement, nothing. @erikzhang, you mention “We are not going to wait. Ecosystem development is also underway.” But what does that even mean? Why is there no discussion, no visibility, and why is everything hidden until the very last second before being dropped like, “oh hey, here it is”? End of discussion.

That’s not how you get Neo back into the top 100. Search “layer 1 blockchains” on Google or check CoinMarketCap, Neo isn’t even listed. It’s become a ghost chain. Fixing that should be the number one priority.

You need to be out there talking about what’s coming, building hype, creating a community, and giving people something to be excited about. Stop with the vague messaging. Stop repeating the same mistakes Neo has made for years. This isn’t 2017 anymore with only a handful of layer 1s. It’s 2025. There are dozens of strong competitors above Neo.

So why would anyone choose Neo when not even its own leaders promote it? Da is gone again... Why would developers or users commit to a chain with barely any activity and even fewer projects?

Sep 29 '25 15:09 KayAppeal

Be patient, I've only been back less than a week.

Sep 29 '25 15:09 erikzhang

We need a clear vision who is at the top of NEO and what there rolles are. Everyone here commenting shows Neo isn't completly dead yet but now more then ever Neo needs a good plan on hype and marketing, the tech is allready there to work with. Let's all be positive and help bring Neo back to where it belongs. Top 10 at least.

Be patient, I've only been back less than a week.

Sep 29 '25 15:09 HugoBrynner

We need a clear vision who is at the top of NEO and what there rolles are. Everyone here commenting shows Neo isn't completly dead yet but now more then ever Neo needs a good plan on hype and marketing, the tech is allready there to work with. Let's all be positive and help bring Neo back to where it belongs. Top 10 at least.

Be patient, I've only been back less than a week.

Because we're the bag holders since 2016 and would like to see a ROI. These are the facts!

Sep 29 '25 15:09 CryptoKent77

Engineer here.

First convince us why you're better alternative than:

S3, cloudinary, etc
any rdbms like Postgres
existing enterprise ledgers

We can't just jump into these things when there is no cognitive comparatives to the existing tech we are using.

This is a blockchain problem on a whole, not just neo.

Back in the day I followed neo because it supported C# and every new project I touch I tried to see how I can adopt the tech and have failed.

Court the devs first guys.

Sep 29 '25 16:09 shawnmclean

To @shawnmclean

S3 / Cloudinary vs Blockchain Storage We’re not claiming to replace S3 or Cloudinary for simple file hosting. The value of blockchain storage (e.g., NeoFS) is about trust, auditability, and programmability. Data is verifiable and tamper-proof, secured by an incentive model, and can be tied directly to smart contracts (e.g., NFTs with bound files, DeFi collateral proofs). That’s a layer cloud storage cannot provide.
Postgres / RDBMS vs Blockchain RDBMS solves single-organization data management. Blockchain solves multi-party trust. A Postgres admin can rewrite history; on a blockchain, history is immutable and auditable. If you’re building apps within one company, use Postgres. If you need verifiable state across multiple organizations, that’s exactly where blockchain shines.
Enterprise Ledgers vs Public/Consortium Chains Enterprise ledgers are usually closed, siloed systems. A public or consortium chain is interoperable, transparent, and consensus-driven. It reduces single-point trust and enables ecosystems to emerge around shared infrastructure.
On “Court the devs first” Agreed—this is critical. Neo’s choice of C# support back in the day was exactly about developer adoption, and that remains a core philosophy. We don’t expect you to abandon existing stacks; we aim to be a complementary layer when your use case requires verifiability, immutability, or multi-party trust. The question isn’t “Why replace Postgres or S3?” but rather: “When your system needs properties those tools fundamentally cannot provide, what do you reach for?” That’s where Neo (and blockchain in general) fits.

Sep 29 '25 16:09 erikzhang

Anti-mev needs to be added

Sep 30 '25 02:09 doubiliu

As someone who wrote light wallet SDKs, a compliant full node, a standalone indexer/explorer and a bunch of other tools (at COZ Github) since 2017 I feel we don't need this many new features (yet). The chain is already quite flexible but also hard to develop against, especially as a new comer. "Become a better developer" is the wrong attitude as it should be accessible without requiring deep knowledge of internals.

I lost count how many times I had to spin up a node from source to help Discord users debug their issues (this only recently improved with the extended RPC errors). Most likely quit the ecosystem shortly after hitting the next problem they couldn't figure out on their own.

I'd say make existing features easier to use before adding new ones. Things that come to mind that are still problematic to day

contract compliance checking The Supported Standards field in smart contracts cannot be trusted. You can put anything in there regardless if the contract actually supports it. There are contracts without nep-17 as standard that are compliant, and there are many with nep-17 that are not compliant. The most obvious issue that has existed since the nep-5 days is the amount field being returned as a ByteString instead of Integer type. This issue hit that. Despite it being closed it is actually still a problem one can trip on. It just has a work around you happen to be lucky to use.

There are many of such issues historically that are all linked to no strict checking of standards and emitted notifications. Less than 0.001% of the blocks on mainnet have a contract deploy. I can't think of an argument against doing this. This contract verification can be done on a side chain for all I care and take minutes to complete instead of in the first block with space since the tx was broadcasted.
Stricter NEPs in general. The existing NEPs are too loosely written for a standard, leaving not only too much room for interpretation but also causing integration problems later on. For example; the NEP-17 standard for the symbol method says

SHOULD be short (3-8 characters is recommended)

This should have been a MUST and restricted to a max number of characters. Now since it is a ByteString type its only limited by the MaxItemSize limit in the VM. Combine this with point 1. and it becomes much easier to develop against for SDK an tool writers. This in turn can result in more usage.

This is just one of many examples I can give.
Transaction sponsoring It is hard to virtually impossible to do safely beyond the most basic transactions. Most people probably don't even know it is possible to have a smart contract pay for transactions let alone know how to implement it. A fantastic feature if you as a company want to sponsor transactions. However, it's exceptionally hard to do (safely). You currently have to parse the transaction script in the smart contract and verify all opcodes are in a particular order and within an allowed set to prevent getting your funds drained by malicious actors.

One solution from 2021 (!) could be #2577.

Instead of dwelling on (micro) optimizations for the highest TPS (something I've see happen a lot during N3 development), fix some of the usability feature like above first. The truth is, 98.9916% of blocks on Mainnet up to this moment of writing consume less than 0.01% of the available transaction space in the block. That's an actual fact I pulled from the relational DB of our explorer. Having the fastest car is useless if it is undriveable.

Sep 30 '25 09:09 ixje

@ixje

Transaction sponsoring It is hard to virtually impossible to do safely beyond the most basic transactions. Most people probably don't even know it is possible to have a smart contract pay for transactions let alone know how to implement it. A fantastic feature if you as a company want to sponsor transactions. However, it's exceptionally hard to do (safely). You currently have to parse the transaction script in the smart contract and verify all opcodes are in a particular order and within an allowed set to prevent getting your funds drained by malicious actors. One solution from 2021 (!) could be #2577.

This can already be done with a custom verification and invocation script. Just look at this transaction's witness

https://neotube.io/transaction/0x4e914418c2e5f3c6f4300d3be6752c8134c079e027107566cd147eb783569cbb

Sep 30 '25 09:09 cschuchardt88

To @shawnmclean

S3 / Cloudinary vs Blockchain Storage We’re not claiming to replace S3 or Cloudinary for simple file hosting. The value of blockchain storage (e.g., NeoFS) is about trust, auditability, and programmability. Data is verifiable and tamper-proof, secured by an incentive model, and can be tied directly to smart contracts (e.g., NFTs with bound files, DeFi collateral proofs). That’s a layer cloud storage cannot provide.

Postgres / RDBMS vs Blockchain RDBMS solves single-organization data management. Blockchain solves multi-party trust. A Postgres admin can rewrite history; on a blockchain, history is immutable and auditable. If you’re building apps within one company, use Postgres. If you need verifiable state across multiple organizations, that’s exactly where blockchain shines.

Enterprise Ledgers vs Public/Consortium Chains Enterprise ledgers are usually closed, siloed systems. A public or consortium chain is interoperable, transparent, and consensus-driven. It reduces single-point trust and enables ecosystems to emerge around shared infrastructure.

On “Court the devs first” Agreed—this is critical. Neo’s choice of C# support back in the day was exactly about developer adoption, and that remains a core philosophy. We don’t expect you to abandon existing stacks; we aim to be a complementary layer when your use case requires verifiability, immutability, or multi-party trust. The question isn’t “Why replace Postgres or S3?” but rather: “When your system needs properties those tools fundamentally cannot provide, what do you reach for?” That’s where Neo (and blockchain in general) fits.

Disagree. Developers and users are both important. NEO, as a decentralized blockchain, should not be biased toward either users or developers. From the perspective of adoption, users are currently more important. When users come, they will also build for you. Remember, innovations like Uniswap and Hyperliquid were created by ETH users or developers from non-software backgrounds.

Sep 30 '25 16:09 nlesg

Many good points there, but let me concentrate on one that really worries me, that is

NeoVM 2: The next-generation virtual machine. Fully compatible with the RISC-V instruction set for broader hardware support.

It's a big thing that will happily eat a lot of developers time. But what is the problem we're trying to solve with this change? Does it worth this time spent?

I can only imagine two things RISC-V can theoretically improve: VM speed and compatibility (mostly compiler compatibility). And to me both don't change much in the overall picture.

Regarding VM speed. You all know we have extensively tested NeoGo for speed in various scenarios (this and this notably). A single N3 node with N3 VM can do 50K TPS. And this includes all of the pipeline from transaction acceptance into the pool to block processing. Even with this 50K transactions VM is just a part of the equation, while we usually test with NEO transactions that are native code we can also test with a simple compiled NEP-17 contract and the result is basically the same, even though VM executes a lot more instructions in this case. I think that even if we're to make VM execute 10× faster the overall throughput won't reach even 100K TPS. Mostly because it's still a pipeline and making one stage faster can expose more problems in other parts (try to just accept 100K transaction into pool in a second, without any blocks, think of DB commits).

But these 50K are single-node. When you take something more real like 4/7 nodes you quickly end up with just 20K under optimal networking conditions (local net or at least something with 25ms roundtrip). In which case nodes obviously have a lot of spare CPU cycles, but this doesn't help, the overall network bottleneck is communication, not execution. And that's optimal networking conditions. Try the same thing with 200ms pings (which are more realistic for mainnet) and you get 6-7K TPS, no more (like in https://github.com/nspcc-dev/dbft/pull/140#issuecomment-2582588402). What happens if you make VM 10× faster in this case? Nothing. You'd get the same 7K TPS and that's it.

Regarding compatibility. It's very tempting to think how easy it'd be to have any real RISC-V-compatible compiler ready for the platform. But then there are questions:

specific RISC-V ISA
execution environment isolation
startup time for managed environment (contracts in Go/Java/C#/Python)
contract interoperability

I won't dig into them deeper now, but I don't see any clear and efficient way to leverage existing "big" infrastructure that already supports RISC-V. Which means we'll still have to maintain some compilers or ports of compilers of our own. Which means we will again be spending time on these questions that seem to be solved for N3 already.

My point is that N3 VM is good enough for the purpose which is to run a lot of short-lived transactions in a very constrained environment. Resource metering improvements do not require a new instruction set. If I'd be thinking of implementing lambdas for NeoFS (which is something we still want to do in future) --- that's where RISC-V can be handy, a lot of code to execute in a single invocation with much more resources available to this code. But contracts don't need it.

Sep 30 '25 20:09 roman-khimov

Some Context

Over the past 8 years, I have spoken to thousands of people about Neo across a wide range of personas from normal individuals and devs/evangelists to US Senators, MEPs and large multinational corporations to the point of building custom products for them on both Legacy and N3. I have participated in nearly 100 Neo related hackathons, workshops, and conferences all over the world over the past decade.

This post tries to incorporate that external perspective while also providing consideration for our community who depend on us to deliver a healthy ecosystem for them to thrive. On a personal level, I have a very strong, self-imposed, parental sentiment towards this platform and its community. I want it to succeed and have a vested interest here beyond financial gain. This is my family.

Requirements and Vestigial Features

If we want to get real market penetration, we need to identify who we are as an ecosystem and who our target audience is, then define a user-centric strategy to deliver. The industry is very different than it was when we scaled our community in 2017 and our offering is too diluted across many different focal areas to compete. The trend of increasingly specific ecosystems and technologies will continue as the blockchain industry continues to expand, which will make our current approach of increasingly difficult.

We are mediocre at everything, but don't competitively differentiate anywhere because of packaging issues (minor features, UX, and basic expectations of a serious L1 like stablecoins) and a lack of technical focus on any singular goal. Some primary causes here are our technical debt (Neo legacy) and replication of features across multiple languages and teams, but its honestly caused by the lack of a mission statement so we try to do everything, which leaves us with an inferior product offering. We are stuck in 2017, despite our amazing core projects, and the broader industry has moved on to consider other topics.

Our ecosystem is VERY confusing for new devs because of the number of ways, both functional and broken, to do things. This is no fault on the project leads and is an issue with coverage. As a result of the number of poorly defined implementation paths, we are passed up for technically inferior (in my personal opinion), but easier to understand, platforms.

Streamlining the developer experience and throwing as much strength as we can muster to pull ramps, wallets, exchanges, and native stablecoins is imperative to enabling a heathy "crypto native" developer ecosystem. We need this infrastructure if we want projects to have token liquidity and a healthy VC ecosystem for funding them.

Blockchain is still a "hype" term in the VC space, but it is easier to raise for a project on Neo by not even mentioning that it uses our ecosystem because there is very little opportunity for listing of tokens (with exception of our favorite pink bird). This is in stark contrast with Neo Legacy where KuCoin listed many of our projects despite needing to support both UTXO assets and account-model tokens.

Regarding Real World Adoption

I want to introduce this section with a few points:

We have never encountered a scenario where an organization(not Web3) has had a problem with us developing a solution on Neo for technical or adoption reasons. In every situation, where there is a customer impact, its due to a failed BD partnership. We need anchor partners that are strategically selected to draw other collaborators and right now, we dont have any.
Our in-blockchain collaborations are also critically important and NeoX gives us an opportunity there. The anti-MEV capabilities are a differentiator, but I think the message is dilluted by my earlier point about us being "ok at a lot of different things". NeoX also serves as a spring boarrd for a much more powerful feature offering for our community since I think the ecosystem has acquired a lot of wisdom from working on that project.
A major differentiator (and undervalued opportunity) is stability. As a platform, Neo has been around longer than almost any other. N3 alone has been around longer than almost every other sponsor at Token2049 this year. Thats an incredibly strong selling point when engaging with organizations that honestly do not care if you use blockchain or not as long as the utility is there. In a world where L1s rise and fall on a yearly basis, stability is a big deal.

Conventionally speaking, potential integrators have architected their IT stack to operate on a Web2 architecture that has evolved over time to meet the needs of our global business culture. It is in our best interest to understand why that architecture has evolved in the way that it has and identify a solution that meets their needs without introducing unnecesary barriers. Adoption requires conversion from a solution that already works (unless the market is being creates) so any friction, like telling a custom that they need to rebuild their entire IT stack, reduces the value proposition.

The idea of a public-private (inter/intra) ecosystem is front of mind here. Organizations want to own their data and it doesnt make sense for them to pay transaction fees and additionally expose themselves to data leakage risks (like immutable PII GDPR violations) unless there is a clear value proposition. The governance risk (an organization needs to trust the governing body "the council") is also a major hurdle here since they are placing the faith of their organizational reputation in the hands of an external body (which could even be a competitor).

For these reasons, I believe that we should double down on a recursive interoperability architecture that allows ecosystem subchains (I use this term generally to refer to both public networks like Ethereum Mainnet and private networks of many flavors that are deployed internally to an organization) to leverage the utilities on a root NVM-based network.

It is incredibly difficult to design (and harder to implement) a product platform that has a high dynamic range of value propositions across multiple industries. The approach proposed allows organizations to specify on their intranet based on their business requirements, while leveraging what we do best.

Regarding Developers and Community

The developers and community are a major pain-point for me. I have trained and onboarded bright-eyed engineers into this community for nearly a decade and it is miserable watching them slowely become disengaged and leave. We spend significant resources acquiring new projects and community members, then slowely turn them against the community by abandoning them. This has been happening for a very long time and we need to solve it.

A few very quick wins here are for us to EoL all but one node implementation and compiler language or produce a new RISK-V compatible implementation and EoL everything we currently have. This will streamline the documentation and messaging as well as increase the product quality. I want to caution producing a new VM because, as @roman-khimov mentions, this will be a major project and I have not seen market demand.

Another pain point for us is the need for a ROBUST product accelerator/venture studio solution. COZ has tried to build this internally (ITEM Systems, Letter, Neon etc...), but we simply do not have enough resources and our domain speciality for an entire L1 ecosystem is not sufficient so it needs to be an ecosystem level offering. This needs to include packaged technical support, funding, BD, and marketing support with the end goal of sending the teams into a raise through a SAFT or SAFE. Templating this workflow and channeling teams through it gives them the support they actually need, brings eyes to the ecosystem, and anchors value.

Doubling Down on Strengths

The Neo ecosystem has always been "tech-forward" in my opinion and we continue to work on the edge in multiple subdomains within the industry. Over the years, we have driven many different speaking points to sell users: some successful and some unsuccessful. When discussing "Where should Neo go?", I think its important for everyone to have a strong understanding on the bullets that cleanly shut-down discussions surrounding the question "But why Neo?", because they represent our clear differentiators.

Legacy - Neo is one of the longest running decentralized software infrastructure platforms in existence. When discussing tangible business relationships that extend beyond a basic cross-marketing agreement, that is HUGE. Especially in an industry where the majority of blockchain projects never live to see sequential conferences.
Utilities - N3 is very unique for offering a number of services that are critical to contract developers as public services (utilities) that can be governed by the ecosystem. Monopolistic behavior in oracle and decentralized storage solutions is a major risk in other ecosystems and we are hardened against it, creating a safe, stable environment that organizations can trust.
Collaboration (A distinction from coopetition) - Despite current issues with ecosystem governance, there is a small, active community of leaders that have found a stable point that prioritizes collaboration. There aren't very many L1 ecosystems that ever reach this and its a major differentiator. Empowering and scaling that collaborative environment should be a major priority for us because its regularly brought up as a strength of ours even though we don't give ourselves enough credit for it.
Contract Modularity and Complexity - I'm pretty confident that our network's capability (purely from a technical feature set) is one of the most robust solutions on the market. Features like the witness scopes, multiple entry points, verification script overrides, and an extremely deep stack depth (compared to other L1s) really stand out. Simply put, our platform supports contract architectures and complexities that are difficult, if not impossible in other ecosystems.

Some Wing-Tip Proposals

Most of these proposals are high-level and designed to accommodate observed adoption issues with Neo and the industry as a whole. Generally speaking, we need a strategic focus because right now, there isn't one and it is creating a dilute and confusing product offering.

Making it Easier for Devs and Optimizing our Team

Cut node implementations - Right now, every feature requires over 2x the effort to implement as equivalent projects because of our multiple implementations and it honestly doesnt provide us with tangible value besides a few talking points. It makes things difficult for product devs who have to choose between two implementations with different features and documentation levels. This is made worse by the fact that many of these also have a legacy implementation (incl documentation) that needs to be navigated as well.
Cut contract compiler languages to adopt a DSL - (same justification as 1). Its a lot of wasted resources, is confusing for devs, results in a worse (dilluted offering), and isn't actually very marketable.
Heavily reinforce documentation - Especially tutorials, recipes, and dApp templates for the single, unified implementation to significantly reduce the cognitive load on new developers. This approach also introduces a unified technical support opportunity in contrast to the silo'd ecosystem that we have right now.

Creating Product Differentiation and a Market

Prioritize infrastructure focused decentralized technology and ecosystem utilities (no-deploy token standards, Identity, ZK, FHE, Secure Storage, AA, package management, custom types etc...) with the resources saved in (1) and (2) that let our product developers aggressively compete in the market.
Prioritize a fiat backed stable coin and exchange listings of NEO/GAS w/ agreements to support ecosystem projects.
Invest in a public-private ecosystem architecture including a robust, native bridge solution that exposes child-chains and other L1s to interop and native utilities on our root network. This functionality is critical to meet requirements of many traditional organizations and allows projects to tune the network to meet their needs instead of imposing costs and requirements on them.
Seed a number of strategic business relationships as anchors for case-studies and collaboration opportunities with incoming project teams.
Give Neo decimals - Integrations for non-EVM ecosystems are complicated due to custom imfrastructure requirements. Our integer-based native token completely breaks many exchange implementations and introduces technical complexities that dont return significant market differentiation, while simultaneously causing us a lot of pain from a BD and interop standpoint.
This has already been mentioned by @erikzhang , but I think we should decouple GAS rewards from voting, despite my regulatory concerns at CentrePoint. The dual token model is complicated and has corner cases where users can get stuck (a wallet holding NEO without GAS). We have also seen through bNEO that many users are only interested in rewards, not governance. This creates a situation where uninformed voters are heavily skewing governance. Distribution of GAS to all NEO holders (same as Legacy) simplifies the narrative and removes noise from ecosystem governance. The Council members can then campaign to informed voters and offer their own incentives.

Oct 07 '25 12:10 lllwvlvwlll

Look good. At the same time this project needs some massive marketing efforts, otherwise we'll be on the same merry-go-round as N3, cool tech but nobody has ever heard of it thus no adoption.

Oct 10 '25 11:10 CicerBro

Updating my suggestions from some days ago from chat to github.

I think that the PR mentioned above, involving dBFT double speakers, is in line with possible improvements on consensus decentralization.

So, updating what we discussed:

From my side I am in favor of :

1 - Porting anti-mev features to the "mother chain", we contributed for that design and we believe that it is well designed and suitable for N4 in a medium term. It does not need to a be a feature to be enabled first, but could be on the roadmap.

2 - The Double Speakers PR is open until today and still compatible. Double speakers are of great potential for avoiding delays on blocks due to ONE Change View, as well as offering opportunities to allow a node open to public. We could have a list of addresses and sort one each round to be the fallback. That is good for the decentralization image and offer possibility for USERS and GENERAL Public to propose their block (because we will probably have both plaintext, similar to http, and encrypted txs in the future , similar to https).

3 - Generic Smart Accounts models that users can easily manage accounts safely, with multi-signatures, timelocks and etc, possibility of censorship and etc. I believe it is very import to evolve the smart accounts models (which was quite possible on N2 with the old verification script). That is of great potential for compliance with many real world applications for coins. I believe that Smart Accounts needs to be on N4 Roadmap. They are important for many reasons, such as robberies, kidnappings. AI tools embedded on-chain can now censor transactions if owners of the accounts wants.

4- In the line of AI, nowadays we see a VERY OPEN FIELD to embed AI on every deployed smart contracts (optionally). AI agents can verify literal strings written by the developers. So, AI agents can check every deployed SC (if owners check that desire) and these agents could verify the written explanation of each function and functionalities of the contract, which should be meticulous described by developers. That can ensure that upgrades are verified by these agents. There is a very open and promising field on embedding AI agents onchain verification, because that was not possible some years ago, both for smart contract security but also for smart accounts verifications before txs is applied.

In addition to that, I affirmed my support to:

Stablecoins as crucial. Communities and dapps are requesting that for a long time. So, as founder and maybe the BEST dev of our team (@erikzhang), you can surely prepare the system to attend demands that the huge stablecoins providers want N3/N4 to have.

Furthermore, I added that:

In addition:

We are involved in RWA here in Brazil and recently we are engaged in obtaining a license for doing CrowdFunding for securities of Small Enterprises here in Brazil. Brazilians enterprises (approved by the platform) will be able to make a public offer up to around 3M USD/YEAR. The limit will possible be increased to 5M USD in the next years following public discussions that are trying to improve the regulation. In this sense, I believe that improvements on NFT standards that meet requirements of RWA are in the correct directions. Neo should be complaint with that as you mentioned, allowing distribution of dividend/profits and tools to make the companies transparent on how to use funds (but also allowing the company to apply on safe liquid pool for the money to keep being useful before spent).

Finally,

Whitelist of Free Contracts, zk-KYC and zk-Oracle are incredible and they are exactly what many real world applications are searching for. While tools for zk-KYC and zk-Oracle improved considerably in the recent years, I believe that the NGD team has great minds for doing that (such applications were much more difficulty to be done 3-4 years ago - now this knowledge is much more consolidated).

And regarding Whitelist of Free Contracts I believe that IT is possible ! We just need a set of rules and requirements. That is obviously possible if we have protection and well defined rules.

Oct 10 '25 15:10 vncoelho

I'm in favor of the proposal of @lllwvlvwlll to give Neo decimals

Oct 10 '25 16:10 shargon

It's really great to see some strong discussion and new winds for Neo, and with some years teaching Neo to younger students, some experiences that stand-out, but were already mentioned by Erik, Tyler and others:

Our ecosystem is VERY confusing for new devs because of the number of ways, both functional and broken, to do things. This is no fault on the project leads and is an issue with coverage. As a result of the number of poorly defined implementation paths, we are passed up for technically inferior (in my personal opinion), but easier to understand, platforms.

For me, this is the fundamental problem for attracting new devs for blockchain (not only Neo problem)... new devs will either not code properly in a impossible or very insecure manner, or rarely, code properly but follow some infeasible path due to other blockchain limitations (price, efficiency, privacy, etc). Some newer blockchains have greater scalability, much greater, with also much lower decentralization than Neo, so I'm still skeptical that this is the best path for a public blockchain project. It seems that devs (and also AI-agent devs) are becoming more and more oriented to using solutions that are modular and ready to use, secure enough and abstracting away the blockchain challenges... I don't think Neo or any other blockchain can do this at this moment.

Fully compatible with the RISC-V instruction set for broader hardware support.

I fully agree that RISC-V is the way to go, and I've seen some blockchain prototypes in this direction... and they can do awesome things, just because they can reuse most things that already exist in this world, not reinvent them. If such VM becomes very easy to design and maintain, it could be doable.

The idea of a public-private (inter/intra) ecosystem is front of mind here. Organizations want to own their data and it doesnt make sense for them to pay transaction fees and additionally expose themselves to data leakage risks (like immutable PII GDPR violations) unless there is a clear value proposition.

This is a typical problem that flaws many potential interesting applications... perhaps if a more user-data oriented view is put on blockchain, specially in a way to manage storage "by user", also verifying the results expected by the user on the executions, we could easily enforce some privacy constraints onchain and allow easier reuse of Neo in both public and private blockchain scenarios, with same technology (perhaps even some zk-KYC tech).

Finally, I also agree with some focus on interoperability, more open governance and participation, that would require a more open consensus process as frequently rediscussed by @vncoelho and me. If more nodes participate, and if we have remove nodes that are careless about the ecosystem, we need such features. On general, I think we may need some feature to make hard forks easier, and even maintaining multiple states on consensus, if necessary, during some hard fork transition. Data is immutable but protocol is highly mutable, so we need to make an easy way for the technology to evolve, and make it extremely simple for users to build secure and decentralized applications, which is the essence of blockchain tech.

Oct 11 '25 03:10 igormcoelho

Let's be real- crypto is essentially a way for bankrupt, centralized governments to indirectly offload debt securities (war bonds, treasuries, currencies etc.) to the public, or to introduce a CDBC where they can monitor (and potentially control) all of the public's transactions. The only other 'real' use case I've seen emerge are prediction markets, and its a question whether blockchain is even needed for that, though it likely doesn't hurt, I suppose.

Trying to tie blockchain to real-world assets requires buy-in from highly centralized legal and political systems (i.e. governments), else there is no enforcement of transactions because all assets have to exist in and navigate within complex legal and economic entities in order to change hands. This goes for real-estate, securities, loans, you name it. Such transactions can never be "trustless" without enforcement and buy-in from an over-arching legal jurisdiction.

Trying to tie physical real-world assets onto a blockchain seems to be even more of a hopeless endeavor- RFID tags and labels can be removed, replaced, hacked, etc. Serial numbers inscribed on precious metals (like gold) can easily be etched out and replaced. Same goes for CPU's and sensors hidden in electronic products- they can be removed and replaced. How can this process ever be "trustless"?

We've seen a number of upstart blockchains surpass NEO in popularity, but my guess is that many of them are getting 'insider' buy-in from the powers that be (i.e. the Western and soon to be Eastern government/ business nexus) to be part of the financialization chain that is taking place as described in the first paragraph. As governments collapse economically, they will try to roll out this new system to stave it off. These other blockchains are not necessarily better or more idealized that NEO, but they are definitely better connected at this point within the flourishing government- stablecoin train. This is why their market valuations are skyrocketing- it is purely speculation that they will be 'chosen' by the powers-that-be for this new, planned add-on to the existing financial system.

I admire the strenuous efforts put together by longtime, talented, core developers above like @lllwvlvwlll @shargon @igormcoelho etc., but I don't think the community should operate under the false pretense of what we imagine blockchain is capable of in a world that still requires trust and enforcement from governments. There's been a lot of talented development come through NEO, including launched projects and via the various hackathons, but they never went anywhere because the real-world use case simply wasn't there, so the projects died. I don't think it's simply a matter of marketing or even poor dev experience, though certainly that could be improved. But if it was improved, what would you build?

Planning for the future of NEO requires us to be honest what blockchain is really all about, versus what we think it should be. I could be wrong, so I'll just leave my words here for anyone to debate.

Thanks,

Oct 13 '25 04:10 robliou

Please provide a general use case for real world assets. I'm not following...

Oct 15 '25 02:10 onezeroxray

Can we add to 2.1 Consensus & Networking the proof of node?

Oct 22 '25 12:10 shargon

“Echoes drift through hollow dapps,
ghosts trade stories for gas.”

🌑 Coin dust whispers. Neo flickers.
💀 Time forgot, but I didn’t.
🕯️ Welcome to my favorite ghost town...

Oct 22 '25 17:10 flaukowski