> ## Documentation Index
> Fetch the complete documentation index at: https://docs.dune.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Solana Program Decoding Submissions

> How to submit Solana programs for IDL decoding on Dune — UI flow, requirements, IDL validation, new vs upgrade submissions, and what to expect.

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](https://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**.

<CardGroup cols={2}>
  <Card title="Submit a Solana program" icon="file-import" iconType="duotone" href="https://dune.com/contracts/new">
    Select Solana, then fill program address, type, names, slot range, and IDL.
  </Card>

  <Card title="Explore decoded Solana data" icon="table" iconType="duotone" href="/data-catalog/solana/idl-tables">
    Learn how decoded tables are named and how to query them.
  </Card>
</CardGroup>

# What you need to submit

| Field                         | Description                                                                                                                                                                                                                                        |
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Program ID**                | The Solana program address (base58). Entered in the "Search for decoding submission" address field.                                                                                                                                                |
| **Project name**              | The 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 name**              | The program name as given by the project (e.g. `JupiterV6`, `MarinadeFinance`). Must match the IDL program name.                                                                                                                                   |
| **Program type**              | **Anchor**, **Native**, or **System**. Determines how instruction data is decoded.                                                                                                                                                                 |
| **IDL**                       | Interface 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](https://solscan.io) (e.g. "Anchor Program IDL" tab) or from the project repo. |
| **Start block slot**          | The 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.                                                                                                                                     |

<Note>
  **Finding the IDL**

  * **Anchor programs:** Many expose the IDL on-chain. Use [Solscan](https://solscan.io) (e.g. [Jupiter](https://solscan.io/account/JUP4Fb2cqiRUcaTHdrPC8h2gNsA2ETXiPDD33WcGuJB#anchorProgramIDL)) 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.
</Note>

## 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](https://github.com/solana-idl-foundation/solana-idl-spec), 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](https://solscan.io) or [Explorer](https://explorer.solana.com) 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:

```text theme={null}
{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](/data-catalog/solana/idl-tables).

# Summary

| Topic              | Detail                                                                                                                            |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------- |
| **Submit**         | **[dune.com/contracts/new](https://dune.com/contracts/new)** → select Solana → fill the form.                                     |
| **Fields**         | Program ID, project name, program name, program type (Anchor/Native/System), IDL, start (and optional end) block slot.            |
| **IDL**            | Valid JSON, program name (letters/numbers/underscores), all custom types in `types`, borsh-only in instruction args, no generics. |
| **Upgrades**       | Soft (no slot overlap) → auto-approved; hard (overlap) → manual review.                                                           |
| **After approval** | Entry 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](/data-catalog/solana/idl-tables). For EVM contract decoding, see [How contract decoding works](/web-app/decoding/decoding-contracts).