Kaspa Crescendo v1.0.0 was the mainnet software release prepared for the network’s planned move from 1 to 10 blocks per second. Published before activation, the release set a DAA-score trigger, introduced P2P protocol version 7, and gave node operators a new retention setting to manage the additional data load.

Key takeaways

• The official rusty-kaspa v1.0.0 release was published on March 31, 2025 UTC.
• Crescendo was scheduled to activate at DAA score 110,165,000, projected for May 5 at about 15:00 UTC.
• The release prepared a transition from 1 BPS to 10 BPS; it did not mean the hardfork was already active on April 25.
• Beginning 24 hours before activation, upgraded nodes would connect only to peers using P2P protocol version 7.
• Node operators could use retention-period-days to keep more history than the shorter default pruning period.
• The release documented an operational plan, not a guarantee about activation timing, payment finality, adoption, or KAS price.

What did Kaspa Crescendo v1.0.0 prepare?

The official rusty-kaspa v1.0.0 release packaged the node software required for the Crescendo hardfork. Its headline change was a planned increase from one block per second to ten. The release described the expected result as greater transaction capacity and shorter block intervals, with improved network responsiveness as the practical objective.

That wording needs a date-sensitive reading. On April 25, v1.0.0 was available, but the activation point was still ahead. Installing the release prepared a node to follow the new consensus rules when the network reached the configured trigger. It did not make an individual node switch mainnet to 10 BPS early, and it did not prove that the activation had already succeeded.

The broader consensus design is documented in KIP-14, the Crescendo Hardfork specification. KIP-14 explains that the block-rate increase required coordinated changes to parameters, storage accounting, scripting, and the transition itself. The v1.0.0 release distilled the most urgent operator actions from that larger specification.

When was Crescendo scheduled to activate?

The release set the activation threshold at DAA score 110,165,000. It projected that the network would reach that score on May 5, 2025 at approximately 15:00 UTC. The DAA score was the consensus trigger; the calendar time was an estimate derived from network progress.

This distinction matters for accurate reporting. A wall-clock projection can move as blocks arrive, while the configured score remains the rule nodes evaluate. Before the threshold, operators should describe Crescendo as scheduled or pending. Only observations made after the network crosses the trigger can establish what actually happened during activation.

For merchants and wallet teams, the same discipline applies to customer communication. A faster target block interval may support a more responsive payment flow, but it should not be advertised as instant economic finality. Checkout software must still verify the recipient address, amount, transaction acceptance, and the confirmation policy appropriate to the order. Our guide to Kaspa payments for online commerce covers those application-level responsibilities.

Why did P2P protocol version 7 matter?

Rusty-kaspa v1.0.0 introduced a clear network-compatibility deadline. Starting 24 hours before activation, nodes would connect only to peers using P2P protocol version 7. An operator who remained on an older release risked losing connectivity to the upgraded peer network before the consensus change itself.

The practical lesson was simple: upgrade early enough to test startup, synchronization, RPC consumers, firewall rules, storage capacity, and monitoring. Waiting until the projected activation minute would leave little time to diagnose a failed binary replacement or an incompatible service integration.

Version alignment also mattered for pools, exchanges, explorers, wallets, and payment processors. Even when those services did not expose a public node, their infrastructure depended on nodes that could remain connected and interpret the same active rules. A coordinated hardfork is therefore an operational dependency across the ecosystem, not only a task for solo node operators.

How did retention-period-days change node planning?

At a higher block rate, a fixed number of retained blocks represents less wall-clock history. The v1.0.0 notes said the default pruning period would shorten from roughly 50 hours to about 30 hours. To give operators explicit control, the release added the retention-period-days configuration option.

The value is measured in days, accepts fractional values, and must be at least 2. For example, the release showed this command for retaining 2.5 days, or 60 hours, while running the UTXO index:

./kaspad --utxoindex --retention-period-days=2.5

Keeping additional history consumes additional storage, so the setting should be chosen with disk capacity and the node’s actual role in mind. An operator should not copy a retention value without measuring free space and understanding which local services depend on historical data. The setting manages local retention; it does not change the consensus activation threshold.

What should node operators verify before activation?

A concise pre-activation checklist starts with downloading v1.0.0 from an official project channel and verifying the release asset by the project’s published method. Back up configuration files, record the current binary version, and ensure there is a tested rollback procedure for operational problems that occur before the consensus boundary.

After installing, confirm that the node starts cleanly, reports the expected version, synchronizes, and exposes the RPC interfaces required by dependent services. Review logs and peer counts, then check CPU, memory, bandwidth, and disk headroom under realistic load. Operators who need more than the default pruning history should set retention-period-days deliberately and monitor storage growth.

Finally, verify that alerting can detect loss of peers, stalled synchronization, RPC errors, and low disk space. The project’s Crescendo node upgrade guide should remain the operational reference because release instructions can be more precise than secondary summaries.

What could the release not prove in advance?

A release candidate becoming a mainnet release is strong evidence that maintainers consider the software ready for deployment. It is not evidence of the future activation outcome. Before May 5, no responsible article could claim that mainnet had already sustained 10 BPS, that every service had upgraded, or that real-world payment behavior had improved by a measured amount.

The release also did not support price forecasts. Protocol capacity, exchange markets, merchant adoption, and token price are related only through many uncertain variables. Kaspa merchandise can help supporters start a conversation, but technical claims should still lead back to primary documentation. A product such as the Bitcoin the Turtle #470 T-shirt is community apparel, not evidence about network performance or investment returns.

Frequently asked questions

Was Kaspa already running at 10 BPS on April 25, 2025?

Not according to the v1.0.0 release schedule. The software was available, while mainnet activation was planned for DAA score 110,165,000, projected for May 5 at approximately 15:00 UTC.

Was the May 5 time the actual consensus trigger?

No. The release identified the DAA score as the activation condition. May 5 at about 15:00 UTC was a projection of when the network would reach it.

Did every node need retention-period-days?

No. The setting was optional. It was intended for operators who wanted to retain more historical data than the default pruning period and had sufficient storage.

Did 10 BPS mean payments would be final in 0.1 seconds?

No. Ten BPS describes a target block-production cadence. Applications still need an acceptance and confirmation policy based on transaction value and risk.

Source and verification note

The primary source is the Kaspa project’s Mainnet Crescendo Release – v1.0.0, published March 31, 2025 UTC. Technical scope is cross-checked against KIP-14 and the official Crescendo guide. This article is written from an April 25 pre-activation perspective and does not claim a later outcome or provide investment advice.