About
The sovereign execution layer for real-time applications
Inazuma — Japanese for lightning — is an independent Layer 1 built from its own primitives, currently running on devnet.
- Block time
- 400ms
- Finality
- 1 block
- Genesis supply
- 11,100,000 INAZ
- Stage
- Devnet
Sovereign by design
No borrowed consensus, no inherited state model, no compatibility layer stitched on top. Every part of the stack exists to serve one goal: pure, autonomous execution.
We engineered it for zero-dependency state and native consensus. Sub-second settlement is a consequence of that design, not a marketing claim. Accounts, tokens, staking and validation all live in the protocol itself — nothing is bolted on.
We're building it in the open, one phase at a time: devnet now to harden the client, then a public testnet, an expanding validator set, mainnet, and finally governance handed to the people running the network.
Zero-dependency state
No borrowed architecture. The consensus, state machine and token layer were designed together, not assembled from other chains.
Native consensus
Validation, staking and finality are protocol-native, not delegated to external bridges or rollup sequencers.
Sub-second settlement
400ms blocks with deterministic finality, so autonomous applications execute without waiting on external infrastructure.
Protocol
What the chain actually is
Client
Inazuma Core — written in Rust, single binary, no external node runtime
Consensus
BFT-style proposer rotation with deterministic finality; committed blocks never reorg
Block interval
400ms, block gas limit 15M
Accounts
ed25519 keypairs, base58 addresses, domain-separated key derivation
Post-quantum
ML-DSA-65 co-signatures available alongside ed25519 in the wallet
Execution
WASM smart contracts on top of native transfer, token and staking operations
State
Sparse Merkle tree over an embedded key-value store; every block publishes a state root
Networking
INSC1 encrypted transport — X25519 key exchange, ChaCha20-Poly1305 authenticated frames
Fees
Paid in INAZ, priced in fractions of a cent
Chain id
7777
Safety
What happens when things go wrong
Slashing & jailing
Double-sign and liveness faults produce on-chain evidence; offenders are jailed and slashed, with a self-unjail path once they are healthy again.
Reorg bound
A hard maximum reorg depth caps how far history can ever be rewritten, so deep rewrites are rejected by the protocol, not by convention.
Snapshots & pruning
Nodes sync from state snapshots instead of replaying genesis, and prune old state so disk growth stays bounded.
Emergency halt
A coordinated halt lets operators stop block production during an incident instead of forking under pressure.
DoS limits
Per-account and per-connection rate limits, mempool deduplication and bounded queues keep spam out of consensus.
Testing
Conformance, fuzzing, adversarial and chaos suites run in CI alongside dependency auditing, plus a Byzantine build for fault injection.
Roadmap
From devnet to governance
01
Devnet
Public RPC, explorer, faucet and wallet against a live network while the client is hardened.
In progress02
Public testnet
Permissioned validator set, open participation for app teams and node operators.
Planned03
Validator expansion
Larger set, staking economics and slashing fully enforced.
Planned04
Mainnet
Genesis distribution and audited core protocol.
Planned05
Decentralization
Permissionless validation and on-chain governance of protocol parameters.
PlannedLive surfaces
Everything running today
Built by builders
No figureheads — just contributors
Inazuma is maintained by an open group of protocol engineers, node operators and app developers. If you ship, you belong here.
Meet the community