Skip to main content
Technical proposal SIMD-0406 Review

Maximum instruction accounts

  1. Idea
  2. Draft
  3. Review
  4. Accept
  5. Implement
  6. Active

Decision brief

Why this proposal matters

This SIMD imposes a hard restriction on the maximum number of account references that an instruction may declare. There is already a limit of 255 account references imposed during serialization in ABI v0 and v1, but it does not currently apply to builtin invocations or precompiles.

Source-backed reading aid · source language: EN

Proposal at a glance

What changes

  • A new verification step must be included in message sanitization for message formats legacy and v0. The verification step must examine every instruction in a transaction, check if the former references more than 255 accounts, and throw an error otherwise. Transactions violating such a restriction must be considered invalid and not included in a block.…
  • This SIMD imposes a hard restriction on the maximum number of account references that an instruction may declare. There is already a limit of 255 account references imposed during serialization in ABI v0 and v1, but it does not currently apply to builtin invocations or precompiles.

Stakeholder map

Who is affected

Builders & client teams Medium impact

Calls to user deployed programs from top level instructions and CPIs will not be impacted, since there is already a limit in place.

Action requirement unknown
Validators & operators Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown
Users & stakers Medium impact

Calls to user deployed programs from top level instructions and CPIs will not be impacted, since there is already a limit in place.

Action requirement unknown
Governance & ecosystem Impact unknown

No proposal-specific evidence was found for this group.

Action requirement unknown

Exact source revision

Full proposal document

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

Summary

This SIMD imposes a hard restriction on the maximum number of account references that an instruction may declare. There is already a limit of 255 account references imposed during serialization in ABI v0 and v1, but it does not currently apply to builtin invocations or precompiles.

Motivation

Although there can only be a maximum of 35 account keys in the legacy message format and 256 in the v0 format, instructions can have up to 65535 (u16::MAX) accounts, each being a u8 index referencing a transaction account.

Allowing instructions to reference more accounts than what the message format allows is not necessary. On one hand there is a limit of 255 accounts for CPI and user deployed programs, on the other, builtins and precompiles do not need as many accounts as the message format allows.

Furthermore, since there can only be 256 unique pubkeys in a transaction, any instruction referencing more than 256 will have aliased references, requiring the validator to deduplicate them, even though they are unused.

New Terminology

None.

Detailed Design

A new verification step must be included in message sanitization for message formats legacy and v0. The verification step must examine every instruction in a transaction, check if the former references more than 255 accounts, and throw an error otherwise. Transactions violating such a restriction must be considered invalid and not included in a block. Likewise, blocks containing transactions that violate such condition should be declared dead.

Transactions in the v1 format (SIMD-0385) already have a limit of 255 accounts per instruction, so this change and the accompanying feature gate do not affect such newer format.

Alternatives Considered

None.

Impact

Calls to user deployed programs from top level instructions and CPIs will not be impacted, since there is already a limit in place.

Instructions that invoke builtin programs or precompiles will error out if they have more than 255 accounts.

Security Considerations

None.

Evidence graph

Related proposals and rollout

One or more sources are unavailable.

Upstream review record

Upstream discussion & review

No verified upstream discussion was found. simd.watch does not invent a discussion link.

simd.watch community discussion · SIMD-0406

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 lifecycleReview
CategoryCore protocol
Devnetinactive
Testnetinactive
Mainnet-Betainactive
DqbnFPASg7tHmZ6qfpdrt2M6MWoSeiicWPXxPhxqFCQ

Exact source revision

Sources & integrity

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

One or more sources are unavailable.