Custody Model

HeartChain Labs currently operates a hosted custody model for member wallet keys. This page explains what that means, how it works, and how it transitions.

Current Architecture: Hosted Custody

What HeartChain Labs holds

All member wallet signing keys are derived deterministically from a master treasury seed held by HeartChain Labs signing infrastructure. This seed is the root of a hierarchical deterministic (HD) tree:

• Identity keys (CAT-721 badges): derived from m / 721' / 0' / group' / tier' / sequence
• Rewards wallet keys (MNEE/BSV): derived from m / 44' / 236' / group' / tier' / sequence

The sequence is your stable member ID (assigned chronologically when you joined). Because everything derives from the master seed, HeartChain Labs can construct your keys on-demand and sign transactions on your behalf.

What members control: Authentication, not key custody

When you authenticate with your passkey, you prove to HeartChain Labs: "I am the member associated with this badge." The backend then:

1. Looks up your member sequence
2. Derives your signing key from the master seed
3. Signs the transaction/attestation you authorized
4. Broadcasts it

Your passkey is authentication (proving identity), not authorization (holding key material). You never receive or hold a seed phrase. You never locally derive a key. This model is custodial: HeartChain Labs bears full responsibility for member keys and balances.

Operational implications

If the master seed is exposed: Every member wallet, every identity key, every balance is compromised. The blast radius is total. This is why the master seed is held by dedicated signing infrastructure with strict operational controls — no human access, no export, no backups outside the signing system.

If HeartChain Labs disappears: Members' badges exist on-chain and are verifiable. Members' balances are settled on-chain. But without access to the master seed, members cannot spend their wallets unilaterally. A third party would need the seed to recover member access. This is an acceptable trade-off for simplicity and consistent member experience, but it is a real dependency.

Target Architecture: Member-Held Keys

The HD derivation model is designed to support a transition to member-held keys. In the target architecture:

• Members receive their xpub (extended public key) at badge activation
• Members derive their own keys locally for spending authority
• HeartChain Labs operates watch-only infrastructure and broadcasts member-signed transactions
• If HeartChain Labs disappears, members retain full unilateral control

This transition is designed into the protocol but not yet implemented. See Three-Chain Overview for the migration path.

Why custody today, non-custody tomorrow

The custodial model trades operational dependency for member simplicity. Members don't manage seed phrases. There's no risk of seed loss. Recovery is straightforward. For a membership program, this is the right starting point.

But it's not a permanent architecture. The transition to member-held keys is a feature, not a future version. It's designed into the derivation paths, the watch-only infrastructure, and the protocol itself.

The goal is to let programs start with custody (simple, reliable) and graduate to non-custody (permanent, user-controlled) as their risk models and member sophistication evolve.