Accounts and wallets

Your Aomi account is your identity across the product. It keeps your threads, Apps, settings, plan, and usage together. Wallets sit beneath that account as separate signing endpoints. This separation matters because one person may use an email login, a browser wallet, an embedded wallet, and a Solana wallet at the same time. A wallet address identifies a key on a chain. It does not identify the whole person. The account is the common owner. Each wallet remains independent: it has its own address, chain family, provider, signing mode, and authorization history. Changing one wallet does not silently change another.

​

What belongs to the account

The General and Usage tabs in Settings describe account-level state. The Account tab describes the wallets linked to that account. A connected wallet is not necessarily linked yet. Connecting makes a wallet available to the current browser session. Linking proves that the wallet belongs to your Aomi account and makes it available as a signing endpoint.

​

How wallets become linked

Aomi accepts two kinds of proof:

• Self-custody proof. Your wallet signs a short-lived message. Aomi verifies the signer before linking the address. Typing or pasting an address is never enough to claim it.
• Provider proof. An embedded-wallet provider identifies the wallet created for your authenticated login. Aomi records the provider relationship and links the public address to your account.

Each public address belongs to one account. On EVM networks, the same address represents the same key across EVM chains, so it carries one signing policy. Solana keys are recorded separately.

​

Every wallet has its own signing policy

In Settings → Account, the Wallet signing policy section lets you choose how each wallet handles a transaction. The options shown for a wallet depend on where its key lives and what its provider supports. For example, a provider-managed signer cannot use a client-side mode because your browser does not hold that key. A self-custody wallet cannot use provider Auto unless a supported delegation exists.

​

Automatic signing has two gates

Auto is intentionally controlled by two independent records:

1. The wallet policy must be set to auto.
2. A live delegated grant must authorize a supported provider to sign for that exact wallet.

Neither gate can substitute for the other. Logging in through a wallet provider does not automatically authorize signing. A delegated grant does not override a wallet that is Manual or Locked. When you enable automatic signing, the provider asks you once to authorize Aomi as a delegated requester. You can revoke that grant in Settings. The next signing attempt checks the current policy and grant again, so a revoked or expired grant cannot be used.

​

Policy changes require a signature

Aomi does not change a wallet policy from an authenticated click alone. The change includes the account, wallet, requested mode, expiry, and current policy version, then requires a qualifying linked-wallet signature. This protects three boundaries:

• A wallet cannot be attached to a different account without proof.
• A stale or replayed policy change cannot overwrite a newer decision.
• Granting more autonomy requires cryptographic approval, not just a logged-in browser session.

The Settings flow handles this ceremony for you. If a signature is rejected or the policy changed in another session, nothing changes and you can try again from the current state.

​

What Aomi stores

Every signature is produced where the key lives: in your wallet, in your own key-holding client, or through a supported provider under an active delegated grant. Aomi verifies the signature and enforces the selected policy.

​

Common account setups

​

Further reading