Thanks to Google's September 10 update, users now have more freedom in choosing where to store their keys.
@ritualnet, in turn, offers two technical building blocks.
The first is signing transactions via passkey (the user signs an action).
The second is P-256 signature verification inside a smart contract, where the contract checks that the signature is genuine.
How to use them is up to the application developers.
Ritual also shared advice for those building on Ritual:
The approval screen should clearly explain what exactly the user is signing - logging in, submitting a proposal, or delegating a specific capability to an AI agent.
Plan for account recovery from the start - what to do if a device is lost or a key is changed, and how to revoke the old one.
Keep agent delegation specific - which actions are allowed, when access expires, and how to revoke it.
Passkeys turn signing into a dApp into a familiar, intuitive action, and Ritual provides the ready-made building blocks for it - the signature and its verification in the contract.
But the technology is only half of it: the rest depends on how clearly the app explains to the user what they're signing, and how well account recovery and permission revocation are thought through in advance.
Good UX here is built not on the technology itself, but on transparency and control at every step.
@ritualfnd
Your next onchain user may already have a passkey.
On September 10, Google announced easier passkey transfers between password managers on Android.
For Ritual builders, that opens a useful design question: what should a familiar sign-in unlock?