Skip to content

Operating an Autonity full node

What you need to know

This section outlines how to:

  1. Download a Docker image that contains an Autonity Go Client pre-configured for the Autonity Bakerloo testnet, and create a running Docker container from it to instantiate your own Autonity full node.
  2. Add your node to the Bakerloo testnet.
  3. Interact with your node and thereby the Bakerloo testnet.


This guide explains how to add a full node (holding a full copy of the system state) to the Autonity Bakerloo testnet. Over time, we will provide additional details on node and validator node operations

Adding support for a light client mode is part of the Autonity Go Client roadmap

Useful to know

  • Autonity is derived from Ethereum protocols, so we assume you understand the basics and principles of Ethereum
  • you need basic skills for finding your way around Linux environments, and know how to obtain or set up a simple Linux host with a static internet IP address, and root access
  • we explain the use of Docker in as much detail as you initially need, but in general, it will be helpful to know more about how Docker works


Setting up and maintaining an Autonity node — for instance as part of the Bakerloo testnet — is easy to do in a setting that is not a production (real value trading) system

For production use, you will likely have requirements for node availability and security that a simple setup such as the one described in this guide is not designed for

For example, the configuration outlined here exposes the Autonity Go Client's unencrypted http RPC interface to the internet. For production use, one would add encryption functionality in most scenarios, for example using a reverse-proxy such as NGINX

Key concepts

In addition to Ethereum concepts such as address, gas, and node, there are a few things worth knowing in an Autonity context:

Concept Meaning
Auton (AUT) Autonity's native account coin (intrinsic balance of an account, like "Ether" in Ethereum)
Light node A node that runs the Autonity Go Client in light mode, which does not receive the full blockchain data, but is able to obtain cryptographic proof of state transitions, via a peering arrangement with a full node. Light mode support for AGC is roadmapped
Participant node Any full node on the network that is not a Validator node
Validator node A full node that is eligible to participate in the Consensus Committee. In future implementation, this will be any full node that has stake bonded to by its owner, a stakeholder
Consensus Committee The subset of Validator Nodes that at a specific point in time participates in block validation by consensus computation. The Consensus Committee is chosen algorithmically according to the protocol


The key difference between Participant full nodes and Validator nodes is whether they are able to take part in consensus computation

In a production setting, requirements for Participant nodes and Validator nodes may be significantly different, depending on the needs and role(s) of their owners

For example, a Participant node may be used to submit transactions to the network, and therefore might need to meet high availability criteria; whereas a Validator node must mostly be highly secure, so as not to lose part of the stake bonded to that node ("stake slashing")


If you need help, you can: