Turnkey’s Policy Engine: Guardrails for web3 transactions

With over $610 million drained across multiple chains, the 2021 Poly Network hack is a clear example of the damage that can occur when strong policy controls are not in place to protect critical assets.

During the exploit, hackers took advantage of the network’s cross chain bridge contracts, forging contract validated messages that redirected assets to their own addresses. The underlying contracts accepted these messages without confirming that they came from an approved source, which allowed the attacker to impersonate privileged system components.

Today, most wallet infrastructure still relies on implicit trust and user vigilance. Turnkey’s approach has always been to work to strengthen these weak links, providing verifiability over trust and policy over user actions. 

Well-designed policies at the signing layer can enforce strict rules on who can authorize transfers, which contracts can be called, and how much value can move in a single request. 

Turnkey’s policy engine gives teams a deterministic, enforceable layer that governs how keys behave before any signature is produced. This article explains how to use Turnkey’s policyengine to keep critical assets safe and reduce exposure to threats and vulnerabilities.

What is a WaaS policy engine?

Policy engines enforce and maintain rules that determine whether a wallet is allowed to perform a specific action before any signature is produced. 

Today several wallet as a service providers (WaaS) allow developers to set policies for the wallets they issue to their customers. These can include things like contract allowlists, amount limits, method selectors, token approvals, message fields, or entire transaction patterns.

By enforcing these constraints at the signing layer, a policy engine creates a programmable trust boundary that does not depend on the frontend or the surrounding application logic. With the right controls in place, a wallet can block malicious routes, prevent unexpected contract calls, and stop unsafe spending behavior.

In practice, this gives developers a predictable and enforceable way to define key behavior. It also ensures that only transactions matching the approved patterns can ever be signed.

Why a policy engine is necessary

The flexibility of Web3 transactions often introduces serious security risks. A single unexpected contract call or token approval can expose users to large, irreversible losses if it is not tightly controlled.

Common attack surfaces include issues like malicious routing, slippage manipulation, and unapproved program interactions. Even well-intentioned applications can put users at risk when interfaces break or when there is an unsurfaced flaw in a smart contract. 

Policy engines reduce this risk by defining exactly how a wallet is allowed to behave. It ensures that every transaction follows the patterns your application expects, no matter what happens in the surrounding environment.

Developers can use policies to block dangerous behavior such as:

• Interacting with unapproved or unknown contracts
  
  
• Sending assets above a defined spending limit
  
  
• Executing transactions with excessive slippage
  
  
• Signing messages that do not match expected fields or domains
  
  
• Approving tokens or transferring assets to suspicious addresses
  
  

By enforcing these rules before any signature is produced, a policy engine protects users from compromised UIs, buggy integrations, and hostile network conditions. It turns wallet behavior into something predictable, testable, and safe.

How Turnkey designed its policy engine

Turnkey designed its policy engine to run entirely inside a Trusted Execution Environment (TEE). This is a secure area of a processor that provides hardware-enforced isolation from the host operating system.

Turnkey uses AWS Nitro Enclaves for its TEE infrastructure to create a sealed, network-isolated environment that cannot be accessed, modified, or observed by the host. Even administrators, cloud providers, or the underlying VM have no ability to read memory, inject instructions, or tamper with code running inside the enclave.

Turnkey’s signing workflow is built on these enclaves. Every signing request enters a Nitro Enclave where private keys are managed, the policy evaluation is run, and the final signature is produced. Nothing leaves the enclave unless it satisfies the rules defined by the developer.

This design stands in sharp contrast to other WaaS providers that run their policy checks in normal application environments. In those setups, a compromised host can often bypass or alter policy logic. Policy enforcement is vulnerable to manipulation, inconsistent deployments, and misconfigurations because it happens outside the hardware boundary that protects the keys. 

Turnkey eliminates that risk by running all policy logic inside the enclave itself. The rules are evaluated in the same trusted hardware boundary that protects the keys, which means policy cannot be bypassed, disabled, or modified without breaking attestation.

If the code or policies running inside the enclave ever differ from what developers expect, the attestation measurement will change and the system will refuse to proceed.

The engine inside the enclave uses a deterministic, JSON-based policy language that supports program allowlists, contract checks, token mint restrictions, amount limits, slippage bounds, memo validation, and structured message constraints.

These capabilities give developers precise control over how their wallets behave, with full hardware-backed assurance that the rules cannot be tampered with.

By combining policy evaluation and signing inside TEE infrastructure, Turnkey ensures that only transactions matching the policy can ever be signed.

Where policies can be implemented across chains

Turnkey’s policy engine is built to work consistently across multiple chains while still giving developers access to each chain’s unique transaction surfaces. This allows teams to enforce precise, chain-aware rules without maintaining separate policy systems for every environment they support.

Ethereum policies

On Ethereum, policies can validate contract addresses, method selectors, call data patterns, gas usage, and EIP-712 domain details. Developers can also set spending caps, restrict token approvals, and limit what kinds of interactions are allowed.

These checks make it possible to enforce safe DeFi actions and other application-specific behaviors. By combining contract allowlists with structured message constraints, Ethereum policies give developers fine-grained control over both onchain transactions and off-chain signatures.

Read more on how to create Ethereum policies with Turnkey.

Solana policies

Turnkey’s policy engine evaluates the full instruction set of a Solana transaction. It inspects program IDs, account lists, token mints, compute budget configuration, address lookup table usage, and all SPL token transfers.

This gives developers the ability to write tightly scoped swap policies, staking flows, NFT minting rules, or program-specific allowlists that ensure transactions only interact with the intended Solana programs.

Read more on how to create Solana policies with Turnkey.

TRON policies

For TRON, policies can validate contract interactions, transfer types, token IDs, method names, and approved spender addresses. This is especially important for enterprises using TRON for stablecoin flows, settlement pipelines, or controlled outbound transfers where enforcing strict transfer behavior is critical.

With these controls, teams can define exactly how their TRON-based wallets are allowed to operate and ensure that every transfer or contract call follows the expected pattern.

Read more on how to create TRON policies with Turnkey.

Policy examples and common use cases

Turnkey’s policy engine gives developers the ability to define precise transactional behavior across a wide variety of scenarios. These policies help ensure that wallets operate only within approved boundaries, regardless of changes in frontend logic or integrations.

Some examples of this include:

Swap-only policies

Swap-only policies restrict a wallet to swapping between specific tokens using an approved program or router. This prevents transactions from routing through malicious contracts or unexpected liquidity sources that could manipulate pricing or extract value.

By limiting swap behavior to known, audited paths, developers can protect users from phishing routes, slippage games, or harmful contract interactions.

Spending-cap policies

Spending-cap policies set hard limits on how much value a wallet can move in a single request or over a defined timeframe. These limits are effective for stablecoins, withdrawals, subscription like payments, and automated workflows.

They create predictable outflows and act as a strong defense against draining attacks, compromised applications, or integrations that try to move more funds than intended.

Contract allowlists

Contract allowlists ensure that a wallet only interacts with approved, trusted smart contracts. This is valuable in exchanges, games, custodial systems, and enterprise architectures where interactions must remain within a controlled ecosystem.

If a transaction references a contract outside the allowlist, the policy blocks the request before any signature is produced.

Structured message governance policies

Structured message governance policies apply to off-chain signing on EVM chains, such as EIP 712 typed data. These policies enforce approved domain separators, contract addresses, message fields, and allowable values.

By controlling how off-chain messages are constructed, developers can prevent signature replay, unauthorized approvals, and rogue message signing that could grant unexpected permissions.

Tips for implementing strong policy

Implementing effective policy is not only about defining rules but also about designing a predictable and secure operating boundary for your application. A few best practices can help ensure that your policies remain safe, maintainable, and resilient as your system evolves.

Start by creating a minimal allowlist that includes only the programs or contracts your application truly depends on. This establishes a tight perimeter and reduces the surface area for unexpected behavior.

From there, layer in granular constraints such as token mint restrictions, amount limits, slippage caps, memo rules, or specific method selectors to refine how each interaction is allowed to behave.

Before deploying policy changes, test transactions in simulation, devnet, or staging to confirm that the expected instruction patterns and contract calls align with your rules. Keeping policies versioned, regularly updated, and periodically audited is essential as your application logic, token lists, and third party integrations evolve over time.

Finally, design policies with the expectation that unexpected behavior will occur. Write rules that fail closed instead of failing open, so that if an integration changes or a dependency behaves unpredictably, the wallet remains protected.

This approach ensures that security comes from the policy itself, not from assumptions about external systems.

Turnkey’s policy engine: Protecting assets at the signing layer

Web3 applications increasingly operate in environments where value moves quickly and risks emerge without warning. 

Relying on UI checks or off-chain logic is not enough to protect users when contracts change, integrations fail, or attackers look for ways to bypass an application’s intended flow. Strong, deterministic policies are the only reliable way to define how keys are allowed to behave.

Turnkey’s policy engine brings this protection directly into a trusted execution environment, ensuring that every rule is enforced inside hardware isolation and cannot be tampered with. Developers gain precise control over how their wallets operate, and users gain confidence that only safe, expected transactions can ever be signed.

By applying clear guardrails across chains, narrowing allowed behaviors, and designing policies according to your specific needs, your dev team can significantly reduce their exposure to threats and vulnerabilities.

With Turnkey, policy becomes an integral part of your signing architecture, enabling safer, more predictable Web3 applications at every scale.

Get started with Turnkey.