Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Per-App Accounts

A user's smart account address is derived from your app's account namespace. The same person signing up on two different 1auth apps gets two different accounts — separate addresses, separate balances, separate recovery setups.

This is deliberate. Accounts are isolated by the app that created them: your app only ever sees the accounts in its own namespace, and a passkey registered on another app cannot sign in to yours.

What "one account" means

Two claims are easy to confuse:

  • One account across chains — true. A 1auth account has the same address on every supported EVM chain, one unified balance, and executes anywhere. That is chain abstraction.
  • One account across apps — not true. Each app gets its own account for the same user.

What this means for your integration

  • Account management lives in your app. App-origin integrations provide their own account-management UI; client.openAccountDialog() is available only to the experimental cross-origin mode and returns an explicit unsupported result in app-origin. There is no central 1auth dashboard listing a user's accounts across apps — the architecture has no single account to show.
  • Recovery is per app. Guardians a user sets up in your app recover your app's account only. See Lost Passkey Recovery.
  • Funding is per app. Deposits go to the address your app reports; funds in an account created by another app are not reachable from yours.
  • Users authenticate per app. Signing in to one 1auth app does not sign a user in to another, and each app's sign-up registers its own passkey.

Your namespace is part of your configuration

In the app-origin default the namespace is https://<rpId> — the RP ID hostname, with the port excluded. In experimental cross-origin mode it is the exact calling origin, including a non-default port. Anything that changes the namespace changes your users' addresses:

https://app.example.com vs https://beta.example.comdifferent accounts
https://example.com vs https://www.example.comdifferent accounts
http://localhost:3000 vs http://localhost:3001same account in app-origin; different accounts in cross-origin

So staging and production hold separate accounts, which is usually what you want. And moving your app to a new domain moves your users to new, empty accounts — treat the production hostname as fixed once you have users, and talk to us before changing it.

Switching WebAuthn mode also selects a different account, because the two modes derive the namespace differently. See Choose your WebAuthn mode.

Native apps

A native app is its own namespace by default and does not see your web app's accounts. Sharing is supported but explicit: we register your native app's identifier against the web origin whose accounts it may use, so native and web resolve to the same accounts. Contact us to set this up.