Open Network X

Open Network X (ONX) is an independent blockchain project designed for the next decade, using the architecture and technical vision described in the original The Open Network (TON) white paper as a reference rather than a contract.

The meaning of X is intentionally left open pending owner wording (ADR-0065). ONX is not a successor to TON, and it has nothing to do with X, the social network.

ONX develops an independent chain from first principles, making explicit decisions for durable operation. It is not the TON blockchain, is not an official continuation of TON, and is not intended to replace the existing TON network or its community. The native currency of Open Network X is Onyxi (ticker: ONXI).

Contents

• What is Open Network X?
• Independence
• The white paper is a reference, not a contract
• Onyxi
• Project philosophy
• Project status
• Websites
• Changelog and roadmap
• Milestones and the maintenance gate
• Development tasks
• Research
• Contributing
• Volunteer roles
• Repository structure
• Quick start
• Long-term goal
• Disclaimer
• License

What is Open Network X?

The original TON design describes a highly scalable, decentralized blockchain architecture built around concepts including:

• Masterchains, workchains, and shardchains
• Dynamic sharding
• Asynchronous message passing
• Validator networks and Byzantine fault-tolerant consensus
• Smart contracts and a specialized virtual machine
• Distributed storage
• Scalable blockchain infrastructure

Open Network X exists to investigate what it would look like to implement that architecture independently. The guiding question is:

How can an independent chain use the original design as a reference while meeting the needs of the next decade?

ONX is therefore not intended to be a conventional fork. We are not taking an existing implementation, changing its name, and continuing from there. Instead, the project begins with the protocol's published design and works forward toward an independent implementation.

Independence

Open Network X is a separate project. ONX:

• Does not claim to be TON.
• Does not claim to represent the TON Foundation, TON Society, or the TON community.
• Does not attempt to replace the existing TON network.
• Does not require the existing TON network to function.
• Does not treat the current TON implementation as the authoritative specification for ONX.
• May make independent technical decisions where the original specification is ambiguous or incomplete.

Similarity between ONX and existing TON architecture is intentional where that similarity follows from the original protocol design.

The white paper is a reference, not a contract

The original TON white paper (WHITEPAPER.md) is a historical and architectural reference, included in this repository unmodified. It is not a contract that every ONX feature must reproduce. When an assumption in the paper fails for a chain designed for the next decade, ONX may depart from it; each departure must have its own ADR naming the exact paper section and explaining the reason.

The white paper informs the written ONX specifications, which remain the implementation's source of truth. The current design, interpretations, and departures are recorded in specifications and ADRs.

Onyxi

Onyxi is the native currency of Open Network X. The currency exists as part of the ONX protocol rather than as a separate application-layer token. The exact monetary policy, denomination system, issuance mechanism, validator economics, transaction fees, and other economic parameters will be specified as the protocol develops.

Project philosophy

ONX follows several principles:

1. Written design before implementation. We begin from an explicit protocol design, not existing source code; specifications govern implementation and can evolve through recorded decisions.
2. Independent implementation. Existing implementations may be studied for educational and interoperability research purposes, but ONX is intended to be independently implemented.
3. Explicit decisions. When reference material does not provide an answer or a paper assumption fails for a next-decade chain, the project records the decision instead of silently inventing behavior; every departure names its paper section in its own ADR. Obsolete paper features, including payment channels, may be dropped through that process.
4. Testable protocol behavior. Important protocol properties should eventually have deterministic tests.
5. No accidental compatibility. ONX should not inherit compatibility with another network merely because doing so is convenient — compatibility must be an intentional protocol decision.
6. Transparency. Interpretations, departures from named paper sections, limitations, and known incompatibilities are documented openly.

Project status

Phase: development. ONX is being built, not maintained. It switches to maintenance when every box in the maintenance gate (M8, 1.0.0) is checked.

Now: M7, A public testnet other people can use (0.6.0 – 0.9.x): 0 of 8 exit criteria met.

M0 ✅ ── M1 ✅ ── M2 ✅ ── M3 ✅ ── M4 ✅ ── M5 ✅ ── M6 ✅ ── M7 ▶ ── M8 🏁

	Milestone	Version	Progress
✅	M0 · Specifications and protocol libraries	0.1.0 baseline	done 2026-09-10
✅	M1 · Deterministic replay	in 0.2.0	done 2026-10-05
✅	M2 · Single-node chain: TVM, message model, hardening	in 0.2.0	done 2026-10-07
✅	M3 · Authenticated blocks, devnet-1, release engineering	v0.2.0 tag	done 2026-10-08
✅	M4 · Pay down debt: a single node you'd trust	0.3.0	done 2026-10-09
✅	M5 · Networking: nodes find each other and stay in sync	0.4.0	done 2026-10-09
✅	M6 · Consensus: more than one validator	0.5.0	done 2026-10-12
▶	M7 · A public testnet other people can use	0.6.0 – 0.9.x	░░░░░░░░░░ 0/8
🏁	M8 · Maintenance gate: stop developing, start maintaining	1.0.0	░░░░░░░░░░ 0/16

Progress counts the exit-criteria checkboxes in MILESTONES.md; a box is ticked in the PR that earns it. There are no target dates. This block is generated by scripts/site.py build, and site.py check fails when it falls behind.

Pre-release, latest tag v0.3.0. What M0–M6 delivered: deterministic replay (onx replay --genesis genesis.toml --blocks ./blocks/ executes, persists, recovers, and replays a chain to identical state roots), TVM contract calls and the message model, authenticated ONXBLK05 blocks, followers that sync and verify blocks over ADNL (M5), and BFT consensus with several validators, partition and restart safety, and equivocation evidence (M6).

Protocol version 2 (the T14 batch, before 1.0) changes genesis and the chain ID: scheme-tagged keys and signatures with SLH-DSA-SHA2-128s and hybrid validator keys, AuthRoot addresses with backup keys, account key rotation and backup recovery, validator rekeys, wallet-handler policies, on-chain upgrade activation, 5-second slots and named consensus limits (release notes, ADR-0066 to ADR-0072). devnet-1 runs protocol version 1 until that release ships.

devnet-1 is a single-producer development chain run by the project. Its blocks are published at data.on-x-scan.com/devnet-1/ and shown by the explorer. It is not a public testnet: it still runs one producer, so the multi-validator consensus in the code (M6) does not run on it yet. A public testnet is milestone M7.

Everything below is graded honestly — no "done" claims the code hasn't earned.

Component	Spec	Logic	Integrated	Adversarially tested
onx replay command	✅ plan	✅	✅	✅ kill -9, corruption, two-process, golden vectors
Canonical encodings (BoC)	✅	✅	✅	✅ 50× probe, cross-process byte-identical
Genesis (real accounts, chain ID)	✅	✅	✅	✅ cross-process determinism
STF — message execution (wallet handler + delivery)	✅	✅	✅	✅ bounce, redelivery, ordering, kill-9, two-process
Merkle proofs	✅	✅	✅	✅ fabricated/absent-key proofs rejected
Atomic storage + crash recovery	✅	✅	✅	✅ 100× kill -9, full-or-nothing
onxd block-production loop	✅	✅	✅	✅ spool mempool, demand blocks, replay-to-identical-roots
VM / TVM execution	✅	✅	✅	⚠️ partial — LDREF child-cell bug fixed (#7, vm_child_cells.rs), checked arithmetic (#8), tvm_execution has a fuzz target, JMPREF/CALLREF work from real contracts (#32, callref_stf.rs); open: nested calls after an implicit return, padding bits of bit-granular code cells (M4)
Consensus	✅	✅ BFT with locking (ADR-0049, ADR-0052)	✅ onxd runs it; 4 real nodes finalize over TCP in tests; devnet-1 still has one producer	✅ split-lock scenario, seeded Byzantine simulation, forged/unbounded-vote tests, catch-up of an offline validator, partition-and-heal and a Byzantine voter with real nodes (partition_safety.rs), restart safety (ADR-0057), invalid-block rejection, 6.3 h soak (ADR-0056)
Networking (ADNL/DHT)	✅	⚠️ partial	⚠️ partial	⚠️ partial — block-sync wire protocol + ADNL datagram transport + follower sync loop (M5, follower_sync.rs, multinode-sync-test.sh); open: peer discovery/DHT, mempool gossip, broadcast overlay
Sharding	✅	❌	❌	❌ — frozen
Payment channels	✅	❌	❌	❌ — frozen
RPC / telemetry	✅	partial	❌	❌ — frozen

"Adversarially tested" means a probe tried to break it — torn writes, fabricated proofs, corrupted files, killed processes — and it held. A green test suite once coexisted with all four original bugs; the probes are the point, not the suite.

See CHANGELOG.md for release notes, ROADMAP.md for the per-PR history and roadmap of what has been built, MILESTONES.md for the milestones still ahead and the criteria for switching from development to maintenance, and CONTRIBUTING.md for the workflow every contribution is expected to follow.

Websites

Site	What it is	Source in this repo
on-x.live	Project site: what ONX is, how it is built, and its current status	site/
on-x-scan.com	Block explorer for devnet-1. Verifies every block in the browser against the pinned genesis hash	explorer/

Both sites are single static HTML files deployed from this repository. Facts on on-x.live that come from the repository (version, counts, ADR and specification lists, the build it describes) are generated by scripts/site.py; python3 scripts/site.py check, run locally before each push, fails when they drift from the repository. What each domain actually serves is compared against main by hand — there is no scheduled check. See site/README.md.

Repository structure

.
├── .github/                 # PR template and helper scripts (no CI workflows)
├── config/
│   └── genesis.toml         # Default genesis configuration
├── contracts/system/        # Masterchain contract adapters and TVM fixtures
├── crates/
│   ├── protocol/            # Consensus-critical protocol crates
│   ├── node/                # Runtime, networking, RPC, and telemetry crates
│   └── tooling/             # CLI and genesis-generation crates
├── docs/
│   ├── adr/                 # Architecture decision records (one series, 0001–)
│   ├── decisions/           # Retired ADR location; README maps old numbers
│   ├── specification/       # ONX protocol specifications
│   ├── planning/            # Research logbook and development tasks
│   ├── guides/              # Operational and local-network guides
│   ├── generated/           # Archived log from the retired spec-tracker workflow
│   ├── reference/           # One-off reference and audit notes
│   └── research/            # Research reports and work plans
├── explorer/                # Block explorer served at on-x-scan.com
├── fuzz/                    # cargo-fuzz targets
├── reference/               # Independent Python reference implementation and golden vectors
├── scripts/                 # Repository checks and maintenance tools
├── site/                    # Project site served at on-x.live
├── tests/simulation/        # Python model of a multi-node network (not real binaries)
├── Cargo.toml               # Rust workspace
├── Cargo.lock               # Locked dependency versions
├── CHANGELOG.md             # Release notes per version
├── INSTRUCTIONS.md          # Development principles for this repository
├── CONTRIBUTING.md          # Contribution workflow
├── LICENSE                  # Project license
├── MILESTONES.md            # Milestones and the maintenance gate
├── ROADMAP.md               # Per-PR history
├── WHITEPAPER.md            # Reference white paper (unmodified)
├── deny.toml                # cargo-deny configuration
└── rust-toolchain.toml      # Rust toolchain pin

Quick start

ONX is for developers and researchers who want to read, run, or try to break an independent implementation of the TON architecture. It is pre-release: there is no public network yet (see Project status).

1. Prerequisites

• Linux. ONX is developed and tested on Linux. Other platforms are untested.

• git and a C compiler (gcc or clang). One TLS dependency (aws-lc-sys) compiles C code. On Debian or Ubuntu: sudo apt install git build-essential.

• rustup. The repository pins Rust 1.98.1 in rust-toolchain.toml; rustup installs that version by itself on the first cargo command.

  curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
  

• Disk space. A debug build with all the tests takes several GB; allow about 10 GB free.

2. Clone and build

git clone https://git.on-x.live/amethyst/the-open-network-x.git
cd the-open-network-x
cargo build --workspace --bins

This builds four programs in target/debug/:

Program	What it does
onxd	The node: validator or follower.
onx	Replays a chain and checks its state roots; verifies equivocation evidence.
onx-cli	Wallet: creates hot and backup keys and their address, signs every account action (transfer, policy, cancel, key rotation, backup recovery), and assembles validator rekey and upgrade records.
onx-genesis	Creates a new chain from a genesis config.

3. Run the tests

cargo test --workspace --all-targets

Every test should pass. One known exception: on slow machines sync::tests::pipelined_rounds_move_large_transfers can time out; run it again on its own. The full set of checks run before every merge is in CONTRIBUTING.md.

4. See it run

• Two nodes syncing, in about a minute:

  bash scripts/multinode-sync-test.sh
  

  It starts a producer and a follower on localhost and sends transfers. It kills the follower with kill -9, restarts it, and checks that both reach the same state root. It ends with ALL MULTINODE CHECKS PASSED.

• A four-validator BFT network: follow docs/guides/local-network-launch.md.

• Deterministic replay: cargo test -p onx --test phase5_replay replays a frozen test chain and checks every state root against fixed golden values.

5. Where to go next

• How the protocol works: docs/specification/, starting with architecture.md.
• Why it works that way: the decision records in docs/adr/.
• Contributing: CONTRIBUTING.md and the volunteer roles.
• Found a vulnerability? Report it privately: SECURITY.md.

Long-term goal

The long-term goal is to develop an independent, functioning blockchain network designed for durable operation over the next decade, using the original TON design as a reference while maintaining a distinct identity, implementation, network, and ecosystem. ONX should ultimately be able to stand on its own — the project does not need to replace TON to be successful.

Disclaimer

Open Network X is an independent project. ONXI, Open Network X, and Onyxi should not be represented as official TON products, networks, or services. The use of historical TON technical material as a reference does not imply endorsement, affiliation, or control by the organizations or communities associated with the existing TON ecosystem.

License

Open Network X is licensed under the Apache License, Version 2.0, as decided in ADR-0022. Individual reference materials may have their own copyright and licensing requirements — see WHITEPAPER.md for the applicable source and attribution information.