Using ABIs and IDLs to control transaction signing
With the introduction of Turnkey’s smart contract interface functionality, our policy engine includes enhanced support for uploading Ethereum ABIs and Solana IDLs, empowering your organization to build more sophisticated and context-aware policies. By parsing transaction call data through these standardized interfaces, the policy engine can accurately interpret and enforce rules based on the specific function calls, arguments, and data structures used in smart contract interactions. This enables granular control over wallet operations, such as restricting access to certain contract methods and validating transaction parameters—across both Ethereum and Solana ecosystems. The following guide will walk you through uploading a specific ABI or IDL, and then crafting a policy that targets specific contract call arguments. For an example usage flow, please navigate to the Usage Walkthrough section.Ethereum
ABI Format
Ethereum ABIs are represented in JSON format as an array of objects, each describing a function, constructor, event, or error. Each object contains specific fields that fully describe the callable interface or event signature. See ABI documentation reference for more. Example ABIPolicy Formats
For Ethereum, if an ABI corresponding to a contract has been uploaded, then ABI related policies for transactions calling that contract will be available under the following namespaces:- function_name: This field contains the string representation of the name of the function as defined in the ABI
- function_signature: This field contains the bytes making up the function signature
- contract_call_args: This field contains all the arguments in a mapping of arg name to argument
MapKey
access pattern. All arguments are named and are accessed using the syntax as such:
Solana
For Turnkey’s Solana IDL support, we accept IDLs formatted according to Anchor’s IDL language standardization. While other standards do exist, most commonly used IDLs that aren’t Solana’s own native IDLs, adhere to the Anchor IDL format, and there exist tools like native-to-anchor which can help create anchor formatted IDLs for native solana programs.Turnkey Formatting requirements
NOTE: this is just included for reference and troubleshooting, most Anchor IDLs should work straight out of the box. Also, some older formats of IDLs are supported (such as using the optional booleansigner
instead of isSigner
, or the optional boolean writable
instead of isMut
) – the format detailed below is the most widely used format, for reference.
Instructions Array
The instructions array is a list of objects, each defining an instruction callable by the program.
- instructions (array of objects)
- name (string): Name of the instruction.
- discriminator (optional): Unique identifier for the instruction (optional).
- accounts (array of objects): List of accounts required by the instruction.
- isMut (boolean): Whether the account is mutable.
- isSigner (boolean): Whether the account is a signer.
- isOptional (boolean): Whether the account is optional.
- name (string): Name of the account.
- args (array of objects): Arguments required by the instruction.
- name (string): Name of the argument.
- type (IdlType enum): Data type of the argument.
- types (array of objects)
- name (string): Name of the custom type.
- type (object)
- kind (string enum): The kind of type (e.g., “struct”).
- fields (array of objects): Fields within the type.
- name (string): Name of the field.
- type (IdlType enum): Data type of the field.
- Fixed arrays: Array<IdlType>
- Booleans: Bool
- Byte strings: Bytes
- Float types: F32, F64
- Signed Integer Types: I8, I16, I32, I64, I128
- Unsigned Integer Types: U8, U16, U32, U64, U128
- Solana Addresses: PublicKey
- Vectors: Vec<IdlType>
- Strings: String
- Optional Types: Option<IdlType>
- Custom Defined Types: DefinedType
- Enum
- Struct
- Alias
- Explorer Links
- Anchor CLI:
- Using the command:
anchor idl <program_account_string>
- Using the command:
Policy Formats
On the Solana side, if an IDL corresponding to a program has been uploaded, then IDL related policies for instructions calling that program will be available in each instruction under theparsed_instruction_data
namespace. The subfields will be as follows:
- instruction_name: Name of the instruction that is being called in call data
- discriminator: the bytes at the beginning of the instruction call data that signifies which instruction is being called
- named_accounts: a mapping of account names (as defined in the IDL) to the actual accounts that were entered to this instruction
- program_call_args: all program arguments required by this instruction call
MapKey
access pattern. All arguments are named and are accessed using the syntax as such:
route
instruction:
Usage Walkthrough
Let’s walk through an example flow of how to explicitly reference smart contract arguments in policies by uploading the ABI for the smart contract which you will be invoking in your transactions. Let’s take the Wrapped ETH (WETH) smart contract as an example. Its ABI can be found here, and we’ve included the JSON down below:


Address
section of the smart contract interface creation is populated with the correct Address. It is case insensitive with Ethereum, but case sensitive with Solana.

transfer
function call. It has two arguments: wad
(uint256) and dst
(address), corresponding to the amount and destination, respectively. We can now next construct a policy like the following:
dst
is a specific address (our testnet warchest).
We can create this policy via the same Security tab:


transfer
call, we can enforce it within a policy via the following:
0x
prefix is necessary when writing a policy against function signatures. Generally, you can find function signatures on an explorer like Etherscan. In this case, the function signature for WETH’s transfer
can be found here.
Note that these two operations, creating a new Smart Contract Interface and a Policy, can be performed programmatically as well. Here’s are two respective sample snippets that use our @turnkey/sdk-server
package:
- Native to Anchor: Tool that creates Anchor IDLs for native solana programs
- Anchor Framework Github (Solana Foundation): Github reference for Anchor
- Q: Is there a size limit on ABIs or IDLs?
- A: Yes, we enforce a limit of 200kb. If your ABI/IDL exceeds that, we recommend minifying the JSON string (to get rid of whitespaces or extra characters). This can be done programmatically via a command similar to
JSON.stringify()
, or a webtool like https://codebeautify.org/jsonminifier .