One network, five responsibilities
Ozone Chain’s architecture separates the work of a blockchain into five layers: Network, Consensus, Application, Execution and Applications. The layers are responsibilities within one network. They are not five separate chains, and “five-layer” does not mean a fifth version of blockchain technology.
For a builder, the useful question is what each component does: how data reaches nodes, how blocks become final, where network state is maintained, how smart contracts run and how people use the result.
01 / Network: moving data
The peer-to-peer layer carries transactions and blocks between validator and full nodes over TCP/IP. Gossip spreads information across connected peers so that nodes can receive the material they need to verify and process the chain.
A full node gives an operator a way to verify the blockchain independently. Running one is distinct from joining the validator set: validators also participate in proposing and voting on blocks.
02 / Consensus: agreeing on blocks
CometBFT provides the consensus engine. Validators propose and vote in rounds; a block commits after validators representing more than two-thirds of voting power sign it. The threshold concerns voting power, rather than a simple count of nodes.
Under the stated Byzantine fault tolerance assumptions, a committed block has single-block finality. Safety requires less than one-third of voting power to be faulty. Finality does not eliminate software, application or key-management risk, and a typical block time is not a guarantee that every request will complete within that time.
03 / Application: keeping state
The Cosmos SDK application maintains the network’s state: the balances, staking positions and other records that change as transactions are processed. Its modules handle OZONE transfers, staking, distribution, slashing and governance.
This is the network’s application layer, singular. It is different from the user-facing Applications layer at the top of the stack. Separating the two helps distinguish protocol responsibilities from individual products.
04 / Execution: running contracts
An EVM module executes Ethereum-compatible smart contracts inside the Cosmos SDK application. The whitepaper describes Solidity contracts, familiar 0x addresses and standard Ethereum JSON-RPC, with MetaMask, Hardhat and Remix tooling.
This lets developers begin with an Ethereum workflow. A familiar interface does not remove the need to test: teams still need to review their contracts, network settings, transaction costs and dependencies before a deployment.
05 / Applications: the user experience
Wallets, games, payment tools, marketplaces and the explorer are where people encounter the network. Applications settle through the layers beneath them and use OZONE for transaction fees or ecosystem payments.
The network foundation and each application have different security boundaries. A contract’s permissions, operational practices and audit scope must be assessed for that application; a chain’s architecture does not guarantee that every product built on it is safe.
Where to go next
Use the interactive architecture overview to explore the stack, then open the developer centre for the network’s RPC and chain settings. Validators and delegators can follow the participation guides for their own responsibilities.
This article explains the architecture described in whitepaper v3.0. For current activity, inspect the public explorer. For a technical specification, read the full whitepaper and the upstream documentation linked from the resource centre.
This original explainer draws on sections 2, 3 and 9 of the supplied Ozone Chain whitepaper v3.0. Protocol parameters and application availability may change. It does not replace a technical or security review.
Read the five-layer architecture ↗