pull down to refresh

Citrea's blog post describes the lifecycle of their transactions:
[...]the technical process begins with users sending transactions to a full node. Upon receiving these transactions, the full node sends them to a sequencer for soft confirmations. Anyone who wants to access Citrea's transaction history or wants to query data can set up a Citrea full node. A sequencer is a type of full node that soft-confirms the transactions and builds blocks. It then propagates these soft confirmations, soft blocks, to every full node available. The purpose of soft-confirmations is to provide users with fast transaction experience. The next step involves a special type of full node that is used for zero-knowledge rollups. This full node is called Prover and has an important role in inheriting Bitcoin security for user's transactions.
A prover, as all full-nodes do, receives the soft confirmations from the sequencer and keeps the data. What makes a prover special is that it creates a batch by roll-ing up the transactions that the sequencer has soft confirmed.
Then, it generates a zero knowledge proof of this batch for anyone to verify its validity. The prover does not only generate the proof but also creates a data called state difference - which is the storage slots difference between the initial and latest state. Creating state differences is what makes Citrea’s Bitcoin blockspace usage efficient. Since Bitcoin blockspace is limited and expensive, Citrea inscribes state differences instead of full transactional data to minimize blockspace usage and the data cost.
There is one caveat; proof producing is not instant. There is a cost to proving. The more transactions the batch contains, the cheaper each transaction data becomes. Therefore, the prover collects the transactions until the cost of creating the zero-knowledge proof of the batch reaches an optimal cost. To ensure that no one can alter the ordering while validity proof is being generated, the sequencer inscribes the Merkle root of the batch to Bitcoin every 10 minutes. The prover makes sure that the zero knowledge proof is generated based on the ordering submitted to Bitcoin.
Does proof generation on Citrea start as soon as the sequencer finalizes the batch? Or do they start generating the proof but wait with inscribing the state differences till the corresponding Merkle root gets confirmed with a certain number of blocks? Or rather do they start proof generation after a certain number of blocks confirming the inscription of the batch's Merkle root?