> For the complete documentation index, see [llms.txt](https://docs.valuechain.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.valuechain.xyz/2.-host-chain-and-consensus.md).

# 2. Host Chain and Consensus

#### 2.1 Role of the host chain

The host chain is the foundation layer. Validators run consensus on it, and it provides shared security for everything above. Every subchain on ValueChain inherits the same validator set and the same finality guarantees. No application has to bootstrap its own security.

#### 2.2 CometBFT

ValueChain uses **CometBFT**, a Byzantine-fault-tolerant consensus engine.

* **Safety threshold.** The network operates correctly as long as Byzantine validators hold less than ⅓ of the total voting power.
* **Voting power.** Each validator's voting power is proportional to its stake.
* **Commit rule.** A block is committed once validators holding more than ⅔ of the voting power have precommitted it.
* **No forks.** CometBFT does not fork or reorganize. A committed block is final, and every transaction in it is settled at once.

Consensus moves forward one height at a time, one block per height. Each height has one or more rounds, and each round has three steps: *propose*, *prevote* and *precommit*.

* A proposer is chosen by deterministic round-robin, weighted by voting power. It broadcasts a candidate block.
* Validators then prevote and precommit on that block. When more than ⅔ of the voting power has precommitted, the block is committed and the height advances.
* If a round fails, for example because the proposer is offline or the proposal is invalid, a new round starts at the same height with a new proposer.

#### 2.3 Single-slot finality

On the EVM system chain, a block is final in the same slot in which it is proposed (2-second slots). Once a transaction appears in a block, consensus will never revert it. Applications do not need to wait for further confirmations.

|                           | ValueChain  | Ethereum                 |
| ------------------------- | ----------- | ------------------------ |
| Slot time                 | 2 s         | 12 s                     |
| Finality                  | Single slot | Two epochs (Gasper)      |
| Reorgs                    | None        | Possible before finality |
| Confirmation depth needed | None        | Application-dependent    |

#### 2.4 Block times and epochs

| Parameter                              | Value                          |
| -------------------------------------- | ------------------------------ |
| EVM system chain block time            | 2 s                            |
| SoDEX Spot / Perps appchain block time | 100 ms each                    |
| EVM block gas limit                    | 30,000,000                     |
| Epoch length                           | 192 EVM blocks (≈ 6.4 minutes) |

The validator set changes only at epoch boundaries. Within an epoch, the set and each validator's voting power stay fixed. New activations, stake changes and exits all take effect at the next epoch boundary.