Working now
Aliases, tokens, DEX actions, EVM and SVM execution, messaging, file and data operations and ordinary IOC sends are exercised together in the same soak, not in isolation.
Testnet
Protocol upgrade · architecture dossier
The engineering record for DIONS 2.0.
A C++20 rewrite of the I/O Coin node. Ordinary Proof-of-Stake still produces the blocks; everything new sits behind a consensus activation gate. This page is the detail behind that sentence, including what is not ready.
- Runtime
- C++20
- Block budget
- 4 MiB
- Status
- Release candidate
- Target
- December 2026
01 · Status
Tested in public, before any retail-ready claim.
The goal is to prove the chain under real use rather than announce it. The public testnet has been open since 2025 and collects data under load. Many features already run together; what remains is pressure, scale and reproducible evidence.
Mainnet has not launched
No mainnet genesis is published. A mainnet node started on an empty data directory refuses to start. Anything described here as dormant is dormant on mainnet.
Not launchedStill to prove
Sustained 4 MiB pressure, near-16-second confirmations under committed load, reward visibility, explorer views and master-wallet scale — on one final pinned build.
Gated
02 · Architecture
L1 settlement, with execution and data above it.
DIONS 2.0 does not replace the original DIONS work. It tightens the chain model and widens the application surface on the same legacy Proof-of-Stake continuity layer — the one that has produced blocks without a halt since the 2014 genesis block.
03 · Consensus
Ordinary stakers. No quorum, no leader.
Difficulty retargets every block from actual spacing. Values below are the constants in the source, not estimates.
There is no minimum stake amount. The only value rule on a stake kernel is that input value is above zero — a very small stake is permitted, it simply rarely wins.
04 · Execution
Two lanes, described as they actually are.
Both are previews. Neither offers broad Ethereum or Solana wallet compatibility, and saying otherwise would set up an expectation the code cannot meet.
EVM lane
Active from height 0, both networks- Runs on the project's own interpreter via the
EVM_OPenvelope - The vendored
evmonestate-transition path sits behind a far-future sentinel height and is not the execution engine - Developer preview — not a drop-in Ethereum environment
SVM lane
Testnet only · dormant on mainnet- Deploy and execute are includable on testnet from height 0
- Program execution is read-only: an account asking for signer or write authority is refused, because no SVM transaction authentication exists yet
- Its Solana-wire admission path authenticates with raw Ed25519, which has no post-quantum companion
05 · Data availability
64 data shards, plus 32 for parity.
Reed-Solomon direction: any 64 of 96 shards reconstruct the block. Light clients sample rather than store, so participating does not require carrying the chain.
06 · Cryptography
Post-quantum where it is, classical where it isn't.
Protection is protocol-specific, not a blanket property. The project does not claim the chain is quantum-proof, and the honest version is more useful than the slogan.
Encrypted messaging — Message V3
Testnet 0 · mainnet 4096- X25519 and ML-KEM-768 shared secrets, both mixed through HKDF-SHA256 into one AES-256-GCM content key
- Breaking either exchange alone does not open the message
- The RSA-only encrypt path is hard-blocked
Signing and private sends
Implemented- Post-quantum signing paths alongside classical compatibility
- Stealth v2 uses ECDH + ML-KEM; v1 requires an explicit legacy opt-in
- The SVM's Ed25519 wire path has no post-quantum companion — stated, not hidden
07 · Identity
DID records for aliases, devices and agents.
Identity is expressed as W3C DID Core 1.0-direction records, so a person, an autonomous agent and a piece of hardware can each hold keys and act within limits.
Alias
did:dions:alice
A human-readable identity tied to wallet ownership. New aliases are payable, so funds can go to a name rather than an address string.
Agent
did:dions:agent:bot1
An autonomous entity that owns keys and can delegate to devices. The basis for AION's passport, leash and receipt model.
Device
did:dions:device:sensor7
Hardware identity delegated from an agent or account, so a sensor can sign for itself without borrowing a person's wallet.
08 · Rewards
Two roles earn. Light service does not.
Stakers and PoP relays. That is the complete list — and the Light service role, which earlier drafts of this page counted as a third earning lane, pays nothing.
A PoP node is paid only if its wallet is encrypted and unlocked for service. A staking-only unlock cannot sign participation receipts, and an unencrypted wallet never earns.
09 · Activation gates
Nothing ships live on day one.
Every feature switches on at a defined block height. The activation manifest is schema 34 with 74 canonical gates. Heights compiled into the source are defaults — a running network's authority is its signed activation manifest, so read the live posture from the node rather than from this page.
10 · Release evidence
What has to pass before retail-ready.
Retail readiness is not claimed during the public testnet. That claim only comes when every gate below produces a reproducible artifact on the final pinned build.
11 · Network and build
Protocol parameters and build surface.
Build from source
cd build
cmake --build . -j$(nproc)
# dions2d · dions2-light · dions-cli · dions-explorer
# dions2-migrate · dions-relayer · dns seeder · test binaries