Network architecture

An Avalanche L1

Real Chain is an Avalanche Layer 1 with its own validator set and one EVM blockchain. Its architecture follows the standard Avalanche L1 model rather than introducing 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 still uses the Avalanche Primary Network's P-Chain as the validator registry. 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. Validators repeatedly sample other validators' preferences until a block reaches the configured confidence threshold. A vote for a block also supports its accepted ancestors, which lets the network converge on one ordered history. AvalancheGo runs this consensus process; Subnet-EVM 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 determine how validator responses contribute to acceptance. They must be configured consistently across the network. For implementation detail, see Avalanche's consensus architecture.

Validator model: PoA today, PoS later

Real Chain currently uses a permissioned Proof-of-Authority validator model. PoA governs admission to the validator set; it does not replace Snowman consensus. A PoAManager, whose owner was verified as the protocol timelock at testnet block 4503 on 17 September 2026, initiates validator additions, removals, and weight changes. The P-Chain records the resulting validator set. The trust model identifies the observed timelock controls.

REAL's planned path is a governed migration to Proof of Stake using the network's native ASSET token. The migration hands Validator Manager control from the PoA manager to a native-token staking manager. After that transition, staking rules can govern new validator admission, weight, delegation, uptime-based rewards, and exits.

The PoS migration is a future network-governance action, not a currently active capability. It changes validator admission and incentives; it does not replace Subnet-EVM, change application contract state, or switch Real Chain away from Snowman consensus. Avalanche documents both models in its Validator Manager architecture.

Network validators

Network Validators run AvalancheGo and participate in consensus. Joining the validator set requires admission through the active validator-management model; running node software by itself does not establish membership.

Operators maintain connectivity, synchronization, monitoring, software updates, and the credentials required by their role. Independent infrastructure and administration reduce common failure modes. Several nodes exposed to the same operational failure do not provide the same resilience as independently operated nodes.

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.

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.

A transaction hash proves submission, not acceptance or successful execution. Applications should wait for a receipt and check its status. A portal may remain behind the chain while its indexer processes the accepted block; that delay does not authorize submitting the transaction again.

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 transform blocks and contract logs into query-oriented views for the explorer, portals, and APIs. Those services may also combine chain data with off-chain workflow state, such as document review or a pending bank payment. An indexed view can be stale or incomplete without changing the underlying chain state.

Keep the control layers distinct

A network operator does not gain issuer authority by running a node. An issuer administrator does not gain network-governance powers by operating an asset.

Finality and external obligations

An accepted Snowman block is intended to provide irreversible finality; Real Chain does not rely on a longest-chain confirmation race. Applications must still distinguish submission from acceptance and check the receipt's execution status. This documentation does not publish an independently measured REAL finality benchmark.

Finality concerns the blockchain record. A bank payment, document review, or service obligation has its own completion conditions. An application should show those conditions explicitly instead of treating every successful transaction as completion of the entire business workflow.