How CDP’s Security Suite could prevent the next major crypto hack

• Coinbase Developer Platform (CDP) provides the tools developers need to build onchain apps – including wallets, fiat-to-crypto onramps, onchain data, trading, staking, and more

• CDP Security Suite protects developers and their users through customizable wallet policies, API key restrictions, isolated hardware environments, and bulit-in compliance guardrails like sanctions screening

• Simple usage of these security features could have prevented several recent, high-profile crypto hacks, and can play a key role in securing onchain apps and infrastructure

As of this writing, the estimated dollar amount of crypto hacks in 2025 is $3.1 billion. This already exceeds the estimated total of $2.85 billion from 2024 by hundreds of millions of dollars, with more than four months left in the year. Crypto platforms, traders, apps, and protocols remain prime targets of advanced attacks, and the number and sophistication of malicious actors will only increase as more assets come onchain. The threat landscape is not getting any less scary.

Fortunately, necessity is the mother of invention, as the saying goes. There’s a rich and growing ecosystem of security tools that onchain developers can use to help protect themselves, their systems, and their users. It pays to understand the different security tools available, make an informed decision of which ones you want to employ, and use them intelligently.

Coinbase is among the most established and trusted names in crypto, and at CDP we empower any developer to use the same builder tools that power Coinbase products. We’re doing for Coinbase what AWS does for Amazon. That extends to security, and in CDP Security Suite we think we’ve built something really powerful to protect developers and their users.

In the context of onchain apps and platforms, we think of security as being comprised of four pillars:

(1) API Key restrictions: Your CDP API Key authenticates you with our APIs; it’s the key to the front door. To ensure no one can make changes or transfer funds even if your API key is compromised, you can restrict your API key usage to specific IP address ranges and subnets, and scope what each API key is allowed to do (transfers, trades, policy updates, etc.).

(2) Wallet policies: With CDP Server Wallets (and soon, Embedded Wallets as well) developers can restrict transactions – allowing or denying transfers to select addresses and networks, setting max transaction amounts in token or USD values, budgeting transaction amounts per unit time, and even restricting the smart contracts and methods with which a wallet can interact.

(3) Enclave isolation: CDP Security Suite keeps the private keys for all CDP Wallets encrypted and isolated in secure enclaves. Signing operations take place in Trusted Execution Environments powered by AWS Nitro enclaves, with verifiable hardware isolation. This approach maximizes private key security while enabling a simple developer experience with no key management.

(4) Built-in compliance screening: Through sophisticated “Know Your Transaction” checks behind the scenes, CDP Wallets automatically protect against sends to sanctioned addresses and other malicious interactions. CDP Risk API (coming soon) enables developers to pass an address and find out if Coinbase’s internal systems see risk indicators (i.e. if Coinbase would allow transactions with the address or not), along with useful risk metadata, enabling another layer of protection.

This all sounds great, but how would these pillars stand up against real-life threats? To find out, let’s take a look at some of the largest crypto hacks in recent memory, and how CDP Security Suite could’ve helped prevent them.

Attack Overview: The incident occurred when an ETH multisig transaction facilitated from a cold wallet to a warm wallet, during which the attackers manipulated the transaction through a sequence of events. It included 3 main attack vectors:

• Compromising a developer’s workstation to get AWS credentials to access the wallet provider’s AWS account via social engineering

• Malicious javascript injection on the S3 bucket serving the wallet provider’s frontend application to manipulate transaction construction

• Attackers altered the transaction payload to replace it with a delegation call to a malicious contract that allowed transfer of funds without requiring additional multisig approvals

CDP Security Suite Protection:

• Role based access on CDP Portal: It’s difficult to protect against compromise of a developer’s workstation via social engineering, given the human-in-the-loop element. It’s common to require periodic training of developers on how to spot and report social engineering attempts, but even then the success rate won’t be 100%. One way CDP helps its developers protect against social engineering is via role-based access control (RBAC) in CDP Portal. Developers can restrict which of their users can perform sensitive operations like configuring API keys or updating policies, minimizing the ability of a compromised account to put funds at risk.

• Wallet policies on EIP-712 message signing: In this example, the manipulated transaction was able to compromise funds by signing an EIP-712 execTransaction with a particular field (“operation=1”) that authorized a transaction that used delegateCall under the hood. CDP Security Suite enables wallet policies on EIP-712 signing, where developers can set the allowed structure of an EIP-712 message and associated values. In this case, the wallet policy shown below would have prevented the message signing that resulted in the loss of funds.

Attack Overview: In this incident, an attacker gained access to the secure dashboard of an AI agent capable of executing onchain transactions via social media posts. The attacker exploited the absence of safeguards on the AI agent’s wallet and, by issuing malicious prompts, triggered unauthorized asset transfers. The failure wasn’t due to flawed AI, but rather the lack of programmable guardrails between the agent’s intent and executions of irreversible onchain transactions. Enforcing policies such as allowlists, max transaction amounts, and input validation could have blocked the malicious payload before signing.

CDP Security Suite Protection:

• IP Allowlisting: Allowlisting IP ranges from which the AI bot accepts the request and restricting this range to known IPs of authorized dashboard admins would have blocked the transfer in this scenario.

• Max transaction amounts: Setting max transaction amounts for the AI wallet would block unusually large transfers. With CDP Security Suite, wallet policies enable developers to configure limits expressed in native token terms (e.g. deny transactions above 1 ETH), or USD terms regardless of token (e.g. deny transactions with USD-equivalent value greater than $1,000).

• Destination Allowlisting: Ensuring transfers only occur to pre-approved addresses would prevent unauthorized transactions.

The wallet policy below illustrates a combination of allowlist and max transaction amounts in native token terms:

Attack Overview: The exchange in this scenario used multisig wallets with a 4-of-6 threshold, address allowlisting, and hardware wallets to secure funds. The attacker replaced the exchange’s multisig wallet with a malicious smart contract by exploiting human oversight, convincing signers to approve what appeared to be a benign transaction. The attack mirrors Case #1 above, where signers believed they were approving a simple transfer. In reality, the transaction replaced the underlying implementation of the multisig wallet. This scenario underscores the importance of codified wallet policies, and highlights the limitations of relying solely on human auditors and multisig configurations for protection. 

CDP Security Suite Protection:

• EIP-712 message signing policies: Similar to Case #1, wallet policies could have been used in this scenario to deny any EIP-712 typed data that modified the multisig contract, or restricted such modifications to approved upgrade addresses.

Attack overview: Blind message attacks are a common attack vector in onchain apps, in which a malicious site prompts users to sign messages that allow attackers to hijack accounts by reusing signatures. This usually happens when users connect their wallet to an onchain app and generate a signature for authentication. The attacker replays this signature to log into or execute actions on a target platform.

CDP Security Suite Protection:

• EIP-191 message signing policies: Developers using CDP Server Wallets (and soon, CDP Embedded Wallets) can implement wallet policies that allow signing only for a specific EIP-191 message pattern. This mitigates the risk of blind message attacks, while enabling legitimate use cases.

The wallet policy below illustrates enforcing a particular EIP-191 message pattern, denying signatures that don’t fit the pattern:

CDP Security Suite introduces a proactive and programmable security layer for your crypto assets, reducing the risks associated with major crypto threat vectors. By enforcing address allowlisting, max transaction amounts, IP allowlisting, message validations, and more, you can efficiently protect crypto assets from sophisticated threats. Through CDP SDK (available in TypeScript and Python), CDP APIs, and the CDP Portal UI, developers can configure wallet policies which are enforced at every signing request.

Whether you are securing DeFi bots, protecting autonomous trading agents, fortifying payments infrastructure, or safeguarding treasury wallets, CDP Security Suite enables enforcement you can trust, built directly into the signing layer. Get started today:

• Start building

• Explore the docs on wallet policies

• Join the community

• Follow @CoinbaseDev

Have questions for our team? Chat with us about your use case.