This is actually not desirable behaviour because a pre-confirmation could be invalidated if, in the slot where the pre-confirmation will be executed, the user has an higher nonce or an insufficient balance.
In such case the proposer won't be slashed because it can prove on-chain what happened, however the builder won't be able to produce a bid with all the proofs which will be discarded by MEV-Boost, leading to a sub-optimal locally built block.
In order to solve this, pre-confirmations should be cached by their slot and when a new head comes we should check again their validity. Lastly, constraints should be submitted only after the commit deadline for a given slot is crossed.
As we can see in the main sidecar loop here https://github.com/chainbound/bolt/blob/4f87242f70ec11ccbb01e32852703bcf17fc6d6a/bolt-sidecar/bin/sidecar.rs#L68-L116 constraints are submitted immediately to MEV-Boost after quick checks on protocol rules (nonce, balance, base fee). In turn, this constraints are then forwarded to relays and pulled from builders.
This is actually not desirable behaviour because a pre-confirmation could be invalidated if, in the slot where the pre-confirmation will be executed, the user has an higher nonce or an insufficient balance. In such case the proposer won't be slashed because it can prove on-chain what happened, however the builder won't be able to produce a bid with all the proofs which will be discarded by MEV-Boost, leading to a sub-optimal locally built block.
In order to solve this, pre-confirmations should be cached by their slot and when a new head comes we should check again their validity. Lastly, constraints should be submitted only after the commit deadline for a given slot is crossed.