Kaspa P2P Network: Peer Discovery, Gossip & Block Propagation

Kaspa's BlockDAG produces blocks at 10 per second. Every one of those blocks has to reach every honest node on the network — fast enough that the DAG stays well-connected and GHOSTDAG can order events correctly. But none of this happens by magic. Beneath the consensus layer sits a peer-to-peer networking stack that handles three deceptively simple jobs: finding other nodes, staying connected to them, and moving data between them.

This article walks through that networking layer — the mechanics that keep the gossip running — and explains why Kaspa Forge chose to build its own node infrastructure on top of it.

Bootstrap: The First Address

A freshly started Kaspa node knows nobody. It has no peer list, no address cache, no history. To break this cold-start problem, the codebase includes a set of DNS seeders hardcoded in the network parameters (domain/dagconfig/params.go).

When the node starts, it resolves these DNS names, which return IP addresses belonging to well-known, currently-running Kaspa nodes. The node picks from that list and attempts its first TCP connections. As the Kaspa wiki's Developers Knowledge Base documents, this is the entry point every node must pass through.

This is the most centralized touchpoint in the entire networking layer — a small set of seeders that any new node must reach. It's a pragmatic trade-off: without *some* known entry point, a node has no way to discover the network at all. Once connected, the node quickly graduates to decentralized peer exchange.

Peer Exchange: Growing the Address Set

After the first successful connection, the node asks its new peer for more addresses. By default, the peer responds with 1,000 shuffled addresses drawn from its local address database, which holds up to 4,096 entries.

The requesting node stores these and begins connecting to them. Each new peer it contacts provides another batch of addresses. Over minutes, the node builds its own address database — a rolling, gossip-propagated directory of the network's active participants.

This mechanism means address discovery is proportional to network size. The more nodes there are, the faster any individual node fills its address store. No central directory is needed after the initial DNS bootstrap.

Connection Management: Eight Outbound Peers and a Heartbeat

A Kaspa node doesn't connect to everyone. It targets 8 active outbound connections (infrastructure/network/connmanager/outgoing_connections.go). It also accepts inbound connections from other nodes, but 8 is the number it actively maintains.

To keep these connections healthy, nodes exchange ping-pong messages every 2 minutes (app/protocol/flows/v5/ping/send.go). A peer that fails to respond is considered dead and dropped. The node then sweeps its address database for a replacement and reconnects, maintaining its target count.

Eight peers might seem modest — Bitcoin defaults to 8 outbound as well, but Bitcoin produces one block every 10 minutes. Kaspa produces 10 blocks per second. Each peer relationship carries dramatically more data. The connection count is a deliberate balance between redundancy and the bandwidth cost of staying synchronized at 10 BPS.

The Gossip Layer: Announce, Then Request

Here is the core mechanism that moves data across the network.

When a Kaspa node receives a new block — whether it mined the block itself or received it from a peer — it does not immediately send the full block to every connected peer. Instead, it broadcasts only the block hash (app/protocol/flowcontext/blocks.go). Transaction hashes get the same treatment (app/protocol/flowcontext/transactions.go).

Each receiving peer checks whether it already has the corresponding block or transaction. If it does, nothing further happens — the hash is quietly acknowledged and ignored. If it doesn't, the peer requests the full data from the announcing node.

Node A mines block B
  → broadcasts hash(B) to peers [C, D, E, ...]
  → Node C receives hash(B), lacks the block
    → requests full block B from A
    → once received, broadcasts hash(B) to its peers [F, G, ...]
  → Node D already has block B
    → ignores hash(B)

This inventory-based gossip — a pattern Bitcoin popularized and Kaspa inherits — has a critical property: the announcement payload is a fixed 32-byte hash regardless of block size. The expensive full-block transfer happens once per peer that needs it, and only on demand.

At 10 blocks per second, this matters enormously. Naively broadcasting full blocks to every peer would mean bandwidth proportional to peers × block_size × 10. The announce-then-request pattern reduces the baseline gossip traffic to peers × 32 bytes × 10, with full blocks transferred only where gaps exist.

Transport: TCP, Not UDP

Kaspa's peer communication uses TCP — specifically, gRPC over TCP (infrastructure/network/netadapter/server/grpcserver/grpc_server.go). This is a deliberate choice with clear trade-offs.

TCP guarantees ordered, reliable delivery. Every message arrives exactly once, in sequence. UDP, by contrast, is faster but lossy — packets can arrive out of order or not at all. For a blockchain network where a missed block hash means a missed block and a potential gap in a node's DAG view, TCP's reliability outweighs UDP's latency advantage.

The cost is real: TCP's connection establishment, congestion control, and acknowledgment overhead add latency that UDP avoids. In latency-sensitive applications — live video, gaming — UDP wins. For a blockchain gossip layer where correctness matters more than shaving milliseconds, TCP is the more defensible foundation.

Transaction Relay: Mempool Policy at the Network Edge

Transactions propagate through the same gossip mechanism — hash first, full data on request — but the mempool adds a policy layer on top.

By default, Kaspa nodes enforce a minimum fee of 0.0001 KAS per UTXO as a relay threshold. A transaction below this fee is rejected from the node's mempool and not forwarded to peers. This is an anti-spam measure, not a consensus rule. A miner is free to include zero-fee transactions in a block; other nodes will accept that block without complaint.

The distinction between relay policy and consensus rule is important. The fee floor is a social agreement among node operators — a spam filter at the network's edge. It can be adjusted by updating node software; it does not require a hard fork.

Transactions also have expiration behavior that depends on how they entered the mempool:

• P2P-relayed transactions (received from a peer) expire after 60 blocks if not included in the DAG.
• RPC-submitted transactions (sent by a wallet, such as Desk) never expire. They are periodically rebroadcast until the node restarts or the transaction is mined.

This asymmetry means wallet-submitted transactions persist indefinitely in the mempool, while relayed ones get garbage-collected. For covenant-based products where a transaction might need to wait for a time-lock window, the non-expiring RPC path ensures the commitment stays alive until the DAG accepts it.

Why Kaspa Forge Runs Its Own Nodes

The networking layer described above is the substrate every Kaspa service depends on. Blocks and transactions arrive through gossip. They can arrive at different times to different nodes, which means the selected chain — and therefore the "canonical" ordering of events — can temporarily disagree between nodes. This is normal in a BlockDAG, but it has consequences for any service tracking on-chain state.

Several design consequences flow from the gossip model:

Propagation delay creates temporary forks. At 10 BPS, a block mined in one part of the network might not reach all nodes before another block references the same tips. GHOSTDAG handles this gracefully — that's what the DAG is for — but indexers must be prepared to reprocess state when the selected chain reorganizes. Our indexers rebuild their projections from the node's updated DAG view whenever this happens, as described in our reorg-aware indexer design.

Transaction submission uses the same relay path. When a user signs a transaction in Desk and submits it, that transaction enters the local node's mempool via RPC and then propagates to peers through gossip. The non-expiring RPC behavior ensures covenant transactions — vault withdrawals, Escrow settlements, Deposit claims — remain in the mempool until they're mined, even if the relevant time-lock hasn't elapsed yet.

Fee policy affects relay speed. A transaction at or above the default relay minimum will be forwarded by honest peers. Below that threshold, it may be silently dropped. For Kaspa Forge's covenant contracts, which must calculate fees precisely to enforce on-chain spending conditions, understanding the relay policy is not optional — it's a design constraint. Our contracts account for this, as detailed in the fee budget griefing protection writeup.

Trade-offs and Honest Limitations

The networking layer works, but it has known trade-offs worth stating plainly.

DNS seeder centralization. The bootstrap mechanism depends on a small set of DNS seeders compiled into the node binary. If every seeder went offline simultaneously, new nodes would have no automated way to discover peers. In practice, operators can manually add peer addresses, and the seeder infrastructure has been reliable — but it remains a single point of trust at first launch.

TCP overhead at high BPS. TCP's reliability comes with connection management overhead. At 10 blocks per second with 8+ peers, the constant stream of block hashes, ping-pongs, and data requests adds up. This is manageable today, but as Kaspa scales toward higher block rates, the networking layer will face increasing bandwidth and latency pressure.

Gossip latency is not uniform. A block hash doesn't reach all nodes simultaneously. The further a node is from the miner in the gossip graph — measured in hops, not geography — the longer the delay. Different nodes may temporarily hold different views of the DAG's tips. GHOSTDAG tolerates this, but it creates the reorg events that downstream indexers must handle.

No built-in peer quality scoring. The current protocol doesn't rank peers by latency, uptime, or data quality. A slow or unreliable peer occupies one of the 8 outbound slots just like a fast one. This is an area where future protocol improvements could help, but today the node treats all peers equally.

These are not bugs — they are engineering trade-offs made in the context of a network that prioritizes simplicity, correctness, and the ability to function at 10 blocks per second. Understanding them helps explain why Kaspa Forge invests in dedicated node infrastructure rather than relying on public endpoints: when your indexer's state depends on seeing every block in near-real-time, controlling your position in the gossip graph is not a luxury.