Data Format

The OP data is constructed in JSON format and MUST comply with the following rules:

• All keys and values MUST be strings and MUST contain ASCII printable characters only.

• All numeric values MUST be expressed in decimal and denominated in the smallest unit.

• If duplicate keys occur, the last key-value pair prevails.

• Unknown fields outside the protocol scope will be filtered out.

• For certain OPs, byte-level consistency MUST be enforced and duplicate keys and unknown fields are not permitted (e.g., send).

For example, a typical transfer OP data:

{"p":"krc-20","op":"transfer","tick":"KKKKK","amt":"100000000","to":"kaspa:..."}

Use P2SH Redeem Script

OP data can be embedded into a Layer-1 transaction via a Commit–Reveal scheme using a P2SH redeem script. This approach involves two transactions:

• Commit transaction: Creates an output (UTXO) locked to a P2SH address, committing to a redeem script that will be revealed later. The redeem script contains the defined OP data and serves as the “envelope” carrier.

• Reveal transaction: Spends the UTXO produced by the Commit transaction, thereby revealing the redeem script contents on Layer-1. KRC-20 nodes parse OP data based on the Reveal transaction, extracting it from the “envelope”.

Use Transaction Payload

With Kaspa now supporting transaction payloads, KRC-20 also supports embedding OP data directly via the payload field. This method requires only a single transaction and writes the OP JSON body directly (without constructing an “envelope”), making it simpler and more efficient. However, for specific OPs that bind KRC-20 tokens to UTXOs (e.g., send), the P2SH Commit–Reveal scheme is still used.