Trust Model

Every system has a trust model — the set of parties, mechanisms, and assumptions that have to hold for the system to work correctly. HeartBadge's goal is to make the trust model small, explicit, and to provide a path toward user custody over time.

What you have to trust (today)

• HeartChain Labs to custody your keys. Member wallet keys are derived from a master seed held by HeartChain Labs. Your passkey authenticates you; HeartChain Labs holds the signing authority. See Custody Model.
• The underlying infrastructure. OP_CAT Layer for badges and proofs, BSV for rewards. We inherit their security.
• The open-source protocol implementation. The covenant code and the protocol client are public and auditable.
• Cryptography. Signatures, Merkle proofs, standard primitives.

What you don't have to trust

• A program's honesty. The covenant enforces program-level rules. A program cannot secretly mint extra badges or drain members' wallets, regardless of what they claim.
• The payment processor. Payments are separate from badge state. A payment reversal doesn't retroactively revoke an activated badge outside the covenant's explicit revocation rules.
• That HeartChain Labs will exist forever. Your badge's existence is on-chain and verifiable independently. If our servers went down tomorrow, your badge would still exist, your balance would be settled on-chain, and a third-party tool could verify both. The custodial dependency is real (see above), but the on-chain data is not.

The transition to member custody

The custody model is designed to evolve. In the target architecture, members hold their own keys. At that point, the trust model shifts: instead of trusting HeartChain Labs to custody your keys, you trust yourself. HeartChain Labs becomes optional infrastructure that broadcasts transactions you sign locally. See Custody Model for the transition plan.

Related pages: Vendor Dependencies, Security Model.