Glossary
Every term the docs assume you know. Referenced from every other page.
Every page in these docs links back here when it uses a term that isn't obvious. Entries are in alphabetical order. If a term's missing, email docs@heartbadge.com.
Badge
The durable, unique object minted to a member when they join a program. A badge carries identity, rewards, status, and proofs. It's a CAT-721 token under the covenant model.
Badge Identifier
The 20-digit, Luhn-checksummed number that uniquely identifies a badge. Safe to share; verifiable offline. See Badge Identifier.
BEEF
Background Evaluation Extended Format — the structure that allows a transaction to carry its own proof of inclusion, so verifiers don't need to query a node. Used with SPV for offline verification.
BRC-31
The BSV standard for authenticated messaging between identity keys. Your badge's identity key is your messagebox identity. BRC-31 ensures every message is cryptographically signed by the sender and verifiable by the recipient without trusting a third party.
CAT-721
The token standard HeartBadge uses for badges. Extends the OP_CAT token family. Enforced by the HeartBadgeRulesContract.
Collection
A program's set of badges. Each program deploys its own collection via POST /cat721/collection/deploy. Badges are minted under a
collection.
Co-Sign Attestation
A mutual proof-of-presence where two members bump badges and both sign a shared attestation. Proves "I was here, and so was this person, at this time." Can stay private or be published to a public messagebox.
Covenant
The on-chain contract that enforces rules about who can mint, transfer, and supersede a badge. HeartBadge's covenant is the HeartBadgeRulesContract.
C-Protocol
The proof authority model HeartBadge uses for attestations. Defines canonical obligations (what must be proven), substrate agnosticism (proofs work across chains), and the PA role. See C-Protocol.
Derivation Path
The hierarchical path that encodes a badge's program, group, tier, and
sequence: m/721'/0'/{group}'/{tier}'/{seq}.
See Derivation Paths.
Gift Code
A transferable code that, when redeemed, mints a badge or credits rewards. See Buying a Gift.
Activity Tier
The dynamic axis of HRTB, recomputed every 30 days. Four tiers — Dormant (0.5x), Active (1.0x), Engaged (1.25x), Core (1.5x) — based on the count of qualifying actions in the trailing period. See Earning Status.
Cohort
The permanent axis of HRTB, determined by your HeartBadge ID at activation. Four tiers on powers-of-ten boundaries — Founder (1–100k, 2.0x), Pioneer (100k–1M, 1.5x), Member (1M–10M, 1.2x), Community (10M+, 1.0x). Your cohort never changes. See Levels and Multipliers.
Founder Cohort
The first 100,000 members to activate a badge. Permanent 2.0x cohort multiplier. The gravity in the "early believer and still showing up" story — Founders carry the highest cohort weight, but only realize the full 3.0x ceiling when they stay active.
HRTB (HeartBeat)
Your rewards multiplier — HeartBeat. The product of your cohort multiplier (permanent, by HeartBadge ID) and your activity multiplier (dynamic, by actions per 30-day period). Ranges from 0.5x to 3.0x. Applies to platform rewards and event bonuses; does not apply to peer-to-peer transfers or gifts. See What Is HRTB.
Humanity Score
A ZK-verifiable measure of a member's demonstrated presence and participation history, without revealing the underlying data. Used to gate inbox access — higher humanity score means more inbox permission. Currently on the Horizon.
MaaS
Membership-as-a-Service. The offering for operators who want to run a program on HeartBadge. See What Is MaaS.
Channel
A message category on the participation bus. Channels are just
messageBox names — venue_broadcast,
shoutout, checkin_proof, inbox,
notifications. All run on the same three endpoints. See What's on the Horizon.
Ephemeral Message
A message that auto-deletes when the recipient acknowledges it. Used for shout-out channels where no archive should exist. Gone from the relay, no screenshots-from-server. Ephemeral by protocol design.
Messagebox
A BRC-31 authenticated communication surface. Every badge has a messagebox
identity derived from its key. Messages can be free, paid, or blocked
depending on sender permissions. Three endpoints handle everything:
sendMessage, listMessages,
acknowledgeMessage. See What's on the Horizon.
Participation Bus
The architectural frame for MessageBox. Every interaction at an event —
check-in, shout-out, broadcast, reward claim — is a message on a channel.
The channels are just messageBox names on the same
infrastructure. Not a messaging app — a protocol-native event interaction
layer.
MNEE
The rewards unit and settlement pipeline. Handles the two-tier ledger, dispatches rewards, and webhooks back to operators. Pronounced "money." See MNEE Rewards Pipeline.
Paid Inbox
A messagebox configuration where unsolicited messages require a micropayment in MNEE to deliver. Prevents spam; rewards the member for attention. The payment flows to the recipient, not the platform.
Program
An operator-configured membership on HeartBadge. A festival, a club, a venue, a streaming service. See What Are Programs.
Proof Authority (PA)
A role in the C-Protocol that attests to facts about the world — "this member was at this event" — which the covenant can then enforce. See Proof Authorities.
Public Surface
The member-controlled broadcast layer. A member can publish attestations, milestones, and announcements to a public messagebox that anyone can read. All authenticated by BRC-31.
Ring
The maturity classification for features in these docs. Ring 1 is shipped and load-bearing. Ring 2 is in active development. Ring 3 is horizon / architecturally designed but not member-facing yet. See Welcome.
Shout-Out Channel
An ephemeral, paid messagebox channel where fans send messages to artists during a show. The artist sets their rate (e.g., $2/message), fans see the quote before sending, payment attaches to the message, artist acknowledges and it's deleted. The artist makes money. The fan gets a moment. No platform takes a 30% cut — just 0.001¢ relay fee.
SPV
Simplified Payment Verification. A badge can prove its state to a verifier without running a full node, using header chains and Merkle proofs. See SPV and BEEF.
Superseded
A badge's prior state after it's been updated (new proofs, new balance, new owner). Superseded states are historical, not invalid.
Three-Chain Architecture
HeartBadge runs across two layers: OP_CAT Layer for identity and proof (CAT-721 badges, C-Protocol attestations), and BSV for rewards (MNEE micropayments, messagebox). Each layer does what it does best. See Three-Chain Overview.
Transferable / Restricted / Available
The three reward balance states. See Understanding Balances .
Two-Tier Ledger
The architecture where reward accrual is fast and in-memory, while settlement is on-chain and auditable. See Two-Tier Ledger.