This guide provides instructions for setting up and running a Kanari Network node with the current transaction-driven checkpoint and Mysticeti DAG integration.

For the full command reference, see Kanari Node CLI.

Prerequisites

Ensure you have built the project as described in the Compile and install guide. The binary kanari-node will be located at target/release/kanari-node.

Features

P2P Networking: Built with libp2p.
Automatic Discovery: mDNS for local network and Kademlia DHT for wider discovery.
Message Propagation: Gossipsub protocol for transactions, checkpoints, and DAG metadata.
NAT Traversal: Supports DCUtR (Hole Punching) and Relay Server mode.
Transaction-driven checkpoints: Idle nodes do not create new checkpoint height without transactions.
Strict recovery paths: Snapshots and encrypted validator backups are available for repair and migration.

Single Node Setup

To start a standard node with default settings:

kanari-node start --network devnet --p2p-port 19000 --rpc-port 19001 --rpc-host 0.0.0.0 --data-dir ./data

Available Options for `start`

--p2p-port: P2P listen port (default: 19000).
--rpc-port: RPC listen port (default: 19001).
--rpc-host: RPC listen host/IP (default: 0.0.0.0).
--data-dir: Directory for blockchain and state storage.
--relay-server: Run as a relay server to help nodes behind NAT.
--authority-id: Authority ID for DAG consensus (e.g., 0x1).
--authorities: Comma-separated list of authority IDs.
--consensus-private-key-file: Private consensus key file for this validator.
--consensus-public-keys: Shared public-key map for the authority set.
--genesis: Shared genesis manifest used to verify that all nodes join the same chain.

Multi-Node Setup (Local)

Running multiple nodes locally is useful for testing consensus and synchronization. Each node must have a unique data directory, unique ports, unique consensus private key, and the same public-key map.

The recommended Windows devnet reset is:

cd D:\kanari-sdk\crates\kanari-node

.\setup-multi-node.ps1 `
  -NodeCount 4 `
  -Network devnet `
  -ResetSourceData `
  -ResetReplicaData `
  -ResetConsensusKeys

Manual Setup (Example for 3 Nodes)

Node 1 (Authority 0x1)

kanari-node start --network devnet --p2p-port 19000 --rpc-port 19001 --data-dir data/node1 --authority-id 0x1 --authorities 0x1,0x2,0x3

Node 2 (Authority 0x2)

kanari-node start --network devnet --p2p-port 19010 --rpc-port 19011 --data-dir data/node2 --authority-id 0x2 --authorities 0x1,0x2,0x3

Node 3 (Authority 0x3)

kanari-node start --network devnet --p2p-port 19020 --rpc-port 19021 --data-dir data/node3 --authority-id 0x3 --authorities 0x1,0x2,0x3

Local Node Mode

For testing without P2P connectivity, you can run a local-only node:

kanari-node local

Monitoring and Tools

The kanari-node binary includes several subcommands for managing and inspecting the node:

List Wallets

List all wallet files managed by the node:

kanari-node list-wallets

Blockchain Statistics

Show current blockchain stats (height, total supply, total accounts):

kanari-node stats

Account Information

Get details about a specific account:

kanari-node account &lt;ADDRESS&gt;

Block Information

Get block details by height:

kanari-node block &lt;HEIGHT&gt;

Troubleshooting

Discovered Peers: Check the logs for Node Peer ID: and Discovered peer: to confirm P2P connectivity.
Port Conflicts: Ensure --p2p-port and --rpc-port are not used by other applications.
Height not increasing while idle: This is expected. New checkpoints are produced when transactions commit.
RPC URL in browser looks empty: JSON-RPC is served through POST requests to /rpc, for example http://127.0.0.1:19001/rpc.
State divergence: Prefer snapshot restore or encrypted validator backup restore instead of deleting data blindly.

Setup Node