100M+ policies already created on Turnkey: How builders are protecting transactions and why it matters

Over the past three years, Builders have created over 100 million policies on Turnkey.

Today’s wallet ecosystem is broader than it’s ever been with new use cases constantly emerging. Wallets may be operated by teams, embedded in applications, connected to automated services, or used by AI agents acting within tightly defined boundaries. Each use requires its own rules, permissions, and safeguards.

This article examines what builders are encoding in over 100 million policies, why policy has become fundamental to modern wallet infrastructure, and what these patterns reveal about the financial systems being built today.

What is Turnkey’s policy engine?

Turnkey’s policy engine allows engineers to easily create and enforce rules that govern wallet actions and use cases. Every wallet needs rules to prevent the unintended or unauthorized use of digital assets. This defining and enforcing of who can access a wallet, what they can do, and under which conditions helps mitigate losses that might otherwise result from misuse.

{
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '4b894565-fa11-42fc-b813-5bf4ea3d53f9')",
  "condition": "eth.tx.to == '<ALLOWED_ADDRESS>'"
}

Policies can authorize specific users, teams, services, or AI agents while restricting the transactions they can initiate. Turnkey’s policy engine operates fully inside secure hardware enclaves, where unauthorized requests are rejected before a signature can be produced. These enclaves keep raw private keys inaccessible to users, application developers, Turnkey, and outside attackers.

What is the average amount of policies each vertical creates for their wallets?

Builders create policies for each individual wallet, automatically, at creation time. Here’s a breakdown of how many policies builders in different verticals typically create.

Variance among verticals 

Among verticals, policy selection and implementation varies. 

‍Developer tooling platforms average around 2 policies per wallet. Most are applying a standard template of one policy scoping what the platform can do and one policy scoping what the end user can do. 

‍DeFi and trading apps add a layer on top of that, with three policies per wallet as typical. The extra policy is usually a transaction-level control, an allowlist specifying which contracts, functions, or addresses a wallet is permitted to interact with. 

‍Payments apps also have on average three policies. But the third policy tends to be role separation, a clean line between what the platform's service account controls versus what the end user controls. Payments builders care about that boundary in a way that pure signing apps don't.

‍Consumer apps show the widest variance. Most run 2–6 policies per wallet, but some stack significantly more. Apps with complex user permission models, granular roles, tiered access, multi-action wallets, can push 20–30 policies per wallet. 

‍AI agents now have on average two to three policies per agent wallet: one defining what the agent is permitted to sign, one defining what the platform retains control over. As agent use cases mature and multi-chain deployments become standard, that number continues to grow.

What types of policies are builders creating?

Looking at actual policy conditions across the platform, according to Turnkey’s data, five patterns account for nearly all volume:

‍Type 1: Embedded wallet defaults (highest volume)

The standard pattern for consumer/embedded wallets: two policies per wallet at creation. One allows the end user to add their own passkey. One allows the platform's service account to initiate recovery. 

{
  "policyName": "Allow the end user to add their own passkey",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<END_USER_ID>')",
  "condition": "activity.resource == 'CREDENTIAL' && activity.action == 'CREATE'"
}

Type 2: Transaction firewalls

‍Contract address + function + destination allowlisting. This wallet can only sign transactions that go to this specific contract, call this specific function, and send to these specific addresses. Used by trading apps and DeFi builders that need to constrain what their wallets can do onchain.

{
  "policyName": "Allow transfer calls to one contract, sending to one recipient",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<USER_ID>')",
  "condition": "eth.tx.to == '<CONTRACT_ADDRESS>' && eth.tx.function_name == 'transfer' && eth.tx.contract_call_args['dst'] == '<ALLOWED_RECIPIENT>'"
}

Type 3: Cross-chain agent permission matrices

The standard pattern for AI agents and automated DeFi bots operating across multiple networks: a separate policy for each chain and action type. A single wallet may have policies covering Ethereum, BNB Chain, Base, Solana, Arbitrum, Polygon, and more, along with structured data signing (EIP-712) and raw payload signing for specific protocols.

{
  "policyName": "Allow the agent to call the Uniswap router, on Ethereum mainnet only",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<AGENT_ID>')",
  "condition": "eth.tx.to == '<UNISWAP_ROUTER>' && eth.tx.data[0..10] == '0x38ed1739' && eth.tx.chain_id == 1"
}

Type 4: Platform Role-Based Access Control (RBAC)

Two policies per sub-org separating platform capabilities from end-user capabilities. Platform service accounts can manage credentials and end users can do everything else in their own sub-org. Clean role separation encoded as policy.

{
  "policyName": "Allow the platform service account to manage credentials",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<SERVICE_ACCOUNT_ID>')",
  "condition": "activity.resource == 'CREDENTIAL'"
}

‍Type 5: Export permissions

The builder explicitly grants the user the right to export their private key or wallet. This is an architectural decision encoded in policy that allows a user to opt in for this feature.

{
  "policyName": "Allow the user to export only wallet account <WALLET_ACCOUNT_ADDRESS>",
  "effect": "EFFECT_ALLOW",
  "consensus": "approvers.any(user, user.id == '<USER_ID>')",
  "condition": "activity.action == 'EXPORT' && wallet_account.address == '<WALLET_ACCOUNT_ADDRESS>'"
}

With policy creation volume continuing to climb through 2026, the data suggests builders increasingly treat policies as a design decision rather than a retrofit, creating policies at wallet instantiation rather than updating existing policies in place.

Why policy is now core wallet infrastructure

Across over 100 million policies created, the patterns across verticals show how flexible that model is. 

Underneath the variety sit a small number of repeatable patterns: embedded wallet defaults, transaction firewalls, cross-chain agent permission matrices, platform role separation, and explicit portability grants. This tells you most builders are solving a handful of well-understood control problems, then composing them into richer permission models as their products grow.

The takeaway for teams evaluating wallet infrastructure: Policies need to be flexible enough to match the use case. Embedded wallets may need recovery and authentication controls, while trading platforms, DeFi applications, and AI agents require granular rules for contracts, functions, destinations, spending limits, and cross-chain activity. Builders provisioning these controls at wallet creation are treating programmable access as a foundational part of wallet design.

For a deeper look at how programmable policies support different wallet use cases, explore Turnkey’s Policy Engine ebook. Then, dive into the policy engine documentation to learn how these controls are structured, or follow the quickstart guide to create your organization and first policy-governed wallet.

Get Started with Turnkey today. 

_{‍Methodology (footnote)}

_{Data is current as of August 2026. Policy counts reflect completed CREATE_POLICY_V3, CREATE_POLICIES, and prior versions. Ratios calculated from policy vs. sub-org creation. Data reflects Turnkey platform usage and does not represent the broader market. Companies counted at parent org level.}‍