# Kaspa v2.1.0 Node Sync: What Changed in IBD?

> Kaspa v2.1.0 uses 20 MiB IBD chunks and supports Protocol 10 peers, but publishes no end-to-end sync-speed benchmark. Here’s what operators can verify.

![Kaspa v2.1.0 Node Sync: What Changed in IBD?](https://kaspa-daily.nicheflash.com/media/articles/2774-2duh44dzxst4-16x9.jpg)

- Source: https://kaspa-daily.nicheflash.com/blogs/kaspa-v2-1-node-sync
- Author: [Kaspa Daily Editorial Team](https://kaspa-daily.nicheflash.com/authors/kaspa-daily-editorial-team)
- Publisher: Kaspa Daily
- Published: 2026-10-19
- Updated: 2026-10-19

## Key takeaways

- Kaspa v2.1.0 introduces P2P Protocol Version 11, which streams large Initial Block Download (IBD) payloads in 20 MiB chunks. [1]
- The 1 GiB limit applies to specified proof and trusted-data transfers, not necessarily every IBD payload. [2]
- Protocol 11 is backward compatible with Protocol 10 peers. [1]
- Chunking targets transfer bottlenecks and timeouts; the release publishes no end-to-end sync-speed benchmark. [1]

Kaspa v2.1.0 node sync changes how large IBD data moves between peers: Protocol 11 sends specified payloads in chunks rather than as one large transfer. The release does not establish that this change shortens the full time needed to sync a node.

## What is IBD, and what was the sync problem?

Initial Block Download, or IBD, is how a new or returning node obtains data from peers to catch up with the network. Kaspa v2.1.0 identifies pruning-point proofs, headers, and trusted data among the large payloads involved. [1]

The release describes message-framing bottlenecks and timeouts during synchronization. Protocol 11 addresses transfer handling by streaming large payloads in smaller pieces. This changes how data travels between peers; it does not reduce the data a node must validate. The release states a goal of avoiding bottlenecks and timeouts, not a measured improvement in total sync time. [1]

## What does Kaspa v2.1.0 change in node synchronization?

Protocol Version 11 sends large IBD payloads in 20 MiB chunks. The release identifies pruning-point proofs, headers, and trusted data as payload categories covered by chunking. [1]

The implementation describes separate changes for chunking pruning-point proofs, headers, and trusted-data transfers. Protocol 11 is also backward compatible with Protocol 10 peers, although the release does not prescribe a rollout sequence. [1][2]

## What transfer limits and safeguards should operators know?

The stated values apply to different parts of the transfer process and should not be treated as interchangeable:

- **Chunk size:** Large IBD payloads are streamed in 20 MiB chunks. [1]
- **Proof and trusted-data transfer limit:** The implementation describes rejecting proof or trusted-data transfers larger than 1 GiB and applying a total time limit to those transfers. It does not specify the duration of that time limit, and the limit is not stated to cover headers or every IBD payload. [2]
- **General P2P message-size setting:** The release lowers **P2P_MAX_MESSAGE_SIZE** from 1 GB to 256 MB. These are the release’s stated MB/GB labels; the chunk and transfer values are stated in MiB/GiB. [1]
- **Wire block-message cap:** Wire block messages are capped at 2 MB. [1]
- **Progress and timeouts:** The release mentions progress logging and total-transfer timeouts for the relevant transfers, but does not give a log format or progress interval. [1]

In short, 20 MiB is the chunk size; the 1 GiB cap and unspecified total time limit apply to the specified proof and trusted-data transfers. The message-size setting and wire block-message cap are separate controls. [1][2]

## How should node operators approach the upgrade?

The release encourages node, mining, and infrastructure operators on mainnet and testnets to upgrade, but gives no deadline or mandated rollout procedure. Protocol 11’s compatibility with Protocol 10 peers can inform a staged rollout. [1]

1. **Identify the systems in scope.** List nodes performing IBD, nodes serving data to peers, and relevant infrastructure. Record which will be upgraded first and which will remain on Protocol 10.
2. **Test a limited group if your operations call for it.** Confirm that upgraded nodes connect and exchange data with peers. The release confirms Protocol 10 compatibility but does not document a command or interface for checking an individual peer’s protocol version. [1]
3. **Observe progress over time.** Inspect the progress information available in your deployment. If successive observations show the transfer advancing, it is progressing, even if slowly. If the same transfer state persists, check for a reported timeout or error and record the node, peer, and last reported activity. The release does not specify a log name, field, interval, or numeric threshold for declaring a stall.
4. **Verify completion before expanding.** Use the sync or IBD status exposed by your node software or deployment, if available, to confirm that IBD is complete and the node reports itself caught up. The release does not identify a universal interface or completion indicator. If your deployment exposes neither progress nor completion status, consult its documentation rather than treating a peer connection or quiet log as proof of completion.
5. **Decide whether to continue.** Expand the rollout when the test nodes complete IBD and operate as expected. Pause expansion if transfers repeatedly stop advancing, time out, or fail to complete. The release provides no prescribed rollout schedule or stall threshold.

## Does chunked IBD mean Kaspa nodes will sync faster?

The practical implication is narrower: operators can expect a different way of handling large transfers, designed to address framing bottlenecks and timeouts. The v2.1.0 release notes do not publish a measured end-to-end sync-speed improvement. [1] A shorter total sync time remains unproven.

## Frequently asked questions

### How can I check which P2P protocol version a peer uses?

The v2.1.0 release information confirms compatibility with Protocol 10 peers but does not provide a peer-version check. [1] Use a protocol-version field only if your node software or deployment documentation says it exposes one. Otherwise, consult the documentation for your specific deployment; there is no universal command or log field established by the release.

### What should I check if an IBD transfer stalls?

Review the progress information available in your deployment and compare successive observations. Check for a timeout or error, then record the node, peer, and last reported transfer activity. A transfer that continues to advance is slow, not stalled; one that repeatedly shows no progress or times out warrants investigation. The release does not provide a formal troubleshooting procedure or a numeric stall threshold. [1]

### Does v2.1.0 include changes beyond node synchronization?

Yes. The release also lists Stratum bridge hardening, a standalone ZK SDK crate, and a workspace-wide arithmetic safety audit. These are separate from the Protocol 11 IBD changes. [1]

## References

- [1] Rusty Kaspa, *v2.1.0 release notes*, sections describing Protocol Version 11, IBD transfers, compatibility, message limits, and other release items.
- [2] Rusty Kaspa pull request on chunked pruning-point proofs, headers, and trusted-data transfers; implementation details covering transfer limits and timeouts.

## References

1. [github.com](https://github.com/kaspanet/rusty-kaspa/releases)
2. [github.com](https://github.com/kaspanet/rusty-kaspa/pull/1136)