Step 01
Create private key access
Create a user-verifying service account and a credential-bound encrypted Ed25519 seed without publishing an email, legal name, or secret.
Begin with context
Your identity should start with consent.
Passkey approval can now atomically create an authentication-service account and its credential-bound encrypted key wrapper. A random anonymous .drool candidate is derived locally from the public root without email or legal identity. Profile publication, recovery, protocol identity creation, and the onchain name claim are still unavailable.
Service account path
Checking authentication service readiness…
Follow the status card next step: Retry probe if the service is unreachable or degraded; open Passkeys & devices after readiness; configure auth URL env vars only on loopback/dev. Registration stays fail-closed until reachability is ready — this page does not invent “online.”
Before you begin
Only the passkey action changes account state.
- Service account
- Created only after passkey approval
- Private key
- Generated only with PRF support
- Protocol write
- Not attempted
- Anonymous name
- Derived locally; not an onchain claim
Step 02
Start pseudonymously
Receive a collision-resistant anonymous .drool candidate from the public passkey root, then add optional profile details with field-level visibility.
Step 03
Set your boundaries
Select feeds, safety defaults, storage providers, and a recovery plan before joining the public conversation.
Replaceable authentication
Create a service account with your passkey.
The browser requires a discoverable, user-verifying credential with the PRF extension. A new Ed25519 seed is encrypted locally, then the credential and ciphertext-only wrapper are committed together. If either part fails, no service account is activated. The resulting public root deterministically yields an anonymous .drool candidate, but no protocol identity or name claim is created.
User-verifying passkey
A user-verifying WebAuthn ceremony authenticates the service account. Any PRF output is used only inside this browser and is removed from the response sent to the service.
Checking for an existing service session…
This flow creates or resumes an authentication-service session only. It never submits a transaction or claims that an onchain identity exists. A green ceremony is still not “product online.”