Skip to content
HeartBadge docs

CAT-721 Covenant

The HeartBadgeRulesContract, ClosedMinter, UTXO lifecycle, and how badges are enforced on-chain.

Your badge is a CAT-721 token — a non-fungible token on the OP_CAT Layer governed by a covenant contract. This page describes the covenant model, the HeartBadgeRulesContract, and the UTXO lifecycle of a badge.

What is a covenant?

A covenant is a contract that constrains how a UTXO (unspent transaction output) can be spent. Instead of "anyone with the private key can spend this," a covenant says "this UTXO can only be spent if certain conditions are met — and the next UTXO it creates must also meet conditions."

Covenants are self-enforcing. There's no trusted server that checks the rules. The blockchain itself rejects any transaction that violates the covenant.

HeartBadgeRulesContract

The HeartBadgeRulesContract is the covenant that governs all HeartBadge badges. It enforces:

  • Minting authority. Only authorized minters (the ClosedMinter for a given collection) can create new badges.
  • Collection membership. Every badge belongs to exactly one collection (program). Cross-collection transfers are prohibited.
  • Ownership binding. A badge is bound to an identity key. Only the holder of that key can authorize transfers or state updates.
  • Supersession rules. When a badge's state changes (new proofs, new owner), the old UTXO is superseded by a new one. The covenant ensures continuity — the new UTXO inherits the badge's identity and history.

ClosedMinter

Each collection (program) deploys a ClosedMinter. This is a constrained minting contract that can only mint badges into that specific collection. The ClosedMinter is configured at collection deployment with:

  • The collection ID
  • The authorized minting keys (typically HeartChain Labs + the program operator)
  • Minting limits (e.g., max badges per day, total supply cap)
  • Group and tier structure

Once deployed, the ClosedMinter's rules are fixed. Neither HeartChain Labs nor the operator can mint outside these constraints.

UTXO lifecycle

1. Minting

A badge is minted when the ClosedMinter creates a new UTXO that satisfies the HeartBadgeRulesContract. The UTXO contains:

  • The badge identifier (derived from collection, group, tier, sequence)
  • The initial owner's identity key
  • Metadata (program branding, tier information)

2. Ownership

The badge UTXO exists on-chain, unspent. The owner holds the private key corresponding to the identity key embedded in the UTXO. To prove ownership, the owner signs a challenge with that key.

3. State updates

When the badge's state changes — the owner adds a proof, the balance is updated, or ownership transfers — a new transaction is created that:

  1. Spends the current badge UTXO
  2. Creates a new UTXO with the updated state, still under the HeartBadgeRulesContract
  3. The covenant verifies that the transition is valid (e.g., only the current owner authorized the change)

4. Supersession

The old UTXO is now "superseded" — it's spent, and the new UTXO represents the current state. The badge identifier remains the same. The chain of UTXOs forms a verifiable history.

Why this matters

The covenant model means:

  • No trusted intermediary. HeartChain Labs can't mint badges outside the rules, can't transfer badges without owner consent, can't modify badge state arbitrarily.
  • Verifiable by anyone. Any node can verify the entire history of a badge by walking the UTXO chain and checking covenant compliance at each step.
  • Durable ownership. Your badge is yours because the chain says so, not because a database has a row with your name.

Related