RFC: Loader V3: Fix or Replace

[buffalojoec]

Loader V3: Fix or Replace

The Upgradeable Loader (Loader V3) has many known issues impacting validator
performance, runtime complexity, and developer experience. The purpose of this
RFC is to clearly define these problems and collect feedback to determine
whether Loader V3 should be repaired or replaced with a new design.

Two SIMDs authored by @Lichtso propose the replacement path. SIMD-0167 (Loader
V4) has accumulated substantial discussion, and SIMD-0315 (Loader V3 -> V4
Migration) remains contentious [1, 2]. Other contributors like @deanmlittle
have proposed the repair path instead [3].

This RFC aims to establish a final decision framework for addressing the Loader
V3 problem set. To that end, it includes a formal call for review with feedback
requested by a specified deadline.

This RFC does not prescribe the exact form of any fix. Instead, reviewers are
asked to assess whether a repair strategy is viable or whether a full
replacement is more appropriate. Specific technical proposals can be developed
in follow-up discussions.

Issues with Loader V3

This RFC describes six problem areas in the current Loader V3:

1. Account Indirection
2. Metadata and ELF Coupling
3. ELF Misalignment
4. Program Behavior Constraints
5. Lack of Proper Specification
6. Technical Debt

1. Account Indirection

Loader V3 programs use two accounts (Program and ProgramData), requiring an
extra lookup and validation step on every invocation.

// Program account.
struct Program {
    /// Address of the corresponding ProgramData account.
    programdata_address: Pubkey,
}

// ProgramData account
struct ProgramData {
    /// Slot when this program was last modified.
    slot: u64,
    /// Optional authority that can upgrade the program.
    upgrade_authority_address: Option<Pubkey>,
    // ... Followed by program ELF bytes.
}

Why this is bad:

• Double account lookup on every invocation. Each program call requires loading
  the Program account, deserializing its state to extract the program data
  address, then loading the ProgramData account separately.
• Transaction loading complexity. The account loader must explicitly track and
  deduplicate ProgramData accounts to avoid double-counting toward transaction
  size limits, requiring a separate memory and branching logic.
• Repeated relationship validation in the loader program. Many loader
  instructions (upgrade, extend, etc.) must validate that the Program
  account's program data address matches the provided ProgramData account.
• Circumvents an obsolete constraint. The executable boolean flag on accounts
  will soon be removed [4, 5].

Additional Details

You can see here during program loading within the transaction processing
pipeline, Loader V3 programs require two account loads.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/svm/src/program_loader.rs#L83-L107

You can also see Loader V3 programs require the most special-casing during the
program loading stage, including determining which account to obtain the ELF
from as well as which offset to begin loading the ELF at.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/svm/src/program_loader.rs#L165-L185

Replenishing the program cache also requires two account loads for Loader V3
programs, since the "last modified slot" value is stored on the ProgramData
account.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/svm/src/program_loader.rs#L218-L253

Account loading and applying cost modeling for data loads has also been made
extremely non-trivial due to the account indirection.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/svm/src/account_loader.rs#L505-L540

Same with snapshot minimization.

https://github.com/anza-xyz/agave/blob/462e586a88c285cfcf1bfc1c4d0fbb2dc6c102f0/runtime/src/snapshot_minimizer.rs#L172-L195

The codepath for migrating builtin programs to Core BPF (Loader V3) programs,
as well as upgrading those Core BPF programs once they exist on-chain, must
navigate the account indirection as well.

https://github.com/anza-xyz/agave/blob/462e586a88c285cfcf1bfc1c4d0fbb2dc6c102f0/runtime/src/bank/builtins/core_bpf_migration/target_core_bpf.rs

Furthermore, the Loader V3 program itself must also perform validation between
the two accounts for multiple instructions.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L686-L697
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1021-L1027
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1154-L1157
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1292-L1308

2. Metadata and ELF Coupling

Loader V3 stores both program metadata and the ELF in the same ProgramData
account, causing inefficient metadata updates and preventing clean evolution of
the metadata format.

struct ProgramData {
    // ---- Program Metadata ----
    slot: u64,
    upgrade_authority_address: Option<Pubkey>,

    // ---- ELF ----
    // ...
}

Why this is bad:

• Updates to only program metadata require the entire ELF. Changing just the
  upgrade authority (33 bytes) requires borrowing and mutating an account that
  could contain megabytes of ELF data.
• Deserialization is cumbersome to implement and maintain. Every codepath
  accessing ELF bytes must skip over the metadata, and those that access the
  metadata must truncate before the ELF.
• Fixed 45-byte metadata header cannot evolve. Its size is not only hard-coded,
  but backed up against the ELF in the account data. This makes introducing new
  fields or versions cumbersome.
• Layout does not enforce separation of duties. Two orthogonal states share the
  same disk storage location and thus are lugged around with each other.

Additional Details

Everywhere Loader V3 programs are loaded, the code has to manage slicing the
account data to obtain the ELF.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/svm/src/program_loader.rs#L165-L185

This includes the added complexity for the loader program itself in managing
program accounts.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L549
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L731
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1114-L1120

The entire ProgramData account - which can be substantially large - is
required to change only the 33-byte upgrade authority. Even though the
deserialization is managed efficiently in the SetAuthority operation, the
account is still required to be loaded during transaction processing.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L838

3. ELF Misalignment

The metadata stored at the start of the ProgramData account is not 16-byte
aligned, which means the ELF that follows is also misaligned. This forces the
ELF parser to make at least one copy of the entire ELF to an aligned buffer
before verification.

Why this is bad:

• Forces at least one full ELF copy during verification. SBPF's lenient parser
  always copies the ELF for ownership and relocations, and may clone it again
  if the input pointer is misaligned.

Additional Details

Both the lenient (current) and the strict (future) parsers clone the ELF bytes
when they're passed into AlignedMemory::from_slice.

https://github.com/anza-xyz/sbpf/blob/3bcd21dc63dd15f6eae49b31fa18a2bc25431bd0/src/aligned_memory.rs#L43-L54

The lenient parser could actually end up copying twice.

https://github.com/anza-xyz/sbpf/blob/3bcd21dc63dd15f6eae49b31fa18a2bc25431bd0/src/elf.rs#L584-L592

4. Program Behavior Constraints

Loader V3 imposes several behavioral constraints that make program deployments
and upgrades less flexible than they need to be [3]. These limitations include:

• The buffer account’s upgrade authority must match the program’s upgrade
  authority, an unnecessarily strict requirement that complicates upgrade
  workflows.
• The ProgramData account cannot be downsized after creation; it may only be
  extended, even when the ELF shrinks.
• Extending the ProgramData account is permissionless, allowing any caller to
  increase the account's size and rent requirements.
• The Upgrade instruction does not resize the ProgramData account to fit the
  new ELF. Resizing must be done separately via ExtendProgram, even though the
  loader could determine the required size directly from the ELF and resize
  automatically, as long as the account has been prefunded.
• Most loader instructions cannot be invoked via CPI. Deployment-related
  instructions (DeployWithMaxDataLen, Write, InitializeBuffer) are
  explicitly blocked, preventing programs from deploying or managing other
  programs on behalf of users.
• Closed programs are tombstoned permanently. Once closed, the program ID can
  never be reused, and any accounts still owned by the closed program become
  permanently inaccessible.

Note SIMD-0164 already seeks to address the third bullet [6].

Why this is bad:

• Reusable public buffer accounts are not supported. Specialty ELFs like an "abort
  program" cannot be deployed to known addresses and reused by programs as
  shared infrastructure [7].
• Program and buffer upgrade authorities must be kept in-sync. For workflows
  that leverage buffers for something like release snapshots, changing the
  program's upgrade authority means updating all buffer accounts as well.
• ProgramData accounts greedily lock up lamports. When a program's ELF
  shrinks, the Upgrade instruction zeroes out unused space rather than
  reclaiming it, and ExtendProgram only adds bytes.
• Permissionless extension can disrupt custom upgrade workflows. The
  ExtendProgram instruction can be griefed to cause rent exemption errors for
  legitimate operations. If Upgrade resized atomically, a permissionless
  ExtendProgram would be unnecessary and this attack vector would not exist.
• Deployment subsidy programs are impossible. Third parties like the Solana
  Foundation cannot build programs that deploy on behalf of users, since
  DeployWithMaxDataLen must be a top-level instruction. This prevents
  subsidized onboarding flows and limits ecosystem tooling.
• Closing a program can permanently lock user funds. Accounts owned by a closed
  program can never be reassigned or drained, since the program can never
  execute again. This makes program closure extremely dangerous and irreversible.

Additional Details

You can see the Loader V3 program disallows arbitrary buffer accounts to be
used for program upgrades. This may have originally been intended to prevent
footguns, but use cases have popped up where such a feature would actually be
useful [7].

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L476-L480

Loader V3 does not support shrinking the size of a program account nor retrieval
of unused rent lamports. When the newly deployed program is smaller than the
previous version, the remaining data is zeroed out, then only ever used again to
grow the ELF if need be.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L817-L821

Because the ExtendProgram instruction accepts an additional_bytes parameter
(rather than something like target_size), an attacker could front-run a
prepared multisig extension, for example, by first extending the program by
only a few bytes. This could cause the legitimate instruction to fail later,
when the combined size exceeds the rent-exempt balance.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1061

The runtime explicitly blocks CPI to most Loader V3 instructions via
check_authorized_program(). Only a small allowlist of instructions can be
invoked via CPI: Upgrade, SetAuthority, SetAuthorityChecked,
ExtendProgramChecked, and Close. Deployment instructions like
DeployWithMaxDataLen, Write, and InitializeBuffer return
ProgramNotSupported when called via CPI.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/program-runtime/src/cpi.rs#L192-L222

When a program is closed, the Close instruction tombstones it by setting the
program account data to the special "closed" marker. Once tombstoned, the
program can never be redeployed to that address, and any accounts it owned
become permanently inaccessible since the program cannot execute to release them.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1029-L1034
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1445-L1448

5. Lack of Proper Specification

Loader V3 was never formally specified, leading to undocumented behavior,
developer confusion, and technical debt that has accumulated over time.

Why this is bad:

• Developers must rely on forums and diving through source code to understand
  expected loader behavior.
• Edge cases and invariants are implicit in the implementation rather than
  defined in a specification.
• Accumulated workarounds and inconsistencies make the loader harder to
  maintain, audit, and reason about.
• Entangling account management and program execution makes the loader more
  obscure and blurs the relationship between the builtin and the runtime.

Additional Details

Making a program immutable requires setting the upgrade authority to None via
SetAuthority, but this isn't obvious from the instruction set or documented
clearly - hence questions about this appearing on developer forums [8].

Furthermore, the act of omitting the new authority key is actually done by
omitting the account from the instruction, which is brittle and goes against
known conventions for updating authority addresses.

https://github.com/anza-xyz/solana-sdk/blob/a07c25923f6e44a136058e7b0646b3000ac3ee70/loader-v3-interface/src/instruction.rs#L125-L127
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L842

Closing a program is irreversible and can permanently brick accounts owned by
that program, locking up liquidity forever. Developers find this extremely
surprising and dangerous - hence the opening of a discussion forum to discuss
the issue [9].

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1029-L1034
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1445-L1448

The program ID keypair is only used during initial deployment. After that, the
upgrade authority (stored in ProgramData) controls the program entirely.
Developers frequently ask whether the program ID private key can be made public
after deployment, not realizing it's already irrelevant [10].

6. Technical Debt

Loader V3 has accumulated quite a bit of technical debt, both as a result of
its design limitations as well as patching security issues.

Why this is bad:

• Workarounds for runtime quirks increase code complexity and obscure intent.
• Inconsistent patterns make the codebase harder to navigate and maintain.
• Acknowledged bugs that weren't fixed create long-term maintenance burden.
• New contributors must understand historical context to safely modify the code.

Additional Details

Loader V3 has a few small acknowledged bugs or workarounds in the codebase,
which are highlighted by comments.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L603-L609
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L479

The program's design also employs workaround tactics for runtime quirks, such
as stuffing an extra account into CPI to avoid an UnbalancedInstruction error.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L595-L598

The program is also not consistent with how it manages index accessors for
provided accounts in its instructions. In some places, hard-coded indices are
used, but elsewhere uses constants.

https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L505-L510
https://github.com/anza-xyz/agave/blob/e4a04896f2824e0ebc27d67f8ef319a6b3e7d19e/programs/bpf_loader/src/lib.rs#L1257-L1261

In general, the program could use some refactoring for smaller things as well.

On-Chain Loader Prerequisites

Both Loader V3 and the proposed Loader V4 are currently implemented as validator
builtin programs. Moving either loader on-chain as a deployed BPF program would
require eliminating areas where the loader calls back into the runtime to
perform privileged operations. Both loaders are equally susceptible to these
issues. Two specific runtime dependencies must be addressed.

ELF Verification

During program deployment and upgrades, the loader invokes a runtime routine to
verify the ELF before writing it to an account. An on-chain program cannot call
back into the runtime to perform this verification.

One possible approach is to defer ELF verification to invocation time. For
example, validators could allow any ELF to be deployed, but verification
violations would be caught when the program is first invoked. Invalid programs
would fail at runtime rather than at deployment.

Another approach is a privileged syscall for ELF verification that only loaders
could call. This would mean even more special-casing in the runtime for loader
programs.

Program Cache Updates

After a program is deployed or upgraded, the loader notifies the program cache
directly that the entry for the program ID has changed in the current slot. An
on-chain program cannot update the global program cache.

One possible approach is to redesign the cache to observe account state changes.
For example, a cache structure that listens for "account modified" events from
the accounts database would not require any callbacks from the loader.

Relevance to Both Paths

These runtime dependencies are not specific to Loader V3. Any loader - repaired
or replaced - would face the same constraints when moving on-chain. Addressing
these issues would generally enable either Loader V3 or Loader V4 to be deployed
as an on-chain BPF program.

Repairing Loader V3

This section evaluates the feasibility of fixing each Loader V3 issue in-place,
without replacing the loader entirely. For each proposed fix, we consider the
scope of the changes required and the risk to validator implementations.

As stated in the introduction, this section will not detail the specific nature
of any particular fix. Instead, we will simply analyze its feasibility in order
to make a directional decision.

Four categories of potential fixes are considered:

• Migrate to a New Account Layout
• Feature-Gated Instruction Changes
• Formal Specification
• Code Refactoring

Migrate to a New Account Layout

A new account layout for Loader V3 could address issue numbers 1, 2, and 3 in
unison. For example:

• Account Indirection: Moving the ELF to the Program account (under the
  program ID) would eliminate the extra lookup in the runtime, since the
  program ID itself would contain the executable bytes.
• Metadata and ELF Coupling: Storing metadata in a separate region - or a
  separate account entirely - would allow independent updates without requiring
  the ELF.
• ELF Misalignment: Adjusting the program metadata to a 16-byte aligned
  size (e.g., 48 bytes) would ensure the ELF starts at an aligned offset. The
  metadata section could also be changed to a footer or removed entirely.

Regardless of the new layout itself, this change would be highly disruptive.
New state layouts under the owner BPFLoaderUpgradeab1e11111111111111111111111
means on-chain programs, off-chain infrastructure, and applications would
require updates.

Furthermore, the network itself would not realize much benefit from this change
without migrating all existing Program-ProgramData account pairs to the
new layout, further exacerbating the disruption.

If any logic does not validate the serialized enum variant discriminator in
addition to the owner ID for Program or ProgramData accounts, they could
end up consuming unexpected data. Additionally, the new discriminators would
need to be added to said logic in order to parse the new program account
layout for their intended target.

Feature-Gated Instruction Changes

Issue number 4 would require individual feature gates to target each constraint
listed as problematic. We can assume at least four feature gates would likely
be required, and each one would require a dedicated SIMD proposal.

Constraint	Fix	Complexity
Buffer authority must match program authority	Relax check or add new instruction	Low
ProgramData cannot shrink	Add ShrinkProgram instruction or modify Upgrade	Medium
ProgramData locks up lamports	Add WithdrawExcessLamports instruction or modify Upgrade	Medium
Permissionless extend (griefing)	Add new instruction requiring authority signature	Low

SIMD-0164 already exists for the last feature gate [6].

Formal Specification

This is primarily a documentation and process issue, not a code issue. This
document should:

• Describe all Loader V3 instructions, their expected behavior, error
  conditions, and invariants.
• Document the relationship between Program and ProgramData accounts.
• Clarify the role of the program ID keypair vs. upgrade authority.
• Document the immutability process (setting authority to None).
• Add warnings about irreversible operations (closing programs).

Code Refactoring

Some technical debt can be addressed without changing behavior. Magic account
indices can be replaced with consistent use of named constants or vice versa,
duplicated logic can be factored into helpers, and inconsistent error codes can
possibly be rectified.

However, some issues like CPI workarounds and security patches cannot be
removed, but instead can be better integrated into the program's implementation
so that maintainers can better service the code.

Loader V4

This section evaluates the alternative path: replacing Loader V3 with a new
Loader V4, as proposed in SIMD-0167 [1]. We consider the tradeoffs relative to
repairing Loader V3 in place.

Account Layout Migration

Similar to migrating layouts under Loader V3, a migration from Loader V3 to
Loader V4 layouts would also be incredibly disruptive. Programs and apps will
require updating to support the new V4 owner ID and state layouts, and existing
programs could unexpectedly appear under the new configuration.

Both paths require an account layout migration to address issues 1, 2, and 3.
The key difference is whether the migration occurs under the existing owner ID
(BPFLoaderUpgradeab1e11111111111111111111111) or a new one.

Migrating under a new owner ID (Loader V4):

• Existing tooling can distinguish between V3 and V4 programs by owner ID
  alone, without parsing account data.
• Easier to halt or roll back if issues arise, since loaders V3 and V4 have
  separate deployment processes.
• Any logic that filters by owner ID would need to be updated to include the
  new loader.

Migrating under an existing owner ID (repaired V3):

• Programs remain under the same owner, but the account layout changes.
• Harder to halt or roll back if issues arise.
• Tooling that doesn't validate discriminators may consume unexpected data
  after the migration.

Behavior Constraints

A new loader could incorporate all constraint fixes natively in its design,
rather than accumulating feature-gated patches. A well-designed Loader V4
should address:

• Relaxed or removed buffer authority matching requirement
• Programs can be resized (grown or shrunk)
• Excess lamports can be reclaimed
• Extension requires authority signature

These behaviors would be built into the loader from the start, avoiding the
patchwork of feature gates that would accumulate in a repaired V3.

Specification and Code Hygiene

The new loader's SIMD would serve as a formal specification from day one. Future
changes would go through the SIMD process, ensuring that behavior is documented
and reviewed before implementation.

In contrast, a formal specification for Loader V3 would be a retroactive
effort - documenting existing behavior rather than defining intended behavior.

A new loader would also start with a clean implementation, free of the
workarounds and compatibility constraints that have accumulated in Loader V3.
However, this benefit will diminish over time as Loader V4 accumulates its own
history.

Call to Action

This RFC requests explicit review from the following core contributors:

• @Lichtso (Anza)
• @jstarry (Anza)
• @2501babe (Anza)
• @joncinque (Anza)
• @deanmlittle (Blueshift)
• @L0STE (Blueshift)
• @topointon-jump (Firedancer)
• @mjain-jump (Firedancer)
• @jacobcreech (Solana Foundation)

Any additional community members are welcome to provide feedback and their input
will be equally considered. The above merely lists contributors already involved
in this debate or with relevant domain expertise.

What We're Asking

Reviewers should consider the following questions:

1. Feasibility: Are the proposed Loader V3 repairs technically viable, or do
   they introduce unacceptable risk or complexity?
2. Disruption: Given that both paths require breaking changes, which path
   minimizes disruption to the ecosystem?
3. Maintenance: Which path results in a more maintainable loader
   implementation over the next 3+ years?

Please provide feedback by commenting on this GitHub discussion. Feedback
should focus on the directional decision (repair vs. replace), not on specific
implementation details of either path, unless directly relevant to your review.

Deadline

Feedback is requested by January 8th, 2026. After this date, community input
will be distilled into a final decision on whether to repair Loader V3 or
replace it with Loader V4. This decision will be binding and development will
proceed accordingly.

Sources

• [1] SIMD-0167: Loader-v4 #167
• [2] SIMD-0315: Loader-v3 to loader-v4 migration #315
• [3] https://gist.github.com/deanmlittle/d95f2fc68866f11cf148c34b582c18c4
• [4] https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0162-remove-accounts-executable-flag-checks.md
• [5] SIMD-0319: Remove Accounts is_executable Flag Entirely #319
• [6] SIMD-0164: ExtendProgramChecked loader-v3 instruction #164
• [7] feat: Add emergency-abort command to Solana CLI anza-xyz/agave#6932
• [8] https://solana.stackexchange.com/questions/9224/how-do-i-make-a-program-immutable
• [9] Allow Closed Programs to be Recreated #247
• [10] https://solana.stackexchange.com/questions/4027/after-deployment-of-a-program-can-the-program-ids-private-key-be-made-public

[buffalojoec]

Breakpoint Discussions

December 12, 2025

The RFC has been updated after discussions at Breakpoint. A potential roadmap that can be further discussed here was also laid out.

Additions to the RFC

• Loader v3 CPI limitation was added to "4. Program Behavior Constraints".
• Loader v3 Upgrade instruction not resizing automatically if pre-funded was added to "4. Program Behavior Constraints".
• Loader v3 tombstones versus being able to reopen programs to reclaim assets was more explicitly described in "4. Program Behavior Constraints".
• New section "## On-Chain Loader Prerequisites" was added detailing what's stopping either loader from being moved on-chain.

Proposed Roadmap

The roadmap proposed at Breakpoint consists of three phases:

Phase 1: Loader V3 Repairs and Runtime Feature Gates

Design and implement runtime feature gates to address the two runtime constraints
described in "On-Chain Loader Prerequisites" (ELF verification and program cache
updates).

In parallel, ship sequential feature gates to Loader V3 to address the
behavioral constraints described in "Program Behavior Constraints".

All changes in this phase will go through R&D and the SIMD process.

Phase 2: Loader V3 Account Layout Migration

Introduce a new account layout for Loader V3 to address the issues described in
"Account Indirection", "Metadata and ELF Coupling", and "ELF Misalignment". This
phase includes a migration path from the existing layout to the new one.

All details regarding the new layout, migration mechanics, permissioned vs
permissionless migrations, handling of frozen programs, etc. will be specified
through the SIMD process.

Phase 3: On-Chain Loaders

Once the runtime changes from Phase 1 are complete and activated, remove the
runtime callbacks from Loader V3. Following that, Loader V4 will be
reintroduced via SIMD as an on-chain BPF program, replacing the program
management functionality of Loader V3. Existing Loader V3 programs will not be
required to migrate to V4.

Attendees

Contributors in attendance at the Breakpoint meeting:

• @Lichtso
• @joncinque
• @febo
• @deanmlittle
• @jacobcreech
• @Woody4618

[deanmlittle]

Thank you to @buffalojoec for collating all of our concerns and feedback. With the timeline of direct mapping currently uncertain and pre-DM account layout changes resulting in a sizable CU penalty in CPI, I agree that we should first focus on shipping features/bugfixes that are immediately and urgently addressable without adding additional instructions or modifying account layouts. I vote that we should initially prioritize:

1. Relaxing buffer owner and authority checks.
2. Making extend program permissioned.
3. Modifying upgrade to resize the program data account to the exact size of the deployed ELF file, refunding additional lamports to the existing spill account.
4. Modifying close program to reclaim the program account by default, and henceforth explicitly tombstone by self-assigning the address.

After delivering on these 4 features, I think we can give more consideration to some of the more invasive ideas, such as migrating the ELF from the program data account to the program account, or considering what, if anything, to do about existing tombstoned programs.

[topointon-jump]

These 4 seem fine to me, as they are all relatively straightforward and easy to ship.

[febo]

All sounds great! I agree with @deanmlittle's ordering of the changes.

[jacobcreech]

Awesome. This lines up with what we all chatted about at breakpoint. Let's get these into SIMDs and start the discussions there.

[mjain-jump]

I'm in agreement with most of what was proposed. However, I am against the account layout changes being a part of loader v3 - you end up with an extensive mess of edge cases and complexity, where some accounts have the v3 v1 format and others using v3 v2. It just doesn't seem right to me.

[buffalojoec]

Is the issue that the two different account layouts would be under the same program owner, or that they would coexist? In either case - Loader V3 or V4 - we would not want these two layouts to coexist for long. There would be a migration period, and we can discuss tightening that up as much as necessary.

[mjain-jump]

If both layouts will exist under loader v3 then yes we should definitely have the coexisting period be as short as possible. Otherwise the account layout changes are alright with me!

[buffalojoec]

Okay so you're on-board with changing the account layout under Loader V3 then? Provided we have a tight window of coexistence.

[mjain-jump]

Yes, the less the two layouts coexist the better

[topointon-jump]

Program Cache Updates
After a program is deployed or upgraded, the loader notifies the program cache
directly that the entry for the program ID has changed in the current slot. An
on-chain program cannot update the global program cache.

One possible approach is to redesign the cache to observe account state changes.
For example, a cache structure that listens for "account modified" events from
the accounts database would not require any callbacks from the loader.

One side note, I agree with the direction suggested here, however we end up getting there. The program cache should not be part of consensus - the loader programs, which need to execute exactly the same across all clients, should not reference it at all. It should be a validator client implementation detail. If we need to store metadata about the state of programs, that should be stored on-chain, not in the cache.

[topointon-jump]

• @deanmlittle's suggestion of initially prioritising the 4 easy wins seems great to me.

Once the runtime changes from Phase 1 are complete and activated, remove the runtime callbacks from Loader V3.

Big fan of this, as per my earlier comment. The program cache should not be part of consensus. 💪

Phase 2: Loader V3 Account Layout Migration

• I echo @mjain-jump's concerns about having multiple account layouts, and the edge cases here.

Phase 3: On-Chain Loaders

• It sounds like this is already the direction, but it would be awesome if we could do this without adding extra syscalls/runtime callbacks.

[buffalojoec]

• It sounds like this is already the direction, but it would be awesome if we could do this without adding extra syscalls/runtime callbacks.

Yes, this is the goal. If we ship the new program cache index structure and rework ELF verification, we shouldn't need the loaders to call back into the runtime for anything.

[topointon-jump]

Phase 2: Loader V3 Account Layout Migration

What is the urgency of migrating these accounts/solving problems 1)2)3)? Could we just do this as part of loader v4? Bundling more features into the roadmap means it's less likely to make progress...

[LucasSte]

Bundling more features into the roadmap means it's less likely to make progress...

I agree.

[topointon-jump]

With #178 removing relocations coming in SBPFv3, do we need the program cache at all for new SBPFv3 programs? So loader v4 could only support SBPFv3 programs, and not need to use the cache at all... is there a good reason why we can't remove the program cache for loader v4 altogether? (I'm asking, there might be)

We would enforce that loader v4 can only deploy/execute SBPFv3+ programs.

[Lichtso]

Our cache is responsible for a lot of things, not just caching relocations, but also verification and compilation results.

Also, the loader-v3 rework, or loader-v4 for that matter, both are meant to be independent of the SBPF version so that you can migrate old programs to more efficient layouts. I would strongly advise against coupling even more changes together and keep them independent.

[topointon-jump]

To answer the original question of the RFC, I would vote for putting our energy behind making loader v4 what we want it to be, rather than spending time trying to fix loader v3. Migrations are always messy and time consuming and prone to bugs. I think it will be much faster and simpler to make minimal changes to loader v3 (such as those suggested by @deanmlittle) and focus on shipping loader v4.

[buffalojoec]

Thank you to everyone who weighed in on the discussion - both IRL at Breakpoint
and here in the thread. Since the deadline has now passed, I wanted to provide
some directional updates.

To make things easier to follow and be as conclusive as possible, I'll rewrite
my comment here below to include all changes as a result of this RFC discussion.

Note the last two phases are entirely different.

---

Phase 1: Loader V3 Repairs and Runtime Feature Gates

This phase maintains its original form.

Summary

Design and implement runtime feature gates to address the two runtime constraints
described in "On-Chain Loader Prerequisites" (ELF verification and program cache
updates).

In parallel, ship sequential feature gates to Loader V3 to address the
behavioral constraints described in "Program Behavior Constraints".

Development

We've kicked off development on four Loader V3 feature gates:

• SIMD-0430: Loader V3: Relax Program Buffer Constraints
• SIMD-0431: Loader V3: Permissioned Extend Program
• SIMD-0432: Loader V3: Reclaim Closed Program
• SIMD-0433: Loader V3: Set Program Data to ELF Length

@Lichtso has begun work on a new program cache index structure, which will
eliminate the need for loaders to call back into the global program cache.
@deanmlittle and I are also looking at the global program cache as well as
moving deploy-time verification into execution-time.

All of the above work will ship and will conclude Phase 1.

Phase 2: Loader V4

This phase has changed from migrating the account layout under Loader V3 to
migrating it under Loader V4. It also includes high-level details about the new
loader program.

Summary

Introduce a new loader - Loader V4 - which will primarily solve the account
layout issues described in "Account Indirection", "Metadata and ELF Coupling",
and "ELF Misalignment".

We will revisit the design for Loader V4, as many folks have thoughts on it,
but the specifics around the new loader's design belong in that corresponding
SIMD, not this RFC. Directionally, we are committed to a new account layout
under Loader V4, and not under Loader V3.

Loader V4 will be an on-chain program from its inception. It will not
ship as a builtin program.

As part of the Loader V4 rollout, we will include a Migrate instruction on
Loader V3 to allow program authorities to migrate their programs from Loader
V3 to Loader V4. We will not force-migrate or make migrations mandatory at
this time.

Development

We will be following up on Loader V4 design, either continuing SIMD-0167 or
closing it in favor of a new SIMD. In general, the new loader should be
designed from first principles with maximum simplicity. If anyone is curious
about what we are thinking for the new loader's redesign, you can check out
this Gist.

Since we are committed to releasing Loader V4 as an on-chain program, not a
builtin program, the existing builtin program implementation will be removed
from Agave.

Phase 3: Assess Further Migration

The original Phase 3 was baked into the above revised Phase 2. An entirely
new Phase 3 is presented below

Summary

In Phase 3, we will have shipped the following in previous phases:

• Loader V3 feature gates
• Loader-cache decoupling
• Execute-time verification
• Loader V4 as an on-chain program

At this time, we will take a detailed, research-based approach to
determining the necessity of any kind of
migration of on-chain programs from
their Loader V3 layout to the new Loader V4 layout.

We will consider datapoints such as:

• The actual performance increase between Loader V4 and Loader V3 layouts
• How many programs have already willingly migrated to Loader V4 on their own
• Traffic levels of any remaining non-migrated programs