Don't trust our claims. Inspect the design.

What holds, and where in the code

• Keys never leave the phone

  A 256-bit seed is generated on the device and stays in the platform keychain or keystore, gated by the biometric. Everything else is derived from it. The index, the site, and we never see it.

• Phishing fails by construction

  The phone signs the site’s registered host into every approval, and the per-site key is derived from that host. A signature for a lookalike domain never verifies for the real one.

• Nothing replays

  Every challenge carries a nonce, is accepted once, and expires after 60 seconds. Signed requests from the phone carry a timestamp and are rejected if seen twice.

• What you see is what gets signed

  For a sensitive action the site’s server composes the text, the phone shows it, and its hash is inside the signature. An approval for one amount and payee is useless for another.

• The index is safe to leak

  It stores public keys, push tokens, rotating Bluetooth keys, per-site identifiers, revocation state, and an audit trail. Client and webhook secrets are stored as hashes. A full database breach yields nothing that can sign in as anyone.

• Sites cannot match you

  Each site receives its own identifier, a hash of a key derived for that site alone, and its own device id, derived the same way. The cross-site identifiers the index uses are never released, and there is no email in any token.

Each row of the threat model names the function that enforces it.