IDL

The Anchor framework auto-generates an IDL when you build a program. It records the instruction names, the order of accounts each one expects, the account discriminator for every account type, and the field layouts as a typed schema. Think of it as the protobuf descriptor for a Solana program.

Clients like @coral-xyz/anchor and anchorpy take an IDL plus a program ID and give you a typed object you can call instructions on. They handle the borsh encoding, the account ordering, and the discriminator routing. If the on-chain program changes, you regenerate the IDL and the clients update.

Two important caveats. First, not every Solana program is written in Anchor. Native programs, Pinocchio programs, and many performance-critical DeFi programs ship without an IDL, and you decode them against hand-rolled types. Second, even Anchor IDLs sometimes lag behind the deployed program when a team forgets to publish the new IDL on chain. Pin the IDL you tested against; do not blindly trust the on-chain copy.

One opinion: IDLs are a great default for application teams. They are not enough for streaming infrastructure, where the performance difference between borsh-via-IDL and a hand- written decoder can be 10x. Pick the right tool for the job.

IDLs ship with most Anchor programs. Examples include the Whirlpools program at whirLbMiicVdio4qvUfM5KAg6Ct8VwpYzGff3uctyCc, the Raydium CLMM at CAMMCzo5YL8w4VFF8KVHrK22GGUsp5VTaW7grrKgrWqK, and Pump.fun at 6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P. You can fetch them via anchor idl fetch or read them from the program's GitHub repo.

Every event in our Enhanced Streams is decoded against the right IDL or hand-written equivalent before it leaves our pipeline. You consume already-typed payloads instead of writing your own decoder for each program. Our Program Streams page lists every program we decode out of the box.