Kaspa Toccata now has an official operator guide, and the useful part is not the headline. It is the checklist.
The guide was expanded on June 21, 2026, nine days before the expected mainnet activation window. The hard fork is scheduled for DAA score 474,165,565, roughly June 30, 2026 at 16:15 UTC. Node operators are told to upgrade before activation because failing to upgrade can split a node away from the network. Exchanges can record wrong balances. Miners can produce invalid blocks. (Toccata guide) (PR #1059)
The current recommended path is rusty-kaspa v2.0.1 or newer. The latest release is v2.0.1, published as the Mainnet Toccata maintenance release. It can be used as a drop-in update for v2.0.0 nodes and as the Toccata upgrade version for pre-Toccata 1.x nodes. (rusty-kaspa v2.0.1)
Toccata is built around four KIPs. KIP-16 adds OpZkPrecompile, the zero-knowledge proof verification opcode that gives Kaspa a native base-layer hook for verifiable computation. (KIP-16) KIP-17 expands covenant and scripting capability through transaction introspection, byte-string operations, signature-from-stack checks, hash opcodes, and higher post-activation script limits. (KIP-17) KIP-20 introduces covenant_id, a consensus-tracked identifier for covenant lineage and state membership. (KIP-20) KIP-21 changes the sequencing commitment model so lane proofs can scale with relevant lane activity instead of global chain activity. (KIP-21)
That is the protocol side. The operator side is more immediate.
Node Operators
Run kaspad --utxoindex from the v2.0.1 or newer release, or build from the stable branch. Existing flags can stay if they are still appropriate. Testnet use is the same command with --testnet. (Toccata guide)
The database upgrade is one-way. Once a node database is upgraded to the Toccata release line, it cannot be downgraded back to an older version. Operators can resync if they need to return to an earlier version, but exchanges, pools, and larger public nodes should treat that as a real operational cost, not a casual rollback button. (Toccata guide)
Recommended hardware has moved up. The guide lists 8 CPU cores, 16 GB RAM, 640 GB SSD, and 10 MB/s network bandwidth as the minimum. The preferred profile is 12 to 16 CPU cores, 32 GB RAM, 1 TB SSD, and stronger bandwidth. Pool operators are strongly pushed toward the preferred side. (Toccata guide)
The storage path matters more than the label "SSD". The linked node-resource study found that weak storage failed even with more CPU and RAM, while an 8 vCPU / 16 GiB local-SSD cloud host passed direct IBD, sustained stress, repeated pruning windows, and controlled downstream serving. The study recommends treating write latency and queue depth as early warning signs. (node research)
If you operate infrastructure, use conservative RPC exposure. The guide recommends --disable-upnp for pools and exchanges, --rpclisten=127.0.0.1 when local software talks to the node on the same machine, and --unsaferpc only when RPC is not publicly exposed. Performance logs are available through --perf-metrics --loglevel=info,kaspad_lib::daemon=debug,kaspa_mining::monitor=debug. (Toccata guide)
Fees
The biggest wallet-facing change is the minimum standard fee rule.
On Toccata activation, the minimum fee rate moves from 1 sompi/gram to 100 sompi/gram. The node policy formula is:
100 sompi max(compute grams, 2 transaction bytes)
The guide is careful about scope. This is node policy and mempool policy, not a consensus rule. Consensus does not have a fee policy, and zero-fee transactions remain consensus-valid. But direct transaction submissions to upgraded nodes can fail if software still assumes the old fixed floor. Before activation, the higher rule is enforced for direct RPC submissions to upgraded nodes; after activation, P2P relay follows the higher rule too. (Toccata guide)
Wallets that already use the RPC fee estimation API should not need a fee calculation change. Wallets or services with hardcoded fee assumptions need to update. Go kaspawallet users should move to kaspad v0.12.23, which includes Toccata preparation and the wallet minimum-fee update. (Toccata guide) (kaspad v0.12.23)
Transaction And RPC Changes
Toccata introduces transaction version 1 and new transaction fields that software must preserve, parse, and store correctly.
The old transaction API field mass is now storage_mass in Rust and protobuf, and storageMass in JSON and JavaScript. JSON currently emits both mass and storageMass for compatibility, and deserializers may accept either. New integrations should read and write storageMass. JavaScript/WASM mass is deprecated and aliases storageMass. (Toccata guide) (rpc.proto)
The protobuf surface now includes RpcTransaction.storage_mass, RpcTransactionInput.computeBudget, RpcTransactionOutput.covenant, and RpcUtxoEntry.covenant_id. Integrators that generate their own bindings should regenerate them from the updated messages.proto and rpc.proto. (messages.proto) (rpc.proto)
Two RPCs deserve special attention. GetBlockRewardInfo gives pools and miners reward-accounting data by block hash, including block color, confirmation count, merging-chain block hash, and reward amount when the block is blue. GetSeqCommitLaneProof returns the witness needed to prove a single KIP-21 lane against the seq_commit carried in a block header. (Toccata guide) (rpc.proto)
Exchanges
Exchanges should upgrade every node before activation, not just one fallback machine.
They should use rusty-kaspa v2.0.1 or newer, or Go kaspad v0.12.23 where that SDK path is still used. If bindings are generated internally, regenerate them after reviewing the protobuf changes. Then test the full deposit and withdrawal path against Testnet-10: indexing, balance tracking, fee estimation, transaction parsing, and internal services that depend on block or transaction formats. (Toccata guide)
The recommendation is simple: do not discover transaction version 1, storageMass, computeBudget, covenant outputs, or covenant_id handling on mainnet activation day.
Miners And Pools
Miners using a pool should verify that the pool upgraded. Miners using their own node should upgrade the node and use the provided Stratum Bridge, or another Toccata-compatible mining stack. (Toccata guide)
Pools have the highest risk if they partially update. Post-Toccata block templates contain fields that must survive the full mining path. Job generation and block reconstruction must not drop or overwrite RpcBlockHeader.version, transaction version 1, RpcTransaction.storage_mass, RpcTransactionInput.computeBudget, or RpcTransactionOutput.covenant. If custom Stratum messages serialize block-template transactions, those messages need to round-trip the new fields. After activation, blocks that strip those fields can be invalid. (Toccata guide)
The Stratum Bridge is still marked beta, but it is the official bridge path in rusty-kaspa. It can run against an external node or an in-process node, ships with sample configuration, Prometheus metrics, a web dashboard when configured, and automatic handling for several ASIC miner types. Pool operators should test GetBlockTemplate to work distribution to solved-block reconstruction to SubmitBlock on Testnet-10 before mainnet activation. (Stratum Bridge docs)
Explorers, Indexers, Wallet Backends And APIs
Explorers and indexers should treat Toccata as a schema event. Full transaction, output, and UTXO storage needs room for covenant bindings and covenant IDs. APIs should continue accepting deprecated JSON mass where needed for backward compatibility, but emit and document storageMass for new integrations. (Toccata guide)
If an integration needs reward accounting, block-color handling, or lane-proof data, it should review GetBlockRewardInfo and GetSeqCommitLaneProof before activation. Those are not cosmetic RPCs. They are part of making post-Toccata infrastructure observable and verifiable. (Toccata guide) (rpc.proto)
Practical Recommendation
Upgrade first. Test second. Publish compatibility status third.
For normal users who do not run a node, wallet backend, exchange, pool, explorer, miner, or other Kaspa infrastructure, the guide says no action is required. For operators, the safe checklist is:
- run rusty-kaspa v2.0.1 or newer before DAA 474,165,565;
- avoid downgrading assumptions after the database upgrade;
- test full infrastructure on Testnet-10;
- stop relying on fixed fee assumptions;
- update or regenerate protobuf and SDK bindings;
- preserve transaction version 1 and new Toccata fields through every custom pipeline;
- prefer storage with proven write latency, not just a cheap disk labelled SSD;
- keep public RPC exposure tight.
