diff --git a/images/preconf-process.svg b/images/preconf-process.svg
new file mode 100644
index 00000000..7f758d41
--- /dev/null
+++ b/images/preconf-process.svg
@@ -0,0 +1,12 @@
+
\ No newline at end of file
diff --git a/knowledge-base/what-happens-during-a-blob-preconf.mdx b/knowledge-base/what-happens-during-a-blob-preconf.mdx
new file mode 100644
index 00000000..4781d240
--- /dev/null
+++ b/knowledge-base/what-happens-during-a-blob-preconf.mdx
@@ -0,0 +1,60 @@
+---
+title: What Happens During A Blob Preconfirmation?
+sidebarTitle: What Happens During A Blob Preconf?
+description: "Learn about what happens behind the scenes during a blob preconfirmation."
+---
+
+## Background
+
+EIP-4844 introduced blob-carrying transactions to Ethereum, providing a more cost-effective data availability solution for Layer 2 rollups. Blobs are ~125 KB data containers using KZG commitments, stored off-chain for approximately 18 days. The blob space operates on a separate fee market from regular gas, using a blob base fee that adjusts based on demand, similar to EIP-1559.
+
+## The Problem
+
+The fixed (large) size of blobs creates unique challenges:
+- Limited flexibility compared to regular transactions
+- Potential for extreme price volatility
+- Uncertainty in inclusion for time-sensitive L2 operations
+- Vulnerability to censorship by block builders
+
+These factors can lead to suboptimal mev extraction opportunities and unpredictable L2 state updates.
+
+## Using a Blob Preconfirmation
+
+Blob preconfirmations on mev-commit provide a way to secure blob inclusion in advance, which reduces uncertainty and volatility in the blob market. Here’s how:
+
+
+
+
+Bidders create a blob transaction (containing up to 6 blobs) and submit a bid on mev-commit including:
+- Transaction hash
+- Target slot (typically N+1)
+- Bid amount
+- Bid Evaluation
+
+Preconf providers analyze bids considering things like:
+- Bid amount
+- Potential impact on block propagation
+- Available space in the target block
+- Possible mev opportunities within the blob data
+
+
+
+
+If a bid is accepted, the provider generates a commitment. This commitment is sent back to the bidder, typically within milliseconds
+
+
+
+
+The bidder's node automatically verifies the received commitment, and the blob is now guaranteed to be included in the specified block as per the preconfirmation terms
+
+
+
+## Benefits
+
+Blob preconfirmations offer significant advantages for mev searchers, rollups themselves, and the broader Ethereum ecosystem, particularly:
+- By providing advanced knowledge of future blob content, preconfirmations enable mev searchers to develop more sophisticated cross-domain strategies that span multiple blocks, both between L2s and between L2s and L1.
+- The reduced uncertainty from preconfirmations allows for tighter latency optimization in mev extraction. Searchers can more accurately time their strategies because they know when specific blobs will be included.
+- With guaranteed inclusion, Layer-2 sequencers can adopt more aggressive strategies, which in turn may lead to new forms of mev specific to L2 systems.
+- Preconfirmations allow for collaborative building of type3 blockspace, which creates a pricing basis for a robust futures market. Such a market offers more reliable inclusion and price stability for rollups and other blob posters.
+- These benefits collectively contribute to a more efficient, predictable, and opportunity-rich environment for mev extraction, while also supporting the overall stability and functionality of Layer-2s.
+
diff --git a/knowledge-base/what-happens-during-an-execution-preconf.mdx b/knowledge-base/what-happens-during-an-execution-preconf.mdx
new file mode 100644
index 00000000..b6440fa0
--- /dev/null
+++ b/knowledge-base/what-happens-during-an-execution-preconf.mdx
@@ -0,0 +1,66 @@
+---
+title: What Happens During An Execution Preconfirmation?
+sidebarTitle: What Happens During A Preconf?
+description: "Learn about what happens behind the scenes during an execution preconfirmation."
+---
+
+Let's say you're a searcher or solver looking to execute a complex mev strategy on Ethereum involving multiple DeFi protocols.
+
+## Problem
+
+Currently, when you send a transaction bundle:
+- You define your maximum slippage tolerance for each trade (eg. 1%)
+- You broadcast your bundle to one or more block builders.
+- You wait about 12 seconds (1 block) or more for it to be included.
+
+During this time, you have no guarantee that:
+- Your entire bundle will be included in the next block.
+- The transactions won't revert due to changing conditions.
+- Other mev actors won't push your transaction toward your slippage limit
+
+As a result of these factors:
+- You might miss your target prices.
+- You might pay gas for failed transactions.
+- Your bundle may not get included, which is especially problematic for single-shot opportunities in DeFi. Some arbitrage opportunities only exist for a very brief window, and missing this window means losing the entire opportunity.
+
+## Using an Execution Preconfirmation
+
+
+
+Instead of blindly sending your transaction, you can use an execution preconf. Here's how:
+
+
+
+ - Follow the [Quickstart guide](/get-started/quickstart) to set up your mev-commit bidder node and fund your account.
+
+
+
+ - Identify your mev opportunity. Craft your bundle and send the signed transaction to block builders as per usual.
+
+
+
+ - Create and submit a bid for the transaction from your mev-commit bidder node (following the [bid structure here](concepts/bids/bid-structure)), supplying the hash of the transaction you just sent.
+ - When you submit a bid, it goes to multiple providers by default.
+ - If a provider accepts your bid, it will generate a cryptographic commitment to execute your transaction. These are typically sent in milliseconds.
+ - Your bidder node automatically verifies each commitment it receives.
+ - Aim to receive commitments from all registered providers. If you don’t, consider increasing your bid amount to make it more attractive to all providers.
+
+
+
+ - Your transaction is now guaranteed to be executed as per the preconf terms for that provider (or else that provider will be slashed).
+ - The transaction will execute in the specified block.
+
+
+**Benefits**
+
+ - Real-time confirmation of future execution, translating to reduced risk for transacting
+ - Ability to secure a specific execution slot at a better price
+ - Even in the event of being frontrun, your transaction parameters will remain within your defined slippage, or else not execute
+ - Instant transaction UX for searchers
+ - Predictable gas costs
+
+By using a preconf, you've eliminated the uncertainty of the 12-second wait, secured your execution parameters, and protected yourself against potential mev exploitation, all in real-time.
+
+Unlike simple inclusion preconfirmations (which might still result in reverted transactions), execution preconfs ensure your bundle executes as intended. This leaderless, multi-provider approach offers superior guarantees that improve your chances to capture time-sensitive mev opportunities.
+
+
diff --git a/mint.json b/mint.json
index 90bcc4bd..9f0247be 100644
--- a/mint.json
+++ b/mint.json
@@ -111,7 +111,9 @@
"knowledge-base/what-is-foundry",
"knowledge-base/why-is-cast-necessary-for-mev-commit-chain-interactions",
"knowledge-base/why-do-i-receive-the-same-commitment-when-resending-a-bid",
- "knowledge-base/what-is-execution-preconfirmations",
+ "knowledge-base/what-is-execution-preconfirmations",
+ "knowledge-base/what-happens-during-an-execution-preconf",
+ "knowledge-base/what-happens-during-a-blob-preconf",
"knowledge-base/eigenlayer-operator-registration"
]
},
+
+Instead of blindly sending your transaction, you can use an execution preconf. Here's how:
+