Network Peer-to-peer
Validator and full nodes exchange transactions and blocks through peer-to-peer gossip over TCP/IP. A full node can verify the chain independently, without relying on a third-party explorer.
THE ARCHITECTURE / WHITEPAPER V3.0
Five layers.
A connected foundation.
Ozone Chain brings Ethereum-compatible execution to a Cosmos SDK application, with CometBFT consensus beneath it. Each layer has a defined role—from moving transactions across the network to the applications people use.
ExecutionEVMApplicationCosmos SDKConsensusCometBFTNative coinOZONE
01 / EXPLORE THE STACK
One responsibility
at every layer.
Select a layer to see how it contributes to the network. The interface is a guide to the architecture, rather than a live view of network activity.
Use the Up and Down arrow keys to navigate the layer selector. Architecture descriptions follow whitepaper v3.0, section 3.
02 / THE FIVE RESPONSIBILITIES
From network traffic
to useful applications.
The separation makes it easier to understand where transactions move, where agreement happens and where application logic runs.
Move data
Consensus CometBFT
Validators propose and vote on blocks. A block commits once validators holding more than two-thirds of voting power sign it. Delegated stake contributes to that voting power.
Application Cosmos SDK
The state machine maintains balances and protocol state. Its modules handle OZONE transfers, staking, reward distribution, slashing and on-chain governance.
Execution Ethereum Virtual Machine
The EVM runs Solidity smart contracts within the Cosmos SDK application. Ethereum JSON-RPC and familiar 0x addresses let developers work with tools such as MetaMask, Hardhat and Remix.
Applications User experiences
Wallets, marketplaces, games and ecosystem services use the underlying network. Transactions pay fees in OZONE; each application also has its own contract logic and operating risks.
03 / FINALITY, WITH CONTEXT
Committed in one block.
Under explicit assumptions.
CometBFT provides single-block finality once a block is committed. Its safety model assumes less than one-third of voting power is faulty. Finality describes consensus agreement; it does not remove the risks of faulty contracts, compromised keys or incorrect transaction instructions.
Delegated Proof-of-Stake adds economic accountability. Validators and delegators can face slashing, so choosing an operator and understanding the current network rules remain important.
04 / BUILD ON THE FOUNDATION
Familiar tools.
Clear next steps.
Start with network configuration, inspect activity independently and read the source specifications before deploying an application.
Configure your environment
Find mainnet and testnet RPC settings, chain IDs and coin symbols in the developer centre. Confirm the selected network before deploying or signing.
Inspect on-chain activity
Use OzoneScan to review transactions, blocks and available contract-verification information. For independent validation, explore the project’s node resources.
Read the full specification
Sections 3–5 of whitepaper v3.0 describe architecture, staking and governance. Consult current project resources before relying on operational parameters.
Source: supplied Ozone Chain whitepaper v3.0, October 2026, sections 3–5 and 9–10. No throughput benchmark or uptime guarantee is implied by this architecture overview.