# 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:

```json
{"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”.

<figure><img src="https://2956913934-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FGVoRxPt0850PeAekrKkW%2Fuploads%2FDaiXSQo3ebXXzsjt7Zz0%2Fimage.png?alt=media&#x26;token=f8544708-2271-4e66-a3e8-fed35ac083d4" alt=""><figcaption></figcaption></figure>

### 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.