Chronos, no peers available

[user7]

Issue Report

Source data. Several computers were disconnected from the network from the end of December 2025. Before the disconnection, everything was fine, or even excellent, with the peers. The computers were powered on in the second week of January 2026, but the node has not been able to catch any peers since.

Problem. Nodes cannot find peers.
Service files are old (pre-disconnection), meaning they were working. Nodes see the old block height, cannot see a single peer, synchronization does not happen.

How I tried to solve the problem:

1. Updated the client version. Tried all possible versions:

   • chronos-2025-nov-07;
   • chronos-2026-jan-05;
   • chronos-2026-jan-15;

2. Updated the operating system. Was 22.04, now 24.04 (do-release-upgrade);

3. Changed internet service provider;

4. Deleted all Autonomys data (not just the db folder) and tried to sync from scratch. In this case, some information exchange happens and the node folder grows to about ~314 MB, but there are still no peers.

This issue is not occurring on just one machine; it’s happening across different providers. I hypothesized that there might be a blockade by the national communications oversight agency, but there is a computer nearby that hasn’t been rebooted for a LONG time and is working perfectly. Also, on this working computer, I am running version chronos-2026-jan-05 from 06/01/26 (I am hesitant to update to chronos-2026-jan-15).

Environment

• Operating System: Ubuntu 22.04-24.04
• Space Acres/Advanced CLI/Docker: CLI

Problem

No one peer

[Paste any errors or relevant logs here]

Logs.
Option 1 (machines with a reset node):
2026-01-24T23:20:32.438229Z INFO Consensus: substrate: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), 0 10 B/s
2026-01-24T23:20:37.438787Z INFO Consensus: substrate: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), 0 7 B/s
2026-01-24T23:20:40.683589Z INFO Consensus: subspace_service::sync_from_dsn: Received notification to sync from DSN, deactivating substrate sync reason=NoImportedBlocks last_completed_segment_index=SegmentIndex(0) last_processed_block_number=0
2026-01-24T23:20:42.439276Z INFO Consensus: substrate: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), 0 50 B/s
2026-01-24T23:20:47.439792Z INFO Consensus: substrate: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), 0 36 B/s
2026-01-24T23:20:52.440260Z INFO Consensus: substrate: Idle (0 peers), best: #0 (0x9191…69ab), finalized #0 (0x9191…69ab), 0 36 B/s

Option 2. Attempt to continue synchronization not from zero:

2026-01-24T23:22:50.017221Z INFO Consensus: substrate: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), 0 10 B/s
2026-01-24T23:22:55.017458Z INFO Domain: substrate: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), 0 0
2026-01-24T23:22:55.017538Z INFO Consensus: substrate: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), 0 7 B/s
2026-01-24T23:23:00.017729Z INFO Domain: substrate: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), 0 0
2026-01-24T23:23:00.017777Z INFO Consensus: substrate: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), 0 32 B/s
2026-01-24T23:23:03.125032Z INFO Consensus: subspace_service::sync_from_dsn: Received notification to sync from DSN, deactivating substrate sync reason=NoImportedBlocks last_completed_segment_index=SegmentIndex(187) last_processed_block_number=1159520
2026-01-24T23:23:05.017991Z INFO Domain: substrate: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), 0 0
2026-01-24T23:23:05.018034Z INFO Consensus: substrate: Idle (0 peers), best: #1159520 (0xa058…6cbf), finalized #1099088 (0xee8a…d2be), 0 7 B/s
2026-01-24T23:23:07.274943Z WARN Domain: libp2p_kad::behaviour: Failed to trigger bootstrap: No known peers.
2026-01-24T23:23:10.018216Z INFO Domain: substrate: Idle (0 peers), best: #960981 (0x61f5…81c4), finalized #946486 (0xd134…70c2), 0 0

[user7]

Upd.
Start command

ExecStart=/usr/local/bin/subspace-node-lib2p run --name 7958x5 --base-path /mnt/predator1/ --chain chronos --sync full --farmer --blocks-pruning archive-canonical --state-pruning archive-canonical --rpc-listen-on 0.0.0.0:9944 --rpc-methods unsafe --rpc-cors all – --domain-id 0 --blocks-pruning archive-canonical --state-pruning 28800

[Jim-Autonomys]

This sounds like you may be experiencing issues hitting the boostrap servers. Could you provide output for the below please (feel free to scrub anything you don’t want to share - we just need to know if they succeed)?

# Check if the DNS resolves correctly
dig bootstrap-0.chronos.autonomys.xyz
nslookup bootstrap-0.chronos.autonomys.xyz

# Test port connectivity
nc -zv bootstrap-0.chronos.autonomys.xyz 30333
nc -zv bootstrap-0.chronos.autonomys.xyz 30533
nc -zv bootstrap-0.auto-evm.chronos.autonomys.xyz 30334

If any of those fail it may help to run a trace to see your network routing:

traceroute bootstrap-0.chronos.autonomys.xyz

[user7]

Sure.
1.
root@x5-B650-Pro-RS:/home# # Check if the DNS resolves correctly
dig bootstrap-0.chronos.autonomys.xyz
nslookup bootstrap-0.chronos.autonomys.xyz

; <<>> DiG 9.18.39-0ubuntu0.24.04.2-Ubuntu <<>> bootstrap-0.chronos.autonomys.xyz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4141
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bootstrap-0.chronos.autonomys.xyz. IN A

;; ANSWER SECTION:
bootstrap-0.chronos.autonomys.xyz. 2153 IN A 65.108.232.15

;; Query time: 0 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Jan 26 21:11:12 MSK 2026
;; MSG SIZE rcvd: 78

Server: 127.0.0.53
Address: 127.0.0.53#53

Non-authoritative answer:
Name: bootstrap-0.chronos.autonomys.xyz
Address: 65.108.232.15

root@x5-B650-Pro-RS:/home# # Test port connectivity
nc -zv bootstrap-0.chronos.autonomys.xyz 30333
nc -zv bootstrap-0.chronos.autonomys.xyz 30533
nc -zv bootstrap-0.auto-evm.chronos.autonomys.xyz 30334
Connection to bootstrap-0.chronos.autonomys.xyz (65.108.232.15) 30333 port [tcp/] succeeded!
Connection to bootstrap-0.chronos.autonomys.xyz (65.108.232.15) 30533 port [tcp/] succeeded!
Connection to bootstrap-0.auto-evm.chronos.autonomys.xyz (3.141.201.231) 30334 port [tcp/*] succeeded!

root@x5-B650-Pro-RS:/home# traceroute bootstrap-0.chronos.autonomys.xyz
traceroute to bootstrap-0.chronos.autonomys.xyz (65.108.232.15), 30 hops max, 60 byte packets
1 router.lan (192.168.88.1) 0.171 ms 0.232 ms 0.291 ms
2 188.242.16.1.pool.sknt.ru (188.242.16.1) 0.941 ms 0.957 ms 0.971 ms
3 router.sknt.ru (93.100.0.158) 0.997 ms 1.007 ms 1.020 ms
4 * * *
5 * * *
6 as24940.ix.dataix.eu (178.18.226.223) 7.142 ms 6.691 ms 6.681 ms
7 core32.hel1.hetzner.com (213.239.224.26) 6.814 ms 6.944 ms core31.hel1.hetzner.com (213.239.224.38) 9.101 ms
8 ex9k1.dc1.hel1.hetzner.com (213.239.252.50) 7.537 ms ex9k1.dc1.hel1.hetzner.com (213.239.252.54) 9.215 ms 9.388 ms
9 static.15.232.108.65.clients.your-server.de (65.108.232.15) 6.662 ms 6.452 ms 6.629 ms

[ved]

Hi @user7

Have you also check if the node on your machine reachable externally. Might also be ideal to check on firewall as well

[user7]

A port scan (https://portscaner.ru/) shows that ports 30333 and 30433 are open for my IP.

[Jim-Autonomys]

@ved any advice on what information is required to debug further? OP has confirmed this is a home server so not in a DC.

[ved]

If they are running on a home server, could be an issue with their networking if peers are unable to connect through open connection. Will have to check what is causing this unfortunately

[Jim-Autonomys]

Thanks for your patience @user7. We’ve been discussing this internally and given that everything checks out on the connectivity side (DNS, port checks, traceroute all look clean), our suspicion is that the do-release-upgrade from 22.04 to 24.04 may have changed some underlying network or firewall settings. This is a common side effect of that upgrade.

Could you run the following and share the output?

Check what the upgrade did to your network/DNS config:

resolvectl status
cat /etc/resolv.conf
ls -la /etc/resolv.conf
cat /etc/netplan/*.yaml
ip addr show
ip route show

Check for firewall rules that may have been introduced or changed:

sudo iptables -L -n -v
sudo ip6tables -L -n -v
sudo ufw status verbose

Test whether a connection to the bootnode actually persists (not just opens): The nc -zv tests you ran earlier only prove a quick TCP handshake works. We need to confirm the connection can stay alive long enough for the libp2p handshake. Let this run for about 60 seconds then Ctrl+C and share the output:

timeout 60 bash -c 'exec 3<>/dev/tcp/bootstrap-0.chronos.autonomys.xyz/30333 && echo "Connected" && cat <&3'

Check if there are any active connections to peers while the node is running:

ss -tnp | grep -E '30333|30533|30334'

This should help us narrow down whether it’s a firewall/DNS issue from the upgrade or something else at the network level.

[user7]

Thanks for the detailed response and for taking the time to look into this.

I’ve gone through the suggested checks, and overall the system-level connectivity looks fine (DNS resolution, TCP reachability, no obvious firewall blocks). However, after digging deeper and experimenting, I believe the issue is likely higher up the stack, specifically around libp2p bootstrap/discovery behavior rather than OS or firewall configuration.

What I’m consistently observing is the following:

• Nodes that were running continuously before the libp2p update remain connected and operate normally.
• Nodes that are upgraded or started from a cold state fail to discover peers (0 peers indefinitely), despite being able to resolve DNS and establish basic TCP connections.
• Manually specifying a known, healthy bootstrap node using --bootstrap-node immediately resolves the issue and the node begins peer discovery and syncing as expected.

This strongly suggests that initial peer discovery / bootstrap is failing under certain network conditions, while established or manually seeded connections remain stable.

I’m located in Russia, where UDP and some P2P-related traffic can be unreliable or filtered. My suspicion is that recent libp2p changes (transport prioritization, timeouts, or discovery behavior) may have reduced tolerance to degraded or asymmetric networks, particularly during cold start. Once a peer is known, connectivity appears stable.

From this perspective, the OS upgrade (22.04 → 24.04) seems less likely to be the root cause, since:

• The issue is reproducible only after restart / fresh start.
• Manual bootstrap works without any system-level changes.

It may be worth checking whether:

• bootstrap node availability / reachability assumptions changed
• transport fallback behavior changed (e.g. UDP/QUIC vs TCP)
• cold-start discovery has stricter timing or failure conditions after the libp2p update

I’m happy to provide logs, configs, or help test potential mitigations (e.g. alternative bootstrap lists or transport preferences) if that’s useful.

PS. I can reproduce this reliably on multiple machines / clean installs

[user7]

Check what the upgrade did to your network/DNS config:
root@x-desktop:/home/x# resolvectl status
cat /etc/resolv.conf
ls -la /etc/resolv.conf
cat /etc/netplan/*.yaml
ip addr show
ip route show
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Current DNS Server: 8.8.8.8
DNS Servers: 8.8.8.8 8.8.4.4
Fallback DNS Servers: 1.1.1.1

Link 2 (enp8s0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.88.1
DNS Servers: 192.168.88.1 94.19.255.3 93.100.1.4

Link 3 (wlp6s0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

Link 4 (docker0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported

nameserver 127.0.0.53
options edns0 trust-ad
search .
lrwxrwxrwx 1 root root 39 ноя 26 13:43 /etc/resolv.conf → ../run/systemd/resolve/stub-resolv.conf

network:
version: 2
renderer: NetworkManager
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp8s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether a8:a1:59:56:7b:41 brd ff:ff:ff:ff:ff:ff
inet 192.168.88.66/24 brd 192.168.88.255 scope global dynamic noprefixroute enp8s0
valid_lft 362sec preferred_lft 362sec
inet6 fe80::798:4cee:b0d0:6875/64 scope link noprefixroute
valid_lft forever preferred_lft forever
3: wlp6s0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 78:2b:46:58:18:44 brd ff:ff:ff:ff:ff:ff
4: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default
link/ether 8e:d6:6e:d3:11:32 brd ff:ff:ff:ff:ff:ff
inet 172.17.0.1/16 brd 172.17.255.255 scope global docker0
valid_lft forever preferred_lft forever
inet6 fe80::8cd6:6eff:fed3:1132/64 scope link
valid_lft forever preferred_lft forever
default via 192.168.88.1 dev enp8s0 proto dhcp metric 100
169.254.0.0/16 dev enp8s0 scope link metric 1000
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 metric 425 linkdown
192.168.88.0/24 dev enp8s0 proto kernel scope link src 192.168.88.66 metric 100

Check for firewall rules that may have been introduced or changed:

root@x-desktop:/home/x# sudo iptables -L -n -v
sudo ip6tables -L -n -v
sudo ufw status verbose
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER-USER all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-FORWARD all – * * 0.0.0.0/0 0.0.0.0/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (1 references)
pkts bytes target prot opt in out source destination
0 0 DROP all – !docker0 docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-BRIDGE (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER all – * docker0 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-CT (1 references)
pkts bytes target prot opt in out source destination
0 0 ACCEPT all – * docker0 0.0.0.0/0 0.0.0.0/0 ctstate RELATED,ESTABLISHED

Chain DOCKER-FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-CT all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-INTERNAL all – * * 0.0.0.0/0 0.0.0.0/0
0 0 DOCKER-BRIDGE all – * * 0.0.0.0/0 0.0.0.0/0
0 0 ACCEPT all – docker0 * 0.0.0.0/0 0.0.0.0/0

Chain DOCKER-INTERNAL (1 references)
pkts bytes target prot opt in out source destination

Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 DOCKER-USER all * * ::/0 ::/0
0 0 DOCKER-FORWARD all * * ::/0 ::/0

Chain OUTPUT (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination

Chain DOCKER (0 references)
pkts bytes target prot opt in out source destination

Chain DOCKER-BRIDGE (1 references)
pkts bytes target prot opt in out source destination

Chain DOCKER-CT (1 references)
pkts bytes target prot opt in out source destination

Chain DOCKER-FORWARD (1 references)
pkts bytes target prot opt in out source destination
0 0 DOCKER-CT all * * ::/0 ::/0
0 0 DOCKER-INTERNAL all * * ::/0 ::/0
0 0 DOCKER-BRIDGE all * * ::/0 ::/0

Chain DOCKER-INTERNAL (1 references)
pkts bytes target prot opt in out source destination

Chain DOCKER-USER (1 references)
pkts bytes target prot opt in out source destination
Состояние: неактивен

nc -zv test:
shpekht@MacBook-Air-Igor ~ % nc -zv 192.168.88.66 30333
Connection to 192.168.88.66 port 30333 [tcp/*] succeeded!

Test whether a connection to the bootnode actually persists (not just opens):
root@x-desktop:/home/x# timeout 60 bash -c ‘exec 3<>/dev/tcp/bootstrap-0.chronos.autonomys.xyz/30333 && echo “Connected” && cat <&3’
Connected

Check if there are any active connections to peers while the node is running:
root@x-desktop:/home/x# ss -tnp | grep -E ‘30333|30533|30334’
ESTAB 0 4462 192.168.88.66:30533 65.108.232.15:60972 users:((“subspace-farmer”,pid=307036,fd=537))
ESTAB 0 0 192.168.88.66:30533 74.215.174.254:57349 users:((“subspace-farmer”,pid=307036,fd=527))
ESTAB 0 18452 192.168.88.66:37886 65.108.232.15:30333 users:((“subspace-node-c”,pid=306928,fd=62))
FIN-WAIT-1 0 915 192.168.88.66:48578 65.108.232.15:30533
ESTAB 0 7700 192.168.88.66:30533 65.108.232.15:30533 users:((“subspace-farmer”,pid=307036,fd=529))
ESTAB 0 0 192.168.88.66:30533 185.61.76.201:1052 users:((“subspace-farmer”,pid=307036,fd=517))
ESTAB 0 884 192.168.88.66:49278 65.108.232.15:30533 users:((“subspace-node-c”,pid=306928,fd=60))
ESTAB 0 0 192.168.88.66:30533 13.59.194.214:30433 users:((“subspace-farmer”,pid=307036,fd=522))

[ved]

Thanks for the detailed diagnostics, @user7 — the ss output and
persistent-connection test confirm your network path is fine, so the
issue is purely libp2p cold-start discovery as you suspected.

Chronos has a single bootstrap node by design, so the workaround is to
give your cold-start machines an additional, reliable peer to bootstrap
against. The most robust option is your own long-running node — it’s
on a network path you control and you’ve already proven it stays
connected. Three steps:

1. Get your long-running node’s peer ID. It’s logged at startup as:
Local node identity is: 12D3KooW…
or you can derive it from <base-path>/network/secret_ed25519.

2. Pin it as a bootstrap on your cold-start machines. Three layers,
three flags (only the first two if you’re not running the auto-evm domain):

--bootstrap-node /ip4//tcp/30333/p2p/
–dsn-bootstrap-node /ip4//tcp/30533/p2p/
– # if running the domain operator:
–domain-args --bootstrap-node /ip4//tcp/30334/p2p/

For LAN-only setups, also pass --allow-private-ips so private IPs
participate in the DHT.

3. Add --reserved-peer for the same address. --bootstrap-node is
only used for initial discovery; once your peer set is established the
node may drift. --reserved-peer keeps the connection prioritised, so
you don’t slip back to “0 peers” if Kademlia rotates neighbours.

Other options that may help on a flaky path:

• Bump --out-peers 16 (default 8) — more outgoing connection attempts.
• If your ISP gives you a routable IPv6 prefix, bootstrap-0’s IPv4
  path can be replaced by adding the IPv6 multiaddr; that often takes a
  different network path.

[Emmanuel_Marv]

Chronos “No Peers” Emergency Fix

Overview: If your Chronos node is stuck at “0 peers,” it is likely a “Cold Start” discovery issue. Since Chronos uses a single bootstrap node, you need to manually point your machine to a reliable “anchor.”

Step 1: Get the Peer Multiaddr

You need the address of a stable node (either yours or a trusted friend).

• Find the ID: Look for Local node identity is: 12D3KooW... in your terminal logs.

• Format the Address: It should look like this: /ip4/[PUBLIC_IP]/tcp/30333/p2p/[PEER_ID]

Step 2: Update your Startup Command

Add these specific flags to your node execution command. This tells your node exactly where to look for peers.

Bash

# Force discovery via a known node
--bootstrap-node /ip4/[IP_ADDRESS]/tcp/30333/p2p/[PEER_ID]

# Ensure the DSN layer also connects
--dsn-bootstrap-node /ip4/[IP_ADDRESS]/tcp/30533/p2p/[PEER_ID]

# IMPORTANT: Keep the connection alive
--reserved-peer /ip4/[IP_ADDRESS]/tcp/30333/p2p/[PEER_ID]

Step 3: Troubleshooting “Local” Blocks

• LAN/Private Setup: If your nodes are on the same local network, add --allow-private-ips.

• Network Congestion: If your ISP is shaky, increase your connection attempts: --out-peers 16.

• IPv6: If you have a routable IPv6, try using the /ip6/ multiaddr instead of /ip4/ to bypass IPv4 routing bottlenecks.