Kaspa KISR is an open wallet-level invitation design for transferring KAS to someone who does not yet control a Kaspa wallet. The sender creates a dedicated UTXO, pre-signs its input under constrained rules, anchors encrypted redemption data on-chain, and shares a short code plus transaction ID. A compatible wallet can then redeem the value.

Key takeaways

• The repository names KISR the Kaspa Invitation Standard for Redemption; it is a proposed open convention, not a Kaspa consensus rule.
• An inviter creates a dedicated self-transfer UTXO and pre-signs that input with SIGHASH_NONE | ANYONECANPAY.
• A separate anchor transaction carries an encrypted envelope describing the invitation; the shared artifact contains a KISR code and anchor transaction ID.
• The redeemer must validate the network, amount, envelope, and unspent outpoint before constructing the final output.
• Anyone who obtains both sharing secrets may be able to redeem the invitation, so the code and transaction ID should be treated as bearer credentials.

What exactly is KISR?

KASmedia’s September 23, 2025 report introduced Kurncy Wallet’s open-source redemption concept and linked its public implementation. The KISR GitHub repository defines the acronym as Kaspa Invitation Standard for Redemption and describes a cross-wallet flow intended for a recipient who has not yet set up a wallet.

The wording matters because KISR is not a new asset, sidechain, custody service, or consensus upgrade. It is an application protocol built from ordinary Kaspa transaction components: UTXOs, signatures, payloads, network queries, and a receiving address. Wallet developers must choose to implement compatible parsing, encryption, validation, and user interfaces.

KASmedia also used “Innovation Standard” in one introductory phrase, while the linked repository consistently uses “Invitation Standard.” This guide follows the primary repository’s name.

How does an inviter create a redeemable UTXO?

The normative protocol document starts with a self-transfer that creates one dedicated UTXO for the invitation amount. The sender then prepares a signature for the input that references that output using SIGHASH_NONE | ANYONECANPAY.

In simplified terms, NONE avoids committing the signature to a fixed set of transaction outputs, while ANYONECANPAY limits what inputs the signature commits to. That combination lets a redeemer construct the destination output later while using the authorized invitation input. It does not give the redeemer the inviter’s private key.

The inviter next creates a short KISR code, derives an encryption key, and assembles a tag-length-value payload containing the outpoint, pre-signature, sighash flag, amount, network, timestamp, and optional fields. The reference specification uses Argon2id for key derivation and XChaCha20-Poly1305 for authenticated encryption. A separate self-transaction anchors that encrypted envelope in its payload without spending the invitation UTXO.

How does redemption work?

The shared object contains both the KISR code and the anchor transaction ID. A compatible wallet fetches the anchor transaction, checks its envelope prefix and version, derives the key from the code, and decrypts the payload locally.

Before spending anything, the wallet should verify that the destination address belongs to the specified network, the referenced outpoint exists, the UTXO remains unspent, the amount matches, and the fee leaves a valid positive output. It then assembles a transaction using the pre-signed input and sends the invitation amount minus the fee to an address controlled by the redeemer.

Once that UTXO is spent, a second redemption attempt should fail under normal UTXO rules. The inviter can also cancel an unused invitation by spending or compounding the dedicated UTXO back to the inviter’s own wallet. Cancellation does not erase the anchor payload; it invalidates the referenced spendable output.

What security assumptions should users understand?

KISR improves onboarding only if wallets implement the specification correctly. The deeplink and QR guidance explicitly warns that anyone with both the code and transaction ID can redeem. They should therefore be shared through an appropriate channel, kept out of screenshots and public posts, and hidden from clipboard history where possible.

Authenticated encryption can detect altered ciphertext, but it cannot protect a code that the user publishes. The wallet must use secure randomness, avoid logging decrypted payloads or derived keys, and reject network or authentication mismatches. Users must still verify that they installed the intended wallet from an authentic source.

The repository’s existence is not an independent security audit. Implementers should review the exact commit they adopt, test against conformance vectors, threat-model malicious links and replay attempts, and obtain specialist review before handling material value.

How can KISR improve onboarding without adding custody?

A conventional transfer assumes the recipient already has an address. KISR reverses the order: the inviter reserves value first, and the recipient chooses the final address after installing a compatible wallet. That can support gifts, event onboarding, or merchant promotions without requiring the inviter to control the recipient’s wallet.

The design also keeps cancellation inside normal UTXO behavior. There is no separate account administrator who must approve a reversal. However, “permissionless” does not mean risk-free or universally supported. A recipient needs compatible software and network access, while the inviter remains responsible for sending the invitation secrets safely.

For a practical merchant contrast, the B the Barber KAS payment case begins with a customer who already knows how to pay. KISR targets the earlier onboarding problem: how to reserve KAS for a person before that person supplies an address.

Frequently asked questions

Is KISR part of Kaspa consensus?

No. It is an open application and wallet convention. Its transactions must still satisfy Kaspa consensus, but nodes do not need a KISR-specific consensus rule.

Can the inviter cancel an invitation?

Yes. The specification says the inviter can spend the dedicated UTXO. Once spent, the pre-signed invitation input no longer references an available output.

Is the KISR code safe to post publicly?

No. The reference guidance treats the code together with the transaction ID as sufficient redemption material. Anyone who obtains both may redeem before the intended recipient.

Source and verification note

The launch context comes from Jennifer Ghelardini’s September 23, 2025 KASmedia report. Technical descriptions are checked against Kurncy’s public KISR repository, including its normative protocol and deeplink security guidance. Repository specifications can change; implementers should pin and review a commit rather than assume this summary is current code. This article does not certify the implementation, recommend transferring a particular amount, or predict KAS price.