Kaspa WASM UTXO return addresses became available to browser and Node.js clients through Rusty Kaspa pull request 704. The addition exposed an existing node RPC that takes a transaction ID and accepting-block DAA score, then derives a return address from the script of the transaction’s first populated input UTXO.

Key takeaways

• Pull request 704 added the GetUtxoReturnAddress request and response to Kaspa’s WASM-facing RPC layer.
• The request contains a transaction ID and acceptingBlockDaaScore; the response contains one returnAddress.
• Node code reconstructs the transaction in historical UTXO context and reads the first input’s referenced script.
• The result is a candidate sender or return address, not proof of ownership and not a universal change-output detector.
• Coinbase, unfilled inputs, non-standard scripts, multi-party inputs, and unsupported nodes require explicit handling.

What changed in Rusty Kaspa pull request 704?

The official Rusty Kaspa pull request 704, merged July 21, 2025, added 42 lines across three files: WASM interfaces, wRPC client registration, and a Node.js example.

The request interface accepts txid as a hexadecimal string and acceptingBlockDaaScore as a JavaScript bigint. The response exposes returnAddress as a Kaspa address. The example demonstrates the shape of a call but is not a production refund workflow.

The small scope is important: PR 704 did not invent the core node method. It made an existing RPC operation reachable from browser and Node.js applications that use the Rusty Kaspa WASM SDK.

How does the node derive the return address?

The RPC service populates the transaction at the supplied accepting-block DAA score. From the first input’s referenced UTXO, it extracts and returns a standard address encoded by the script public key.

The method looks backward to the output consumed by input zero. It does not classify a new output as change, so “return address” is more accurate than “change address.”

If the transaction is coinbase-like with no spendable input, the first entry is missing, or the script cannot be converted to a standard address, the method returns an error. Applications must preserve those cases rather than replace them with a guessed address.

Why does the request need an accepting-block DAA score?

UTXO information is contextual. After an output is spent, the current UTXO set may lack the data needed to reconstruct it. The accepting-block DAA score provides historical context for populating those inputs.

The score is not an interchangeable timestamp or block height. A caller should obtain it from reliable accepted-transaction data and keep it associated with the transaction ID. Supplying a wrong context can produce a not-found error; silently retrying with arbitrary scores risks masking an indexing or data-quality problem.

Web applications should validate that the score can be represented as bigint, confirm network identity, and use a node release that advertises the operation. JavaScript number cannot safely represent every 64-bit integer.

Is the returned address always safe for refunds?

No. A valid address extracted from input zero proves only that the spent UTXO used that script. It does not prove that the person requesting a refund controls the address today, that all inputs belong to the same party, or that the first input funded most of the payment.

Exchanges, shared wallets, and multi-party protocols can combine inputs with different economic owners. A custodial withdrawal may spend from a service hot wallet, so returning funds there may not credit the customer.

For material amounts, ask the customer for a refund address through the authenticated order channel and verify it under the merchant’s policy. Where risk justifies it, request a signed message or a small verification transfer. Treat the RPC result as supporting evidence, never as sole authorization.

How should a web wallet integrate the RPC?

First, feature-detect or version-gate the method. A public node running an older build may return an unsupported-operation error. Second, validate the transaction ID format and keep the DAA score as bigint from ingestion through serialization. Third, distinguish transport failure, unsupported RPC, historical-data failure, coinbase, unfilled entry, and non-standard script in logs and user messages.

Cache successes with network, transaction ID, accepting score, node version, and time. Let temporary failures expire. If independent nodes disagree, stop automation and investigate.

Finally, test with fixtures for ordinary single-input payments, multiple inputs, multiple outputs, non-standard scripts, and malformed context. A happy-path Node.js example cannot establish refund safety.

How does this fit Kaspa’s UTXO model?

An account model suggests one sender and a balance delta. A UTXO transaction consumes earlier outputs and creates new ones; multiple inputs and recipients mean economic roles depend on context rather than one canonical sender.

This structure enables parallel payment construction and explicit coin selection, but application developers must resist account-model assumptions. The return-address RPC is a convenience for querying one well-defined input relationship. It does not collapse a UTXO transaction into a single universally correct “from” address.

The broader research discussion in Kaspa and proofs of useful work demonstrates the same engineering discipline: a useful primitive should be described by what its implementation proves, not by the most expansive interpretation of its name.

What does this mean for merchant checkouts?

Payment monitoring and refund authorization are separate. A checkout should assign a unique order address, total accepted outputs, compare the quote, apply confirmation policy, and survive retries or partial payments.

If a refund becomes necessary, the merchant can use the WASM RPC to propose an address for review, while retaining the original transaction evidence and order identity. Multi-input transactions should default to manual or authenticated confirmation. The philosophy behind that separation is covered in Kaspa and cypherpunk payments: self-sovereignty still needs explicit operational controls.

Frequently asked questions

Does getUtxoReturnAddress find the transaction’s change output?

No. The node derives an address from the referenced UTXO of the first input. It does not classify any newly created output as change.

Why can the method fail on a valid transaction?

A valid transaction can be coinbase, use a script that has no standard address representation, lack populated historical input data at the supplied context, or be queried through an unsupported node.

Can a browser call the RPC without trusting a backend?

The WASM binding makes direct wRPC access possible, but the application still relies on the selected node’s availability and response. High-risk actions should validate network identity and use independent evidence.

Source and verification note

The primary source is Rusty Kaspa pull request 704, merged July 21, 2025. The diff was checked at file level, and the underlying Rust RPC service was reviewed to confirm its first-input, historical-context, and error semantics. This article intentionally calls the result a candidate return address and does not present it as proof of refund ownership.