Pay3Node Architecture
Strip away the marketing language and an L1 client is a handful of modules working together. This is the planned layout for l1_node — and, since a version of it already runs, a note on which parts are real today versus still ahead.
l1_node, see Run It Yourself) implements a deliberately simplified version of this layout — single-authority block sealing, no networking yet, transfers-only execution. The table below marks each module's current status. Full details on exactly what's simplified and why: Current Limitations.The modules
Building an L1 is building these to work together deterministically — every honest node has to reach the exact same state given the exact same transaction history.
| Module | Responsibility | Status |
|---|---|---|
p2p/ | Peer discovery, gossip protocol for transactions and blocks, spam-resistant peer scoring | Planned — the testnet is a single process today |
mempool/ | Priority queue of pending, signature-valid transactions; per-account nonce ordering | Running (single-node) |
consensus/ | Validator selection, block proposal, voting rounds, finality | Simplified — single authority seals blocks on a timer today, see below |
execution/ | The state-transition function: state + transaction → new state | Running, transfers only — full EVM execution is planned |
state/ | Key-value store plus a Merkle-style structure so any value can be proven against one root | Running, in-memory — state root is a simple hash today, not a Merkle trie |
rpc/ | The JSON-RPC server wallets and dApps call — a chain's entire public interface | Running |
cli/ & node ops | Config, validator key management, metrics/monitoring | Minimal — a wallet CLI exists (see Run It Yourself), ops tooling is planned |
What's actually running today
The current l1_node is a Rust binary that starts a chain from genesis, seals a new block every 3 seconds, and serves an RPC on port 8080. It's intentionally described in its own docs as a teaching/prototype skeleton, not a production chain — useful for exercising the whole wallet → RPC → mempool → block → balance loop end to end, before the harder consensus and networking pieces are built.
faucetOne pre-funded account (1,000,000 units) at genesis — every other account is funded from it.block timeFixed, 3 seconds — one process seals every block on a timer, not a validator vote.storageIn-memory. Restarting or redeploying the node wipes the chain back to genesis.historyComputed by scanning every block on each request — fine for a devnet, not how a real chain indexes it.What's next
The path from today's prototype toward the architecture described elsewhere in these docs:
- Replace single-authority sealing with a real validator set and BFT voting — see Consensus Mechanism.
- Add
rust-libp2p-based networking so multiple nodes gossip and agree together, instead of one process with one RPC. - Replace the simple state-root hash with a provable Merkle/Verkle structure.
- Bring in
revmfor full EVM compatibility, beyond plain transfers. - Persist state to RocksDB instead of memory, so restarts don't reset the chain.