Node Dashboard

The Interfold has two dashboards. The local node dashboard runs inside your ciphernode process and shows what that node knows. The hosted dashboard is a public web app that reads the chain. This page is for operators who monitor a ciphernode. At the end, you can enable the local dashboard and open it safely from another computer. You can also read its JSON API, send alerts from it, and you know when to use the hosted dashboard.

Local node dashboard

The interfold binary includes the local dashboard. It needs no separate installation. It is off until you set a port.

Enable the dashboard

# interfold.config.yaml
node:
  dashboard_port: 9092

Dashboard available at http://127.0.0.1:9092

Open the dashboard from another computer

The dashboard listens only on the loopback interface of the host that runs the node. To open it from your own computer, use an SSH tunnel:

ssh -L 9092:127.0.0.1:9092 user@your-server

Keep the SSH session open, then open http://127.0.0.1:9092 on your own computer.

In a container, 127.0.0.1 is the loopback interface of the container. A port that you publish with Docker does not reach it. Open the dashboard from the network namespace of the node process.

Views

The dashboard has six views. The address of each view is #<view>, for example #logs, so you can bookmark it. The views refresh automatically while the browser tab is visible.

The Operator state card on the Overview reads the chain at most once every 15 s. It shows the status: Active, Registered, Not registered, or Exit queued. It also shows the available tickets, the ticket balance, the ciphernode bond, and the node counts. The ticket balance and the ciphernode bond are raw token base units. Hover over a value to see the full number.

The Rewards count on the card shows the number of E3 rewards that the operator earned as a committee member. The dashboard finds the reward of the operator in the RewardsDistributed and RewardCredited events of each E3. The count includes rewards that go to a separate bond owner wallet. See Rewards.

The Events view gives each event a level:

When a refresh fails, the dashboard keeps the last data and shows Live refresh paused with the error.

Common tasks

• Trace one E3. Open E3 traces and select the E3. The current phase opens first. A trace that stops in a phase shows where the E3 stopped.
• Find errors. Open Events and set the level to Errors. Open an event to read its payload.
• Check the network after a restart. On Overview, compare the connected peers with the configured peers. A network error appears in the Connected nodes panel.
• Prepare an upgrade. Open Updates. Wait until the active E3 count is 0 before you stop the node. See Upgrades.

JSON API

The dashboard gets its data from a JSON API on the same port. You can call the API with curl on the host that runs the node:

curl -s http://127.0.0.1:9092/api/snapshot | jq '.network'

The API has five endpoints: /api/snapshot, /api/e3, /api/events, /api/logs, and /api/updates. Dashboard API gives the parameters, the response fields, and the errors of each endpoint. For OpenAPI tools, use the OpenAPI description.

Protocol events come from the durable EventStore of the node. Log entries come from a bounded in-memory store, and the node also writes them to ciphernode.jsonl in the node data directory. Log entries are diagnostics, not protocol records.

Monitor the node with the API

A monitoring system can read the API and send an alert when a value is out of range. This procedure makes a check that sends an alert when the node has fewer than 10 connected peers. The check needs curl and jq on the host of the node.

#!/usr/bin/env bash
# Exit 0 when the peer count is good, 1 when it is low, 2 when the check fails.
PORT=9092
MIN_PEERS=10
 
body=$(curl -sf --max-time 10 "http://127.0.0.1:${PORT}/api/snapshot") || {
  echo "CRITICAL: dashboard API does not answer"
  exit 2
}
peers=$(jq -e '.network.connected_peers | if type == "array" then length else error("no peer list") end' <<<"$body" 2>/dev/null) || {
  echo "CRITICAL: response is not a dashboard snapshot"
  exit 2
}
if [ "$peers" -lt "$MIN_PEERS" ]; then
  echo "WARNING: ${peers} connected peers (minimum ${MIN_PEERS})"
  exit 1
fi
echo "OK: ${peers} connected peers"

sudo chmod 755 /usr/local/bin/check-interfold-peers.sh

*/5 * * * * /usr/local/bin/check-interfold-peers.sh || /usr/local/bin/send-alert "interfold peers"

Poll /api/snapshot at an interval of 30 s or more. Each request reads the new EventStore events and can start chain RPC reads.

You can make checks for other values with the same method:

Hosted dashboard

The hosted dashboard at https://dashboard.theinterfold.com reads contract events and views directly from the chain. It does not connect to your ciphernode, so it cannot show peers, logs, or the local state of your node. Each page reads one network, and the page shows the network name. The VITE_NETWORK_HOSTS build variable maps each domain to a network (sepolia or mainnet). Other hosts use the VITE_NETWORK build variable, default sepolia.

It has three views:

The operator guide is the only view that writes to the chain. It reads the bond size, the ticket price, the minimum ticket count, and the exit delay from BondingRegistry. It has five steps:

1. Connect a wallet.
2. Authorize the bond owner. The operator key sends setBondOwner.
3. Bond the ciphernode bond. The bond owner approves FOLD and sends bondCiphernodeFor.
4. Register the ciphernode. The bond owner sends registerOperatorFor.
5. Buy tickets. The bond owner approves the ticket collateral and sends addTicketBalanceFor.

After setup, Manage the position sends the other transactions of the interfold ciphernode commands: refreshOperatorStatus (refresh the status), removeTicketBalanceFor (burn tickets), unbondCiphernodeFor (unbond FOLD), deregisterOperatorFor (leave the network), claimExitsFor (claim exits), proposeBondOwner, and acceptBondOwner. It shows the collateral in the exit queue and the part whose exit delay has ended. An open slash proposal, or a committee of the operator that is not released yet, can still hold a claim. The bond owner sends each of them, except that the operator key can also deregister, any wallet can refresh the status and claim tickets, and the proposed owner accepts a transfer. A node that runs without the CLI, for example a DAppNode package, uses these actions.

E3 rewards, at the top of the page, shows the amount that the operator's recipient can claim and a Claim rewards action. The recipient is the bond owner of the operator at committee finalization, or the operator key when it had no bond owner. Connect the recipient wallet to claim. The action sends claimRewards(e3Ids) for the completed E3s, then claimHonestNodeReward(e3Id, operator) for each failed E3. Below it, the committee history shows each E3 that selected the operator, with its outcome, its amount, and a claim status: In progress, Claimable, Claimed, On hold (an open expulsion proposal holds the payment), Forfeited (an executed expulsion), Needs processing, Not eligible (not an honest member of a failed E3), or No reward. Point to a status to see its reason. A failed E3 needs processE3Failure(e3Id) before its honest members can claim. Any connected wallet can send it with Process in the history.

The guide simulates each transaction before the wallet prompt, so a contract error, for example NotBondOwner, shows before you sign. The guide manages the on-chain position only. The ciphernode must run with the same operator key. See Registration for the CLI procedure.

Next steps