SIMD-0568: Deprecate Precompiles by Lichtso · Pull Request #568 · solana-foundation/solana-improvement-documents

Lichtso · 2026-06-17T20:42:47Z

In a discussion on Discord ¹ consensus was reached to proceed with option
4 "Drop protocol-owned verifiers entirely and let normal programs handle this".

https://discord.com/channels/428295358100013066/1164657208613683280/1516459607726358672 ↩

simd-bot · 2026-06-17T20:42:50Z

Hello Lichtso! 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, steviez, or bw-solana
At least one approval from an Firedancer team member: ptaffet-jump, topointon-jump, 0x0ece, lidatong, ripatel-fd, or rexicon226

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

buffalojoec · 2026-06-18T00:47:08Z

+## Impact
+
+The community will have to develop their own on-chain replacements.
+However, this is also an opportunity as solutions using crypto syscalls can be
+cheaper compared to the lamports charged for signature verification at the
+transaction level.


I think this SIMD should do the community a service and describe how the three verification methods can be completely replaced by on-chain syscalls. It should be self-evident in the proposal that alternatives are available, working, and reasonable.

Sounds good, question is just what level of detail is appropriate here:

only mention the specific syscalls

provide some pseudo code

link actual reference implementations

IMO just list the syscalls they can use to perform the same signature verification as the precompiles. That's probably enough.

We just also need to make sure they actually are available, working, and reasonable (CUs) 😅

All good here once we get secp256r1 curve ops syscalls imo.

buffalojoec · 2026-06-18T00:48:49Z

+After the activation of the feature gate every instruction attempting to invoke
+any of the following programs must fail with
+`InstructionError::UnsupportedProgramId`:


Is there a reason why we're doing all three in one feature gate? I suppose it doesn't really matter much, but curious what the rationale is.

We already are hitting feature gate activation queue capacity with our policy of one activation per epoch. Also, these three are related, it makes sense to disable them simultaneously.

I think the best rationale is that we can deprecate all 3 from fee calculation at the same time which is much less invasive than changing it 3 times.

buffalojoec · 2026-06-18T13:52:24Z

+After the activation of the feature gate:

-The three program accounts will continue to exist and be owned by the native
-loader (`NativeLoader1111111111111111111111111111111`) thus they will continue
-to count as programs during transaction loading and only be filtered out during
-instruction execution.
+- Every transaction invoking them with top-level instructions must
+throw `TransactionError::InvalidProgramForExecution` during transaction
+loading time.
+- Every instruction invoking them with in CPI must
+throw `InstructionError::UnsupportedProgramId` instead of
+`CpiError::ProgramNotSupported` as they currently do.


One more bullet for "these will no longer be reserved account keys"?
#568 (comment)

Why do we need to say what error will occur when invoking them? Why not simply say we're unloading the programs and let the VM respond with its normal behavior?

TransactionError::InvalidProgramForExecution happens as a natural consequence of deleting the accounts, yes. Mentioning it here explicitly makes it easier to write conformance tests, that is all.

The transition from CpiError::ProgramNotSupported to InstructionError::UnsupportedProgramId in CPI (to bring it in line with other non existing programs) is an actual change in the code because right now precompiles get special handling in CPI.

Right, my point is, we are not implementing anything to create this error message, we are simply removing the implementation of CpiError, resulting in the default error message for a non-existent program. That's why I don't think it makes sense to write it here, as it sounds like we're adding some functionality to cause this error message to appear instead of the existing one.

You at least want to call out the TransactionError, since it will be a load-error and thus a fees-only transaction, which is protocol. However, I agree, the instruction error code specifically doesn't need to be enshrined, and could just get detailed under the conformance/fixtures section towards the end of the newer template.

The SIMD is to document what changes must be made to the protocol. If unloading the program results in the default VM/Runtime error behavior for a program that doesn't exist, we are not making it do that, we are removing the condition that causes it to not do that today. Making statements like: "Invoking these programs must return such and such error", it implies we're adding some kind of behavior to make this the case, which is the exact opposite of what we're doing here. I think if you want to explicitly mention what would happen when invoking these programs after they're removed, you can throw that into the backwards compatibility section.

I will move it to the "Conformance" section as it is mostly relevant to testing.

deanmlittle · 2026-06-24T12:53:28Z

+## Motivation
+
+Precompiles are rigid, require special handling in validator implementations
+and their cross instruction referencing (in ed25519) is hacky.


All 3 precompiles do cross-instruction referencing.

Suggested change

and their cross instruction referencing (in ed25519) is hacky.

and their inter-instruction data referencing is hacky.

deanmlittle · 2026-06-24T12:54:16Z

+
+### Migrating them to core programs on-chain
+
+The ed25519 one requires top-level instruction introspection, which is not


Same as above, all 3 do this, not just Ed25519.

deanmlittle · 2026-06-24T13:01:18Z

+of the three precompiles before and after the feature activation, at top level
+and in CPI.
+
+The excpected results **before** the feature activation are:


Suggested change

The excpected results **before** the feature activation are:

The expected results **before** the feature activation are:

deanmlittle · 2026-06-24T13:08:11Z

+The change will be tested by twelve transactions, each transaction calling one
+of the three precompiles before and after the feature activation, at top level
+and in CPI.
+
+The excpected results **before** the feature activation are:
+
+- at top level: success
+- in CPI: `CpiError::ProgramNotSupported`
+
+The excpected results **after** the feature activation are:
+
+- at top level: `TransactionError::InvalidProgramForExecution`
+- in CPI: `InstructionError::UnsupportedProgramId`


I am assuming by 12 transactions, you meant 3x:

Invoke pre-activation

CPI pre-activation

Invoke post-activation

CPI post-activation

I think you should be explicit about how you're invoking it, as different inputs could lead to a result other than the one you have written here. I would suggest to instead be explicit that we will:

Invoke with valid signature pre-activation

Invoke with invalid signature pre-activation

CPI with valid signature pre-activation

Invoke with valid signature post-activation

Invoke with invalid signature post-activation

CPI with valid signature post-activation

simd-bot · 2026-08-24T00:01:12Z

Hey @Lichtso, this PR has been inactive for 60 days and is now marked as stale.

If you're still working on this, please comment below to let us know. Otherwise, this PR will be automatically closed in 7 days.

To keep this PR active, simply leave a comment explaining the current status or any blockers you're facing.

Lichtso · 2026-08-28T18:39:37Z

@deanmlittle I think I addressed everything, can you give it another review?

simd-bot · 2026-08-28T18:39:40Z

Thanks for the update, @Lichtso! The stale label has been removed. This PR will no longer be automatically closed.

deanmlittle · 2026-08-29T15:45:48Z

+The expected results **after** the feature activation are:
+
+- at top level with a valid signature:
+`TransactionError::InvalidProgramForExecution`


is this correct? seems odd that the error would change based upon program inputs for an invalid program

deanmlittle · 2026-08-29T15:53:04Z

+
+### Migrating them to core programs on-chain
+
+Precompiles can use top-level instruction introspection, which is not available


I found the wording here a little confusing as it feels like it conflates instrospection from the instructions sysvar account and how it actually accesses it from the TransactionContext. Consider making this clear by saying something like:

"As they are built into the runtime, precompiles have the ability to access instruction data from other instructions from TransactionContext without having to use the SysvarInstructions account. Replicating this in a Core BPF program requires breaking changes, either to the API, or by adding this functionality to the SVM."

deanmlittle · 2026-08-29T15:54:35Z

@deanmlittle I think I addressed everything, can you give it another review?

Sure. Just a few nits. Looks pretty good overall!

Lichtso changed the title ~~Deprecate Precompiles~~ SIMD-0568: Deprecate Precompiles Jun 17, 2026

Initial draft

97b66e7

Lichtso force-pushed the deprecate-precompiles branch from a89775d to 97b66e7 Compare June 17, 2026 20:45

buffalojoec reviewed Jun 18, 2026

View reviewed changes

Lichtso added 2 commits June 18, 2026 13:13

Review feedback by @buffalojoec

3455d79

Review feedback by @deanmlittle

69d6837

buffalojoec reviewed Jun 18, 2026

View reviewed changes

github-actions Bot mentioned this pull request Jun 22, 2026

Upstream Updates - Mon Jun 22 00:50:20 UTC 2026 smartcontractkit/chainlink-solana#1575

Open

Lichtso mentioned this pull request Jun 22, 2026

simulateTransaction enforces precompile signature verification, breaking simulation for unsigned transactions anza-xyz/agave#13252

Open

Moves error codes from "Detailed Design" to "Conformance".

fe58ca8

deanmlittle reviewed Jun 24, 2026

View reviewed changes

simd-bot Bot added the stale Inactive PR - will be closed if no response label Aug 24, 2026

Review feedback by @deanmlittle

019d7ab

simd-bot Bot removed the stale Inactive PR - will be closed if no response label Aug 28, 2026

Lichtso requested a review from deanmlittle August 28, 2026 18:39

deanmlittle reviewed Aug 29, 2026

View reviewed changes

	and their cross instruction referencing (in ed25519) is hacky.
	and their inter-instruction data referencing is hacky.


		### Migrating them to core programs on-chain

		The ed25519 one requires top-level instruction introspection, which is not

	The excpected results before the feature activation are:
	The expected results before the feature activation are:


		### Migrating them to core programs on-chain

		Precompiles can use top-level instruction introspection, which is not available

Uh oh!

Conversation

Lichtso commented Jun 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Footnotes

Uh oh!

simd-bot Bot commented Jun 17, 2026

Uh oh!

Uh oh!

Uh oh!

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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lichtso Jun 18, 2026 • 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!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Lichtso Jun 19, 2026 • 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!

deanmlittle Jun 19, 2026 • 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!

deanmlittle Jun 20, 2026 • 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!

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!

simd-bot Bot commented Aug 24, 2026

Uh oh!

Lichtso commented Aug 28, 2026

Uh oh!

simd-bot Bot commented Aug 28, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deanmlittle commented Aug 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Lichtso commented Jun 17, 2026 •

edited

Loading

Lichtso Jun 18, 2026 •

edited

Loading

Lichtso Jun 19, 2026 •

edited

Loading

deanmlittle Jun 19, 2026 •

edited

Loading

deanmlittle Jun 20, 2026 •

edited

Loading