BPF Upgradeable Program

What it is

When you invoke a program at an address like Jupiter’s JUP6Lkb…, that account is tiny — just 36 bytes. It doesn’t contain the bytecode; it’s a Program state pointing at a separate ProgramData account that holds the actual ELF. This indirection is what makes upgrades possible.

Why it exists

If a program’s bytecode lived directly at its public address, upgrading would change the address and break every integration. The BPF Upgradeable Loader splits it: a stable, tiny Program account at the public address, and a separate ProgramData account that can be rewritten on upgrade. The address you call never changes; the code behind it can.

Byte layout

The account holds the Program variant of UpgradeableLoaderState, bincode-encoded:

Total: 36 bytes.

Where you see it

Every upgradeable program’s main address: Jupiter, Drift, Kamino, Anchor programs deployed normally. When you look up a program account and it’s exactly 36 bytes owned by the BPF Upgradeable Loader, this is it — follow programdata_address to find the code.

Common gotchas

• The program account doesn’t hold code. Decoding it gives you a pointer, not bytecode. The 4 GB of ELF you might expect lives in the ProgramData account it references.
• 4-byte bincode discriminator. Like other native-loader state, the variant tag is a 4-byte u32, not a 1-byte tag.
• Non-upgradeable programs look different. Programs deployed with the older non-upgradeable BPF Loader (BPFLoader2…) store the ELF directly at the program address — no ProgramData indirection. The owner program id tells you which loader.
• Closing/upgrading is gated by the ProgramData authority, not anything in this 36-byte account. The upgrade authority lives in ProgramData.