Neo's own history traces the project to Da Hongfei and Erik Zhang in 2014, followed by publication of source code in 2015 and the Antshares mainnet in 2016. The Neo name arrived in 2017. Its stated mission is broader than issuing a currency: make digital and physical assets usable by people and programs with less reliance on permission and trust. That is the project's organizing ambition. A token representing a physical asset still needs a credible relationship to the thing and rights it claims to represent.

The N3 launch announcement gives a precise transition point: August 2, 2021 at 09:00 UTC. Incompatible changes required a new chain, so Legacy and N3 coexisted during migration. Native tokens and application assets did not all follow identical procedures; NEP-5 projects needed N3 contracts using the newer standard. This history explains why a long-standing brand can cover more than one ledger. An old wallet export, a familiar ticker and a current exchange listing do not by themselves identify which network holds an asset.

NGD's April 29, 2025 notice scheduled Legacy TestNet retirement for June and Legacy MainNet shutdown for October 31. It warned that block production and core functions would end and asked users and projects to migrate beforehand. The notice is a dated shutdown plan, not an independently observed final-block receipt. This review does not turn its historical portal instructions into a claim that migration remains available in September 2026. Anyone assessing an old balance must establish its actual network and the current status of the relevant service.

The developer migration guide documents why moving an application was more involved than changing its display name. N3 changed compiler tooling, contract behavior and platform interfaces compared with Legacy. A user's expectation that an old application will simply reappear on the newer chain therefore needs a project-specific deployment record. Migration can preserve an economic intention while changing contract identifiers, code and operational dependencies.

For developers, this is a compatibility problem; for holders, it is a reminder that the chain's migration and an issuer's migration are separate responsibilities.

The native-token model separates governance participation from resource payment. NEO has a total supply of one hundred million and is indivisible at the protocol level. GAS is divisible and pays for transactions and contract-related resources. This lets an account spend for network use without spending the same units that determine its NEO voting position. It does not make the two market prices move together, and an exchange's fractional NEO account balance should not be confused with a fractional native transfer on the chain.

The technical FAQ divides GAS charges into system and network fees. System fees cover operations such as contract execution and deployment and are burned; network fees compensate consensus processing. That split matters when discussing value capture. Activity can consume GAS while payments to operators and new issuance operate elsewhere in the same economy. A burn counter is therefore only one side of the supply picture. Holding NEO and using an application are also different activities, with different reasons to acquire or retain GAS.

N3 governance documentation describes candidates, an elected council of twenty-one and a seven-member consensus subset. NEO voting determines representation, while the council can adjust network parameters and appoint certain service roles. This creates a clear administrative surface rather than eliminating administration. A public observer should distinguish open candidate registration from the distribution of voting power and the independence of elected entities.

The availability of an election mechanism does not imply that every holder votes or that every listed node represents an unrelated organization.

The dBFT specification explains the consensus side through signed proposals, preparation, commitment and recovery messages. Its fault-tolerance model assumes a bounded number of faulty validators. Within those assumptions, a committed block offers single-block finality rather than a growing probability of settlement after many confirmations. This is not a promise that software cannot contain bugs or that a network cannot lose liveness when too many required participants are unavailable. The relevant security question includes both the algorithm and the operators responsible for executing it.

On February 25, 2025, NGD reported executed reductions to execution, storage and per-byte fee factors. Its explanation described an eleven-of-twenty-one signature requirement for the council's implementing transaction. This is a concrete example of governance affecting a user's costs without changing what NEO and GAS fundamentally represent. It also shows why a fixed fee quoted in a historical tutorial can become stale. The ledger transaction and current parameter state are stronger evidence of the charged rules than a copied marketing comparison.

The April 27, 2026 announcement reported another executed change: a three-second block target paired with issuance of one GAS per block. Adjusting both together preserved the intended issuance pace while improving responsiveness. The announcement linked the implementing transaction and recorded thirteen council approvals. Older pages still describing five GAS per block should therefore be read as historical configuration. A target interval is a protocol setting, not a guarantee that every transaction reaches a user's application within exactly that time under all conditions.

Neo's technology account emphasizes support for familiar programming languages and compilation to NeoVM's execution format. Its integrated approach aims to reduce the number of unrelated infrastructure pieces an application team must assemble. This is a developer-experience thesis, not evidence that every language has identical tooling or that code written for another virtual machine can be deployed unchanged.

The useful distinction is between bringing existing programming skills to Neo and assuming that the semantics, permissions and resource costs of a different chain carry over automatically.

The contract-update guide explains that an application can implement update and destruction interfaces. An update can preserve its contract hash and stored data while changing code. For a user, a stable contract address therefore does not necessarily mean a permanently fixed program. For a builder, authorization around those operations is part of the security design. An audit or explanation of a Neo application should identify whether upgrades are possible and which conditions permit them, rather than relying on the word blockchain to imply immutability.

Neo's native oracle service uses designated nodes to fetch external data and return a signed response for a contract callback. Requests can refer to supported HTTPS or NeoFS resources. This is useful when a program needs information absent from its own ledger, but it changes the trust boundary: agreement on a fetched response is not an independent guarantee that the original website describes the world truthfully. Timeouts, missing resources and insufficient funding are explicitly represented outcomes, so applications must handle failure rather than assume every request succeeds.

NeoFS organizes off-chain data into objects and containers with placement policies and access controls. Wallet-derived identities and session or bearer tokens govern permitted operations. This gives an application more expressive storage options than putting every file into contract state. It also creates configuration responsibilities: who can read, overwrite or delete data, where replicas should reside and which credentials authorize requests. A token ownership record and access to its associated media are different objects, even when a product presents them together in one screen.

NEP-17 defines the standard interaction surface for fungible assets on N3, replacing the Legacy NEP-5 convention. Balances live in contract storage and transfers update those balances through the contract. Standard methods let wallets and applications integrate an asset consistently. They do not establish that the issuer has reserves, that an advertised redemption exists or that a similarly named token is the original. Contract identity, supported behavior and the issuer's external obligations still need to be examined separately from interface compliance.

The smart-contract basics guide makes authorization tangible through witness checks. A method that changes ownership-sensitive state must verify that the appropriate account authorized the transaction; displaying an address in a request is insufficient. Event notifications then help external applications track what execution reported. These are ordinary engineering responsibilities within a sophisticated platform. They explain why an application failure should be traced to its relevant permission or logic boundary instead of automatically being described as a failure of Neo consensus itself.

The July 2024 Neo X launch introduced an EVM-compatible sidechain alongside N3. The announcement identified separate bridge validators, a relayer and bridge governance, and explained that GAS originated on N3. These details prevent a common identity error: a shared ecosystem and resource asset do not make two chains the same ledger. Its initial standby-validator arrangement was a launch configuration. Current control should be checked from later governance evidence rather than assumed unchanged or automatically decentralized because an election was planned.

A September 15, 2025 Neo X announcement reported activation of its anti-MEV functionality at a specific block. It described encrypted transaction envelopes and threshold decryption as the design's tools. That later announcement supersedes the launch post's statement that envelopes were still forthcoming. The feature belongs to Neo X, so it should not be silently attributed to N3 transaction processing. The team's broad fairness claims express its intended benefit; they do not independently measure every possible trading disadvantage or make a bridge transfer risk-free.

The foundation's temporary-committee portal publishes expenditure records, a disclosed address and transaction references, with entries through September 17, 2026 at review. It describes itself as a response to extraordinary institutional circumstances and a step toward future governance reform. Some entries provide general payroll descriptions, while an infrastructure expenditure remains confidential pending a stated process. Those are material disclosure boundaries.

A visible transaction supports that a transfer occurred; it does not on its own reveal every recipient's work, the authority behind the decision or whether the spending was effective.

In issue 233, lerider demanded a committee roster, spending rationales and stronger council oversight. The issue's allegations about mandate and control are the author's position, not an adjudicated finding of misuse. A protocol election can coexist with disputed foundation administration; each deserves a distinct assessment of authority and accountability.

In DigitalCoinz's September 2025 voting discussion, Elean0rZ distinguished maximizing GAS rewards from supporting a representative's contribution to the ecosystem. The same reply questioned the political result if automated reward optimization dominated voting. This is a recognizable tension within Neo's culture: participation is financially encouraged, but the cheapest route to a reward is not necessarily the most deliberate assessment of a council candidate. The thread explains a participant's reasoning without proving that all voters choose one motive or the other.

A January 2026 discussion displayed a different divide. Helftheuvel expressed exhaustion after years of holding, while Sad_Potato6296 invoked earlier market cycles as a reason for continued optimism. Those are personal accounts of confidence and disappointment. Past rallies do not prove a repeat, and disillusionment does not independently establish that a network stopped operating. Their disagreement is valuable historical evidence of how longevity can support opposite narratives: accumulated technical survival for one participant, accumulated opportunity cost for another.

The June 2026 v3.10.0 notice described wallet mnemonic support, transaction-validation improvements, diagnostics and relay tooling, while explicitly saying that this release did not activate Gorgon. It is a useful example of substantive maintenance beyond a promotional roadmap. Better diagnostics and transaction handling matter to builders even when they do not change token economics. The notice's proposed deployment dates remain plans within that document; a release date should not be silently substituted for a separately verified mainnet activation time.

The July v3.10.1 notice then prescribed Gorgon activation heights and corrected wallet fee calculation, startup behavior and storage-path handling. Its fork-time estimates were expressly approximate. This account therefore records the published release and required changes without inventing a precise observed activation timestamp. Read together with the council's executed April parameter change, the records show different kinds of progress: code maintenance, scheduled consensus changes and an actual governance transaction.

Each has a different evidentiary status and a different practical effect.