Kaspa Toccata Hardfork — Post-Activation Node Operator Checklist

The Toccata hardfork is live. Activation happened at DAA score 474,165,565 on roughly June 30, 2026, at 16:15 UTC, bringing native L1 covenant programming and ZK-application infrastructure to the Kaspa mainnet as specified in KIP16, KIP17, KIP20, and KIP21 (source).

If you are running a node, mining, or operating any service that submits or validates transactions, this article is your post-activation checklist. The window for passive preparation has closed — what remains is verification, and understanding exactly what changed so you don't get caught off-guard.

The One-Way Database: No Rollback Without Resync

The first and most consequential detail to internalize: the node database upgrade is one-way. Once you upgrade your database to Kaspa v2.0.1 (or newer), you cannot downgrade it to an earlier version. If you need to return to a pre-Toccata version for any reason, you must resync from scratch.

For a solo hobbyist node this is a mild inconvenience — a few hours of waiting. For pool operators and exchanges running multiple nodes, it is an operational cost worth accounting for in advance. There is no rollback button. Plan accordingly.

The New Fee Floor: Policy, Not Consensus

Toccata changes the minimum standard fee enforced by the node's mempool policy. The new formula:

100 sompi × max(compute grams, 2 × transaction bytes)

The 2 × transaction bytes term reflects the post-Toccata normalized transient-mass component — effectively doubling the transient mass limit to accommodate ZK-STARK proofs.

This is important to understand precisely: this fee rule is a node policy / mempool rule, not a consensus rule. Zero-fee transactions are and remain consensus-valid. A node will not reject a block containing a zero-fee transaction. But a node *will* refuse to relay or accept into its mempool any transaction that falls below the new minimum.

Before vs. After Activation

Before activation, the higher minimum fee was enforced only for transactions submitted directly through RPC. Transactions received via P2P relay still followed the old policy.

After activation, P2P-relayed transactions are also rejected unless they meet the new fee rule. This means any wallet or service that was submitting transactions at the old minimum — or relying on a hardcoded assumption about fee floors — will silently fail if it hasn't been updated.

What Wallets and Services Should Do

The guidance from the source is direct: do not rely on outdated fixed minimum-fee assumptions. Derive the required minimum fee from the node API where possible, or update your fee constants to match the new rule. If your wallet or integration submits a transaction below the floor after activation, it will be rejected by the mempool of upgraded nodes — and since the vast majority of the network is now upgraded, that transaction effectively vanishes.

This is the kind of silent failure that can confuse end users. A transaction appears to send, the wallet reports success at the RPC layer, but the transaction never propagates. If you operate a wallet, a pool payout system, or any automated transaction pipeline, test your fee derivation now.

Hardware Specifications: What Changed and Why

Minimum hardware specs for a Kaspa node have increased:

Two reasons are cited for the change. First, more accurate benchmarking by @elldeeone revealed that previous estimates were optimistic. Second, the doubling of the transient mass limit to support ZK-STARK proofs increases the data load per block.

The minimum specs are sufficient to sync and maintain a node. But running closer to the preferred specs makes your node a stronger focal point on the network: faster initial block download for peers syncing from you, and more headroom for storage growth. Pool operators are explicitly advised to aim for the preferred tier.

The New GetBlockRewardInfo RPC

Toccata introduces a new RPC endpoint, GetBlockRewardInfo, built for pool accounting, miner reporting, and block-level reward tracking. It accepts a block hash and returns:

• header: the queried block header.
• blockColor: UNKNOWN, BLUE, or RED.
• confirmationCount: populated once the block has known merge context.
• mergingChainBlockHash: populated once the block has known merge context.
• rewardAmount: populated once the block reward is calculable.

The blockColor and merge-context fields are particularly useful for pools that need to account for orphaned or red blocks — a DAG-specific concern that flat-chain miners never deal with. If your pool software does not yet consume this endpoint, now is the time to integrate it.

Why This Matters for Self-Custody

Covenants are the headline feature of Toccata, and they are what make on-chain vault logic possible — withdrawal delays, alarm keys, dead-man-switch inheritance — without trusting a third party to hold your funds. Before Toccata, these patterns required off-chain coordination or custodial arrangements. Now they are native to L1.

For anyone who keeps their own keys, this is the upgrade that makes self-custody more than just "hold a seed phrase." On-chain covenants give you programmable guardrails — delays that let you react to theft, inheritance mechanisms that don't require a lawyer. None of this works if your node isn't upgraded and synced to the post-Toccata chain.

Quick Verification Checklist

If you have already upgraded, here is a rapid sanity check:

1. Confirm your node version: kaspad --version should report v2.0.1 or newer. 2. Confirm you are on the post-Toccata chain: your node should be past DAA score 474,165,565. 3. Test a transaction: submit a test transaction via RPC and verify it meets the new fee rule. If it is rejected with a fee-related error, your integration needs updating. 4. Check your DB: if you upgraded your database, remember — it is one-way. Confirm you are committed to this version. 5. Pool operators: integrate GetBlockRewardInfo for accurate reward accounting, especially for red/blue block tracking.

If you have not upgraded yet and you are reading this post-activation, your node is already split from the network. Upgrade to v2.0.1, resync, and rejoin. Every block you miss while un-synced is a block your service cannot see or validate.

---

*Source: Kaspa Toccata Hardfork Node Setup Guide on GitHub.*