Skip to main content
Decoding turns raw Solana instruction data into human-readable, queryable tables. Dune supports Anchor, native, and system programs. Submissions are validated and then written to the decoding pipeline; once processed, decoded tables appear under a {namespace}_solana schema.

​
How to submit

  1. Go to dune.com/contracts/new (you must be logged in).
  2. In “Search for decoding submission”, open the blockchain dropdown and select Solana.
  3. Enter the program address (Solana program ID). For Anchor programs, Dune may fetch the IDL from chain and pre-fill it.
  4. Select program type: Anchor, Native, or System.
  5. In “Program information”, fill in project name, program name, start block slot (and optionally end block slot), and paste or edit the IDL. The preview can help you find a suitable start slot for new programs or upgrades.
  6. Click Submit. The submission is validated (client- and server-side); if validation passes, it is sent to the pipeline and you are redirected to your workspace Contracts page. You can also check status under Settings → Contracts.

Submit a Solana program

Select Solana, then fill program address, type, names, slot range, and IDL.

Explore decoded Solana data

Learn how decoded tables are named and how to query them.

​
What you need to submit

FieldDescription
Program IDThe Solana program address (base58). Entered in the “Search for decoding submission” address field.
Project nameThe protocol or project name (e.g. jupiter, marinade, raydium). Lowercase, no spaces; use underscores if needed (e.g. my_protocol_v2). Used as the schema namespace: {project_name}_solana.
Program nameThe program name as given by the project (e.g. JupiterV6, MarinadeFinance). Must match the IDL program name.
Program typeAnchor, Native, or System. Determines how instruction data is decoded.
IDLInterface Description Language JSON. For Anchor programs with on-chain IDL, it may be auto-filled when you enter the program address; otherwise paste from Solscan (e.g. “Anchor Program IDL” tab) or from the project repo.
Start block slotThe slot from which this IDL version is valid. For new programs, use deployment or first-use slot; for upgrades, the slot where the new version became active. The UI preview can suggest a value.
End block slot (optional)If the program was upgraded or deprecated, the last slot this version was active. Leave blank if still active.
Finding the IDL
  • Anchor programs: Many expose the IDL on-chain. Use Solscan (e.g. Jupiter) or the project’s GitHub (e.g. sdk/src/artifacts/*.json).
  • Native programs: No IDL is published automatically — you must write one manually. See below.

​
Writing an IDL for native programs

Native programs don’t use Anchor, so there is no auto-generated IDL. You need to construct one manually in Anchor IDL format, using the program’s source code or documentation as the reference. Key things to get right:
  • Instruction discriminators — Native programs typically identify instructions via the first byte(s) of instruction data (e.g. a u8 enum variant index). Check the program’s Rust source for the instruction enum to find the correct discriminator value for each instruction.
  • Argument types — All instruction arguments must be borsh-serializable. Map the Rust types in the instruction struct fields to their IDL equivalents (e.g. u64, i64, publicKey, bool, custom structs defined in types).
  • Account ordering — List accounts in accounts in exactly the order the program expects them. The names you give them will become the account_<name> columns in the decoded table.
  • Program name — Set name (or metadata.name) to match the program name you enter in the submission form. Use only letters, numbers, and underscores.
If the program is open source, the canonical reference is the instruction enum and its Pack/BorshDeserialize implementations in the Rust source. If source is unavailable, transaction data on Solscan or Explorer can help you reverse-engineer the instruction layout.

​
IDL requirements

Your IDL is validated in the UI and server-side before approval. The following must hold:
  • Valid JSON — No trailing commas, valid escaping. Doc comments and errors arrays are stripped during validation.
  • Program name — Must be set (in metadata.name or top-level name) and contain only letters, numbers, and underscores (no hyphens).
  • Custom types — Every custom type referenced in instructions, accounts, or other types must be defined in the types array.
  • Instruction args — Only types that use borsh serialization are allowed in instruction arguments. Other serializations (e.g. bytemuck) are not supported for instruction decoding.
  • No generics — IDLs that use generic type definitions are not supported.
If the IDL fails validation, the submission will be rejected with a reason (e.g. invalid program name, missing type definition, or non-borsh type in instructions). The UI runs validation before submit and shows validation errors.

​
New vs upgrade submissions

  • New program — First time submitting this program (no existing entry for this project + program ID). In the UI, use submission type New. Provide the IDL and the slot range where it is valid.
  • Upgrade — The program is already decoded and you are adding a new IDL version (e.g. after a program upgrade). Use submission type Upgrade in the UI.
    • Soft upgrade: Your new start block slot is after the end of the current active entry (no overlap). These are approved automatically. The previous version is closed at end_slot = your start_slot, and the new version is added.
    • Hard upgrade: Your new start block slot overlaps with an existing version’s range. These are marked for manual review so the team can confirm slot boundaries and avoid conflicting decoding.
When in doubt, use the slot where the new program or IDL version actually became active on-chain. The in-app preview (e.g. min/max instruction calls, existing program entries) can help you choose slots.

​
Submission status and what happens next

After you submit:
  1. Pending — The submission is in the queue and will be validated (IDL checks, upgrade logic).
  2. Approved — Validation passed. The submission is then processed and written to the decoding pipeline (solana.programs and related systems).
  3. Rejected — Validation failed (e.g. invalid IDL, empty required field). Check the rejection reason and fix the submission.
  4. Needs manual review — Typically a hard upgrade (overlapping slots). The team will review and either approve or reject.
  5. Processed — The program has been written to the pipeline. Decoded tables will appear and backfill; this can take some time (similar to EVM decoding latency).
Where to check status: Go to your workspace Contracts page or Settings → Contracts.

​
Decoded table naming and usage

Once processed, decoded instructions appear as tables named: 
{namespace}_solana.{programName}_call_{instructionName}
Example: whirlpool_solana.whirlpool_call_initializePool. Columns include the decoded instruction arguments and account arguments (with a call_ prefix for inherited fields like call_tx_id, call_block_time). For details and examples, see Solana IDL decoded tables.

​
Summary

TopicDetail
Submitdune.com/contracts/new → select Solana → fill the form.
FieldsProgram ID, project name, program name, program type (Anchor/Native/System), IDL, start (and optional end) block slot.
IDLValid JSON, program name (letters/numbers/underscores), all custom types in types, borsh-only in instruction args, no generics.
UpgradesSoft (no slot overlap) → auto-approved; hard (overlap) → manual review.
After approvalEntry is processed and written to the pipeline; decoded tables appear under {namespace}_solana with some delay.
For more on querying decoded Solana data, see IDL decoded tables. For EVM contract decoding, see How contract decoding works.