What is the BPF Loader
The BPF Loader is the program bundled into Solana that administers, deploys, and runs every other program on the network. When a developer deploys a program - compiled into sBPF bytecode - the loader persists that bytecode on-chain, marks it as executable, and executes it any time a transaction calls the program's address. The current BPF Loader standard is BPF Loader Upgradeable (aka loader v3), and Loader-v4 is designed as the replacement.
Imagine a shop located at a particular street address. Customers will always go to the shop at the same address, aka the program ID listed on every integration, wallet, and frontend. If the shop is locked up, and no one owns the keys, then the interior stays as-is for eternity: no remodels allowed. The loader manages the address, the interior, and the keys.
How the Upgradeable Loader Works
In loader v3, each deployed program spans 2 accounts. The program account is a simple proxy, with a couple of pointers (i.e., the address is the only thing users invoke). The program data account contains the actual sBPF bytecode (in practice, hundreds of kilobytes). There's also a designated signer, the upgrade authority, which can update the program data account.
Upgrading the program updates the interior while keeping the same street address. The upgrade authority writes out the new bytecode. Existing integrations work because the program ID doesn't change. You can also revoke the upgrade authority (by setting it to nothing), rendering the program immutable. Verification tools and block explorers show the upgrade authority for a given program, and knowing what it is is the single most important due diligence a Solana user can perform.
There's a monetary cost to deploy a program, because bytecode on-chain pays for storage. Each account type needs a rent-exempt deposit proportional to its size, so a moderately sized program locks up multiple SOL- hundreds of dollars, if SOL is $80. Ethereum charges for one gas fee per byte of deployed contract code, so the models are quite different, though neither stores code for free.
How Solana Upgradeability compares to Ethereum
Ethereum smart contracts are immutable by default. Upgradeability has been a convention added on top, with proxy contracts delegating calls to implementation contracts, storage layout rules which must never be violated, a graveyard of exploits (frozen funds, hijacked proxies, misinitialization) from slight deviations from the pattern, each Ethereum team re-inventing or integrating it.
Solana made the proxy a core part of the protocol. The program-account + programdata split is a proxy, implemented once in the runtime, universally available to all programs. Developers can't get the storage layout of a pattern they don't have to write. But the philosophical distinction is the flip side: Solana, upgradeability by default, which has to be unilaterally revoked. Ethereum, immutability by default, which has to be engineered.
Why the loader matters
Imagine depositing $10k in a Solana lending protocol such as Kamino or Solend. If the program's upgrade authority is a single hot wallet, then if that private key is ever compromised, an attacker can deploy arbitrary bytecode to modify or delete your loan position. Teams take this seriously: authority is often a Squads-managed multisig, with the ability to upgrade either timelocked, or disabled after a program has matured. The most prominent decentralized Solana applications, such as Jupiter and Raydium, publicly disclose their upgrade authority because sophisticated participants care to check.
The reality is that upgradeability is a trust assumption. The great majority of programs on Solana are upgradeable; the concept that "code is law" becomes "code is law, until the authority updates the program" - a weaker guarantee than an immutable contract in Ethereum. This is something users need to account for. Loader-v4 is designed as a further improvement on the same, but not a change in the underlying trade.
Can the program change with no advance warning?
Yes. A program can change at the discretion of the upgrade authority, with no protocol-mandated notice. And that's exactly why the most important thing to understand is the authority itself, rather than the current state of the bytecode, before placing funds in a program.
