Skip to content
HeartBadge docs

Three-Chain Overview

OP_CAT Layer for identity and proof, BSV for rewards and communication. What lives where and why.

HeartBadge runs across two layers. Each layer does what it does best. This page explains the architecture, why we chose this split, and how the layers interact.

The two layers

OP_CAT Layer — Identity & Proof

Your badge is a CAT-721 token on the OP_CAT Layer. Attestations and verifiable proofs also run here via C-Protocol. This layer handles:

  • Badge minting and ownership
  • The covenant contract (HeartBadgeRulesContract) that enforces minting rules
  • Collection deployment for programs
  • Badge transfer and supersession
  • Proof Authority (PA) attestations
  • Co-sign attestations between members
  • Humanity score computation
  • ZK selective disclosure

OP_CAT Layer was chosen for its UTXO-based covenant model (enforcing complex rules about who can mint) and support for substrate-native provable attestations. C-Protocol defines canonical obligations and lets proofs work across contexts.

How the layers interact

The layers are connected through identity keys:

  1. Your badge is minted on OP_CAT Layer. It has an identity key derived from its UTXO position.
  2. That same identity key is your messagebox identity on BSV. Messages are authenticated by signatures from your badge key.
  3. That same identity key signs attestations on OP_CAT Layer. Co-signs and proof-of-presence all live in the same proof namespace.

The derivation path (m/721'/0'/{group}'/{tier}'/{seq}) is the canonical anchor. Given the path, you can derive the identity key. Given the identity key, you can verify signatures across all three chains.

What this means for members

You don't need to think about two layers. You have one badge, one identifier, one wallet. The architecture exists so that each operation happens on the layer that handles it best — fast, cheap, secure. The complexity is infrastructure; the experience is unified.

Deep dives