Core concepts

When Claw Wallet performs a sensitive action, it does not run inside the same page as the rest of the agent. It runs inside an isolated sandbox so the main UI cannot directly touch private signing state.

This matters because wallet actions are not ordinary website actions. Signing, unlocking, exporting, and recovery should stay separate from general page logic, so a UI bug or a random component update does not expose secrets.

For users, this is why the product can safely ask for a PIN or a passkey in a dedicated secure flow instead of handling sensitive input in the normal dashboard page.

Claw Wallet does not rely on one single secret living in one place forever. During setup, the wallet secret material is split into separate shares so the whole key is never exposed as one easy-to-copy blob.

That split is what makes controlled custody possible. One part can stay on the agent side, another part can be protected by the relay or encrypted storage, and the remaining part can be kept in a way that supports recovery and activation later.

The practical benefit is simple: if one storage location is lost or compromised, the wallet is still designed around pieces rather than a single raw secret.

Recovery is not an afterthought in Claw Wallet. If a browser session is lost, a device changes, or a wallet needs to be rebuilt, the recovery path uses the wallet's protected shares and verification steps to restore access.

In practice, recovery means the product can rebuild a usable wallet state without exposing the full secret to the normal page. The user may need to verify identity with a passkey or PIN, and then the secure flow reconstructs the pieces it needs.

This is especially important for long-lived wallets. The goal is not just to open the wallet once, but to be able to bring it back safely after something goes wrong.

Many wallets start life on the agent side first. Bind and takeover is the process of linking that wallet to a user account so the user can later control it from the dashboard or claim flow.

First, the system identifies the wallet by UID. Then it checks whether the wallet is still inside the automatic claim window or whether it needs a manual bind step. After the bind is complete, takeover finishes the handoff so the wallet is managed by the logged-in user.

Users usually feel this as a two-stage experience: the wallet is discovered and attached first, then control is confirmed with a secure factor such as passkey or PIN. That is how an agent-owned wallet becomes a user-owned wallet.

Risk policy is the rule set that decides which actions are allowed, which actions need extra confirmation, and which actions should be blocked entirely.

A policy can limit daily transfer volume, cap the amount allowed in a single transaction, restrict the tokens that may be moved, maintain allowlists and denylists, and require approval for risky recipients or large spends.

This is what lets the wallet stay flexible without becoming reckless. A user can keep the wallet usable for normal work while still putting guardrails around dangerous actions like blind signing, unknown tokens, or large transfers.