Wallets & accounts

A wallet address is public information. Merely receiving an address from a browser extension does not prove that the caller owns it. IdleAI uses an EIP-4361 sign-in message and verifies its signature before creating an authenticated session.

The initial browser flow uses an injected EVM wallet provider. It requests the selected address, checks Robinhood Chain, requests a server challenge, asks the wallet to sign, and submits the signature for verification. WalletConnect QR onboarding is not implied by this implementation.

1. The server validates the requested EVM address and creates a random challenge token and nonce.
2. The sign-in message binds the address, canonical site domain, URI, Robinhood Chain ID 4663, issue time, and expiry.
3. The challenge expires after five minutes. Its browser token is carried in an HttpOnly cookie; the server stores its hash and the expected message.
4. The wallet signs the expected message. The server verifies against its stored challenge, not an arbitrary message supplied by the caller.
5. A database transaction consumes the challenge exactly once, creates the account if needed, and inserts a new session.
6. The session cookie is HttpOnly, SameSite=Strict, and Secure in production. Sessions expire after eight hours and can be revoked by signing out.

The persistent account is identified by a normalized wallet address. Account records, session hashes, API key hashes and metadata, and supplier applications live in PostgreSQL. A wallet address supplied in an API query or body is not used to select the authenticated owner.

Private keys and seed phrases are never needed for account creation. Session tokens and API credentials use high-entropy random values and are stored as SHA-256 hashes rather than recoverable plaintext. This is different from hashing a human-chosen password.

• A sign-in message is not a deposit, an allowance, or authority to spend wallet assets.
• Wallet/network changes during sign-in should cause the flow to restart rather than silently authenticate a different account.
• Database or verification-service failures must reject the operation, not create a local-only account.
• Expired or replayed challenges require a fresh sign-in.
• Tests cover disposable EOA signatures and account isolation. Contract-wallet variants and specific extension/mobile combinations require additional coverage.
• Losing wallet access is not the same as forgetting a password; a recovery policy has not been established by this sign-in implementation.