CDP Wallet Policies: Don’t Be the Next Headline Hack

June 23, 2025

By: Charles Starr, Nemil Dalal, and Jayasudha Jayakumaran

TL;DR CDP Wallets enforce programmable policies at the signing layer, based on rules you define and configure via API to stop risky transactions before they start. Control recipients, transaction amounts, smart contract interactions, and message signing – all enforced within a Trusted Execution Environment.

In March 2025, a trading bot called AIXBT lost over 55 ETH after an attacker gained access to its dashboard and initiated unauthorized transactions. The bot had no onchain safeguards—once compromised, the wallet could send funds anywhere, with no checks in place.

When apps and agents move value onchain, every signature carries risk. Whether you’re building a trading bot, an autonomous agent, or a treasury system, the challenge is the same: how do you prevent bad transactions after deployment?

CDP Wallets solve this with programmable policies: declarative rules enforced every time a wallet signs. Set constraints like “only trade from this pool,” “never exceed 1 ETH,” or “block known sanctions,” and CDP ensures those rules are followed at the infrastructure level. No exposed keys. No scattered checks. Just one source of control, enforced by Coinbase’s Trusted Execution Environment. Policies are easy to define via the CDP Portal or programmatically through our TypeScript and Python SDKs. They work out of the box across EVM chains and Solana.

Enforcement Primitives

Operational risk, not code complexity, is now crypto’s weakest link. Total crypto thefts as of mid-2025 have surpassed $2.2 billion, driven largely by mismanaged keys and flawed ops practices. The historic $1.5 billion Bybit hack highlighted how reliance on manual multi-sig approvals leaves critical gaps. These aren’t novel problems; they’re structural ones. Codified wallet policies offer a path to consistent, automated enforcement that humans alone can’t guarantee.

This is where policy enforcement becomes more than just a safeguard. It becomes a critical part of your wallet’s architecture.

CDP programmable policies aren’t just a passive checklist; they’re an active bouncer at the door of every signing request. By expressing these controls declaratively, you make hard promises about what can’t happen – no matter which service or script hits the API.

From blocking shady destinations to rejecting suspicious message signatures, enforcement rules translate organizational policy into code you never have to redeploy.

Transfer recipient allowlist & denylist: Permit or block transactions based on destination addresses.
Transfer amount limits: Set minimums or maximums for value sent in a transaction.
Smart contract invocation controls: Restrict calls to specific contracts or contract methods.
Constraints on call data passed to contracts: Validate or reject based on function inputs.
Message signing criteria to prevent signing fraudulent messages: Enforce rules on messages before signing to avoid misuse.

Guardrails in Action

Policies turn raw enforcement primitives like address filters, allowlists, value caps, and message guards, into building blocks for full‑fledged products. You decide which rules match your risk appetite; CDP Wallets enforce them every time the developer requests a signature.

Below are four patterns our early integrators shipped with ease. Combine multiple enforcement types as needed, then evolve them by editing JSON instead of rewriting bots or redeploying contracts.

AI Agents: Autonomous agents for trading or governance that call only allow‑listed contracts and methods, respect per‑address spend caps, and refuse to sign spoofed messages.
DeFi Bots & Vaults: Yield harvesters and rebalancers that block malicious pool addresses, enforce liquidity limits, and require message integrity before moving funds.
Payments Infrastructure: Embedded send/receive flows that layer KYT‑backed address filters, daily value ceilings, and transfer permissions restricted to verified merchants.
Enterprise Treasury: DAO and corporate treasurers that segment risk across accounts, cap outbound value per recipient, and log every rejected attempt for audit readiness.

How it Works

A Wallet Policy is a single JSON that you create programmatically with CDP APIs / SDKs or via CDP portal. It carries a scope (project or account), an optional description, a rules array. A project-scoped policy applies to all accounts within a CDP project, while an account-scoped policy targets specific accounts.

Each element in rules pairs an operation (e.g., signEvmTransaction) with an action (accept or reject) and one or more criteria. A criterion defines a logical condition that the transaction is evaluated against. It includes a type – evmAddress, solAddress, ethValue, etc., an operator (in, <=, not in, and more) and a set of values. During a signing request the engine evaluates rules top‑down and stops at the first matching condition, guaranteeing deterministic enforcement.

In this example, the policy has two rules. An incoming transaction would be processed against each rule and will be accepted if it meets either of these conditions:

Has a value less than or equal to 1 ETH (expressed in Wei)
Has a value less than or equal to 2 ETH, and an address in the allowlist

Refer to our documentation to learn how to define policies.

Integration Paths

CDP Wallet policies support a variety of developer-first interfaces:

Start Building

Whether you're scaling agents or safeguarding treasury, CDP Wallets’ programmable policies enable enforcement you can trust, built directly into the signing layer.

This is one piece of our broader push to make CDP Wallets programmable, secure, and policy-aware by default. As more apps go autonomous, wallets will need built-in defenses. We’re building toward that future.

Get started today: