Building safer smart wallets with Turnkey controls

In a recent post on X, Ethereum co-founder Vitalik Buterin said that account abstraction is still incomplete, and he imagines a future where smart wallets aren’t tied to just one algorithm like ECDSA over secp256k1. 

In that future, smart wallets could adopt Ed25519 for safer implementations, use BLS signatures for efficient multi-signature security, or even integrate post-quantum cryptography to future-proof digital assets. These options would allow wallet developers to design accounts that are harder to exploit, easier to recover, and more flexible in adapting to new threats.

‍

But that future is not here yet. Today we still operate in an incomplete model of account abstraction, and familiar smart contract risks remain. And while new algorithmic schemes can help with robustness and efficiency, even then many of these attacks could still apply.

While Ethereum’s long-term goal is stronger cryptography and a hardening of onchain security, developers need ways to prevent these attacks now. That’s where Turnkey’s enclave-based policy engine comes in. By enforcing policies before signatures occur, Turnkey stops malicious transactions ahead of time and preserves the integrity of wallet flows.

In this article, we’ll detail some of the risks that threaten smart wallet security and show how Turnkey’s policy engine and enclave-based controls give developers a way to prevent them at the signing layer. 

Why smart wallet security matters

Account abstraction wallets, or smart wallets, have become the wallet of choice for many crypto users because of their advanced smart wallet features like transaction batching, wallet recovery, and integration with decentralized applications. These capabilities make it easier to manage digital assets, streamline routine blockchain transactions, and unlock new possibilities for decentralized application design.

If multi-signature wallets are any indication, adoption of this wallet type is already well underway.

Multi-sig wallets are themselves one of the earliest and most widely used forms of smart wallets, and Ethereum now has roughly 1.4 million of them. Their growth shows that developers and crypto users alike value programmability and stronger security models over EOA setups.

But with all the benefits of smart wallets come new security problems that wallets must address. 

Each added feature introduces complexity into the smart contract code that underpins the wallet type. The more complex the code, the more opportunities attackers have to discover weaknesses, deploy malicious transaction attempts, or trick users into giving over-permissive token approvals.

For wallet developers, this creates a challenge. Building secure cryptocurrency wallets is not only about passing a security audit before launch. It’s about anticipating how attackers will exploit wallet credentials and smart wallet features in live environments and putting protections in place that can withstand ongoing threats.

But in order to have the right protections, you first have to know the risks. ‍‍

Common risks in smart wallet design

Smart wallets expand what a cryptocurrency wallet can do, but every new feature also creates a new potential attack surface. For developers, understanding these risks is critical because the more complex the wallet type, the more opportunities attackers have to exploit it.

Here are some of the most common:

• Phishing and sign-what-you-see mismatch: UI shows one thing, but the signed calldata targets another. This results in hidden permissions or silent asset movement.
• Token approvals and permit abuse: Unlimited or hidden approvals that give ongoing spend rights and allow attackers reuse long after the first action.
• Over-broad session or delegated keys: Sessions scoped too wide or too long let attackers escalate from limited actions to transfers or approvals.
• Address poisoning and look-alike targets: Attackers plant near-identical addresses so users (or bots) paste the wrong destination; funds are unrecoverable.
• Supply chain and environment tampering: Compromised SDKs, dependencies, or builds change validation logic without notice, yet signatures still get produced.

For wallet developers, these threats are not abstract. They are active risks that must be mitigated in order for smart wallets to be a reliable wallet of choice for crypto users. And that requires moving beyond surface-level security audits into real-time enforcement of protections at the transaction layer.

Why traditional defenses fall short

There are plenty of defenses that help protect against these attacks: audits, multisig, monitoring, better algorithms, and stricter integration checks. They reduce risk, but they do not bind user intent to what actually gets signed. 

Some controls act before shipping, others detect issues afterward, yet together they still leave blind spots at the point of authorization.

Security audits are necessary, but they are only a point in time. Once code ships, new integrations, permit patterns, and UI changes open paths an old report will not cover. 

Static checks also cannot verify what a user actually signs, so if the UI shows one destination while calldata targets another, the signature still goes through unless intent is bound to the exact bytes.

Multi-signature security adds resilience, yet it does not enforce context. If all signers approve the wrong address, a hidden approval, or an over-broad session key, the wallet still authorizes the attack. 

Upgrade paths and modules can also serve to widen blast radius. A proxy admin mistake  or malicious dependency can change validation logic without users noticing. 

Relying on off-chain policy engines can also be risky if the signing environment is not trusted. Rules that live in an app server or SDK can be bypassed by a compromised backend or tampered client. 

Finally, as mentioned, swapping algorithms does not necessarily close all these gaps. Ed25519 or BLS improves cryptographic hygiene, but phishing, approval misconfigurations, and environment tampering remain open unless policy is enforced where signatures are produced.

These controls are good and necessary, but they mitigate risk rather than eliminate it. Reliable prevention requires enforcement at the point of authorization.

How Turnkey controls stop these risks

Turnkey’s security model starts with keys and policy logic isolated inside secure enclaves. Raw private keys are generated, stored, and used in-enclave, and the same environment evaluates policies before any signature is produced. 

The policy engine is capability based. Developers define which resources can be acted on, which actions are allowed, and under what conditions. Conditions can reference contract addresses, function selectors, calldata patterns, token amounts, asset types, time windows, user or device attributes, and risk signals. Policies are also versioned and auditable, so changes are controlled and traceable.

Delegated access turns this into practical developer tooling. You can mint scoped, time-limited sessions that carry only the capabilities you intend. Sessions can be bound to a specific decentralized application, chain, contract, function, amount, recipient list, and lifetime. This limits blast radius if a session key or API token is exposed.

Turnkey also supports defense in depth. Multi-party approvals, spend and velocity limits, simulation-before-approval, and recipient allowlists can be composed together. If any required check fails or the attested runtime does not match, the enclave refuses to produce a signature.

Here’s how these policies apply to common smart wallet attacks:

Phishing and sign-what-you-see mismatch

Policies can require simulation and compare the resolved target, function selector, and value against allowlists. If the calldata or target contract differs from what the policy expects, the operation is denied before signing, stopping malicious transaction attempts that silently move digital assets or grant hidden permissions.

Token approvals and permit abuse

Approvals are constrained to what is explicitly allowed. Policies can limit spender contracts, cap allowances, require time-boxed approvals, and reject repeated or stale permit patterns. This prevents the long tail of approval drain where attackers reuse broad token approvals to siphon funds from cryptocurrency wallets over time.

Over-broad session or delegated keys

With delegated access, sessions are narrowly defined by contract, method, amount, and TTL, and can be pinned to a specific decentralized application. Attempts to escalate from limited actions to transfers, approvals, or arbitrary contract calls fall outside the session’s capabilities and are rejected.

Address poisoning and look-alike targets

Turnkey controls the destination, not just intent. Policies can enforce per-asset, per-chain recipient allowlists, bind to a specific chain and contract, and require step-up approval for first-time recipients. Transactions to look-alike or unverified targets are refused, preventing misdirected sends during routine blockchain transactions

Supply chain and environment tampering

Turnkey verifies the enclave binary and policy set through remote attestation. If the attested code hash, configuration, or policy bundle does not match what was audited, signing is denied. This cuts off compromised SDKs, dependency hijacks, and tampered code deployment before signatures are produced.

These controls let wallet developers enforce security decisions where it matters most. Instead of relying on UI cues or off-chain checks, Turnkey evaluates the exact transaction, policy, and runtime together and authorizes only what the developer explicitly permits.

Developer advantages of building with Turnkey

Turnkey gives developers a single place to define and enforce wallet behavior. Policies live in the enclave, so authorization and cryptography share the same trusted boundary design. You can change policies easily without redeploying smart contracts or rebuilding the app.

Defense in depth is built in. Combine multi-party approvals, spending and velocity limits, simulation checks, and recipient verification. When any control fails or the attested runtime differs from what you approved, the enclave refuses to sign.

You can also keep the performance and developer ergonomics you need. The API is simple to integrate, with clean SDKs and clear audit logs for every decision. Routine transactions stay fast, while high-risk actions trigger stronger checks.

Turnkey is also asset agnostic and multi-chain. With SECP256k1 and Ed25519 supported, you keep one policy model that enforces the same controls everywhere you deploy. Policies travel with the workflow, so the same guardrails apply across chains and environments.

The model supports real non-custodial operations. Raw keys never leave the enclave, and policy decisions are attested and tamper-proof. This gives teams stronger assurances that digital assets remain protected even when user credentials are phished or infrastructure is targeted.

Turnkey: Securing the next generation of wallets

Developers face a shifting set of real-world threats that target both users and the systems around them. The common thread is simple: attacks succeed when what’s signed doesn’t match true intent, or when execution happens in an environment you can’t trust.

Algorithm upgrades and security audits can help, but real prevention comes from policy enforced in a trusted boundary. Turnkey keeps raw keys and authorization logic inside enclaves, verifies the runtime, and evaluates explicit rules before any signature is produced, ensuring only intended actions proceed under the exact conditions you approve.

Ready to harden your wallet flows? Get started with Turnkey today. 

‍