Networking

XE is a fully peer-to-peer network with no central servers. All node communication -- block propagation, consensus voting, synchronization, marketplace negotiation, and peer discovery -- happens over direct connections between nodes using libp2p.

Components

Architecture Overview

┌──────────────────────────────────────────────────────────┐
│                       Node                               │
│                                                          │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────┐  │
│  │   Ledger    │  │ State Chain │  │   Directory     │  │
│  └──────┬──────┘  └──────┬──────┘  └───────┬─────────┘  │
│         │                │                  │            │
│  ┌──────┴────────────────┴──────────────────┴─────────┐  │
│  │              Network Layer (net package)            │  │
│  │                                                    │  │
│  │  ┌──────────┐ ┌──────┐ ┌──────────┐ ┌───────────┐ │  │
│  │  │ GossipSub│ │ Sync │ │Messenger │ │    DHT    │ │  │
│  │  └────┬─────┘ └──┬───┘ └────┬─────┘ └─────┬─────┘ │  │
│  └───────┼──────────┼──────────┼──────────────┼───────┘  │
│          │          │          │              │           │
│  ┌───────┴──────────┴──────────┴──────────────┴───────┐  │
│  │           libp2p Host (TCP transport)              │  │
│  └────────────────────────┬───────────────────────────┘  │
└───────────────────────────┼──────────────────────────────┘
                            │
                       TCP / Internet

How Data Flows

Block Propagation

1. A node creates a new block (send, receive, lease, burn, etc.)
2. The block is added to the local ledger
3. The block is published via GossipSub on the xe/blocks topic
4. All subscribed peers receive the block, validate it, and add it to their ledgers
5. Representatives vote on the block's chain position and broadcast those votes on xe/votes

Synchronization

When a new node joins or reconnects after downtime, it uses the sync protocol to catch up:

1. On connection to a peer, the node sends its current frontiers (latest block per account)
2. The peer compares frontiers and streams back any missing blocks
3. A background loop ticks every 10 seconds, but only opens streams when local state has changed — with a forced full re-sync every 60 seconds as a safety net

[!NOTE] Sync carries blocks, not finality The frontier-sync protocol transfers block bodies. It does not transfer finalization state, which is why a node that fell behind may additionally need to pull votes for a position it cannot resolve locally.

Peer-to-Peer Messaging

The messaging protocol provides request-response semantics for targeted communication:

• VM credential delivery and status queries between provider and consumer
• Timekeeper attestation requests
• Account-to-account chat
• Targeted pulls: a missing block body by hash, the votes at a stuck position, a peer's provider certificates

Discovery Mechanisms

Peers find each other through three mechanisms:

1. mDNS -- Automatic local network discovery. Nodes on the same LAN find each other without configuration.
2. Bootstrap peers -- Explicit peer addresses passed via xe node --dial. A watchdog re-dials any disconnected bootstrap peer every 30 seconds for the lifetime of the node.
3. Kademlia DHT -- Distributed hash table for discovering peers by their peer ID. Used by the Messenger to locate peers not already in the peerstore.

[!INFO] No Central Infrastructure XE has no tracker servers, seed nodes, or central coordination points. Any node can bootstrap from any other node. The DHT protocol prefix /xe isolates the XE network from public IPFS DHT traffic.

Security Properties

• Transport encryption: libp2p provides encrypted connections by default (Noise or TLS 1.3)
• Peer identity: Each node has a persistent Ed25519 identity key, giving it a stable peer ID across restarts
• Network-ID handshake: /xe/netcheck/1 checks the peer's network ID and version on connect; a mismatch bans the peer for a bounded period
• Message validation: GossipSub pre-validates field lengths before accepting messages, and vote signatures are verified before a vote can touch dedup state
• Rate limiting: The sync protocol enforces a 5-second cooldown per peer, per direction
• Per-IP connection limits: The libp2p resource manager caps inbound connections per source IP (default 8, --max-conns-per-ip), with loopback exempt
• Size limits: All protocols enforce maximum message sizes to prevent memory exhaustion

Source Code

The networking layer lives in the net/ package of xeprotocol/core: