Skip to main content
Note: see the language section for more details.

​
Allow ABI-specific contract call parameters

For contract interactions, use Smart Contract Interfaces (ABI upload) rather than raw calldata slicing. ABI-based policies use named arguments (eth.tx.contract_call_args['arg_name']) instead of byte offsets — they’re more readable, less error-prone, and won’t silently break if the contract encoding changes. Raw eth.tx.data[...] slicing is a fallback for contracts where no ABI is available. Restrict a transfer call to a maximum amount and a specific recipient:
Restrict by function name or selector (also requires an ABI upload):

​
Iterating over contract call arguments

When a contract function takes an array parameter, use .count(), .all(), and .any() to enforce conditions across every element, rather than checking a single index. Syntax:
  • Array element count: eth.tx.contract_call_args['arrayArg'].count()
  • All elements match: eth.tx.contract_call_args['arrayArg'].all(item, <condition>)
  • Any element matches: eth.tx.contract_call_args['arrayArg'].any(item, <condition>)
For functions that take a tuple array (e.g. executeBatch((address,uint256,bytes)[] calls)), tuple fields are currently accessed by position rather than name: call[0] (first field), call[1] (second field), and so on. The positions correspond to the order of fields as defined in your ABI — substitute the correct indices for your own struct. Named access such as call['target'] is not yet supported and produces OUTCOME_ERROR.
Enforce exact batch size Restrict signing to transactions containing exactly two calls:
Whitelist all call targets in a batch Allow signing only when every call targets a specific contract and sends zero ETH. call[0] is the target address and call[1] is the value, based on the field order in the executeBatch ABI:
Combine batch size and target restrictions
Whitelist recipients in a flat address array For functions that take a plain address[] parameter — such as a disperse-style multi-send contract — use in to restrict signing to a known set of addresses:
See Smart Contract Interfaces for the full upload walkthrough and Solana IDL support.

​
Allow ERC-20 transfers for a specific token smart contract (raw calldata fallback)

Use this pattern only when an ABI is unavailable. The selector 0xa9059cbb is the 4-byte keccak256 hash of transfer(address,uint256).

​
Allow anyone to sign transactions for testnet (Sepolia)

​
Allow ETH transactions with a specific nonce range

​
Allow signing of EIP-712 payloads for Hyperliquid ApproveAgent operations

​
Inspect nested fields in EIP-712 message payloads

The eth.eip_712.message map supports nested field access using bracket notation and array iteration operators, allowing policies to inspect and enforce conditions across typed data contents, beyond just the domain and primary type. Syntax:
  • Nested struct fields: eth.eip_712.message['outerField']['innerField']
  • Array element fields: eth.eip_712.message['arrayField'][0]['innerField']
  • Array iteration: eth.eip_712.message['arrayField'].all(item, <condition>)
  • Array length: eth.eip_712.message['arrayField'].count()
Example: Restrict Permit2 batch token approvals by domain, spender, and token Uniswap’s Permit2 PermitBatchTransferFrom type lets users sign a single message authorizing multiple token transfers. The message contains a permitted array of TokenPermissions structs, each with a token address and an amount.
The following policy pins the complete Permit2 domain, allows one token permission, and restricts that permission to mainnet USDC and a known spender:
Array elements can be accessed by index ([0], [1], etc.). When a policy checks only a specific index, also constrain the array length or validate every element with .all().

​
Iterating over array fields

Each EFFECT_ALLOW policy is evaluated independently. The token-only example below does not cap the amount or batch length, and the batch-length example does not cap individual amounts. In production, combine every required domain, spender, token, amount, and count constraint in the same condition.
Whitelist a specific token across all approvals with .all():
Allow Permit2 batches with two or fewer USDC token permissions:
Allow one token permission for exactly 100 USDC:
Ethers and bigint-based Viem payloads serialize EIP-712 integers as decimal strings. Compare those values to quoted strings, as in p['amount'] == '100000000'. Numeric range comparisons require the submitted typed-data JSON to contain JSON numbers instead.
PermitTransferFrom and PermitBatchTransferFrom sign the permitted token amounts and spender, but not the eventual transfer recipient. To constrain the recipient, use a Permit2 witness type that commits to it or enforce the recipient when the signed permit is executed.

​
Deny signing of NO_OP keccak256 payloads

​
Allow signing of EIP-712 payloads for EIP-3009 transfers

This policy allows a Turnkey key to sign an EIP-3009 TransferWithAuthorization for exactly one mainnet USDC to a known recipient. It pins the complete domain so that a contract with the same domain name cannot reuse the policy.
Replace the from address with the address controlled by the Turnkey key and the to address with the allowed recipient. The example uses USDC’s six decimals, so 1000000 is one USDC.
validAfter, validBefore, and nonce are also available under eth.eip_712.message. You can constrain a single authorization by comparing them to exact quoted values. Policies do not track previously used nonces or compare a validity field to the current time; replay protection and expiration are enforced by the token contract.

​
Allow signing of EIP-712 payloads for EIP-2612 permits for USD Coin

​
Allow signing of EIP-7702 authorizations