Kaspa DNS Seeders help a new node discover reachable peers; they do not set consensus rules or control the network. A July 22, 2025 Rusty Kaspa change removed two operator-managed seed entries, one for mainnet and one for Testnet 10, after the operator requested their retirement.

Key takeaways

• Pull request 690 removed one mainnet and one Testnet 10 DNS seeder hostname from Rusty Kaspa’s network parameters.
• The merged diff contained zero additions and four deletions in a single configuration file.
• A DNS seeder supplies candidate peer addresses during bootstrap; it does not validate transactions or decide the accepted DAG history.
• Removing a retired endpoint is normal operational hygiene, not evidence that Kaspa’s consensus rules changed.
• Node operators should use supported releases, monitor peer connectivity, and configure known peers only when their operating model requires it.

What changed in the Kaspa DNS seed list?

The primary record is Rusty Kaspa pull request 690, titled “Remove DNS seeders managed by H@H upon his request.” It was merged into the master branch on July 22, 2025. The patch deleted ns-mainnet.kaspa-dnsseeder.net from the mainnet parameters and ns-testnet10.kaspa-dnsseeder.net from the Testnet 10 parameters.

That is the complete documented scope: four lines removed from consensus/core/src/config/params.rs, including the two explanatory comments. Other seeder entries remained in the surrounding configuration. The pull request did not allege a security incident, network attack, or consensus failure, so none should be inferred from it.

What does a DNS seeder actually do?

A node joining a peer-to-peer network needs an initial set of addresses before ordinary peer exchange can take over. A DNS seeder answers that bootstrap problem by returning a changing sample of reachable nodes. The official Kaspa DNSSeeder repository explains that its crawler learns peers from address messages, checks availability, and responds to DNS queries with a random selection of reliable candidates.

The distinction between discovery and validation is essential. A seeder can suggest where a node might connect, but the node independently exchanges protocol messages and applies Kaspa’s consensus rules. A seeder cannot make an invalid block valid, spend a user’s UTXO, or rewrite the local consensus implementation.

After a successful bootstrap, nodes learn additional addresses from connected peers. This means a configured seed list is an entry point into a wider topology, not a permanent list of every participant.

Why remove a seeder instead of leaving it in place?

An endpoint that its operator no longer intends to maintain can become stale, fail DNS resolution, or return no useful peers. Keeping it in a default configuration would add avoidable lookup failures and make the software’s bootstrap assumptions less accurate. Removing it also respects the infrastructure operator’s explicit request.

The change illustrates a healthy separation of responsibilities. Community members may contribute discovery infrastructure, while maintainers keep the reference node’s defaults aligned with endpoints that are intended to remain available. Neither role grants control over proof of work or BlockDAG ordering.

The source does not state why the operator retired the services. It is therefore accurate to describe the reason only as an operator request, not as a capacity problem, legal event, compromise, or dispute.

Did the removal make Kaspa dependent on fewer parties?

The diff reduced the hard-coded list by two entries, but a count alone cannot establish the resilience of the whole peer network. Resilience also depends on the independence, geographic and hosting diversity, uptime, software versions, and address quality of the remaining discovery paths and reachable nodes.

Conversely, adding many hostnames would not automatically make discovery decentralized if all of them shared the same operator or infrastructure. A better assessment asks whether nodes can bootstrap through multiple independent routes and then maintain diverse outbound peers.

Operators who want to examine node behavior should measure successful peer connections and synchronization rather than treating a DNS response as proof of node health. A returned address may expose peer-to-peer service without offering the public RPC access needed by a wallet, indexer, or miner.

What should Kaspa node operators do?

Most operators should run a supported Rusty Kaspa release and let its maintained defaults handle ordinary discovery. Building an arbitrary commit from master is different from deploying a tagged stable release; production operators should follow release notes and their own change-control process.

Useful monitoring includes peer count, connection churn, synchronization progress, outbound reachability, resource use, and repeated DNS failures. An operator maintaining isolated test infrastructure may also use explicit peers, but those peers need independent availability checks. They should not be copied from an unverified public list and assumed trustworthy.

Developers who need a controlled environment can follow our Kaspa devnet node guide. For a separate look at verifiable node state, see Kaspa genesis proof tooling.

What the change did not alter

Pull request 690 did not modify block validation, proof-of-work parameters, transaction rules, pruning logic, wallet derivation, mining rewards, or the UTXO set. It changed static discovery configuration only. Existing nodes with active peers would not need a DNS seed to validate the next block merely because one seed entry disappeared.

It also did not guarantee that every remaining seeder would always be online. Discovery infrastructure is operational software, so endpoints can change over time. That is precisely why small maintenance patches and observable node metrics matter.

Frequently asked questions

Can a Kaspa DNS seeder see my private keys?

No. A DNS query asks for peer addresses. Private keys remain in the wallet and should never be sent to a seeder or node operator.

Does a DNS seeder determine which Kaspa transactions are confirmed?

No. Confirmation and acceptance come from the node’s view of Kaspa consensus. A seeder only helps the node locate peers.

Should every operator hard-code extra peers after this change?

Not necessarily. Supported defaults are appropriate for most users. Explicit peers are an operational choice for controlled deployments and require their own monitoring.

Source and verification note

The primary source is the merged kaspanet/rusty-kaspa pull request 690, including its one-file diff and July 22, 2025 merge record. The Kaspa DNSSeeder README documents the seeder’s discovery function. Claims here are limited to those records; the pull request provides no evidence of a security incident or consensus change.