On June 18, the Kaspa Python SDK hit version 2.0.1 and was officially promoted from beta to production/stable on PyPI. For a release that touches covenant serialization, storage-mass calculation, wallet sync events, and a brand-new RPC method, it is worth pausing to look at what changed — and why the details matter for anyone building tooling on Kaspa after Toccata.
The release was tagged by contributor *smartgoo* and pins the underlying Rust dependency to rusty-kaspa commit cfafeb4c0 (v2.0.1). That pin ensures the Python layer and the native node code agree on serialization formats, mass calculations, and RPC signatures — a prerequisite for running anything in production.
Covenant-Binding Fixes: The Headline for Toccata Builders
The most consequential changes in this release are the fixes to CovenantBinding serialization.
Covenants — the Toccata feature that lets on-chain scripts enforce conditions on future spends — depend on a well-defined dictionary format when data crosses the boundary between Python and the Rust node. Prior to 2.0.1, calling CovenantBinding.to_dict() produced a nested structure: the authorizingInput and covenantId keys were wrapped inside an inner "inner" key. The from_dict() path expected the same nesting. This did not match the flat shape described in the 2.0.0 documentation or in the WASM SDK, which meant that code ported between the three SDKs could silently produce malformed transactions or throw key errors.
In 2.0.1, both to_dict() and from_dict() now use the flat shape: {"authorizingInput": ..., "covenantId": ...}. The fix brings the Python SDK into alignment with the docs and the WASM layer. If you are building any tool that constructs or parses covenanted transactions — wallets, escrow contracts, vault logic, indexers — and you were working around the nested format, your workaround is now a bug. Upgrade, and test against the new shape.
A related fix addresses PaymentOutput and TransactionOutput construction from dictionaries. Previously, omitting the "covenant" key from a plain {"address": ..., "amount": ...} dict raised a KeyError. This made it impossible to build a standard, non-covenanted output from a simple dict without always including the covenant field. In 2.0.1 the covenant key is optional, matching the documentation and the WASM SDK. This is a quality-of-life fix, but it removes a real friction point for anyone writing transaction-building code that handles both covenanted and plain outputs.
GenesisCovenantGroup Gets a Proper Constructor
GenesisCovenantGroup — the grouping structure for genesis-level covenants — is now constructible directly:
group = GenesisCovenantGroup(authorizing_input, outputs)It exposes authorizing_input and outputs as properties and has a __repr__ for debugging. More importantly, Transaction.populate_genesis_covenants now accepts either a GenesisCovenantGroup instance or a plain dict with "authorizingInput" and "outputs" keys. This dual-accept pattern makes it easier to build transactions from both structured objects and raw JSON (e.g., when reading from an API or a database).
Storage-Mass Calculation Clamped
The calculate_storage_mass helper now clamps the mean of input amounts to a minimum of 1, matching the behavior introduced in rusty-kaspa v2.0.1's calc_storage_mass. Without this clamp, edge cases with very small or zero-valued inputs could produce undefined or misleading mass values. For miners and fee-calculation code, this is a correctness fix that prevents subtle miscalculations in dust-threshold and mass-limit checks.
New RPC: get_seq_commit_lane_proof
A new method has been added: RpcClient.get_seq_commit_lane_proof(request). This RPC was introduced in rusty-kaspa 2.0.0 and is now surfaced through the Python bindings. It returns a proof for sequence commitments in a specific lane — data that is relevant to verifying state against Kaspa's GHOSTDAG-selected parent chain.
For indexers, block explorers, and any tool that needs to independently verify consensus state (rather than trusting the node's reported tips), this is a meaningful addition. It opens the door to lightweight proof-checking workflows without running a full archival node.
Wallet Sync Events Include SMT Progress
Wallet sync-state events now carry an additional payload during the pruning-point SMT (Sparse Merkle Tree) import phase of initial block download (IBD). The payload reports {processed, total}, giving callers a progress indicator for what has historically been a black-box step.
covenant_idA data structure used by Kaspa nodes to maintain a compact, verifiable snapshot of the UTXO set at the pruning point. During initial block download, a node imports this snapshot before it can validate recent blocks. :::def For wallet applications, this matters. IBD can take a long time, and without progress data the only option was a spinner. Now a wallet can display "Importing SMT: 4,200 / 12,000 nodes" and give the user a realistic sense of progress. It is a small UX improvement with outsized impact on first-run experience. The covenant_id(outpoint, auth_outputs) function was already importable and callable at runtime, but it was missing from the .pyi type stubs. This meant IDEs and type checkers (mypy, Pyright, Pylance) had no information about its signature — no autocomplete, no inline docs, no static type checking. In 2.0.1 the function appears in the stubs. If your team runs a typed Python workflow, this fix alone is worth the upgrade. What This Release Means for the Ecosystem The jump from beta to production is not just a label change. It reflects a set of serialization and correctness fixes that bring the Python SDK into alignment with the Rust node and the WASM SDK. For the Kaspa ecosystem, the practical consequence is this: three SDK layers now agree on the wire format for covenanted transactions. That agreement is what makes it safe to build production tooling — wallets, escrow services, vault contracts, indexers, exchange integrations — without maintaining per-SDK workarounds. :::callout The covenant fixes in this release are directly relevant to on-chain vault and escrow logic. Tools like Kaspa Safe — which enforces a withdrawal delay via a covenant-based vault contract — and Kaspa Escrow — where funds sit in an on-chain contract, not with a middleman — rely on covenanted transactions serializing and deserializing correctly across SDK boundaries. A Python SDK that matches the WASM and Rust formats means fewer silent bugs in the tools that hold your KAS. :::callout For KAS holders who self-custody, the indirect benefit is ecosystem maturity. Every SDK that moves to production status lowers the barrier for someone to build better wallets, better monitoring tools, and better node-indexing infrastructure. The get_seq_commit_lane_proof RPC makes independent verification more accessible. The SMT sync events make wallets less opaque during sync. The covenant fixes make vault and escrow contracts safer to implement. None of this is glamorous. It is the unglamorous work of getting serialization right, clamping edge cases, filling in type stubs, and bumping a Rust pin. But that is what "production stable" actually means: the boring parts work. If you maintain a Python project on Kaspa — a bot, a wallet backend, an indexer, a fee estimator — the upgrade path is straightforward. Check your CovenantBinding round-trips, confirm your output-dict construction no longer requires the covenant key, and verify your storage-mass calculations against the new clamp behavior. The full changelog is on the release page.
FAQ
What is the Kaspa Python SDK?
A set of Python bindings for interacting with Kaspa nodes via RPC, covering wallet operations, transaction building, and consensus queries. It wraps the Rust-based rusty-kaspa internals for use in Python applications.
What does "production/stable" mean on PyPI?
It is the top-tier Development Status classifier on the Python Package Index. The SDK was previously marked as beta; promotion signals that the API surface is considered stable enough for production workloads.
What are the covenant-binding fixes?
CovenantBinding dictionaries now use a flat {"authorizingInput": ..., "covenantId": ...} shape on both serialization and deserialization, matching the 2.0.0 documentation. Previously the keys were nested inside an inner object, which caused mismatches.
Who should upgrade?
Any Python project building wallets, bots, indexers, exchange integrations, or covenant-based tools on Kaspa — especially those targeting the Toccata mainnet upgrade.
What is the seq-commit lane proof RPC?
A new get_seq_commit_lane_proof method added in rusty-kaspa 2.0.0. It allows callers to request a proof for sequence commitments in a specific lane, which is relevant to GHOSTDAG-consensus verification workflows.
Put your KAS where theft can be cancelled
A covenant vault on Kaspa mainnet: your keys, your rules, our tooling. Free on-chain, forever.
Create a vault