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

General
1

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.

6 Likes
2

Absolutely brilliant!! missing piece to my puzzle! :folded_hands:

1 Like
3

Awesome I love this idea

1 Like
4

Big +1 on this. Some tokens already put their JSON straight in the genesis payload, but the covenant ID never covers that payload, so the metadata isn’t really tied to the covenant. KCC-23 fixes exactly that.

I left a review on the PR after checking the test vectors with a separate script (they all match): Add KCC-23: MJ (Metadata JSON) by Manyfestation · Pull Request #26 · kaspanet/kccs · GitHub

The short version is three open questions:

  1. JSON libraries disagree on a few edge cases (duplicate keys, huge numbers, very deep nesting). A strict list of what’s allowed would keep wallets and explorers in agreement.
  2. Should the metadata count for every output of the prep transaction, or only the first? Right now anyone paid by that transaction can create a covenant that verifies as the same token.
  3. The v1 transaction ID is defined in KIP-24, which would be good to list as a requirement.

I’d love to hear from launchpads on 2, since you’re the ones adding fee outputs.

2 Likes
6

The tx.payload would bind to each of the prep tx outpoints. This is a declarative schema only, there is no issue with one payload declarations to be connected to many different covenants.
What is kip24?

1 Like
7

KIP-24 is the spec of txv1 that is already implemented since Toccata. compute budget, covenant binding and lane are commited to the txid, there are new fields. and a few other adjustments to the commit.

1 Like