ioc protocol upgrade / dions architecture / public testnet release

DIONS 2.0 Protocol Report

A technical view of the I/O Coin upgrade path: legacy adaptive Proof-of-Stake continuity, probabilistic confirmations, 4 MB pressure proof, DIONS-native EVM/SVM lanes, native identity, encrypted messaging, data availability, bridge surfaces, and proof-gated Light/PoP participation.

Portal source View diagrams Testnet explorer

DIONS / testnet release Public testnet release

SoakFeature soak+ 4 MB proof required

Gate4 MBpressure required

Blocks4 MBpressure gate

RuntimeC++20legacy PoS core

Base continuity: Fair-launch IOC chain since 2014
Legacy DIONS: Aliases, encrypted messages, data/file paths
Upgrade vector: Legacy PoS, 4 MB pressure, graph, DID, service rewards

community update

DIONS 2.0 testing update for the community.

Public testnet hardening

DIONS 2.0 is being tested in public before any retail-ready claim. The goal is to prove the chain under real users, real businesses, real wallets, service traffic, and heavy transaction pressure.

Working nowCore stack passes feature tests

Still proving4 MB pressure + wallet scale

Retail-readyNot claimed until proof passes

1 Continuity is holding

The chain has repeatedly recovered and converged across the managed testnet using IOCoin's legacy Proof-of-Stake continuity.

2 Features are running together

Aliases, tokens, DEX actions, EVM/SVM execution, messaging, file/data operations, and normal IOC sends are being tested in full soak cycles.

3 Proof gates remain

4 MB blocks, near-16-second confirmations under load, reward visibility, explorer views, and master-wallet scale still need final proof together.

What has been tested and improved

Core Proof-of-Stake continuity: restart recovery, chain convergence, same-SHA node alignment, fork safety, staking unlock behavior, and multi-node recovery.

Feature soak testing: aliases, token creation, token mint/transfer/burn, DEX operations, EVM contract deploy/call, SVM program deploy/execute, plain messages, private/shadow messages, file/data operations, normal IOC sends, and basic RPC checks.

Explorer and rewards: validator reward, Light service reward, and PoP service reward visibility has been improved in the testnet explorer. Graph/general transaction visibility is separated for observability.

What still has to pass before retail-ready

Final wallet bloat-prevention policy and master/service wallet scale.
Final feature soak on the final pinned SHA.
Sustained one-hour mixed 4 MB pressure test.
Near-16-second confirmations under heavy committed load.
msgs_failed=0, no fork/reorg, and safe node spread.
Validator, Light, and PoP rewards paid and visible in the testnet explorer.
Explorer network, rewards, graph, and block-fill views accurate.
Restart/catch-up behavior on the final SHA.
Enterprise and StampRight-style multi-user record-storage fuzz.

What DIONS 2.0 is aiming to deliver

Legacy Proof-of-Stake continuity.
4 MB block capacity.
Near-16-second confirmations under load.
Encrypted messaging, aliases, and identity.
Graph/data paths, tokens, and DEX.
DIONS-native EVM/SVM execution.
Light service rewards and PoP rewards.
Enterprise record storage and StampRight-style proof receipts.

Short version

DIONS 2.0 is working through the final hardening stage on public testnet. Many major features are implemented and passing feature tests, but the most important retail-scale issues still have to pass together: wallet/master-wallet performance, staking bloat prevention, sustained 4 MB blocks, and near-16-second confirmations under heavy load.

01 / what this page is

This is the DIONS 2.0 technical layer, inside the I/O Coin story.

The old DIONS work already gave IOCoin human-readable aliases, alias-linked data, public and encrypted messaging APIs, file transfer paths, AES-256/RSA-4096 encryption, Shade privacy APIs, and Proof-of-Stake chain operation.

DIONS 2.0 does not replace that history. It tightens the chain model and expands the application surface: legacy Proof-of-Stake continuity, hardened indexes, dual execution zones, W3C-style identity, graph/data availability surfaces, fail-closed bridge mechanics, WebSocket/event APIs, and Light/PoP service participation paths.

02 / future retail gate

Retail readiness remains proof-gated after public testnet release.

DIONS 2.0 is not being labeled retail-ready during the public testnet release. That claim only comes when one pinned SHA proves the full feature soak, sustained 4 MB pressure, near-16-second confirmations under committed heavy load, reward visibility, explorer health, and restart/catch-up behavior on the same committed runtime.

Wallet scaleMaster-wallet proof

Real bloated wallet.dat, WAL/delta persistence, cache coherence, and staking-change bloat prevention.

4 MB / 16sFinal pressure gate

Sustained high-fill blocks, msgs_failed=0, no fork/reorg, clean wind-down.

Rewards1.5 / 0.5 / 0.001

Validator, Light service, and PoP rewards must be paid and visible.

StampRightEnterprise records

Many customers, aliases, domains, contacts, records, graph/data writes, and node recovery.

Full feature soak PASS on the same pinned SHA.
Sustained 4 MB pressure for 1 hour.
Near-16-second confirmations under heavy committed load.
msgs_failed=0, no fork/reorg, and spread <= 2.
Validator, Light service, and PoP rewards visible in testnet explorer views.
Testnet explorer network, reward, and graph views healthy.
Bloated master-wallet path works with real bloated wallet.dat fixture.
Legacy staking/change split does not create unbounded wallet bloat.
Restart/catch-up proof passes after load.

03 / enterprise records

DIONS 2.0 targets business records that must survive scale.

The enterprise target is a service model where many customers can operate under one business-grade record system: aliases and domains, service contacts, proof receipts, graph/data writes, and long-lived customer records. The master-wallet scale path must keep working for years without degrading as records, change outputs, receipts, and account history grow.

RecordsBusiness proof layer

Service contacts, aliases/domains, proof receipts, and graph/data writes.

ScaleMany customers

One enterprise service model must support many customer records without wallet degradation.

StampRightProof receipts

StampRight-style records need durable receipts, graph writes, and recoverable wallet history.

LongevityYears of operation

Master-wallet behavior must remain bounded as service activity accumulates.

04 / system architecture

System map: L1 settlement plus execution and data layers.

L1 / DIONS base layer legacy adaptive PoS

PoSLegacy continuity consensus

Adaptive stake retargeting, restart catch-up, bounded fork handling, probabilistic confirmations, and no quorum/finality engine in launch consensus.

IdentityW3C DID direction

Aliases, agents, devices, and key-held identity records.

MessagingEncrypted data layer

Direct messages, channels, shadow messaging, file/data transfer paths.

PQCDilithium-active track

ML-DSA/Dilithium path active; other PQC surfaces remain gated until separately proven.

GraphGraph / DA observability

Graph events, DA shard storage, bounded relay pressure, and explorer graph/general split.

BridgeFail-closed bridge surfaces

ECDSA/HTLC surfaces exist; custody monitor-only / fail-closed until separately activated and proven.

4 MBblock budget

~16sheavy-load gate

0 failpressure target

0.5 / .001Light / PoP rewards

EVM zoneDIONS-native lane

Solidity / Vyper
evmone execution engine
eth_* JSON-RPC layer
Activation-gated compatibility surfaces

SVM zoneDIONS-native v0 lane

Rust / C BPF programs
Account model and PDAs
Concurrent-load proof required
Challenge / dispute path

05 / transition map

Before, now, and what becomes new in the upgrade path.

Feature area	Legacy DIONS / IOCoin	DIONS 2.0 path	New surface
Consensus model	Adaptive legacy Proof-of-Stake	Legacy PoS continuity; near-16s under committed heavy load is a release gate	4 MB pressure, graph/data observability, and modular commitments
Alias resolution	Alias identity and data already present	O(1) LevelDB indexed resolution	Hardened deterministic index path
Messaging	Public/encrypted messaging APIs	Encrypted/plain/shadow messaging with consistency gates	Expanded channel lifecycle and policy controls
Files/data	Upload, download, transfer paths existed	Quota-governed deterministic data behavior	DA/sharding with Reed-Solomon direction
Cryptography	Classical encryption/signing assumptions	Dilithium/ML-DSA production path plus classical compatibility	Additional PQC surfaces remain activation-gated until proven
Execution	No native smart-contract execution zones	EVM and SVM execution paths integrated	Solidity and Rust-style application lanes
Bridge	No mature wrapped-asset bridge stack	ECDSA signing, HTLC, relayer mechanics	custody monitor-only / fail-closed until separately activated and proven
Participation	Full wallet/node model	Light client and PoP relay paths	Headers-only sync and zero-balance relay rewards

06 / chain comparison

DIONS 2.0 is measured against current L1 expectations.

	Ethereum	Solana	DIONS 2.0
L1 capacity	Lower-throughput L1 class	High-throughput monolithic L1	4 MB block budget; TPS published only after reproducible artifacts
Execution lanes	Rollups / L2s	Parallel runtime design	DIONS-native EVM/SVM lanes, benchmark pending
Post-quantum	None	None	Dilithium/ML-DSA active; other PQC paths gated
Native identity	ENS adjacent / off-chain	No	W3C DID Core 1.0 direction
Native messaging	No	No	AES-256 + RSA-4096 path
Light client	Sync committee model	Limited	Native Light service path with 0.5 IOC reward proof required
Earn from zero	No	No	PoP relay reward path

07 / execution

Two execution zones, one IOC continuity layer.

EVM zone

Ethereum-compatible contract lane.

Solidity / Vyper contracts
evmone execution engine
DIONS-native execution lane; throughput proof pending
Full eth_* JSON-RPC surface
State roots posted back to L1

SVM zone

High-throughput program lane.

Rust / C BPF programs
Account model and PDAs
Concurrent-load proof required
Dispute and challenge-response layer
Zone root settlement to L1

08 / data availability

Data availability: 64 data shards plus 32 parity shards.

64 data shards 32 parity shards recover from any 64 of 96

Light client sampling: 20 random shards
Detection confidence: 99.99%
Retention window: 10,000 blocks
Per-node storage: 1-10% direction

09 / cryptography

Post-quantum track and device profiles.

The public retail truth is conservative: Dilithium3 / ML-DSA is the active path. Additional post-quantum surfaces remain activation-gated until each surface is separately proven, documented, and visible in release artifacts.

Active pathDilithium3 / ML-DSA

CompatibilityClassical signatures remain supported

GateAdditional PQC surfaces pending proof

10 / identity + messaging

DID records, aliases, devices, agents, and native encrypted messaging.

Agentdid:dions:agent:bot1

Autonomous entity. Owns and delegates to devices.

Devicedid:dions:device:sensor7

Hardware identity delegated from an agent or account.

Aliasdid:dions:alice

Human-readable identity linked to wallet ownership.

{
  "@context": "https://www.w3.org/ns/did/v1",
  "id": "did:dions:agent:bot1",
  "verificationMethod": [{
    "type": "EcdsaSecp256k1VerificationKey2019"
  }],
  "service": [{
    "type": "DionsMessaging",
    "serviceEndpoint": "dions://msg/bot1"
  }]
}

11 / bridge surfaces

ECDSA/HTLC surfaces exist; custody remains fail-closed.

native IOC lock events monitor-only attestations wIOC mint / burn / unlock accounting

12 / light service diagram

Light-client wallet path: verify, sample, participate.

headers-only sync DA sampling participation rewards

13 / network + build

Protocol parameters and build surface.

Network ports

Mainnet P2P: 33764
Mainnet RPC: 33765
Testnet P2P: 33763
Testnet RPC: 33766
WebSocket: 33776
Chain IDs: 8377 / 8378

Build targets

cd build
cmake --build . -j$(nproc)

# dions2d, dions2-light,
# dions-cli, dions-explorer,
# dions2-migrate, dions-relayer,
# dns seeder, test binaries

14 / release evidence

Security and RC evidence from the portal material.

Feature soakRequired

Full feature soak must pass on the final pinned SHA.

4 MB / 16sRequired

Bloated-wallet mixed pressure must prove high fill and near-16s confirmation behavior under committed load.

Network gate5 nodes

Managed nodes must stay same SHA, spread <=2, no fork/reorg.

Wallet scaleRequired

Real bloated wallet.dat, WAL/cache, and staking-change bloat gates must pass.

15 / source material

Follow the source record.

dions portalDIONS 2.0 Architecture Portal testnet explorerDIONS 2.0 Testnet Explorer wikiI/O Digital Foundation GitBook iocoinReturn to main site