Why We Built Embedded Wallets (and What the Alternatives Are Missing)

You need to add wallets to your app. You look at the options. Turnkey gives you MPC signing but bolts it onto a human-first product. CDP gives you wallets but locks you into Coinbase custody. Privy and Dynamic handle auth but punt on key management entirely. And building it yourself means spending three months on MPC, HSM rotation, nonce serialization, UTXO locking, and spend policies before you ship a single feature.

We built 1Claw embedded wallets because none of these options gave us what we actually wanted: a single platform that handles auth, custody, signing, spend controls, and multi-chain support without requiring three vendors and six months of integration work.

What are 1Claw embedded wallets?

1Claw is a secrets management and agent governance platform. Embedded wallets are one surface among many, all governed by the same policy engine, audited in the same hash-chained log, and optionally signed inside the same TEE (Shroud, running on AMD SEV-SNP).

When you embed a 1Claw wallet, your users get:

• Passwordless login via Email OTP or social login (Google, Apple, Discord). No seed phrases, no extensions.
• Multi-chain wallets across Ethereum (plus L2s), Bitcoin, Solana, XRP, Cardano, and Tron. Six chains from day one.
• HSM-backed custody with optional MPC key splitting across GCP, AWS, and Azure KMS.
• Programmable spend policies that you set per-app or per-user. The server enforces them before every signature.

How provisioning works

The fastest path is the React component. Install @1claw/wallet-react, wrap your app in the provider, and drop in the widget:

import { OneclawWalletProvider, OneclawEmbeddedWallet }
  from "@1claw/wallet-react";

export default function App() {
  return (
    <OneclawWalletProvider appId="plt_...">
      <OneclawEmbeddedWallet
        chains={["ethereum", "solana", "bitcoin"]}
        features={["send", "swap", "receive", "buy"]}
      />
    </OneclawWalletProvider>
  );
}

That gives your users a full wallet UI with send, swap, receive, and buy. If you want programmatic control instead, use the useOneclawWallet() hook.

For server-side provisioning, the Platform API lets you bootstrap a user with a single call. Define a template once, and every new user gets a vault, agent, signing keys, and wallets:

import Oneclaw from "@1claw/sdk";

const client = new Oneclaw({ apiKey: "plt_..." });

// Provision user + wallets in one call
const { connection_id } = await client.platform.upsertUser({
  email: "user@example.com",
});

const result = await client.platform.bootstrapUser(connection_id, {
  template_id: "your-template-id",
});
// result.summary contains vault_id, agent_id, signing_keys

The bootstrap template is declarative JSON. You specify which chains get signing keys, which policies to attach, and whether the agent gets Intents API access. One template handles every new user identically.

How the security model works

Every secret (including wallet private keys) is encrypted with a unique Data Encryption Key (DEK). Each DEK is wrapped by an org-level Key Encryption Key (KEK) stored in Google Cloud KMS. The result: no plaintext key ever exists outside of HSM memory during wrap/unwrap.

On top of envelope encryption, you can enable MPC key splitting:

• XOR 2-of-2 (client custody): One share stays on the server (GCP KMS), one is returned to your client. Neither party can sign alone.
• Shamir 2-of-3 (multi-HSM): Shares split across GCP KMS, AWS KMS, and Azure Key Vault. Any two reconstruct the key. No single cloud provider holds enough material to sign.

For signing, you can optionally route through Shroud, our TEE proxy running on AMD SEV-SNP Confidential VMs. Keys exist only in encrypted memory. The attestation is publicly verifiable:

curl https://shroud.1claw.xyz/v1/shroud/attestation

How spend policies work

Spend policies are server-side rules enforced before every signature. You set them per-app (defaults for all users) or per-user (overrides for specific accounts). The strictest policy always wins.

Available policy fields:

These are not client-side suggestions. The Vault server validates every send and swap request against the effective policy before signing. A compromised client cannot bypass them.

Policy features on every tier

Most wallet providers charge enterprise pricing for basic spend controls. 1Claw ships them on every plan.

Even on the Free tier, you get all seven spend policy fields above, per-agent transaction guardrails (address allowlists, per-tx caps, daily limits, chain restrictions, token allowlists), 40+ tx_conditions fields, and per-chain guardrail overrides. That covers the vast majority of real-world spend control needs without upgrading.

• Free: Spend policies, to_allowlist, to_denylist, daily limits, allowed chains, allowed tokens, tx count caps, tx_conditions, per-chain guardrails
• Pro: Everything in Free + Platform API spend policies (per-app and per-user), Execution Intents guardrails
• Team: Everything in Pro + Cedar policy backend, SSO-enforced policies
• Business: Everything in Team + OPA policy backend, consensus/multi-approval, control-plane governance, expression engine DSL
• Enterprise: Custom policy integrations, dedicated support

The higher tiers add declarative policy languages and multi-party approval flows, not basic safety rails. You should not have to pay $999/month to stop an agent from draining a wallet.

Multi-chain from day one

Each user gets derived addresses across all six chain families. Key generation uses the correct curve per chain (secp256k1 for Ethereum/Bitcoin/Tron, Ed25519 for Solana/XRP/Cardano). The wallet supports native currency sends, token transfers (ERC-20, SPL, TRC-20), and chain-specific features like XRPL transaction types, Cardano native assets, and Solana ATA auto-creation.

EVM chains support EIP-1559 (Type 2), EIP-4844 (Type 3), and EIP-7702 (Type 4) transaction types. Gasless transactions via ERC-4337 with Pimlico paymaster are available on Ethereum, Base, Optimism, Arbitrum, and Polygon.

Head-to-head: 1Claw vs. alternatives

What about building it yourself?

You could build all of this in-house. Here is a rough list of what you would need to implement:

• HSM-backed key generation with envelope encryption (per-secret DEK + org KEK)
• MPC key splitting (XOR or Shamir) across multiple cloud KMS providers
• Nonce serialization with SELECT FOR UPDATE to prevent concurrent transaction races
• UTXO locking for Bitcoin and Cardano (5-minute auto-expiry, double-spend prevention)
• Multi-chain transaction signing (secp256k1 for EVM/BTC/Tron, Ed25519 for Solana/XRP/Cardano)
• Spend policy enforcement (allowlists, daily limits, per-user overrides, token restrictions)
• Audit trail with hash-chain integrity verification
• Email OTP and social login with server-side token verification
• KEK rotation, DEK re-wrapping, and KMS version cleanup

That is three to six months of senior engineering time before you write a single line of product code. And you still need to maintain it, rotate keys on schedule, handle edge cases like Solana ATA auto-creation, and keep up with new transaction types as they ship.

Frequently asked questions

What is an embedded wallet API?

An embedded wallet API lets you add crypto wallets directly inside your application. Your users get a wallet without installing an extension or managing seed phrases. The API handles key generation, custody, signing, and multi-chain support. 1Claw adds spend policies, server-side enforcement, and TEE signing on top.

How is 1Claw different from Turnkey?

Turnkey provides MPC signing infrastructure built for human wallet flows. 1Claw is an agent-security platform with embedded wallets as one capability. You get a policy engine with 40+ conditions (including Cedar and OPA backends), TEE signing via Shroud, per-app and per-user spend policies, LLM traffic inspection, and six native chains. Turnkey does not offer spend policy enforcement, LLM proxy, or agent-specific guardrails.

How is 1Claw different from Coinbase CDP wallets?

CDP wallets lock you into Coinbase custody infrastructure. 1Claw gives you MPC across three cloud providers (GCP, AWS, Azure), so no single vendor holds your keys. You also get server-enforced spend policies, six native chains from day one (CDP is primarily EVM + Solana), and an open SDK built from a published OpenAPI spec.

Do I need to handle key management?

No. 1Claw handles key generation in HSMs, envelope encryption, KEK rotation, DEK re-wrapping, and MPC key splitting. Private keys never leave the HSM boundary during generation. Your application never sees or stores a private key.

Which chains are supported?

Ethereum (plus Base, Optimism, Arbitrum, Polygon, and any EVM chain), Bitcoin, Solana, XRP Ledger (30+ transaction types), Cardano (native assets), and Tron (TRC-20). All six chains are available from day one with correct curve and address derivation per chain.

Can AI agents use these wallets?

Yes. 1Claw was designed for both human users and AI agents. Agents authenticate with short-lived JWTs, access wallets through the Intents API, and are bound by transaction guardrails (address allowlists, per-tx caps, daily limits, chain restrictions). Agents never see private keys. The signing happens server-side or inside the Shroud TEE.

Get started

Create a platform app, get your plt_ key, and start embedding wallets. The React component gets you a working wallet in five lines. The Platform API gets you programmatic user provisioning in three.

Start the setup wizard · Embedded Wallets overview · Read the docs · @1claw/wallet-react on npm