Pay3The Five Layers
Every blockchain node is five cooperating subsystems wired into one loop: listen, validate, order, execute, commit, serve. Here's what each layer is responsible for on Pay3.
Overview
A node binary is these five modules working together — every honest node has to reach the exact same state given the exact same transaction history, which is the entire point of a blockchain.
| Layer | Job | Pay3's approach |
|---|---|---|
| Network | Discover peers, gossip transactions and blocks | libp2p-based gossip network |
| Consensus | Agree on transaction order and finalize it | BFT-style proof-of-stake, targeting sub-second finality |
| Execution | Run transactions, update state | EVM-compatible, with parallel execution for non-conflicting transactions |
| State / Storage | Persist balances and contract data, prove integrity | Merkle-proven state store |
| RPC / API | Let wallets and apps read state and submit transactions | EVM-compatible JSON-RPC — the same interface the Pay3 Wallet already speaks |
Network layer
Before any transaction can be ordered or executed, nodes have to find each other and agree on what's currently pending. The network layer handles peer discovery and gossips both pending transactions and finalized blocks across the network, so every honest node converges on the same picture of the world without needing a central coordinator.
Consensus layer
This is the most safety-critical layer — a bug here can fork or halt the entire chain. Pay3 is being designed around a BFT-style proof-of-stake consensus rather than classic Nakamoto (proof-of-work / longest-chain) consensus. The practical difference matters: Nakamoto consensus gives probabilistic finality, where you wait for confirmations to feel safe. BFT-style consensus gives deterministic finality — once two-thirds or more of staked validators sign off on a block, it's final, full stop, with no waiting around.
Execution layer
The execution layer is the deterministic state-transition function: given a state and a transaction, produce a new state. Pay3's execution layer is EVM-compatible, and is being designed around parallel execution — analyzing which transactions actually touch overlapping state and running the non-conflicting ones across CPU cores at the same time, instead of one after another. This is currently the single biggest lever for real-world throughput on any chain, EVM-compatible or not.
State & storage
Every account balance and piece of contract data lives in a key-value store, organized under a Merkle-style structure so that any single value can be cryptographically proven against one root hash — a wallet or light client doesn't have to trust a node's word for a balance, it can verify it. Higher throughput means more state written per second, which is why state growth is treated as a first-class design constraint rather than a problem to solve later — see State Growth & Decentralization.
RPC / API layer
The RPC layer is a chain's entire public interface — everything else is invisible to wallets and apps. Pay3's RPC mirrors the standard eth_* JSON-RPC methods, which is a deliberate trade-off: it means every existing EVM wallet, and the tooling built around ethers.js-style providers, works against Pay3 with little to no changes on the client side. See Transaction Lifecycle for exactly what that looks like in code.