Skip to main content
The solana_instruction_data field source decodes instructions for any Anchor program. Each condition includes the program’s IDL, the JSON interface that describes its instructions. Policies can then allow or deny instructions based on their decoded arguments and named accounts.
An IDL condition matches any instruction whose data begins with a discriminator from the IDL, regardless of which program it calls. Anchor derives discriminators from instruction names, so unrelated programs with a deposit instruction share the same discriminator. Always pair IDL conditions with a solana_program_instruction programId condition in the same rule. Privy ignores the IDL’s address field.

IDL requirements

  • Privy only accepts IDLs in the modern Anchor format, introduced in Anchor 0.30. Learn how to convert a legacy IDL
  • Each IDL can be up to 32 KB, and all IDLs in a policy up to 128 KB combined. Each condition carries its own copy of its IDL. Published IDLs are often larger, so trim them to the instructions the policy uses. Keep each of those instructions complete, with its accounts in their original order, along with every type it uses.
  • Template variables are not yet supported in solana_instruction_data conditions.

Fields

Fields must resolve to one of the types below. Other types, such as enums, vectors, and floats, can appear in an instruction but cannot be compared.

Allow Marinade deposits up to a maximum value

This policy allows a wallet to stake up to 1 SOL with Marinade. It also requires the minted mSOL to go to the wallet’s own mSOL token account. The programId condition limits the rule to the Marinade program.

Restrict USDC bridging to a specific recipient and chain

IDL fields can reference fields inside struct arguments. This policy allows Circle CCTP burns of up to 1,000 USDC, only to a specific recipient on Base.