Skip to main content
This page is for operators preparing to run an Intention validator. It walks through hardware, software install, key generation, joining the set, configuration, and day-to-day monitoring. Validators on Intention participate in IntentionBFT consensus, sequence trading actions, and certify in-block oracle quorums — the full protocol-native responsibility set described in the architecture overview.
This page will be expanded as mainnet launch approaches. Hardware and configuration specifics are marked TBD; values will harden once load testing and the genesis process are complete. Pre-mainnet the validator set is operated by the foundation and invited partners.

​
Hardware requirements (TBD)

Intention is a high-throughput L1 with protocol-native matching, so validator hardware is closer to an HFT co-location box than a typical chain node.

​
Software install (placeholder)

The validator binary, release channels, and container images will be published with the mainnet launch package. Expect a single binary plus a systemd unit file, and a container image for operators running on orchestrated infrastructure.
1

Provision the host

Install a supported Linux distribution, disable swap, tune ulimit -n, and apply the standard kernel parameters for low-latency networking.
2

Generate validator keys

Run the key-generation tool to produce a consensus key and a node identity key. Back up both to offline media. Consensus keys must live in an HSM or at minimum a hardware-backed keystore.
3

Configure the node

Fill in the config template: chain ID, bootstrap peers, external address, log level, metrics endpoint, and the keystore paths. Set Prometheus scrape, JSON log output, and alert webhooks.
4

Join the validator set

Submit the validator registration transaction with your node identity, contact endpoint, and operator metadata. Pre-mainnet this step is coordinated with the foundation; on mainnet it goes through the standard join flow.
5

Watch the logs

Start the service and monitor the catch-up phase. Confirm block height is advancing, peer count is healthy, and the node transitions from SYNCING to VALIDATING.

​
Configuration surface

A validator config covers identity (keys, endpoints), networking (listen addresses, peer limits), consensus parameters (propose timeouts, batch sizes — set at protocol level, overridable only within a narrow band), the engine (worker pool, queue caps), and observability (Prometheus, tracing, logs).

​
Day-two operations

Monitoring

Dashboards, alert thresholds, and the four-layer metric pyramid.

DDoS and Sybil defense

Rate limiting, connection control, and congestion fair-share at the network edge.
This page intentionally does not cover staking economics, delegation, or rewards. Those do not exist yet — the validator set is a technical operator role until the native token and its economic model are finalized and audited.
For where validators sit in the network — sequencers, full nodes, public RPC — see Network topology.