+This section details Citrea's block production and finalization process, from transaction submission to confirmation. It covers the roles of the sequencer, commitments, mempool, and overall process.
-In Citrea, the entity responsible for producing blocks is called the "sequencer." A sequencer, unlike a validator or miner, doesn't need validations over produced blocks from other sequencers or nodes because every block produced by sequencers undergoes a zero-knowledge proving process, which acts as a natural and trustless validation mechanism over blocks.
+#### Components Overview
-The sequencer builds blocks using its own local mempool. Anyone can send a transaction to sequencer's mempool using its RPC endpoints or a full node. In case of censorship, there is a force transaction mechanism that falls back to Bitcoin and guarantees transactions will be included in the next batch.
+You can read more on each component of the block production process with detailed explanation below:
-The sequencer is only responsible for ordering and publishing blocks. It can neither steal users' funds nor freeze them thanks to ZK proofs, force transaction mechanism, and on-chain data availability.
+- [Mempool](./mempool.md): A holding area for user transactions before they are included in a block.
+- [Sequencer](./sequencer.md): A special full node that orders the transactions, produces rollup blocks, and publishes commitments to the Bitcoin DA.
+- [Sequencer Commitments](./sequencer-commitments.md): Cryptographic commitments to the Citrea blocks that are inscribed on Bitcoin by the sequencer to prevent reorgs.
+- [Soft Confirmations](./soft-confirmations.md): A confirmation mechanism used by the sequencer to provide soft-finality of blocks.
+
+#### Block Production Process
+
+Here is a diagram that shows process & components of block production in Citrea. Feel free to check each component above for more detailed information in the diagram.
+
+
Extended Block Production
+
+{% hint style="success" %}
+In short, block production in Citrea is as follows:
+- User transactions enter the mempool where they undergo some checks until they are included in a block.
+- The sequencer selects valid transactions from the mempool, orders them, and produces a rollup block.
+- The sequencer also provides soft confirmations alongside the block data, allowing full nodes to update their local chain state with a soft-finality.
+- To finalize the ordering of the transactions, sequencer commitments are inscribed on Bitcoin by the sequencer, allowing full nodes to trustlessly verify the blocks.
+- Lastly, the proving of execution is completed by the prover and batch proofs are inscribed (and finalized) on Bitcoin, and hence block becomes finalized & proven.
+{% endhint %}
\ No newline at end of file
diff --git a/technical-specs/characteristics/block-production/decentralized-sequencer-network.md b/technical-specs/characteristics/block-production/decentralized-sequencer-network.md
deleted file mode 100644
index 733a134..0000000
--- a/technical-specs/characteristics/block-production/decentralized-sequencer-network.md
+++ /dev/null
@@ -1,7 +0,0 @@
-# Decentralized Sequencer Network
-
-A single sequencer operating for a rollup is sufficient for security (safety); however, it imposes a limit for censorship-resistance, uptime, and fair ordering. In order to prevent any potential issues, Citrea is working towards a solution that significantly reduces risks by allowing multiple sequencers to produce and finalize blocks with sub-second timing.
-
-The consensus network between multiple sequencers minimizes the risk of censorship on the L2 level, reducing Bitcoin fallback force transaction count (thus reducing the need for users to force-transact). It also removes the need to trust the sequencer ordering, even if it is for a short time, because now ordering is determined and finalized on the sequencer network with sub-second timing.
-
-A Decentralized Sequencer Network can further reduce the costs of the rollup because it allows the posting of roots and proofs to Bitcoin less often, as the ordering is guaranteed and finalized on the L2 directly.
diff --git a/technical-specs/characteristics/block-production/mempool.md b/technical-specs/characteristics/block-production/mempool.md
new file mode 100644
index 0000000..d9f2c05
--- /dev/null
+++ b/technical-specs/characteristics/block-production/mempool.md
@@ -0,0 +1,28 @@
+# Mempool
+
+Citrea has a private mempool (memory pool) as a temporary staging area for pending transactions before they are included in a block.
+
+Once a transaction is submitted, some basic checks are as follows:
+- Is there enough space in the mempool? (see configs section below)
+- Does it fit into account limits? (see configs section below)
+- Does the transaction have a valid nonce that is bigger or equal than the current nonce?
+- Does the address have enough balance?
+
+If the transaction passes these checks, it is added to the mempool.
+
+#### Configuration
+
+Citrea uses a private mempool, inaccessible via RPC, which prioritizes transactions based on their fee.
+
+Citrea mempool has custom [SubPools](https://reth.rs/docs/reth_transaction_pool/enum.SubPool.html#variants) that uses `reth-transaction-pool` architecture. Namely:
+- **Queued**: Includes transactions not ready to be included in the next block due to lack of funds, nonce, etc.
+- **BaseFee**: Includes transactions not ready to be included in the next block due to insufficient base fee.
+- **Pending**: Includes transactions ready to be included in the next block.
+
+For **Queued**, **BaseFee**, and **Pending** pools, Citrea has the 10x configuration limits compared to default values of Ethereum: **100,000** transactions per subpool with **200 MB** limit.
+
+{% hint style="success" %}
+> Citrea does not have a Blob pool as it does not support blob transactions at the moment.
+{% endhint %}
+
+One more custom mempool configuration is the number of transaction slots per account, `max_account_slots`. Citrea has a maximum of **64 slots per account** in the mempool to prevent spamming.
diff --git a/technical-specs/characteristics/block-production/pre-confirmations.md b/technical-specs/characteristics/block-production/pre-confirmations.md
deleted file mode 100644
index 36ede26..0000000
--- a/technical-specs/characteristics/block-production/pre-confirmations.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Pre-Confirmations
-
-The sequencer's ordering promise is only trusted until the next Bitcoin block. The Merkle root of the soft blocks (batch tree) is inscribed in Bitcoin every 10 minutes. After the state root is inscribed, its validity and data availability are asserted inside the zk circuit, preventing any change in the ordering of transactions. This mechanism ensures that ordering of the transactions cannot be changed after it is inscribed in Bitcoin.
-
-With this method, Citrea ensures that ordering finality is not delayed until the batch proof while keeping the full data publishing cost as low as possible. For future work, Citrea will introduce a multi-sequencer network, which will reduce ordering trust assumptions to near-zero.
diff --git a/technical-specs/characteristics/block-production/sequencer-commitments.md b/technical-specs/characteristics/block-production/sequencer-commitments.md
new file mode 100644
index 0000000..0749977
--- /dev/null
+++ b/technical-specs/characteristics/block-production/sequencer-commitments.md
@@ -0,0 +1,27 @@
+# Sequencer Commitments
+
+**Sequencer commitments** are envelopes on Bitcoin that are inscribed by the sequencer before proof generation. Such envelope contains:
+
+- **Soft Confirmation Hashes**: Merkle root built on top of the hashes of soft confirmations, representing a set of Citrea blocks.
+- **Start - End Block Heights**: It includes the range information of Citrea blocks (identified by their start and end heights) that were processed to reach the new state.
+
+These commitments are inscribed directly on Bitcoin, creating an immutable record. Thus, unless Bitcoin is re-orged, the sequencer commitments will continue to be trustlessly accessible.
+
+A sequencer commitment is generated by the sequencer and submitted to Bitcoin based on a number of soft confirmations and a state diff size threshold.
+
+#### Benefits
+
+Sequencer commitments are used to keep track of the canonical history of the rollup's state, as they represent a commitment to a set of Citrea blocks derived from a Bitcoin block.
+
+Once a commitment is inscribed (and finalized) on Bitcoin, the sequencer cannot re-order transactions within that batch without invalidating the commitment. This maintains the integrity of the batch, and therefore the rollup's state.
+
+While it does not fully guarantee data availability, sequencer commitments prevent re-orgs on Citrea blocks once they are finalized. It allows full nodes to verify the sequencer's claims about the ordering of transactions.
+
+Sequencer commitments are also used in the **Batch Proof Circuits** to make sure proofs are generated for the canonical batch used in sequencer commitments. You can read more about it [here](https://www.blog.citrea.xyz/citreas-batch-proofs/).
+
+Lastly, **Light Client Proofs** that are used in BitVM based **Clementine** bridge also benefits from the sequencer commitments indirectly as well.
+Lastly, sequencer commitments are also utilized for the generation of the Light Client Proofs. Light Client Proofs are a criticial component of the BitVM based Clementine bridge, you can read more about it [here](https://x.com/citrea_xyz/status/1877746951309176971).
+
+#### Querying Sequencer Commitments
+
+Sequencer commitments can be queried by using the **Citrea Batch Explorer**, along with the [RPC endpoints](/developer-documentation/rpc-documentation/ledger-rpc-documentation.md). You can find the explorer [here](https://citrea.xyz/batch-explorer).
\ No newline at end of file
diff --git a/technical-specs/characteristics/block-production/sequencer.md b/technical-specs/characteristics/block-production/sequencer.md
new file mode 100644
index 0000000..720aeb3
--- /dev/null
+++ b/technical-specs/characteristics/block-production/sequencer.md
@@ -0,0 +1,20 @@
+# Citrea Sequencer
+
+The Citrea sequencer is a specialized full node responsible for ordering user transactions and constructing rollup blocks.
+
+#### Process of Block Production
+
+Sequencer carries the following operations to build a block, in detail:
+
+- It continuously monitors the [mempool](./mempool.md), a dedicated area for pending transactions.
+- Every two seconds, the sequencer assembles a new block from the transactions in the mempool. The subset of transactions selected from the mempool are stated under the mempool section. The ordering of these transactions are based on their priority fees.
+- Along with user transactions, sequencer is also responsible for including system transactions, such as updating the `L1BlockHash` in the [BitcoinLightClient](/developer-documentation/system-contracts/bitcoin-light-client.md) or handling [Deposit](/developer-documentation/system-contracts/bridge.md) transacations.
+- The sequencer executes the assembled transactions against the current state of the rollup, updates the balances, storage values, and state. Gas usages and state changes are recorded in transaction receipts.
+- Once the trasactions are executed, the sequencer also generates a signed [soft confirmation](./soft-confirmation.md). This provides a soft-finality to the transactions.
+- The signed soft confirmation with block data is broadcasted to the network for full nodes to update their local chain state.
+
+Soft confirmations does not provide finality - you can refer to [Sequencer Commitments](./sequencer-commitments.md) for more information.
+
+#### Trust Assumptions
+
+Regarding the trust assumptions that come with sequencer's role, it's important to recall that ZK Proofs are used to ensure the validity of the transactions and the block. Combined with force transaction mechanism and on-chain data availability, the sequencer may cause liveness failures, but it cannot act maliciously and damage users' funds or freeze them voluntarily.
diff --git a/technical-specs/characteristics/block-production/soft-confirmation.md b/technical-specs/characteristics/block-production/soft-confirmation.md
new file mode 100644
index 0000000..c607864
--- /dev/null
+++ b/technical-specs/characteristics/block-production/soft-confirmation.md
@@ -0,0 +1,22 @@
+# Soft Confirmations
+
+Issued by the sequencer, soft confirmations in Citrea provide soft-finality for transactions in a block, offering users rapid feedback while the rollup awaits finalization on the DA layer. They represent interim state updates within the Citrea rollup.
+
+#### Structure
+
+Each soft confirmation encapsulates essential information about a block:
+
+- **Rollup Block Information:** The information of corresponding rollup block.
+- **Previous Hash**: The hash of the preceding soft confirmation, forming a chain of blocks that prevents replay attacks and ensures correct ordering.
+- **DA Block Information**: The height, hash, and the transaction commitment data of the associated DA block on Bitcoin.
+- **L1 Fee Rate**: The fee rate on Bitcoin L1, relevant for calculating transaction costs.
+- **Transactions**: Transaction data included in the block.
+- **State Root**: The root hash of the rollup state after applying the transactions in this soft confirmation.
+- **Signature**: The sequencer's signature on the soft confirmation data.
+- **Public Key**: The sequencer's public key used to verify the signature.
+- **Deposit Data**: Information about deposit transactions from the BitVM-based Clementine bridge.
+- **Timestamp**: The timestamp of the block, recording when it was produced by the sequencer.
+
+The structure above is signed and distributed to the network.
+
+Soft confirmations form the basis for [sequencer commitments](./sequencer-commitments.md), which are published to the DA layer for finalization.
diff --git a/technical-specs/characteristics/block-production/zero-confirmations.md b/technical-specs/characteristics/block-production/zero-confirmations.md
deleted file mode 100644
index 8e4f0bc..0000000
--- a/technical-specs/characteristics/block-production/zero-confirmations.md
+++ /dev/null
@@ -1,2 +0,0 @@
-# Zero Confirmations
-
