Smart wallet

Self-custody on ERC-4337.

Smart-contract accounts signed by passkeys you control. No seed phrase, no extension, no recoverable secret on a server.

Last updated: May 18, 2026
01

ERC-4337 architecture overview

Cooud's smart wallet is an ERC-4337 account: a contract that holds your funds, validates operations against an arbitrary signature scheme, and pays its own gas (or has a paymaster sponsor it). The user-facing key is a WebAuthn passkey on your device — no seed phrase exists.

The wire path for every action looks like:

UserOperation  ──►  Bundler  ──►  EntryPoint  ──►  Account
                                       │
                                       └──►  Paymaster (optional)

The EntryPoint is the canonical singleton 0x0000000071727De22E5E9d8BAf0edAc6f37da032 (v0.7.0). Every chain we support deploys the same address. Account contracts are stable accounts derived deterministically from your signer (a counterfactual address is shown before the first transaction).

02

Account creation with Turnkey

On first use we provision a Turnkey passkey-bound key as the account's primary signer. Turnkey's policy engine binds the signing material to your WebAuthn credential — no operator at Turnkey or Cooud can sign on your behalf.

The address is deterministic: given the signer public key, anyone can derive the counterfactual account address before deployment. Deployment itself is lazy — it happens inside the first UserOperation via the initCode field, which keeps zero-state users from incurring deployment gas if they never transact.

POST /v1/smart-wallet/accounts

201 Created
{
  "address":  "0x4Cb2...a0e9",
  "signer":   "passkey",
  "chain_id": 8453,
  "deployed": false
}
03

Passkey-based recovery signer

Recovery is purely device-side. Modern passkeys sync via the platform credential provider (iCloud Keychain, Google Password Manager, 1Password) so losing one device does not lose the key.

For users who want belt-and-braces, the account supports a second guardian signer: a passkey on a separate device or a hardware security key (YubiKey, Solo). Adding a guardian invokes a one-shotaddGuardian call on the account. Removing the primary signer requires a co-signed transaction from the guardian after a time-locked window (default 48 hours), so a stolen device cannot immediately lock you out.

Critically, Cooud never holds key material for self-custody users. If you lose every signer and every guardian, the account is permanently inaccessible — exactly the property you signed up for.

04

Building a UserOperation

A UserOperation describes one action by an account. The fields:

{
  "sender":               "0x4Cb2...a0e9",
  "nonce":                "0x07",
  "factory":              null,
  "factoryData":          null,
  "callData":             "0xb61d27f6...",
  "callGasLimit":         "0x7a120",
  "verificationGasLimit": "0x2dc6c0",
  "preVerificationGas":   "0xea60",
  "maxFeePerGas":         "0x59682f00",
  "maxPriorityFeePerGas": "0x59682f00",
  "paymaster":            "0x12...ab",
  "paymasterData":        "0x...",
  "signature":            "0x..."
}

The callData field encodes whatever the account should execute — most commonly an execute(target, value, data) call. The smart-wallet SDK assembles the rest of the fields, fetches gas prices, and asks the passkey for the signature over the structured UserOpHash.

05

Simulation via Tenderly

Before broadcast, every UserOperation is simulated through Tenderly's simulation API. The simulation returns the exact state change (token transfers, NFT moves, approval grants) which we render on the confirmation surface. If the simulated outcome differs materially from the user-stated intent, the call is blocked at the UI layer.

Simulation also serves as a cheap pre-flight against reverts. A UserOperation that reverts under simulation is rejected client-side, so users do not pay gas (sponsored or otherwise) for transactions that cannot succeed.

06

Bundler submission

We submit UserOperations to multiple bundlers — Pimlico and Alchemy on every supported chain — and take the fastest inclusion. The bundler client honours the standard eth_sendUserOperation / eth_getUserOperationReceipt JSON-RPC interface.

POST https://api.pimlico.io/v2/<chain>/rpc
{
  "jsonrpc": "2.0",
  "id":       1,
  "method":  "eth_sendUserOperation",
  "params": [ userOp, entryPoint ]
}

On inclusion the bundler emits a transaction receipt and a logs payload that includes the UserOperationEvent from the EntryPoint. We index that event and present it on the activity surface as a single, user-readable row.

07

Paymaster + sponsored gas

Cooud operates a verifying paymaster on every supported chain. The paymaster signs an off-chain attestation that the UserOperation is eligible for sponsorship, and the EntryPoint then debits the paymaster's deposit instead of the account.

Sponsorship is gated by two checks: the account must be in the smart-wallet cohort (see below), and the operation must be one we sponsor — currently the first 5 swaps per account on Base, every deposit-to-CEX call, and the first 10 transfers per month. Anything else is charged to the user's ETH balance, which can be provisioned via the on-ramp surface.

08

Cohort gating

During the staged rollout, smart-wallet access is cohort-gated. Cohorts are configured under the cohort flag described in Operations. A user is in the cohort if their user_id hash falls inside the active band, or if they have the explicit smart_wallet_alpha flag.

Outside the cohort, the smart-wallet surface renders a polite waitlist with the live cohort percentage. Inside the cohort, the full feature is available — swap, transfer, sponsor, recover.

Exchange — Premium Crypto Trading