Recovery where the math matches the marketing

Carlos drops his phone in an airport

Not the glass-cracking story—the quieter one. The phone is gone: left in a bin, lifted from a jacket, or simply never coming back from the belt. What remains is the sickening gap between I had access and I need access now.

His HUMΛN Passport is not a username in a database. It is keys, delegations, and relationships he configured when life was calmer—guardians who agreed to vouch for him if he ever lost his devices. Within minutes of starting recovery on a new phone, those people get a push: Carlos needs recovery approval. Three of them open the app, authenticate with Face ID or a fingerprint, and tap through. The device in his hand receives a session. Carlos is breathing again.

The product story writes itself in one sentence: you never hand the platform your master secret. The engineering story has to be equally tight—or the marketing is lying, and the next security review will say so in writing.

The dirty secret of “we never see your key”

Many systems say they never see your key while still doing something subtly different: they accept plaintext shards from guardians, hold them long enough to reconstruct a master secret S on the server, verify it, and issue new credentials. Even if that window is milliseconds, S existed in server memory. A compromised host, a malicious insider, or a sophisticated memory attack during that window turns the platform into exactly the centralized oracle Canon rejects—the place where identity can be reassembled without the human’s device.

We call that path Option A in our implementation language: server assembly. It exists because not every client can run native code with Secure Enclave storage yet. It is not where Canon wants the world to end.

What Canon-aligned recovery looks like

Option B is different in kind, not only in degree. Guardians’ shards stay on their devices—encrypted at rest, released only after biometric unlock. When Carlos recovers, shards travel device-to-device over a short-lived encrypted channel (the same signaling fabric we use for P2P device sync). Carlos’s new device reconstructs S locally. It never sends S upstream. It sends only a proof: an HMAC-SHA256 over the recovery request identifier, keyed by S, that the server can verify against a verifier stored when the session was opened—after which S was discarded on the server side.

The API learns that reconstruction succeeded, not what the secret was. That is how the math matches the marketing.

Why the 48-hour lock still matters

Cryptography does not replace governance. After Carlos starts recovery, his other enrolled devices—and his guardians—still see that a recovery is in flight. Canon allows a lock period (we ship 48 hours) during which a fraudulent attempt can be canceled from a device Carlos still controls. The lock is not friction for friction’s sake; it is the human-readable backstop when cryptography and push notifications are not enough.

If you tell this story to a buyer, lead with the lock as well as the proof. Serious people ask both: can someone steal my account in one session? and can I stop a thief if I still have one trusted device?

Why “zero-knowledge” footnotes fail

Experienced buyers stopped trusting slogans years ago. They ask: Where does the secret exist? Who can log it? What leaves the wire? If the honest answer is “only in memory on our side, briefly,” you have described Option A—and you should name it, publish your path to Option B, and encode the mode in your API so clients cannot be silently downgraded.

Proof-only completion (client_proof) is not a branding exercise. It is the line where HUMΛN stops being the oracle for Carlos’s recovery secret.

So what?

If you build identity: document server assembly vs client proof in your public architecture, not only in internal wikis. Ship completion modes and tests that prove a client_proof session cannot accept plaintext shards—otherwise an attacker will force the weak path.

If you evaluate vendors: ask for a sequence diagram of bytes on the wire during recovery. If S appears at the server, you are not evaluating decentralized recovery—you are evaluating hosted key escrow with extra steps.

If you are Carlos: ask your wallet the same questions you’d ask a bank. The answers should sound like cryptography, not policy.

Technical deep dives in this series: server-blind HMAC proof and completion modes; Shamir cross-language alignment.