KCC-23: Convention for Binding Covenant Metadata to a Covenant ID

Manyfest · September 24, 2026, 11:33am

Add KCC-23: MJ (Metadata JSON) (#26)

main ← Manyfestation:kcc23-metadata-json

opened 07:37PM - 12 Sep 26 UTC

Defines KCC-23, a convention for binding JSON metadata to a KIP-20 covenant ID. …A version 1 preparation transaction carries a `0x00` codec byte followed by a UTF-8 JSON object in its payload and creates an output. The genesis transaction spends that output to initialize the covenant. The covenant ID commits to the spent outpoint, whose transaction ID commits to the payload bytes. Deployment uses one additional transaction, with no persistent metadata UTXO, dedicated contract, or additional covenant state. Both transactions can be shared off chain as a launch proof for optional verification. Readers can also follow the genesis authorizing outpoint to discover the declaration. Includes a KCC-20 token example and machine-readable conformance vectors. Field meanings are left to ecosystem conventions. Metadata adds no application spending logic or authority. Validation: recomputed the payload digest, preparation transaction ID, and covenant ID using the pinned rusty-kaspa hashing rules; checked declaration vectors and `git diff --check`.

The idea is to define a convention for attaching descriptive metadata to a covenant at deployment.

For example, a KCC-20 token may declare:

{
  "name": "Example Token",
  "symbol": "EXT",
  "decimals": 8
}

KCC-23 uses tx.payload to carry this JSON.

Since Kaspa is prunable, the block containing this transaction would eventually no longer be available from regular nodes, and the metadata alone would no longer be verifiable.

KCC-23 harnesses KIP-20’s covenant ID genesis logic to bind the metadata to the covenant ID: the genesis transaction spends an output from the metadata transaction, making that transaction part of the covenant ID commitment.

The deployment transactions can then be preserved and shared off-chain, while still allowing anyone to verify the metadata against the covenant ID.

This allows a covenant to declare data and values that are not part of its on-chain verification logic, while still committing to them as part of the covenant’s identity.