SIMD-406: Restrict the number of accounts in an instruction by LucasSte · Pull Request #406 · solana-foundation/solana-improvement-documents

LucasSte · 2025-11-19T18:07:57Z

No description provided.

simd-bot · 2025-11-19T18:07:59Z

Hello @LucasSte! Welcome to the SIMD process. By opening this PR you are affirming that your SIMD has been thoroughly discussed and vetted in the SIMD discussion section. The SIMD PR section should only be used to submit a final technical specification for review. If your design / idea still needs discussion, please close this PR and create a new discussion here.

This PR requires the following approvals before it can be merged:

At least one approval from a Anza team member: @t-nelson, @sakridge, or @bw-solana
At least one approval from an Firedancer team member: @ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, or @ripatel-fd

Once all requirements are met, you can merge this PR by commenting /merge.

simd-bot · 2025-11-19T18:18:31Z

Thanks, @Lichtso!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)
Missing approval from: Firedancer (@ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, @ripatel-fd)

simd-bot · 2025-11-19T18:30:10Z

Thanks, @mjain-jump!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)
Missing approval from: Firedancer (@ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, @ripatel-fd)

ptaffet-jump · 2025-11-19T19:13:40Z

Can you clarify what happens if there are exactly 256 accounts?

both user deployed programs and CPIs only allow 255 accounts

vs.

if it references more than 256 accounts, and must throw
`InstructionError::MaxAccountsExceeded

t-nelson · 2025-11-19T19:52:06Z

+accounts, each being a `u8` index referencing a transaction account.
+
+Allowing instructions to reference more accounts than those contained in the 
+transaction is pointless, because it entails some accounts will be aliased, 


pointless

is it? instruction account references map to roles as defined by that instruction. multiple roles may reasonably be filled by the same account

restricting instruction account references to a unique set would force role mapping on chain, either statically in the program or dynamically via instruction data. the latter would cost addition transaction byte bloat, both would incur additional cu cost and risk of error

this seems like a naive motivation

My wording there might have been imprecise. What I wanted to say is that allowing instructions to reference more accounts than the number of pubkeys the message format allows (256) is not reasonable.

The argument for that is: for what the protocol offers today, that is not necessary. On one side, there is a hard limit of 255 for CPI and programs. On the other, builtins and precompiles don't use that many.

We will continue to allow account aliasing and instructions referencing more accounts than the number of pubkeys in a transaction, provided that you are not overusing the message format.

I rewrote the motivation in 9ce30cb

t-nelson · 2025-11-19T19:58:49Z

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


Suggested change

This SIMD imposes a hard restriction on the maximum number of accounts an

instruction may refer to. There is already a limit of 255 accounts during

serialization in ABI v0 and v1, but it does not apply to builtin invocations

or precompiles.

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 rederences imposed during serialization in ABI v0 and v1,

but it does not current apply to builtin invocations or precompiles.

LucasSte · 2025-11-19T20:42:56Z

Can you clarify what happens if there are exactly 256 accounts?

both user deployed programs and CPIs only allow 255 accounts

vs.

if it references more than 256 accounts, and must throw
`InstructionError::MaxAccountsExceeded

Good point. We can keep erroring out at 255 for programs and CPI, or we can increase the serialization limit to 256. Any thoughts @Lichtso?

Lichtso · 2025-11-19T21:17:47Z

Limit should be u8::MAX meaning 255, not 256 in all paths / cases.

simd-bot · 2025-11-20T01:16:00Z

Thanks, @cmoyes-jump!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)
Missing approval from: Firedancer (@ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, @ripatel-fd)

LucasSte · 2025-11-20T16:49:14Z

I addressed all the feedback in the previous three commits, including the reduction of the limit to 255.

simd-bot · 2025-11-20T20:50:50Z

Thanks, @Lichtso!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)
Missing approval from: Firedancer (@ptaffet-jump, @topointon-jump, @0x0ece, @lidatong, @ripatel-fd)

simd-bot · 2025-11-20T21:36:10Z

Thanks, @topointon-jump!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (@t-nelson, @sakridge, @bw-solana)

buffalojoec · 2025-11-21T04:48:00Z

+For every instruction that goes through program runtime (CPI, user deployed 
+program invocation, builtin invocation or precompiles), program runtime must 
+check if it references more than 255 accounts, and must throw 
+`InstructionError::MaxAccountsExceeded` when that is the case.


Where should this check occur exactly? When should it throw? Ideally as early as possible.

Yeah agreed. I think that in addition to the program runtime restriction, we should also add a sanitization check for the number of accounts passed to top-level instructions.

Where should this check occur exactly? When should it throw?

The exact position I was thinking is in prepare_next_instruction and prepare_next_top_level_instruction. I did not detail the function names since this is Agave specific. I'll write down "right before account deduplication" as an alternative.

we should also add a sanitization check for the number of accounts passed to top-level instructions.

Yes, I also had that idea, but thought it would difficult to pass down a boolean through the sanitization trait we have. Since everyone also believes in that being useful, I am going to update the SIMD with that requirement.

we should also add a sanitization check for the number of accounts passed to top-level instructions.

On a second thought, transaction sanitization is used in far too many places throughout the mono repo. It is going to be time consuming to get everything right there. Do you think the additional check is still worth it?

I mentioned where the check happens in 959ecc3.

I didn't yet write about sanitization, because I'm waiting for your opinion on that.

Just so I can compile all feedback and amend the SIMD, are we going to place the check in both runtime and sanitization?

If we throw in sanitization then the runtime check becomes unreachable. So, for the SIMD it is either or. Specifying both is inconsistent / self conflicting.

Regarding the implementation in Agave, the check in the program-runtime is easier to do, since we already have the feature gating infrastructure in place. Implementing it in sanitization involves more code changes throughout the monorepo.

I see people weighing on both approaches, but I still did not understood if one is preferable over the other. Does anyone have any strong reason for the check not to be in runtime?

I'm happy to change if that is the case, but for simplicity my preference would be runtime.

Looks like we have most people agreeing on adding a protocol error for transactions which use too many accounts in an instruction. If you need some additional convincing, v1 Transactions will have a sanitization limit of 255 accounts per instructions, so I think it makes sense to limit ix accounts in legacy and v0 transactions in the same way. I think the Agave implementation should be fine, we can discuss later if you want.

Thanks for the feedback. I updated the SIMD to use only a check during sanitization. The latest version is in 5bc845a.

buffalojoec · 2025-11-25T05:19:46Z

+For every instruction that goes through program runtime (CPI, user deployed 
+program invocation, builtin invocation or precompiles), program runtime must 
+check if it references more than 255 accounts, and must throw 
+`InstructionError::MaxAccountsExceeded` when that is the case.


did not detail the function names since this is Agave specific. I'll write down "right before account deduplication" as an alternative.

I think this is as close as we can get without a spec. 😅

Maybe FD can help us clear up the exact location/timing of this check - @mjain-jump @topointon-jump ? The most important piece is specifying which errors this should eclipse and which ones it should not.

Co-authored-by: Joe C <jcaulfield135@gmail.com>

simd-bot · 2025-12-01T19:37:54Z

Thanks, topointon-jump!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)

simd-bot · 2025-12-04T15:51:53Z

Thanks, topointon-jump!

⚠️ Status: Cannot merge yet

Missing approval from: Anza (t-nelson, sakridge, or bw-solana)

jstarry · 2025-12-04T15:57:03Z

+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 `SanitizationError::ValueOutOfBounds` otherwise. Transactions violating 


We don't need to specify the error here, it's an implementation detail. It's enough to say that the transaction and any block including this transaction will be rejected.

While the specific error code is not part of consensus it is still good to specify it for fuzzing between validator implementations. At least that is how we handled it in other SIMDs.

topointon-jump · 2026-01-05T23:30:42Z

@LucasSte shall we merge this?

topointon-jump · 2026-01-05T23:31:00Z

@bw-solana mind taking a look?

bw-solana · 2026-01-06T01:58:26Z

+A new verification step must be included in message sanitization for message 
+formats legacy and v0. The verification step must examine every instruction in 


how about the new Transaction v1 format?

The new transaction v1 format also specifies this limit, so this applies to all transaction formats. Definitely worth specifying 👍

The limit for v1 transactions won't be behind the feature gate implied by this SIMD. Is it worth specifying if that is the case?

Maybe just mention it for clarity?

I mentioned v1 transactions and dead blocks (from the following thread) in f600fbc

bw-solana · 2026-01-06T02:00:29Z

+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 `SanitizationError::ValueOutOfBounds` otherwise. Transactions violating 
+such a restriction must be considered invalid and not included in a block.


Should we mention that blocks should be declared dead if they include such transactions? Or is the block still good but the transaction does not execute?

Is this fine for bankless leader because we can perform static analysis and determine validity?

Should we mention that blocks should be declared dead if they include such transactions?

Yes we should mention this.

Is this fine for bankless leader because we can perform static analysis and determine validity?

Yes this is correct.

simd-bot · 2026-01-06T16:50:13Z

Thanks, bw-solana!

⚠️ Status: Cannot merge yet

Missing approval from: Firedancer (ptaffet-jump, topointon-jump, 0x0ece, lidatong, or ripatel-fd)

simd-bot · 2026-01-06T17:09:30Z

✅ All approvals received! @LucasSte, you can now merge this by commenting /merge.

✅ Status: Ready to merge

LucasSte · 2026-01-06T17:46:05Z

/merge

simd-bot · 2026-01-06T17:46:10Z

✅ Merge successful! LucasSte's PR has been merged.

LucasSte changed the title ~~Restrict the number of accounts in an instruction~~ SIMD-406: Restrict the number of accounts in an instruction Nov 19, 2025

LucasSte force-pushed the max-accounts branch 3 times, most recently from 05b895f to d01e14b Compare November 19, 2025 18:11

Restrict the number of accounts in an instruction

6fe01cb

LucasSte force-pushed the max-accounts branch from d01e14b to 6fe01cb Compare November 19, 2025 18:12

Lichtso approved these changes Nov 19, 2025

View reviewed changes

mjain-jump approved these changes Nov 19, 2025

View reviewed changes

t-nelson reviewed Nov 19, 2025

View reviewed changes

cmoyes-jump approved these changes Nov 20, 2025

View reviewed changes

jstarry reviewed Nov 20, 2025

View reviewed changes

Comment thread proposals/0406-maximum-instruction-accounts.md Outdated

LucasSte added 3 commits November 20, 2025 13:40

Trent's feedback

96dec4e

Change limit to 255

8e7a4ae

Rewrite motivation

9ce30cb

Lichtso approved these changes Nov 20, 2025

View reviewed changes

topointon-jump previously approved these changes Nov 20, 2025

View reviewed changes

Lichtso requested a review from t-nelson November 20, 2025 21:47

buffalojoec reviewed Nov 21, 2025

View reviewed changes

Specify where the check happens

959ecc3

LucasSte dismissed topointon-jump’s stale review via 959ecc3 November 21, 2025 16:47

buffalojoec reviewed Nov 25, 2025

View reviewed changes

Update proposals/0406-maximum-instruction-accounts.md

9ac1694

Co-authored-by: Joe C <jcaulfield135@gmail.com>

topointon-jump previously approved these changes Dec 1, 2025

View reviewed changes

topointon-jump self-requested a review December 2, 2025 15:42

Use only a sanitization check

5bc845a

LucasSte dismissed topointon-jump’s stale review via 5bc845a December 4, 2025 14:26

topointon-jump previously approved these changes Dec 4, 2025

View reviewed changes

jstarry reviewed Dec 4, 2025

View reviewed changes

topointon-jump mentioned this pull request Dec 4, 2025

flamenco, runtime, vm: clean up bounds on the number of instruction accounts firedancer-io/firedancer#7553

Merged

jstarry approved these changes Dec 5, 2025

View reviewed changes

topointon-jump mentioned this pull request Dec 17, 2025

SIMD-0385: Transaction V1 Format #385

Merged

bw-solana reviewed Jan 6, 2026

View reviewed changes

Mention v1 transactions and dead blocks

f600fbc

LucasSte dismissed topointon-jump’s stale review via f600fbc January 6, 2026 16:48

bw-solana approved these changes Jan 6, 2026

View reviewed changes

topointon-jump approved these changes Jan 6, 2026

View reviewed changes

simd-bot Bot merged commit 68a2fac into solana-foundation:main Jan 6, 2026
2 checks passed

LucasSte mentioned this pull request Jan 8, 2026

SIMD-406: Restrict to 255 the number of accounts in instructions for transactions v0 and legacy anza-xyz/solana-sdk#520

Closed

github-actions Bot mentioned this pull request Jan 12, 2026

Upstream Updates - Mon Jan 12 00:19:11 UTC 2026 smartcontractkit/chainlink-solana#1414

Open

LucasSte deleted the max-accounts branch January 27, 2026 14:13

LucasSte mentioned this pull request Jan 27, 2026

SIMD-406: Limit number of accounts in an instruction anza-xyz/agave#10223

Merged

github-actions Bot locked as resolved and limited conversation to collaborators Mar 30, 2026

		A new verification step must be included in message sanitization for message
		formats legacy and v0. The verification step must examine every instruction in

Conversation

LucasSte commented Nov 19, 2025

Uh oh!

simd-bot Bot commented Nov 19, 2025

Uh oh!

simd-bot Bot commented Nov 19, 2025

Uh oh!

simd-bot Bot commented Nov 19, 2025

Uh oh!

ptaffet-jump commented Nov 19, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LucasSte Nov 19, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LucasSte commented Nov 19, 2025

Uh oh!

Lichtso commented Nov 19, 2025

Uh oh!

simd-bot Bot commented Nov 20, 2025

Uh oh!

Uh oh!

LucasSte commented Nov 20, 2025

Uh oh!

simd-bot Bot commented Nov 20, 2025

Uh oh!

simd-bot Bot commented Nov 20, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LucasSte Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LucasSte Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

simd-bot Bot commented Dec 1, 2025

Uh oh!

simd-bot Bot commented Dec 4, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

topointon-jump commented Jan 5, 2026

Uh oh!

topointon-jump commented Jan 5, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

topointon-jump Jan 6, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

LucasSte Nov 19, 2025 •

edited

Loading

LucasSte Nov 21, 2025 •

edited

Loading

LucasSte Nov 21, 2025 •

edited

Loading

topointon-jump Jan 6, 2026 •

edited

Loading