What is Unforgettable?
TL;DR: Unforgettable uses account abstraction and visual keys to manage EVM wallets, so you never have to store or remember seed phrases.
Why Unforgettable?
- No seed phrases: Users authenticate leveraging visual memory (their face, a favorite object, etc.) instead of managing 12–24‑word phrases.
- Self-custodial and private: The cryptographic secret is re-derived on the client device; only a public key and additional helping data are stored in the blockchain or on the app server. Raw biometrics or key material never leave the device.
- Multi‑factor auth: Combine visuals (e.g., face + object), location and add a short password or proof‑of‑work (PoW) step to reach the full 112‑bit security target.
- Smooth onboarding: First‑time users set up in seconds. Ideal for dApps that target mainstream audiences.
- Phishing‑resistant: There is nothing to type or copy, eliminating most social‑engineering vectors.
Tech overview
Unforgettable relies on a novel cryptographic primitive called fuzzy extractors, which convert “noisy” biometric/visual data into a stable, private key that can be reproduced from a close‑enough reading of the same object. Security is layered by combining factors (e.g., face + object) and strengthened further with a password or a proof-of-work challenge.
Security assumptions
To achieve a 112‑bit security baseline, Unforgettable fuses ≈46 bits of entropy extracted from a face‑plus‑object pair with an additional 66 bits contributed by either a short password alone or a shorter password reinforced by an optional 2¹⁶‑space proof‑of‑work challenge.
| Factor | Entropy usable today | Notes |
|---|---|---|
| Face | ≈14-20 bits | FAR ≈ 2⁻²⁰–2⁻²¹ |
| Generic object | ≈40 bits | Image distinguishing points |
| Location | Up to 40 bits | 10-meter range accuracy required |
| Face + object | ≈54 bits | Independent sources add up |
| Password | ≈49 bits (8 chars) | ~6.12 bits per printable ASCII char |
| PoW Challenge | ≈6 bits | 2⁶ space |
| Total | ≈112 bits | ≥112-bit baseline satisfied |
Further improvements are being researched:
- Model upgrades: Moving to 512‑D face embeddings and “specific‑object” extractors is expected to yield 40-60 bits per object and ≥ 70 bits from a face + object pair.
- Shorter secrets: With 70 visual bits, the password can drop to 7 random characters, or 5 with the same PoW range, while preserving 112‑bit security.
- New modalities: Voice prints, 3-D scans and other high‑entropy sources are being researched to reduce user effort further.
Registration and recovery flows
To set up an Unforgettable smart-contract wallet we need to:
- Create a standard externally owned account (EOA).
- Delegate the EOA to the Unforgettable smart contract via a type‑4 set‑code transaction.
- Pay the annual subscription fee to the Subscription contract.
- Grant the Unforgettable contract permission to use the private key derived from Unforgettable’s security challenges.
Once the smart-contract wallet is ready, all the user needs to do to restore access to it is:
- Make sure the annual fee was paid;
- Derive the Unforgettable private key from the security challenges;
User flow
Example of Unforgettable flow is shown in the demo below:
Subscription
The subscription is activated at setup, but the fee can be only charged when you actually invoke the recovery flow.
Comparison with other wallet approaches
Unforgettable fits into the “smart account + just‑in‑time key derivation” category. Below is a practical comparison against common alternatives.
| Dimension | MPC wallet | Smart account + MPC signer | Smart account + passkeys (WebAuthn) | Unforgettable (smart account + fuzzy extractor) |
|---|---|---|---|---|
| What it is | Key is split into shares; multiple parties/devices must co-sign each transaction | Funds in a smart-contract wallet; multiple parties/devices must co-sign each transaction | Funds in a smart-contract wallet; authorization uses passkeys/WebAuthn-derived signing keys | Funds in a smart-contract wallet; signing key is derived on demand from biometrics/visual keys/location via fuzzy extractor (JIT keys) |
| Self-custody / regulatory risk | Medium–High (signers can be seen as custodians) | Medium–High (signers can be seen as custodians) | Low–Medium (platform doesn’t control the key, but “soft custody” concerns may exist depending on the passkey provider model) | Low (user is the end key owner; platform never holds end keys/shares, only helper + policy metadata) |
| Key storage & risk | Medium–High: shares stored on MPC provider infra (often in TEE). Risks: collusion, DoS | Medium–High: shares stored on MPC provider infra (often in TEE). Risks: collusion, DoS | Low–Medium: key stored on device; optionally synced. Risks: device loss/theft; ecosystem DoS/collusion if synced | Low–Medium: no end-key storage (JIT). Risks: spoofing attempts; platform availability/DoS |
| Recovery | Depends on MPC providers | Depends on MPC providers | Device control (for local keys); if cloud-synced, relies on provider liveness | Relies on deterministic re-derivation; optional on-chain guardians/timelocks as safety nets |
| Cost assumptions | Platform fee + per-signing/per-wallet costs; expensive at consumer scale | Platform fee + per-signing/per-wallet costs; expensive at consumer scale | Smart-account gas + bundler/paymaster ops; generally cheaper than MPC | Smart-account gas + bundler/paymaster ops + small helper-data storage; generally cheaper than MPC |
| Interoperability | High: most dApps work out of the box | Medium: needs bundler/paymaster; usually per-chain deployments/modules | Medium: needs bundler/paymaster; usually per-chain deployments/modules | High: can produce standard keys/signatures and/or use smart-account policies; easier multi-chain (smart-account deployments still need bundler/paymaster infra) |
| Portability | Medium: broad device/OS support, but hard to migrate | Medium: broad device/OS support, but hard to migrate | Low–Medium: often hard/impossible to switch passkey provider or attach passkeys to a different account | Medium–High: re-derive on any device; optional advanced export; avoids cloud lock-in |
| Sanctions / screening / abuse controls | High: centralized controls (screening/limits), can increase custody-like perception | High: centralized controls (screening/limits), can increase custody-like perception | Medium: on-chain allowlists possible; depends on whether users can transact outside the app | Medium–High: screen at initiation; smart-account rules can enforce on-chain limits/allowlists while remaining non-custodial |
* For smart-account approaches, availability/DoS risk can be reduced with extended on-chain emergency recovery functions (e.g., locktimes, guardians/social recovery).
Key takeaways:
- MPC-based approaches can feel seamless, but introduce higher custody/regulatory risk (signers can be viewed as custodians) and higher costs at consumer scale.
- Passkey-based smart accounts reduce custody risk, but often trade off portability (provider/device lock-in) and can inherit ecosystem availability/DoS risks.
- Unforgettable avoids storing end keys (keys are derived on demand) and aims for low custody risk, with optional on-chain safety nets (e.g., guardians/timelocks) where needed.
Conclusion
Unforgettable offers an alternative to seed phrases with visual keys derived via fuzzy extractors, combining factors (face + object) with a short password and a PoW challenge to reach a ≥ 112-bit security baseline without exposing biometric data. Built on account abstraction, it enables fast onboarding and straightforward recovery of EVM smart-contract wallets while remaining self-custodial, private and phishing-resistant.