Skip to main content
simd.watch GitHub · Solana RPC Proposals
⌘K SIMD repository
Technical proposal SIMD-0160 Accepted

Static Instruction Limit

by Andrew Fitzgerald (anza) Source updated Jul 25, 2025

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. Active
View proposal document ↗
⚠ 1 source or integrity warning(s). Review before acting. ⚠ 1 source observation(s) are not fresh. Each source keeps its own timestamp and status below.

Decision brief

Why this proposal matters

Transactions will fail execution in SVM if the transactions use more than 64 instructions, including CPI calls. This proposal is to make transactions that use more than 64 top-level instructions fail sanitization checks and be rejected by the network.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • Any transaction that has more than 64 top-level instructions cannot be included in a block. If a block contains a transaction with more than 64 top-level instructions, the block must be marked as invalid.
  • Transactions will fail execution in SVM if the transactions use more than 64 instructions, including CPI calls. This proposal is to make transactions that use more than 64 top-level instructions fail sanitization checks and be rejected by the network.

Stakeholder map

Who is affected

Builders & client teams Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Validators & operators Medium impact

Smaller upper bound on number of instructions can help performance of validator.

Action requirement unknown
Users & stakers Medium impact

Users are prevented from creating transactions that cannot be executed successfully.

Action requirement unknown
Governance & ecosystem Medium impact

Transactions will fail execution in SVM if the transactions use more than 64 instructions, including CPI calls. This proposal is to make transactions that use more than 64 top-level instructions fail sanitization checks and be rejected by the network.

Action requirement unknown

Exact source revision

Full proposal document

View proposal document ↗
Source-language document. Technical identifiers and evidence remain unchanged. 0616093b2952

Summary

Transactions will fail execution in SVM if the transactions use more than 64 instructions, including CPI calls. This proposal is to make transactions that use more than 64 top-level instructions fail sanitization checks and be rejected by the network.

Motivation

The current limit of 64 instructions is a runtime failure, and makes sense in the context of CPIs. It is bad user experience to allow creation and submission of transactions that have no chance of being executed successfully. Several other checks worst-case performance scales with the number of top-level instructions in a transaction, so limiting this number can help the worst-case performance.

Alternatives Considered

  • Do nothing.
  • Allow transactions with more than 64 top-level instructions to be included in blocks, but skip execution only taking fees.
    • Checking the number of top-level instructions in a transaction is a relatively cheap operation and can be done very early in the processing of a transaction, similar to the current check that the number of required signatures matches the number of signatures provided.
    • Additionally, if we still allow more than 64 top-level instructions in a transaction we would still need to parse all the instructions to determine the fee, so there is a performance benefit in strictly limiting the number of top-level instructions.

New Terminology

None.

Detailed Design

Any transaction that has more than 64 top-level instructions cannot be included in a block. If a block contains a transaction with more than 64 top-level instructions, the block must be marked as invalid.

Impact

  • Users are prevented from creating transactions that cannot be executed successfully.
  • Smaller upper bound on number of instructions can help performance of validator.

Security Considerations

  • Requires a feature-gate to enable the new limit.

Drawbacks (Optional)

  • Similar to the runtime check on number of instructions including CPI, logic is duplicated.
  • Can no longer collect fees from transactions that are rejected due to new limit.

Backwards Compatibility (Optional)

  • Some transactions that are currently valid will be rejected.

Evidence graph

Related proposals and rollout

One or more sources are unavailable.

Upstream review record

Upstream discussion & review

GitHub review is editorial context, not evidence of on-chain support, voting, or outcome.

PR #160 · merged SIMD-0160: Static Instruction Limit 5 comments and reviews · Jan 19, 2026
@jstarry

Why not allow them to be included but limit processing to fee payer validation? So before we load the program cache, we check the instruction count and fail the transaction immediately if it exceeds the limit but still allow fee collection?

GitHub ↗
@apfitzge

I view it similarly to having the number of signatures not match the required signatures field in the header; its' a basic sanitization check that can be checked extremely cheaply. checking it does not scale with any aspects of the transaction such as number of instructions, number of account lookup tables, etc.

GitHub ↗
@jstarry

So long as we do it really early then I'm fine with prohibiting such transactions from being included. Can you write up a brief summary of this comment thread in the alternatives section?

GitHub ↗
@apfitzge

4398665f2ae72df927fd532effcb6b145903700a

GitHub ↗
@apfitzge

@Benhawkins18 can we merge this? we have approval from both FD and Anza teams

GitHub ↗

simd.watch community discussion · SIMD-0160

Powered by Giscus · Sign in with GitHub to comment

Community comments load when this section approaches the viewport.

Provenance

Evidence & technical details

Rollout or chain data, source revisions, freshness and integrity.
2

SIMD

Deployment Status

Document lifecycleAccepted
CategoryCore protocol

Feature Gate not yet created

Exact source revision

Sources & integrity

  • Proposal document pinned_commit_blob
    0616093b2952ed6de52c4a27d66aadd11d48d4f9
  • simd-document document · stale · Sep 10, 2026
    0616093b2952ed6de52c4a27d66aadd11d48d4f9

One or more sources are unavailable.