Kaspa PSKT payload support arrived in rusty-kaspa pull request #703, merged September 4, 2025. The change added an optional transaction payload to the global Partially Signed Kaspa Transaction record, introduced PSKT version 1, preserved empty payloads for version 0, and rejected incompatible payloads when separately prepared transaction records are combined.
Key takeaways
- PSKT means Partially Signed Kaspa Transaction, a structured format for moving a transaction through preparation and signing stages.
- Pull request #703 added an optional byte payload to the PSKT global data model.
- Payloads require PSKT version 1; version 0 remains compatible by producing an empty transaction payload.
- Combining PSKTs keeps one identical payload but rejects conflicting payloads and payload use under an older version.
- The merged patch changed 3 files with 54 additions and 2 deletions; it did not by itself create a consumer-facing payment feature.
What did Kaspa PSKT payload support change?
The primary source is the merged rusty-kaspa pull request #703, which closed issue #700. Its diff added payload: Option<Vec<u8>> to the PSKT Global structure. In plain English, one optional sequence of bytes can now travel with the global transaction data rather than being absent from the partially signed representation.
The patch also changed the final transaction construction path. For PSKT version 1 or later, it copies the stored payload into the signable transaction, using an empty byte vector when the optional field is unset. For version 0, it always constructs the transaction with an empty payload.
That behavior matters because a partially signed workflow must preserve every transaction field that signers believe they are authorizing. Silently dropping a payload between construction and signing could produce a different transaction from the one an application intended.
Why are partially signed transactions useful?
A partially signed format separates transaction assembly from final authorization. One component can select inputs and outputs, another can add required metadata, and one or more signing environments can authorize the resulting transaction without sharing private keys with the constructor.
This separation is useful for hardware signers, multisignature policies, offline signing, and services that divide duties between a coordinator and a secure key store. It also creates a review boundary: a signer can inspect the canonical transaction fields before producing a signature.
PSKT is a data format and workflow primitive, not a security guarantee on its own. Applications still need to authenticate participants, display the complete signing intent, protect serialized records from substitution, and validate the final transaction before broadcast.
Why did the patch introduce version 1?
Before PR #703, the Version enum only contained version 0. The patch added version 1 and made the enum orderable so code can test whether a record supports a feature. The constructor’s new payload() method returns a PayloadRequiresVersion1 error when an application tries to set payload bytes on version 0.
Versioning prevents an old-format record from appearing to support a field that its rules do not define. That is safer than accepting the field and silently discarding it. It also keeps the version 0 path explicit: older payload-free PSKTs can continue to produce a transaction with an empty payload.
Developers should therefore select the version deliberately. A tool that needs payload bytes must create version 1 before setting them, while software that only understands version 0 should not claim that it preserved a payload.
How do two PSKT payloads combine?
The Global addition implementation now follows four published rules:
- Two missing payloads remain missing.
- If only one side has a payload, that payload is retained.
- If both sides carry identical bytes, one copy is retained.
- If both sides carry different bytes, combination fails with
PayloadMismatch.
There is a second guard: if either side has a payload while the combined record’s version is below 1, the code returns PayloadRequiresHigherVersion.
These rules protect signing intent. A combiner must not choose arbitrarily between conflicting payloads because doing so could make one participant sign data supplied by another without an explicit resolution. An error forces the caller to investigate the mismatch and reconstruct a consistent PSKT.
What should wallet developers test?
Test both happy paths and rejection paths. At minimum, fixtures should cover version 0 without a payload, version 1 with no payload, version 1 with payload bytes, two equal payloads, one-sided payload data, two different payloads, and a payload attached to version 0.
Round-trip tests should serialize, deserialize, combine, and finalize the PSKT, then assert that the resulting native transaction contains the expected bytes. The signing interface should display or meaningfully describe payload intent where an end user is expected to approve it. Showing only recipient and amount may be incomplete for an application that assigns semantics to payload data.
Treat payload bytes as application data, not automatically as human-readable text or a private memo. The PR defines storage and combination behavior; it does not promise encryption, confidentiality, a universal schema, or safe arbitrary content.
How does this relate to merchant payments?
The change expands wallet infrastructure rather than directly changing a checkout. Multi-component payment systems can benefit when the partially signed representation preserves the same fields that will appear in the final transaction. That can make coordination more deterministic and easier to audit.
However, ordinary merchants still need address-and-amount verification after broadcast. Payload support does not replace checking the payment output, transaction status, or order attribution. The Kaspa Shop Seoul payment lesson covers the customer-facing flow, while the B the Barber merchant case shows why operational simplicity matters outside a developer environment.
Frequently asked questions
Does PSKT version 1 change Kaspa consensus?
The cited PR changes the wallet PSKT representation and transaction-construction path. It does not describe a consensus hardfork.
Can version 0 carry a payload?
No. The new constructor rejects that combination, and finalizing version 0 uses an empty transaction payload.
What happens when two participants supply different payloads?
Combination fails with a specific payload-mismatch error. The software does not silently choose one value.
Source and verification note
This article is based on kaspanet’s merged rusty-kaspa PR #703, merged September 4, 2025, and its public three-file diff. The reported 54 additions, 2 deletions, version rules, field type, construction behavior, and combination outcomes are taken directly from that patch. Broader workflow and testing recommendations are editorial analysis; applications should verify behavior against the exact rusty-kaspa revision they ship.
