Skip to content

SIMD-0433: Loader V3: Set Program Data to ELF Length #433

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
buffalojoec wants to merge 3 commits into
base: main
Choose a base branch
from
Open

SIMD-0433: Loader V3: Set Program Data to ELF Length #433

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b3578fc
SIMD-0433: Loader V3: Set Program Data to ELF Length
buffalojoec Dec 15, 2025
327c99d
Update proposals/0433-loader-v3-set-program-data-to-elf-length.md
buffalojoec Dec 18, 2025
1667bca
bidirectional resizing
buffalojoec Jan 14, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
69 changes: 69 additions & 0 deletions proposals/0433-loader-v3-set-program-data-to-elf-length.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,69 @@
---
simd: '0433'
title: 'Loader V3: Set Program Data to ELF Length'
authors:
- Joe Caulfield (Anza)
- Dean Little (Blueshift)
category: Standard
type: Core
status: Review
created: 2025-12-14
feature: (fill in with feature key and github tracking issues once accepted)
---

## Summary

This SIMD proposes changing the default behavior of program upgrades to resize
the program data account to the length of the ELF being deployed, refunding any
surplus lamports to a spill account.

## Motivation

Currently, Loader v3 program data accounts may be extended but cannot be
retracted. As program sizes decrease due to SDK improvements such as Pinocchio,
this limitation results in program data accounts remaining larger than
necessary, with no mechanism to reclaim the rent paid for unused bytes. This
unnecessarily increases rent costs and program loading overhead.

## New Terminology

No new terminology is introduced by this proposal.

## Detailed Design

The `Upgrade` instruction will be updated to automatically resize the program
data account to match the length of the ELF in the buffer being deployed.

If the new ELF is larger than the current program data account, the upgrade will
fail. The account must first be extended to at least the required size via the
`ExtendProgram` instruction.
Copy link
Contributor

@Lichtso Lichtso Jan 2, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How does this interact with #164? Or rather, why require an ExtendProgram instruction at all and not have that be automatic in Upgrade instead of failing if the account is too small? Obviously the required funds would still have to be deposited before hand.

Copy link
Contributor

@Lichtso Lichtso Jan 2, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIRC Breakpoint we discussed the alternative workflow in which programs which want to self upgrade to a larger ELF would reassign their authority to a TX fee payer temporarily, then upgrade at top-level (to avoid the 10 KiB CPI account growth limit of ABI v1) and reassign back to the original authority, all with the atomicity of a single TX.

Copy link
Contributor Author

@buffalojoec buffalojoec Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This proposal is just simply the lightest lift to solve the issue of excess space and lamports. It's trivial: existing workflows already resize the account to be large enough for the ELF, but there's no way to reclaim excess if you overshoot it.

If we want to go all the way we can. My main concern would be what happens to any existing workflows that use ExtendProgram. Would we continue to support the instruction, perhaps post-#431, so as to not break anyone's flows? Or, since #431 is already breaking, do we just close #431 and make all resizing part of the upgrade?

Copy link
Contributor

@Lichtso Lichtso Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we just close #431 and make all resizing part of the upgrade

That is what I was saying: "have that be automatic in Upgrade".

Copy link
Contributor Author

@buffalojoec buffalojoec Jan 6, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my opinion, we should keep this SIMD focused on addressing the core issue, which is the inability to reclaim lamports for an oversized programdata account. I don't think we should bloat the change with more complexity at this time. If we want to add another step to enable more automation within the upgrade workflow and move away from Extend*, it's pretty trivial to do so in the future. However, nobody has asked for this afaik.

IIRC Breakpoint we discussed the alternative workflow in which programs which want to self upgrade to a larger ELF would reassign their authority to a TX fee payer temporarily, then upgrade at top-level (to avoid the 10 KiB CPI account growth limit of ABI v1) and reassign back to the original authority, all with the atomicity of a single TX.

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade. If we bake in resizing, you'll still have to best-guess the new size anyway, in order to top up rent. Seems like a small marginal benefit overall IMO.

Copy link
Contributor

@Lichtso Lichtso Jan 6, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade.

This was not about guessing the size at all. It was about not being able to upgrade to larger programs in a single instruction, no matter if it is done in Extend or Upgrade, both are limited to +10 KiB in CPI of ABI v1.

Copy link
Contributor Author

@buffalojoec buffalojoec Jan 7, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds a little more hacky than it's worth just to avoid having to best-guess a size increase before running an upgrade.

This was not about guessing the size at all. It was about not being able to upgrade to larger programs in a single instruction, no matter if it is done in Extend or Upgrade, both are limited to +10 KiB in CPI of ABI v1.

I think you misunderstood my comment. I'm not implying you were describing the act of guessing the size. I'm saying the workflow you outlined would be required if we decided to handle both resizing events automatically via Upgrade. The goal of doing such a thing would be to avoid the extra step whereby developers must know their new program size ahead of time. My point is that - even if we get rid of ExtendProgram completely - devs will always have to know the new size of their program in order to top up rent, so the point is moot IMO.

Copy link
Contributor

@Lichtso Lichtso Jan 7, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, we are on the same page and I understood your comment as such: "even if we get rid of ExtendProgram completely - devs will always have to know the new size of their program in order to top up rent, so the point is moot IMO" agreed, and I did not bring it up as a reason.

The reasons (for handling the size changes in Upgrade) are:

  • To avoid having to deal with changes to ExtendProgram (such as SIMD-0431) which has been controversial in the past (see SIMD-0164).
  • To have both size increases and decreases handled in a unified matter, instead of having one be implicit and the other explicit.
  • To have only one instruction change the size, so that the CPI account size increase limit of ABI v1 only needs to be dealt with once per TX.

Copy link
Contributor Author

@buffalojoec buffalojoec Jan 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm willing to adjust the proposal to support bidirectional resizing, but I don't think we should eliminate ExtendProgram/ExtendProgramChecked in this proposal.

We should seek more opinions from stakeholders on the solution you described earlier in this thread - temporarily changing the authority to avoid the 10KiB CPI limit in ABI v1 - and route the feedback into SIMD-0431 or SIMD-0164.


If the new ELF is smaller than the current program data account, the account
will be retracted and surplus lamports will be refunded to the spill account.

This change will be a feature-gated behavioral change to the existing `Upgrade`
instruction.

## Alternatives Considered

An alternative approach would be to add a new `WithdrawExcessLamports`
instruction, similar to the instruction of the same name in the Token-2022
program. This would allow the program's upgrade authority to claim excess
lamports after the auto-resizing from `Upgrade`.

## Impact

This proposal results in a lower program footprint in Accounts DB, incentivizes
developers to upgrade to newer, more performant libraries and SDKs, and enables
the recovery of surplus lamports, including those accidentally sent to the
program data address.

## Security Considerations

N/A

## Backwards Compatibility

This change modifies an existing Loader v3 instruction and therefore requires a
feature gate for consensus safety. From an API and tooling perspective, the
change is backwards compatible.
Loading