Why HeartBadge Is Built on Bitcoin

Back in 2018, in a small room in New York City, a handful of us would gather most weeks to sit quietly with one idea: that the scripting language of Bitcoin — the layer most of the industry had written off as legacy plumbing — was actually where the most interesting work was still waiting to happen.

At the time, the conversation in crypto had already moved on. Ethereum had captured the programmability story. New L1s were launching every few months, each one promising a faster, more expressive environment for smart contracts. Bitcoin's script, with its deliberate constraints and its stack-based simplicity, looked to most observers like something to work around rather than work in.

But the teacher at the front of that room — a scripting language researcher whose work would later become foundational to the sCrypt ecosystem — was describing something different. Not the script most people dismissed. The script as it was originally designed to be: a small, precise, deterministic system for expressing conditions under which value could move. A system whose constraints weren't limitations to be escaped but guarantees to be inherited.

I joined as a silent student. I wanted to understand why a person with that level of mathematical and engineering depth was spending his time on something the market had apparently written off.

It took years for the answer to become obvious. Today, HeartBadge is one of the projects built on the answer.

This post walks through what we built, what we chose to build it on, and why.

What HeartBadge Actually Is

HeartBadge is a membership protocol. One badge, one human. Each badge is a cryptographically verifiable attestation of participation, bound to a specific person, backed by a private endowment, and paired with stable-dollar rewards that flow when the person actually shows up — at events, at venues, at community moments, at gatherings that matter.

That's the product. Under the hood, HeartBadge is a coordination problem across three layers that must work together without any of them becoming the single source of trust:

• An identity layer — the badge itself, its uniqueness, its lifecycle, its binding to exactly one human
• A rewards layer — the stable-dollar currency that flows to members, the treasury it flows from, the accounting that keeps both honest
• A proof layer — the attestations that say "this person was actually here, at this time, doing this thing," which are what unlock rewards in the first place

Each of those three layers has different requirements. The identity layer needs permanence, soulbound semantics, and miner-enforced lifecycle rules. The rewards layer needs speed, near-zero fees, and regulatory-grade stability. The proof layer needs substrate-agnosticism, because the physical world doesn't care which blockchain you picked.

We could have built all of this on any of the popular smart contract platforms. We didn't. Here's why.

Why Bitcoin, Specifically

The case for building membership identity on Bitcoin starts with a property almost no other chain has: the UTXO model itself is an identity primitive.

In an account-based system — Ethereum, Solana, most of the chains a founder would reach for by default — identity is a pointer. An address is a key. Tokens that "belong" to an identity live as balances in a contract's storage, which the contract can update according to whatever rules it implements. The identity is a label attached to state that lives somewhere else.

In a UTXO-based system, an asset is a specific transaction output. Its existence and ownership and spending conditions are one atomic thing. You don't look up a balance; you point at a specific piece of the chain and say this is the thing. When that piece of the chain is bound by a covenant — rules enforced at consensus — the asset's lifecycle becomes enforceable by the network itself, not by an application layer you hope to trust.

For a protocol whose core claim is "one badge, one human," the difference between "the application will enforce this rule" and "the chain will enforce this rule" is the difference between a product and a primitive.

That shift — from enforcement-by-application to enforcement-by-chain — is what Bitcoin's scripting language was designed to express. It's what most of the industry forgot was there. And it's what quietly came back online over the last several years as the tooling caught up.

The sCrypt Inflection

For most of Bitcoin's history, script was hand-written in a low-level stack language, which meant that in practice almost no one wrote it. The barrier wasn't the language itself — it was the absence of a professional toolchain. No type system. No testing framework. No compile-time correctness guarantees. Writing script for real production systems was closer to hand-writing x86 assembly than to building with modern engineering tools.

sCrypt changed the math on that. A typed, TypeScript-like language compiles down to Bitcoin script, with testability, composability, and static analysis at the front of the developer experience. What had been a handful of esoteric patterns hand-crafted by a small number of specialists became a programming environment anyone with modern engineering habits could reach. The latent expressiveness of the scripting language — covenants, statefulness, multi-party coordination, constraint enforcement at the chain layer — became accessible.

In parallel, Bitcoin itself continued to evolve. Taproot shipped. The conversation around covenant opcodes — OP_CAT, OP_CTV, OP_VAULT — moved from theoretical papers to live discussion. And for the first time in a decade, it was reasonable to ask whether full on-chain lifecycle enforcement for non-fungible, covenant-bound assets might actually be within reach.

OP_CAT Layer: Bringing Covenant-Bound NFTs to a Live Chain

OP_CAT Layer is the piece that closed the gap for us. It's a merge-mined Bitcoin L2 — meaning it inherits Bitcoin's proof-of-work security — and it ships the covenant semantics we needed without requiring us to wait for BIP-level activation debates to resolve on Bitcoin mainnet. Crucially, the layer is quantum-resistant by design, and its CAT-721 standard gives us exactly the primitive we'd been looking for: a non-fungible token whose lifecycle is enforced by miners under a covenant, with the inscription bound to a specific UTXO.

For HeartBadge, that primitive maps one-to-one onto the product:

• A badge is a CAT-721 inscription on a specific UTXO
• A covenant enforces soulbound semantics — the rules under which the badge can and cannot move
• A minting contract enforces the upper bound on how many badges can ever exist in a collection
• Derivation follows a hardened path — so the same seed can produce a deterministic tree of group-and-tier-addressable badges

None of these are application-layer conveniences bolted on top of a generic smart contract. They are properties of the chain, enforced by every honest miner, inherited by the project and by every member who ever holds a badge. That's the part that matters.

Why Not an Account-Based L1?

It's a fair question to ask, and we take it seriously, because the account-based world has real strengths: developer velocity, liquid tooling, composability with DeFi primitives. There are products for which an account-based L1 is clearly the right substrate, and we're happy to see them shipped there.

But for HeartBadge specifically, three things don't carry over:

The identity binding is weaker.An NFT on an account-based chain is a row in a contract's storage. It can be transferred, revoked, migrated, reinterpreted, or rugged, depending on how the contract was written and whether the admin keys were ever rotated. For a protocol where the asset represents a human's participation record, that's too much surface area. The covenant-bound UTXO model removes most of it.

The security inheritance is thinner.Bitcoin's proof-of-work security is, by any measure, the most expensive and most tested consensus security in the world. Merge-mining inherits that security directly. Picking an L1 with a smaller honest-miner set means picking a smaller shield.

The narrative optionality is worse.HeartBadge is building for a long horizon. "Anchored in Bitcoin" is a story that ages well across market cycles and regulatory shifts. An account-based chain's story changes every time the ecosystem it lives in reorganizes. Choosing the bedrock chain is also choosing the quietest story, which is a feature.

None of this is dunking on other ecosystems. Different tools, different problems. For identity tied to humans, UTXO-bound covenants on a Bitcoin-secured layer are the right fit.

The Rewards Layer: $MNEE on BSV

Identity is only half of HeartBadge. The other half is the rewards — the stable-dollar flows that go to members when they actually participate. And this is where we made a different choice from the identity layer, for reasons that matter.

Rewards need three things the identity layer doesn't: sub-second settlement, near-zero per-transaction fees, and regulatory-grade stability. A member checks in at an event, a reward hits their wallet within the same session. A streamer earns from a live audience, a settlement closes at the end of the stream. This is not a covenant-bound lifecycle problem. It's a fast-payments problem.

$MNEE is a USD-backed stablecoin issued under the 1Sat Ordinals protocol on BSV, reserve-backed 1:1 by Treasury bills and cash, and structured to align with U.S. regulatory frameworks that distinguish stablecoins from speculative tokens. For the rewards layer specifically, it gives us dollar-denominated value that moves at the speed of the chain it lives on, at fees small enough to support the kinds of micro-reward flows HeartBadge relies on.

Member wallets are provisioned deterministically from the HeartChain treasury seed, on a path indexed by the member's badge sequence. Every badge corresponds to exactly one wallet address; every reward flows to exactly that address; the address never changes and never needs to be discovered. The wallet is a function of the badge, not a separate artifact the member has to manage.

The two layers meet at the derivation: badge sequence on OP_CAT Layer, member index on BSV, deterministically linked, never commingled. Two chains, one identity, one coordinated flow.

The Proof Layer: C-Protocol and the Network-Agnostic PAs

Wallet Derivation: Member wallets are derived deterministically from a treasury seed, indexed by badge sequence. Wallet addresses are computed once during issuance and become the on-chain identity marker for that member.

Two-Tier Ledger.The application maintains an off-chain ledger of member activity—payments, claims, participation. When member balances or states need to be final, they're batched and settled on-chain. This separation lets us keep the cost of interaction low while preserving cryptographic finality where it matters.

The Protocol: A canonical obligation flow governs how members accrue rights, make claims, and settle transactions. The protocol enforces state transitions at consensus layer, not application layer.

Proof Authorities: Specialized verifiers confirm different proof types—payment verification, temporal constraints, geospatial bounds, and settlement finality. Each proof type has its own authority and scope, but all feed into the same settlement logic.

That last part matters more than it sounds. C-Protocol was designed from the start to be substrate-agnostic. The verifier interface is stable; the verifier implementation is swappable. Today the PAs are signed JSON with a key registry. Tomorrow they could be WASM contracts on a consensus layer, Bitcoin covenant scripts, ZK proofs, TEE attestations — whatever makes sense for the physical-world flow they're proving. The real world doesn't care which blockchain you picked. The attestation layer shouldn't either.

The protocol is how we keep HeartBadge honest to reality. The chain records what happened. The verifiers prove that it did.

A Note on What We Deliberately Did Not Build

Part of building right is being disciplined about what you don't put on-chain.

Rewards distribution uses a two-tier ledger: off-chain accrual during real-time activity, on-chain settlement at natural close points (session end, period end, batch boundary). Millions of heartbeat events become a handful of clean settlement transactions. This is how every production micropayment system at scale has ever worked, and it's how HeartBadge works too.

Custody is non-custodial by architectural commitment. Member wallets are deterministically derived, but the long-term posture is that members hold their own signing authority — not HeartChain Labs. That's an architectural guarantee we treat as load-bearing, because it's what keeps HeartBadge on the right side of every regulatory line that matters for a membership protocol.

Facilitation is deliberately minimal. HeartBadge provides identity and discovery — who is a member, what's their address, are they verified — but it doesn't route value, take fees off peer-to-peer transfers, or insert itself into flows between members. The architectural posture and the legal posture are the same posture: not a broker, not a processor, not in the path.

Every one of these choices is a small tax on short-term development velocity and a large investment in long-term defensibility. We think it's the right trade.

Looking Forward

What's live today: badges minting on OP_CAT Layer, peer-to-peer $MNEE flowing between verified members, the first program partnerships activating, and an audit packet prepared for formal review against the CAT-721 mint surface and the rewards dispatch pipeline.

What's next: deeper integrations with community partners — alta.live chief among them, where we're exploring real-time micropayment flows for live-streaming creators paid directly by their audiences. A public humanity score. Selective disclosure primitives. Native XR and physical-world check-in flows that use NFC-bound artifacts to cross-sign LocationPA attestations. An expansion of the PA substrate to support programmable verifiers where they add value.

Everything we build from here inherits the same discipline: UTXO-bound identity where identity matters, fast stable rails where speed matters, substrate-agnostic attestations where real-world provability matters. Different layers for different problems. No single point of trust.

And under it all, the scripting language of Bitcoin — the layer most of the industry wrote off a decade ago — quietly doing the work it was designed to do.