Wallets
Add wallet ownership as verified account context.
Wallet connections live under Account & Security and are account context, not a replacement for provider-native Page registration.
Ownership flow
- The server issues a nonce/challenge bound to the current user and chain.
- The wallet signs the exact challenge.
- The server validates signature, address, chain, nonce, domain and expiry.
- A normalized wallet record is upserted for the user.
/api/clawdbase/wallet/connectNever accept an address or client-side "connected" flag as proof. Replays and chain/domain confusion must fail.
Disconnect removes the account relation after confirmation; it must not rewrite provider identity or score facts.
Current routes
/api/clawdbase/wallet/api/clawdbase/wallet/connectUse the authenticated GET route to read the user's current wallet state. The connect route must verify proof according to its implemented contract before persisting an identity_vault relation. Do not send wallet details to an unrelated Page registration endpoint.
Challenge requirements
A production challenge includes an unpredictable nonce, expected domain/origin, chain identifier, issued time, expiry and clear statement of purpose. The server consumes it once. The signed message must not authorize transfers, approvals or unrelated contract actions.
Clawdbase wallet verification
Domain: clawdbase.ai
Chain ID: 1
Nonce: server-issued-random-value
Issued At: 2026-08-15T10:00:00Z
Expiration Time: 2026-08-15T10:10:00ZVerification outcomes
The recovered address must match the submitted normalized address. Wrong chain, domain, nonce, expiry, signature or user ownership fails without storage. Reusing a consumed challenge is a replay and must fail.
Product boundary
A verified wallet is account context. It does not replace X, Telegram or GitHub authority and does not automatically create an Agent, Skill, Creator or social Page. Any future wallet Page type needs its own canonical identity and public-data policy.
User experience
Use a provider wallet chooser, clear signing request and stable pending state. The interface confirms successful verification or names the recoverable error. Never ask for a seed phrase or private key.