Network architecture

An Avalanche L1

Real Chain is an Avalanche Layer 1 with its own validator set and one EVM blockchain. It follows the standard Avalanche L1 model. It does not add a new consensus protocol or virtual machine.

Avalanche calls this a sovereign network because the L1 defines its own validator membership and token economics. Real Chain still uses an Avalanche P-Chain as the validator registry. Real Testnet registers its validators on the Fuji (testnet) P-Chain. Real Chain validators sync the P-Chain, but they do not participate in P-Chain consensus unless they separately validate the Primary Network. See Avalanche's L1 overview and network architecture.

Consensus and EVM execution

Snowman is Avalanche's consensus protocol for linear blockchains. Each validator repeatedly asks a random sample of other validators which block they prefer. It continues until a block reaches the configured confidence threshold. A vote for a block also counts for that block's accepted ancestors, so the network settles on one ordered history. AvalancheGo runs this consensus process. Subnet-EVM, Avalanche's EVM engine, verifies and executes the transactions inside each proposed block.

This separates two decisions:

1. Is the block accepted? Network Validators reach consensus on the ordered block history.
2. Is the transaction valid? Subnet-EVM applies account rules, gas rules, and contract code. A transaction that violates a contract check reverts even if its containing block is accepted.

The consensus parameters and validator weights decide how much each validator's response counts toward acceptance. The network must use the same configuration for them everywhere. For implementation detail, see Avalanche's consensus architecture.

Validator model: PoA today, PoS later

Real Chain currently uses a permissioned Proof-of-Authority (PoA) validator model: only approved operators can join the validator set. PoA decides who joins. It does not replace Snowman consensus. A PoAManager contract owns the Validator Manager and starts validator additions, removals, and weight changes. The protocol timelock owns the PoAManager, so these changes go through the timelock delay. The P-Chain records the resulting validator set. The trust model explains administrative powers.

Real plans a governed migration to Proof of Stake (PoS) that uses the network's native ASSET token. The migration moves Validator Manager control from the PoA manager to a staking manager for the native token. After that change, staking rules can decide new validator admission, weight, delegation, uptime-based rewards, and exits.

The PoS migration is a future network-governance action. It is not active today. It changes validator admission and incentives. It does not:

• replace Subnet-EVM,
• change application contract state, or
• move Real Chain away from Snowman consensus.

Avalanche documents both models in its Validator Manager architecture.

Network validators

Network Validators run AvalancheGo and take part in consensus. To join the validator set, an operator must be admitted through the active validator-management model. Running node software alone does not make a node a member.

Operators maintain connectivity, synchronization, monitoring, software updates, and the credentials their role needs. Independent infrastructure and administration reduce shared failures. Several nodes that can fail from the same cause are less resilient than nodes that different parties operate independently.

Network Validators and Business Validators are separate roles. Network Validators secure block production and consensus. Business Validators perform assigned tokenization, scoring, or insurance responsibilities. One organization may perform both roles, but neither role automatically grants the other. A network operator does not gain issuer authority by running a node, and an issuer administrator does not gain network-governance powers by operating an asset.

Follow a transaction

1. Sign. A wallet authorizes a transaction for the Real Chain ID, destination, value, and call data.
2. Submit. An RPC node validates the transaction format and places an acceptable transaction in its local transaction pool.
3. Build and verify. An eligible validator orders transactions into a candidate block. Subnet-EVM executes them, and other validators verify the resulting state transition.
4. Reach consensus. Validators use Snowman to decide whether to accept the block and its history.
5. Confirm. Once the block is accepted, a receipt records each included transaction's status, emitted logs, and gas used.
6. Index. Explorers and application indexers consume accepted blocks and logs to build searchable views.

How transactions settle explains what each of these states proves and how to handle indexer delay.

Chain state and application views

Subnet-EVM stores the canonical on-chain state. This includes native ASSET balances, contract bytecode and storage, token balances, identity records, and Business Validator protocol records.

Indexers turn blocks and contract logs into searchable views for the explorer, portals, and APIs. These services can also combine chain data with off-chain workflow state, such as a document review or a pending bank payment.

Keep the control layers distinct

Finality and external obligations

Snowman is designed so that an accepted block is final and cannot be reversed. Real Chain does not rely on a longest-chain confirmation race. Real does not publish a measured finality benchmark.

Finality applies to the blockchain record. A bank payment, document review, or service obligation has its own completion conditions. An application should show those conditions clearly. It should not treat every successful transaction as the end of the whole business workflow.