SIMD-0418: Enable Loader v2 to v3 Program Migrations (#418)

* Add migration details

* Update smid number

* Fix review comments

* Rename title

* Update impact

* Add buffer details

* Add clarification for runtime-level migration

* Update 0418-enable-loader-v2-to-v3-program-migrations.md

Co-authored-by: mjain-jump <150074777+mjain-jump@users.noreply.github.com>

* Improve design description

* Update alternatives text

---------

Co-authored-by: mjain-jump <150074777+mjain-jump@users.noreply.github.com>

Author: febo

proposals/0418-enable-loader-v2-to-v3-program-migrations.md

@@ -0,0 +1,104 @@
+---
+simd: '0418'
+title: Enable Loader v2 to v3 Program Migrations
+authors:
+  - febo (Anza)
+category: Standard
+type: Core
+status: Review
+created: 2025-11-27
+feature: N/A 
+---
+
+## Summary
+
+This proposal introduces a feature-gated mechanism for runtime-level migration
+of Loader v2 programs to Loader v3.
+
+## Motivation
+
+Loader v2 programs are immutable by design, as the loader does not support
+program upgrades. However, several essential Loader v2 programs would benefit
+from a feature-gated, consensus-driven mechanism that allows the community to
+approve targeted upgrades to specific programs (e.g., SPL Token).
+
+## Alternatives Considered
+
+Previously, the runtime could "upgrade" Loader v2 programs by directly modifying
+their account data. This approach is no longer recommended due to the introduction
+of the global program cache, since it can cause inconsistencies if account data is
+modified in-place. The global program cache does not support upgrades of Loader v2
+programs because in Loader v2 there is no upgrade path and thus also no last
+upgrade slot metainfo. Without this metainfo, the global program cache cannot
+distinguish the old and new version across forks. When migrating to Loader v3
+this would not be a problem because the owner is a distinguishing feature and
+Loader v3 does have the last upgrade slot metainfo for further future changes.
+
+## New Terminology
+
+N/A
+
+## Detailed Design
+
+The migration from Loader v2 program to Loader v3 is only performed by the
+runtime and activated via a feature gate. This SIMD describes the procedure
+to follow to execute the migration. Each individual program upgrade will
+reference the procedure described in this SIMD when proposing a migration
+and specify its corresponding feature gate.
+
+Migrating a Loader v2 program to Loader v3 involves creating a buffer
+account owned by the Loader v3 (BPF Upgradable Loader) that contains
+the ELF bytes of the program's implementation to be migrated. This
+buffer is deployed before initiating the migration, and a portion
+of its lamports is later used to fund the new program and program data
+accounts. Any remaining lamports in the buffer are burned as part of
+the migration process.
+
+The migration proceeds in the following steps:
+
+* **Create the program data account**:
+  A program data account is derived from the program ID. This account must
+  not already exist, with one exception: if an account with the derived address
+  exists, holds lamports, and is owned by the System Program, it may be reused.
+  In that case, any excess lamports are burned. The ELF bytes from the buffer
+  account are then copied into this program data account.
+
+* **Rewrite the program account**:
+  The existing Loader v2 program account is replaced with a Loader v3 program
+  account that references the newly created program data account. Because
+  Loader v2 programs are not upgradable, they do not have an upgrade authority,
+  and `None` is assigned during migration.
+
+* **Close the buffer account**:
+  Once both program and program data accounts have been created and populated,
+  the buffer account is closed and any remaining lamports are burned.
+
+In the slot immediately following the feature activation, the program will not be
+invocable. This status will last one slot, then the program will be fully operational.
+The program ID does not change by this migration process.
+
+Each individual program migration should be controlled by its own feature gate,
+which triggers the migration process when activated.
+
+## Impact
+
+This change introduces a feature-gated, consensus-driven mechanism that allows
+the community to approve targeted upgrades for specific programs that would
+otherwise be non-upgradeable.
+
+## Security Considerations
+
+Migrating Loader v2 programs have serious security implications surrounding
+the replacement of essential programs with the contents of another account.
+This is an extremely sensitive process that must be handled with maximum
+caution.
+
+## Backwards Compatibility
+
+This proposal itself does not directly introduce any breaking changes. The code
+introduced to migrate Loader v2 programs to Loader v3 programs will exist off of
+the runtime's "hot path" until it's actually used for a migration.
+
+When a migration is conducted, the Loader v3 version of a program is expected to
+be backwards compatible *functionally* — its Loader v3 version must provide
+the exact same results as the Loader v2 program it aims to replace.