Skip to content
You are reading Hyperledger Besu development version documentation and some displayed features may not be available in the stable release. You can switch to stable version using the version box at screen bottom.
Last update: December 21, 2021


Besu implements the Clique proof of authority (PoA) consensus protocol. The Rinkeby and Goerli testnets uses Clique and private networks can also use Clique.

In Clique networks, approved accounts, known as signers, validate transactions and blocks. Signers take turns to create the next block. Existing signers propose and vote to add or remove signers.

Genesis file

To use Clique in a private network, Besu requires a Clique genesis file. When connecting to Rinkeby, Besu uses the rinkeby.json genesis file in the /besu/config/src/main/resources directory.

A Clique genesis file defines properties specific to Clique.

Example Clique genesis file

    "constantinoplefixblock": 0,
  "alloc": {},

The properties specific to Clique are:

  • blockperiodseconds - The block time, in seconds.
  • epochlength - The number of blocks after which to reset all votes.
  • extraData - Extra data including the initial signers.

Extra data

The extraData property consists of:

  • 0x prefix.
  • 32 bytes of vanity data.
  • A list of initial signer addresses (at least one initial signer is required). 20 bytes for each signer.
  • 65 bytes for the proposer signature. In the genesis block there is no initial proposer, so the proposer signature is all zeros.

One initial signer

One Initial Signer

Two initial signers

Two Initial Signers

Connecting to a Clique network

To connect to the Rinkeby testnet, start Besu with the --network=rinkeby command line option. To start a node on a Clique private network, use the --genesis-file option to specify the custom genesis file.


In Clique, blocks created by in-turn validators are published immediately. Out-of-turn validators create blocks that are published after a short delay. In-turn blocks have a higher difficulty than out-of-turn blocks, which allows small forks to resolve to the chain with more in-turn blocks.

However, when the out-of-turn delay is shorter than the block propagation delay, out-of-turn blocks may be published before in-turn blocks. This may cause large, irresolvable forks in a network.


We recommend using a more updated consensus protocol such as IBFT 2.0 or QBFT.

Questions or feedback? You can discuss issues and obtain free support on Hyperledger Besu chat channel.
For Hyperledger Besu community support, contact the mailing list