.png)
The problem with passwords is not that they are hard to remember. It is that they can be shared. Once a password leaks or gets typed into the wrong page, the protection is gone. The credential and the secret behind it are the same thing. That is the design flaw.
Passkeys are an attempt to fix it.
What are passkeys?
A passkey is a cryptographic credential stored on your device or in a password manager such as iCloud Keychain, Google Password Manager, or 1Password. Instead of typing a password that a server checks against its records, your device holds a private key, and the service holds a matching public key. Authentication happens through a brief mathematical exchange between the two.
You unlock the passkey the same way you unlock your phone, with a fingerprint, a face scan, or your PIN. The cryptographic part happens in the background. From your side, it looks closer to unlocking a phone than logging in.
The private key never leaves the device or password manager that stores it. The service you are signing into never sees it either. There is nothing to memorise, nothing to type, and no credential a fake login page could capture.
Why this matters
This is more than a security upgrade.
In a traditional account, your password is rarely the only thing protecting you. Behind it sits a bank with fraud teams, dispute processes, and the power to reverse transactions or freeze the account when things go wrong. A leaked password is bad. It is rarely catastrophic.
A self-custodial account does not have that buffer. Your credential sits directly in front of your funds, with nothing else in between. Whatever protects the credential, protects the money. There is no second line.
Passkeys are designed for that role.
How passkeys resist phishing
A password can be stolen by tricking you into typing it on the wrong website. A convincing email arrives, you click the link, type your details into a page that looks right, and a moment later the credential is in someone else's hands.
Passkeys are bound to the specific service that issued them. A passkey created for one website cannot be used on another, even one designed to look identical. Your device performs the cryptographic check against the real domain. If the domain does not match, nothing happens. The phishing site has no password to capture, because there is no password being typed.
This is what people mean when they call passkeys phishing-resistant. The attack pattern behind most credential theft simply does not apply.
Do passkeys need two-factor authentication?
A reasonable question: if a passkey is just one step, where is the second factor?
The short answer is that a passkey already combines two factors into one motion. The cryptographic key is something you have, on your device. Unlocking it requires biometric or PIN verification, which is something you are or something you know. That is why mainstream passkey implementations do not bolt on a separate 2FA step. The factors are already there.
How Moneda uses passkeys
A Moneda account is a self-custodial smart wallet on the Base network. The passkey you create when you sign up does the actual signing. No bank, no exchange, no custodian sits between you and your funds. When money moves, your passkey authorises it.
Because Moneda does not hold your funds, Moneda also cannot hold your credentials. If you lose your passkey without a recovery mechanism in place, the wallet is gone with it. That is the cost of self-custody, not a quirk of Moneda.
The trade-off cuts both ways. The upside is that no one else can move your money either, which is the whole point. No third party holds the keys. The downside is that the credential is your responsibility. That is the bargain.
Where to keep your passkey
Store the passkey somewhere that survives losing a single device.
Cloud-synced password managers handle this naturally. iCloud Keychain on Apple devices and Google Password Manager on Android both encrypt passkeys and synchronise them across all the devices signed into your account. The catch is that each one stays inside its own ecosystem. A passkey saved in iCloud Keychain will not appear on Android, and a passkey in Google Password Manager will not appear on Apple. If you switch platforms, the passkey does not come with you.
Cross-platform managers like 1Password and Bitwarden avoid that problem. They work on iOS, Android, and desktop, and the same passkey is available regardless of which device you sign in from. If there is any chance you might switch ecosystems, that is the safer place to store the passkey from the start. If you have already saved one to a platform-specific manager and need to move, you can set up a new passkey on the new device through the recovery flow described below.
Browser-bound passkeys, like one saved in a specific Chrome profile, are tied to that browser installation on that device. They work, but they will not appear on another machine, and clearing browser data can wipe them. Hardware keys such as a YubiKey are physically very strong, but they need similar care. Lose the device or reset it, and your passkey is gone with it.
For a financial account, the recommendation is simple. Use a cloud-synced manager so the passkey survives the loss or replacement of any one device. Avoid clearing saved credentials all at once. And treat the passkey the way you would treat the only key to a safe.
What happens if you lose your passkey?
The first line of defence is redundancy. A passkey synced across more than one device means the loss of a single phone is recoverable from another.
The second line is social recovery. Moneda lets you nominate Recovery Contacts, people whose accounts can authorise the recovery of yours. The mechanism runs onchain, with a built-in safety delay (24 hours by default) before any change finalises. The delay exists so that an unauthorised recovery attempt can be cancelled before it takes effect.
Both layers are worth setting up. The first reduces the chance of ever needing the second. Without either, losing your passkey means losing the wallet. There is no master key for Moneda to fall back on, and that is the point.
For a more detailed walkthrough, refer to the FAQ on our website.
If a service offers self-custody but also offers to recover your account for you, one of those two statements is not quite true.
For the curious: the deeper mechanics
At a deeper level, passkeys are an implementation of WebAuthn, a public web standard that forms the authentication layer of the FIDO2 specification. The standard defines how browsers, operating systems, and websites cooperate to issue, store, and verify cryptographic credentials without ever exposing a private key to the network.
When you sign in, the service sends a one-time challenge to your device. Your device signs the challenge with the private key, and the service verifies the signature against the public key it stored when the passkey was created. The challenge is unique to that session, so a recorded signature cannot be replayed. The private key never moves.
The reason phishing fails is built into the protocol. Each passkey is bound to the exact origin of the site that created it. In our case, that means auth.moneda.com. The device checks this origin during signing. A look-alike site at a different domain cannot trigger a valid signature, even if the user does not notice the difference.
On the device itself, the private key sits in a hardware-isolated environment. On iOS that is the Secure Enclave, on Android the Trusted Execution Environment or StrongBox, on hardware keys like the YubiKey a dedicated security module. Software running outside that environment, including the operating system, cannot extract the key directly. Cloud-synced passkeys are end-to-end encrypted before they leave the device, which is why providers like Apple or Google never see the underlying material.
A self-custodial setting requires one extra step. WebAuthn produces a signature in one format, while a blockchain account expects a signature in its own. Moneda accounts are Safe smart accounts on Base, configured to verify passkey signatures directly onchain. So in our case, the same gesture that proves who you are also authorises the transaction. Both jobs collapse into one.
The Recovery Contacts mechanism extends this logic with a Safe recovery module. A nominated guardian can submit an onchain transaction that proposes a new passkey as the account owner. The module enforces the safety delay before that change takes effect, giving the original owner a window to cancel a malicious request. Recovery is therefore not a permission Moneda grants, but a behaviour built into the contract itself.
The result is a system where the credential, the device, and the account are tied together by maths rather than by a central authority. Trust does not disappear from the picture. It just lives somewhere different.
