[Core MD] Clarify repo scope: C# implementation ≠ Neo Core protocol

[Jim8y]

Description

This PR formally redefines this repository as an implementation of the Neo Protocol (akin to NeoGo), not the Neo Core itself. It addresses historical conflation between implementation details and protocol authority that has hindered maintenance.

Problem Statement

Since we merged repos into a mono repo, we've conflated the C# implementation with the Neo Core protocol due to:

1. Undocumented Origins: Early protocol designs were directly coded in C# without formal specs
2. Authority Fallacy: The absence of reference documentation led to treating this codebase as canonical truth
3. Scope Bloat: Non-protocol components (CLI, GUI, plugins) became entangled with core protocol logic

This has caused:
⚠️ Maintenance Paralysis: Resistance to modify "core"-labeled non-protocol components
⚠️ Unrealistic Expectations: Assumption that all repo code is protocol-mandated and bug-free
⚠️ Innovation Bottleneck: Difficulty introducing non-protocol improvements

Why This Matters Now
As Neo matures, we must:

1. Enable protocol evolution without implementation coupling
2. Decoupling reference specs from any single codebase
3. Empower contributors to improve tooling without "core" constraints

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[roman-khimov]

Do you have a definition of "Neo blockchain protocol"? If not, then what are we implementing here? Until we have this solved this repository is the protocol definition, unfortunately. You can't write an implementation against some standard definition now, you have to follow what is done here.

[roman-khimov]

And it's Neo, btw. NEO coin, Neo blockchain.

[Jim8y]

Do you have a definition of "Neo blockchain protocol"? If not, then what are we implementing here? Until we have this solved this repository is the protocol definition, unfortunately. You can't write an implementation against some standard definition now, you have to follow what is done here.

Neo blockchain protocol is another topic either tc can decide or neo foundation can decide. I don't think that can be of any issue for 'csharp implementation'. Similar question can go to any blockchain project, what is ethereum protocol, what is bitcoin protocol, what is sui protocol.

[roman-khimov]

what is ethereum protocol

https://ethereum.github.io/yellowpaper/paper.pdf + EIPs

It's not that I prefer to have an implementation be the definition of the protocol, it's just that we don't have anything else at the moment and we can't ignore this fact.

[Jim8y]

I thought about it for a while, neo blockchain protocol should be combination of a few subprotocols: neo-gas economy protocol, dbft consensus protocol, neo vm contract/execution protocol. This should be in side of a neo white paper, then extended and detailed in many many NEPs.

[vncoelho]

Agreed with @roman-khimov

[Jim8y]

what is ethereum protocol

https://ethereum.github.io/yellowpaper/paper.pdf + EIPs

It's not that I prefer to have an implementation be the definition of the protocol, it's just that we don't have anything else at the moment and we can't ignore this fact.

Neo whitepaper: allcryptowhitepapers.com/neo-whitepaper/

Neo NEPs: https://github.com/neo-project/proposals

protocols are system ruls, it can be verified, analyized, proved.
Implementations are actions to fulfill the rules, it can be run, tested, and benchmarked, but may contain bugs....

This repo implements neo protocol, but it also implements other things that are not part of the protocol.

I understand that the csharp implementation used to be the main place where the design is done, but fact is neo repo also contains many things that should not be considered part of neo protocol, the GUI, the CLI, the plugins. Implementation is implementation, it can have features and tools that is not part of the neo protocol and other implementations do not need to follow.
And when people use that code to run neo, it is not because they trust that implementation has no bugs and works perfectly, but it implements the neo protocol and is provided by default, they can also use neogo if they like, as neogo is another neo protocol implementation.

You guys also wrote many NEPs, so you definately know where the protocols should be.

[vncoelho]

I agree, @Jim8y

But the time has not come yet for that. We need a better protocol specification document that is strictly connected to the NEPS (proposals repository).

After that, I believe that the change in this PR will be more suitable.

[Jim8y]

I agree, @Jim8y

But the time has not come yet for that. We need a better protocol specification document that is strictly connected to the NEPS (proposals repository).

After that, I believe that the change in this PR will be more suitable.

@vncoelho i am not saying of any big change to any code, just a few lines of specification to this repo..... take a look at those few words change, you will find that nothing actually need to be done for real. Just explicitly tell people that this repo is a csharp implementation of neo protocol.

[cschuchardt88]

@Jim8y is right!

NEPs are for the defining the protocol for neo.

I am sick of moving forward 1 step to just go backwards 10 steps. By developers and community members wanting some new feature built into the protocol. Changes NEEDS to be detailed in a NEP paper in proposal repo. That goes for Notary contract and many many other things. I HATE how a developer doesn't put any thought into the design and implementation in code. Just because @roman-khimov knows how it works and needs to work. Doesn't make it right or ok. We all need to know the protocol for such things (not just developers). All developers say Neo's Protocol is a black box. So where does the standards come from? READING THE CODE. Bad or wrong implementation leads to changes in standardizing neo protocol for non-developers. This is one reason why no one uses neo protocol for bridging funds from other blockchains or anything else related. Also why no contract developers, seeing how you have to read code in order to find out how something works. So please make the necessary changes to stop this behavior. Only than maybe others will use neo protocol, seeing how they can now know what the hell it's protocol is and features are.