SIMD-406: Limit number of accounts in an instruction by LucasSte · Pull Request #10223 · anza-xyz/agave

LucasSte · 2026-01-27T19:40:40Z

Problem

Currently, there is no restriction on how many accounts an instruction may reference. Even though transactions may be limited to 256 account keys, an instruction may reference up to u16::MAX keys with duplicates. In SIMD-406, we proposed restricting the number of accounts an instruction may reference to 255 to remove complexity from runtime.

It was decided that such a check belongs in message sanitization, and the implementation fitted best in the validator code rather than the SDK (see anza-xyz/solana-sdk#520 (comment)).

The check only affects transactions v0 and legacy. Moreover, it will only impact top-level instructions that invoke native programs and pre-compiles, since the runtime serialization cannot serialize more than 255 accounts and will already throw an error for that case.

Summary of Changes

Create a feature gate.
Add the check to fn RuntimeTransaction<SanitizedTransaction>::try_create in sdk_transactions.rs.
Add the check to fn sanitize_instructions in sanitize.rs.
Fix affected code.
Created two tests: one in sanitize.rs and the other one in bank/tests.rs.

mergify · 2026-01-27T19:41:16Z

If this PR represents a change to the public RPC API:

Make sure it includes a complementary update to rpc-client/ (example)
Open a follow-up PR to update the JavaScript client @solana/kit (example)

Thank you for keeping the RPC clients in sync with the server API @LucasSte.

codecov-commenter · 2026-01-27T20:34:04Z

Codecov Report

❌ Patch coverage is 94.22222% with 13 lines in your changes missing coverage. Please review.
✅ Project coverage is 82.8%. Comparing base (d8724e9) to head (5438454).
⚠️ Report is 489 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff            @@
##           master   #10223    +/-   ##
========================================
  Coverage    82.8%    82.8%            
========================================
  Files         848      848            
  Lines      321446   321688   +242     
========================================
+ Hits       266394   266608   +214     
- Misses      55052    55080    +28

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

buffalojoec · 2026-01-28T08:15:28Z

+
+        if enable_instruction_account_limit {
+            for instr in tx.message.instructions() {
+                if instr.accounts.len() > solana_transaction_context::MAX_ACCOUNTS_PER_INSTRUCTION {
+                    return Err(solana_transaction_error::TransactionError::SanitizeFailure);
+                }
+            }
+        }
+


To me this looks like the right place for this check, but the SIMD does say it will throw SanitizeError::ValueOutOfBounds.

Maybe we just need to update the proposal?

this is an internal type and error, it's not reported to users in any way; irrelevant for the SIMD since the error type is entirely different.

Likely that error should be reported by the actual SDK changes, right?

We wanted to avoid making a breaking change to the SDK sanitization API so that's why the sanitization check is here. When the feature is activated, the check can be moved into the SDK and return the ValueOutOfBounds error.

Maybe we just need to update the proposal?

If this PR is merged, I can amend the SIMD by either removing the error type at all or updating it.

If this PR is merged, I can amend the SIMD by either removing the error type at all or updating it.

Yeah, this is what I was thinking, maybe just take the variant name out of the proposal.

buffalojoec · 2026-01-28T08:20:30Z

+#[test_case(false; "pre_simd406_limit_instruction_accounts")]
+#[test_case(true; "simd406_limit_instruction_accounts")]
+fn test_verify_transactions_accounts_limit(simd_406_enabled: bool) {


Wouldn't you rather test this in runtime-transaction/src/runtime_transaction/sdk_transactions.rs? You're asserting the same error and it's only bubbling its way up to your bank caller.

Instead, you can just get rid of a lot of this setup and test the functionality directly.

Also, do you think you could add a test that ensures exactly 255 is allowed?

I like this test because all replay verification goes through Bank::verify_transaction so it's a nice place for a sanity check. But I agree that unit tests in sdk_transactions.rs should be added as well.

buffalojoec · 2026-01-28T08:42:07Z

+                    // Vote instructions are created in the validator code, and they are not
+                    // referencing more than 255 accounts, so it is safe to set this to true.
+                    true,


Even though true is the correct choice here, I think the comment is misleading.

Sure, Vote instructions are typically created by validator software, but there's nothing that says they have to be. The simple vote transaction filtering doesn't know where the transaction originated and it also doesn't enforce a specific number of accounts. For the latter reason, though, true is the right setting here.

it also doesn't enforce a specific number of accounts.

I didn't follow. If it does not enforce a specific number of accounts, then, theoretically, it could receive instructions with more than 255 accounts, right?

That's correct. If someone crafted a "simple vote" transaction on their own, outside validator software, they could include > 255 accounts and it would still be filtered as a simple vote transaction. This is why I said using true is correct.

Your comment says that the transactions are created in the validator code, but that's not guaranteed.

What about changing the comment to "Vote instructions do not need more than 255 accounts, and the vote transaction filtering does not enforce that, so enforcing the constraint here is right" ?

apfitzge · 2026-01-28T20:09:29Z

    enable_static_instruction_limit: bool,
+    enable_instruction_accounts_limit: bool,


might consider adding a struct here: SanitizationFeatures or something with these bools on it. Rather than we continue to add more and more bools which are easily confused with order. wdyt?

apfitzge

Commenting as a quick note; TxV1 automatically supports this feature because the new format directly uses a u8 for the number of accounts in top-level instructions.

topointon-jump · 2026-01-28T22:01:37Z

It would be awesome if we could get this into the 4.0 release 🙌

jstarry · 2026-01-29T01:40:58Z

+
+        if enable_instruction_account_limit {
+            for instr in tx.message.instructions() {
+                if instr.accounts.len() > solana_transaction_context::MAX_ACCOUNTS_PER_INSTRUCTION {
+                    return Err(solana_transaction_error::TransactionError::SanitizeFailure);
+                }
+            }
+        }
+


We wanted to avoid making a breaking change to the SDK sanitization API so that's why the sanitization check is here. When the feature is activated, the check can be moved into the SDK and return the ValueOutOfBounds error.

jstarry · 2026-01-29T01:52:58Z

+#[test_case(false; "pre_simd406_limit_instruction_accounts")]
+#[test_case(true; "simd406_limit_instruction_accounts")]
+fn test_verify_transactions_accounts_limit(simd_406_enabled: bool) {


I like this test because all replay verification goes through Bank::verify_transaction so it's a nice place for a sanity check. But I agree that unit tests in sdk_transactions.rs should be added as well.

buffalojoec

Lgtm

LucasSte force-pushed the simd-406-1 branch from b8cc2bd to 97a4b2f Compare January 27, 2026 19:42

LucasSte requested review from Lichtso, apfitzge, buffalojoec, jstarry and tao-stones January 27, 2026 22:41

LucasSte marked this pull request as ready for review January 27, 2026 22:41

LucasSte requested a review from a team as a code owner January 27, 2026 22:41

buffalojoec reviewed Jan 28, 2026

View reviewed changes

apfitzge reviewed Jan 28, 2026

View reviewed changes

topointon-jump mentioned this pull request Jan 28, 2026

flamenco, vote: fix signer checks for transactions with large number of instruction accounts firedancer-io/firedancer#8073

Merged

jstarry reviewed Jan 29, 2026

View reviewed changes

LucasSte added 2 commits January 29, 2026 18:42

Implement SIMD-406

607efeb

Justin's feedback

5438454

LucasSte force-pushed the simd-406-1 branch from 97a4b2f to 5438454 Compare January 29, 2026 22:52

buffalojoec approved these changes Jan 30, 2026

View reviewed changes

jstarry approved these changes Jan 30, 2026

View reviewed changes

apfitzge approved these changes Jan 30, 2026

View reviewed changes

LucasSte added this pull request to the merge queue Feb 2, 2026

Merged via the queue into anza-xyz:master with commit a4cbc6b Feb 2, 2026
50 checks passed

LucasSte deleted the simd-406-1 branch February 2, 2026 15:19

This was referenced Feb 2, 2026

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

Closed

Update SIMD-406 solana-foundation/solana-improvement-documents#463

Merged

		enable_static_instruction_limit: bool,
		enable_instruction_accounts_limit: bool,

Conversation

LucasSte commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Summary of Changes

Uh oh!

mergify Bot commented Jan 27, 2026

Uh oh!

codecov-commenter commented Jan 27, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Codecov Report

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!

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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

apfitzge left a comment

Choose a reason for hiding this comment

Uh oh!

topointon-jump commented Jan 28, 2026

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

buffalojoec left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

LucasSte commented Jan 27, 2026 •

edited

Loading

codecov-commenter commented Jan 27, 2026 •

edited

Loading