Security Model

Trust boundaries, custody posture, key management, and the security architecture of HeartBadge.

Security in HeartBadge is architectural, not incidental. This page documents the trust boundaries, custody model, and security assumptions.

Trust boundaries

What HeartChain Labs controls

The HeartBadge app and web infrastructure
The fast-tier ledger (real-time balance updates)
API keys and rate limiting
Program configuration and operator onboarding

What HeartChain Labs does NOT control

Member private keys (non-custodial)
On-chain badge state (enforced by covenant)
Settlement transactions (broadcast to public chains)
Attestation validity (verified cryptographically)

What members control

Their badge's private key
Authorization of transfers and state updates
Messagebox permissions (who can message, at what cost)
Publication decisions (what to share publicly)

Non-custody posture

HeartBadge is architecturally non-custodial:

Badge ownership. Badges are owned by whoever holds the identity key. HeartChain Labs cannot transfer a badge without the owner's signature.
Reward balances. On-chain settled balances are controlled by the badge owner. Fast-tier balances are committed to settlement; HeartChain Labs cannot unilaterally redirect them.
Key storage. Private keys are stored in the member's device (secure enclave) or in their own wallet. HeartChain Labs does not have access.

This is not a policy decision — it's a technical constraint. The architecture makes it impossible for HeartChain Labs to act as a custodian.

Key management

Member keys

Members' identity keys are generated locally on their device and stored in the secure enclave (iOS Keychain, Android Keystore). The private key never leaves the device unless the member explicitly exports it.

Recovery

Members can back up their key via an encrypted recovery phrase. If the device is lost, the key can be restored on a new device. HeartChain Labs cannot assist with recovery — we don't have access to the key or the recovery phrase.

Platform keys

HeartChain Labs holds keys for:

ClosedMinter authorization (minting new badges within rules)
Fast-tier ledger signing (committing balance updates)
API request authentication

These keys are stored in HSMs (Hardware Security Modules) with strict access controls. They cannot be used to move member assets.

Threat model

Protected against

HeartChain Labs insider theft (non-custodial architecture)
Database compromise (keys not stored in database)
API compromise (cannot move assets without member signature)
Fake badge minting (covenant enforces minting rules)
Transaction forgery (cryptographic signatures required)

Member responsibility

Protecting their device and recovery phrase
Enabling 2FA for high-value operations
Not sharing their private key
Verifying recipient identifiers before sending

Audit and verification

The security model is verifiable:

Covenant code is published and can be audited by anyone
On-chain state can be verified by running a node or using SPV
Settlement transactions are public and auditable
Third-party audits are published (see Audit Program)