— How Sonar works

What each card checks, and how to read it

Sonar shows a node two ways: live, probed right now from the prober, and recorded, from years of our crawlers' data. Every card below is shown as it appears on a result page, with sample data.

Peers

Paste a PeerID, an ENR or a multiaddress. Sonar probes the node live, from our own infrastructure, and shows the result next to what our crawlers have recorded about it over the years. When the two disagree, that difference is usually the finding.

Networks

The networks the peer belongs to: IPFS, Filecoin, Ethereum, Celestia, Polkadot, Avail and more.

  • A network lights up when the live probe finds the peer in that network's DHT, or when the peer names the network's protocols as it identifies itself.
  • A network marked "recorded" comes only from our crawl records: the live probe did not confirm it.
  • "Checking" lists the networks still being looked up; "not in" the ones ruled out.

Why it matters
A node that should be on a network but is not found there is usually misconfigured, offline or unreachable.

Reachability

Every address the peer is known by, and whether other peers can reach it there.

  • Sonar dials each address one at a time and shows how long the connection took to set up and the round-trip time (RTT) once connected.
  • A failed dial shows a short reason; click it for the full error.
  • Addresses are grouped by host, each with its location. The columns on the right show where each address came from: the identifier itself, the DHT, IPNI, or the peer's identify answer.
  • Turn on "Recorded" to see every address our crawlers stored for the peer, going back years.
  • A relayed address is dialed through its relay, and the relay's own answer is shown apart. Private addresses are shown but never dialed.

Why it matters
This is the card that answers "can other peers connect to my node, and on which address?".

DHT Overview

The peer's own DHT routing table, and how many other peers keep it in theirs.

  • If Sonar can connect, it reads the peer's routing table bucket by bucket. Each cell is a bucket; hover it to see the PeerIDs inside.
  • Below the table: how many other peers in the network have this peer in their routing tables.
  • A peer that runs the DHT only as a client has no table to read, and the card says so.

Why it matters
A thin or empty routing table means the peer will be slow to find content and other peers.

Agent

The client and version the peer runs, and every version our crawlers saw it run before.

  • The live version comes from the identify exchange.
  • The history comes from our crawls, with the day each version was first seen.

Why it matters
Use it to check that an upgrade reached the network, or to spot a node stuck on an old release.

Protocols

The protocols the peer advertises now, and the ones it advertised in the past.

  • Live protocols come from the identify exchange; past ones from our crawl records.
  • Protocols added or dropped over time are marked, so you can see when a feature was turned on.

Why it matters
A missing protocol often explains why other peers cannot use a node for something.

IPNI indexer status

Whether the IPNI indexers know the peer as a content provider.

  • Sonar asks each indexer whether the peer is registered, then shows its latest state: the CID of the most recent advertisement, or the last error the indexer recorded.
  • Most IPFS peers advertise nothing there; it is mainly Filecoin storage providers.

Why it matters
A provider the indexers do not know cannot be found through them, whatever it stores.

Port exposure

Admin ports reachable on the peer's own host.

  • Depending on the network, Sonar checks a short list of well-known ports: the Kubo RPC, the Lotus API, an Ethereum JSON-RPC, a beacon API and others.
  • Only the host the peer itself advertises is checked, never another host or a private range.
  • Each open port shows its risk and what answered on it.

Why it matters
A node set up in a hurry can leave an admin port open to the internet, and anyone can then control it.

GeoIP

Where the peer's public IP addresses are on the map.

  • Every public IP from the addresses above is placed by our GeoIP service, with its network (AS) and company.
  • Labels say whether the address is in a cloud, behind a VPN or on Tor.
  • A diamond is a relay the peer is reached through; its location is the relay's.

Why it matters
Where a node runs, and on whose network, says a lot about how it was deployed.

Consensus layer

For an Ethereum consensus-layer node: what it told Sonar in the live handshake.

  • Sonar runs the consensus-layer Status and MetaData exchange with the node found from its ENR.
  • Status gives its fork, its head and its finalized checkpoint; MetaData the attestation, sync and data-column subnets it serves. The ENR's own subnet bits are shown next to them.
  • A node Sonar cannot reach, or one searched by PeerID rather than ENR, has no handshake to show.

Why it matters
A node on the wrong fork, or far behind the head, is not following the chain however reachable it is.

Identifier encoding

Every field inside the identifier, decoded from the identifier alone.

  • For an ENR: IP addresses, ports, fork digest, subnets and the other key-value pairs.
  • For a PeerID: the multibase, the multihash and the key type.
  • Add &cards=dissection to a result URL to see only this card. With &cards=dissection,geoip it replaces our old ENR viewer.

Why it matters
A wrong field in a record, such as an old IP or the wrong fork, is easy to spot here.

Port checks: inspect your own node

The port check is for operators who want to see what their own node exposes. It checks only a short list of well-known admin ports, only on the host the peer itself advertises, and never on private ranges. Use it on nodes you run, or with their operator's consent. If it finds an open admin port on your node, close it or put it behind a firewall.