diff --git a/docs/_sidebar.md b/docs/_sidebar.md
index dc742b49..6df36788 100644
--- a/docs/_sidebar.md
+++ b/docs/_sidebar.md
@@ -31,7 +31,6 @@
- [Precompiled Contracts](/wiki/EL/precompiled-contracts.md)
- [Transaction](/wiki/EL/transaction.md)
- [DevP2P]
- - [MPT]
- [JSON-RPC](/wiki/EL/JSON-RPC.md)
- [Consensus Layer](/wiki/CL/overview.md)
- [CL Clients](/wiki/CL/cl-clients.md)
@@ -53,13 +52,13 @@
- [Scaling](/wiki/research/scaling/scaling.md)
- [Core Changes](/wiki/research/scaling/core-changes/core-changes.md)
- [EIP-4844](/wiki/research/scaling/core-changes/eip-4844.md)
- - Blobs
- Sharding
- Statelessness
- Purge
- - MEV
- - PBS
- - Censorship
+ - [MEV](/wiki/research/PBS/mev.md)
+ - [PBS](/wiki/research/PBS/pbs.md)
+ - [MEV-boost](/wiki/research/PBS/mev-boost.md)
+ - [ePBS](/wiki/research/PBS/ePBS.md)
- Proof of Stake
- [Upgrades](/docs/wiki/research/Beacon%20Chain%20Upgrades.md)
- SSF
diff --git a/docs/images/MEV-Boost blocks.png b/docs/images/MEV-Boost blocks.png
new file mode 100644
index 00000000..71a07d5f
Binary files /dev/null and b/docs/images/MEV-Boost blocks.png differ
diff --git a/docs/images/PBS-outline.png b/docs/images/PBS-outline.png
new file mode 100644
index 00000000..42ed7bc8
Binary files /dev/null and b/docs/images/PBS-outline.png differ
diff --git a/docs/images/mev-boost-architecture.png b/docs/images/mev-boost-architecture.png
new file mode 100644
index 00000000..4b74b980
Binary files /dev/null and b/docs/images/mev-boost-architecture.png differ
diff --git a/docs/images/pbs/block-building.png b/docs/images/pbs/block-building.png
new file mode 100644
index 00000000..93225c5a
Binary files /dev/null and b/docs/images/pbs/block-building.png differ
diff --git a/docs/images/pbs/mev-boost.png b/docs/images/pbs/mev-boost.png
new file mode 100644
index 00000000..f1886cff
Binary files /dev/null and b/docs/images/pbs/mev-boost.png differ
diff --git a/docs/images/pbs/scourge.png b/docs/images/pbs/scourge.png
new file mode 100644
index 00000000..9952aa57
Binary files /dev/null and b/docs/images/pbs/scourge.png differ
diff --git a/docs/wiki/research/PBS/ePBS.md b/docs/wiki/research/PBS/ePBS.md
new file mode 100644
index 00000000..0c8b3ee7
--- /dev/null
+++ b/docs/wiki/research/PBS/ePBS.md
@@ -0,0 +1,618 @@
+# Enshrined Proposer-Builder Separation (ePBS)
+
+## TLDR;
+
+Enshrined Proposer-Builder Separation (ePBS) refers to integrating the PBS mechanism directly into the Ethereum blockchain protocol itself, rather than having it operate through external services or addons. This integration aims to formalize and standardize the separation between the roles of block proposers and block builders within the core protocol rules, enhancing the system's efficiency, security, and decentralization.
+
+## What is PBS
+
+Proposer-Builder Separation (PBS) is a design philosophy[^1] and mechanism in within the context of Ethereum, that aims to decouple the roles of proposing blocks (proposers) and constructing the content of those blocks (builders). This separation addresses various challenges and inefficiencies associated with block production, and in the context of maximizing extractable value (MEV). This entry assumes reader has knowledge of [MEV](/wiki/research/PBS/mev.md), [PBS](/wiki/research/PBS/pbs.md), and [MEV-Boost](/wiki/research/PBS/mev-boost.md)
+
+## Overview of ePBS
+
+ePBS is a protocol-level enhancement for Ethereum that institutionalizes the division of labor between block proposers and block builders. Unlike the existing out-of-the-protocol solutions implementing [builder API](https://github.com/ethereum/builder-specs) in external software, like [MEV-Boost](/wiki/research/PBS/mev-boost.md), ePBS integrates this features directly into Ethereum clients, aiming to streamline and secure the process.
+
+The key difference between ePBS and current mechanisms like MEV-Boost lies in the protocol's direct support for the separation, eliminating the need for external relays to mediate the transaction. This enshrinement is designed to reduce trust requirements, enhance transparency, and improve overall network efficiency by formally defining the roles and interactions within the protocol itself[^2][^3].
+
+In the ePBS framework:
+
+- **Proposers** are validators responsible for proposing new blocks to the network. Their role is limited to choosing which block to propose, without the need to construct the block themselves. All the communication via builder API is done within the client without an external tool.
+
+- **Builders** are entities or algorithms that assemble blocks, optimizing the transaction order for profitability (e.g., maximizing MEV extraction) and offering these blocks to proposers through a transparent auction mechanism.
+
+- **Relays**, in the traditional MEV-Boost context, serve as intermediaries that facilitate the communication between proposers and builders. Under ePBS, the reliance on external relays is diminished or redefined, as the protocol itself facilitates the direct interaction between proposers and builders. The role of Relays will be significantly different from today's notion.
+
+### Transition from mev-boost to ePBS
+
+The transition from MEV-Boost to ePBS represents a pivotal evolution in Ethereum's approach to handling MEV and improving the network's efficiency and fairness. Dependency on an external, third party software can be dangerous and lead to network incidents even if clients themselves behave correctly.
+In the next section, we will cover the details on why ePBS is needed and what will the ecosystem gain from this in-protocol approach to PBS.
+
+## The Case for ePBS
+
+The transition to ePBS from the current MEV-Boost system is motivated by several key reasons that align with Ethereum's core values of decentralization, security, and efficiency. Proponents of ePBS highlight the importance of integrating PBS directly into the Ethereum protocol to address several concerns arising from the reliance on relays and out-of-protocol mechanisms for block construction. Here's a detailed explanation of these aspects[^4]:
+
+### Main Reasons for Transition to ePBS
+
+1. **Decentralization**: ePBS aims to reduce the reliance on a few centralized relays by embedding the PBS mechanism directly within the Ethereum protocol. This move seeks to distribute the responsibility for block construction across a broader set of participants, enhancing the network's resilience and reducing central points of failure.
+
+2. **Security**: By integrating PBS into the Ethereum protocol, ePBS ensures that the entire block construction process is governed by the same consensus rules and security guarantees that protect other aspects of the network. This contrasts with the current system, where off-chain relays operate without the direct oversight of Ethereum's consensus mechanisms.
+
+3. **Efficiency and Fairness**: ePBS proposes to create a more transparent and competitive marketplace for block space, potentially reducing the inefficiencies and inequities associated with MEV extraction. It aims to ensure that validators have more control and visibility over the blocks they propose, contributing to a fairer distribution of MEV rewards.
+
+### Contradiction of Core Values by Reliance on Relays
+
+- **Centralization Risks**: The current reliance on a limited number of relays introduces centralization into a network that prizes decentralization as a core principle. Centralized relays can become single points of failure or control, undermining the network's distributed nature.
+
+- **Security Vulnerabilities**: External relays, operating outside of Ethereum's consensus rules, could potentially be manipulated or attacked, posing security risks to the network. This external dependency contradicts Ethereum's goal of achieving robust, protocol-enshrined security.
+
+### Perceived Risks and Inefficiencies with Out-of-Protocol PBS
+
+- **MEV-Related Manipulations**: The current PBS mechanism, reliant on external relays, may not adequately protect against manipulative practices associated with MEV extraction, leading to unfair advantages and potential network instability.
+
+- **Opaque Operations**: The operation of relays outside the Ethereum protocol can lead to a lack of transparency and accountability, making it difficult to monitor and regulate block construction practices effectively.
+
+### Sustainability Concerns of Relays
+
+- **Operational Sustainability**: The long-term operational viability of relays is uncertain, as they depend on continuous participation and support from the community. Any disruption in relay services could significantly impact the network's ability to process transactions efficiently.
+
+- **Financial Model**: The financial sustainability of relays is also a concern. If the costs of running relays exceed the revenue generated from their operation, it could lead to a reduction in the number of relays, increasing centralization risks and affecting the competitive marketplace for block space.
+
+The transition towards ePBS involves critical economic and security considerations, especially in the context of Miner Extractable Value (MEV) and proposals like MEV burn. These considerations shape the debate around ePBS, highlighting its potential impact on the Ethereum ecosystem. Here's an exploration of these aspects:
+
+### Economic Considerations
+
+- **MEV Distribution**: One of the primary economic concerns revolves around how MEV is distributed among validators, builders, and users. ePBS aims to create a more transparent and equitable MEV market by ensuring that validators are fairly compensated for the blocks they propose. This could potentially alter the current dynamics, where certain participants may disproportionately benefit from MEV.
+
+- **Market Efficiency**: By integrating PBS directly into the Ethereum protocol, ePBS is expected to foster a more competitive and efficient marketplace for block space. This could lead to better pricing mechanisms for transaction inclusion, benefiting users with fairer transaction costs and potentially reducing the prevalence of gas price auctions that lead to network congestion.
+
+- **Sustainability of Relays**: ePBS addresses the operational and financial sustainability concerns of relays by potentially reducing their role in the MEV extraction process. A protocol-level solution could offer a more stable and predictable framework for handling MEV, alleviating the need for external relays and their associated costs.
+
+### Security Considerations
+
+- **Centralization Risks**: The current reliance on a limited set of MEV-Boost relays introduces centralization or cartelization risks, making the network more vulnerable to attacks or manipulations. ePBS seeks to mitigate these risks by decentralizing the process of block proposal and construction, aligning with Ethereum's security ethos.
+
+- **Manipulative Practices**: External relays and opaque MEV extraction mechanisms can lead to manipulative practices, such as transaction reordering or sandwich attacks, that undermine network integrity. ePBS aims to provide a more regulated and transparent environment for handling MEV, enhancing overall network security.
+
+- **Protocol-Enshrined Security**: Incorporating PBS directly into the Ethereum protocol ensures that block construction adheres to the same rigorous consensus and security standards that govern other aspects of the network. This unified approach to security is seen as a significant improvement over the current system, where external components like relays operate without direct protocol oversight.
+
+### MEV Burn
+
+The concept of MEV burn involves redirecting a portion of MEV profits towards burning Ether, reducing the overall supply and potentially increasing the value of the remaining Ether. This mechanism has been proposed as a way to align the interests of validators, builders, and the wider Ethereum community by ensuring that excessive MEV extraction does not lead to inflationary pressures or disproportionate benefits for certain network participants.
+
+- **Inflationary Pressure Mitigation**: By burning a part of the MEV, Ethereum could potentially control inflationary pressures arising from new Ether issuance for block rewards.
+
+- **Economic Stability**: MEV burn could contribute to the economic stability of Ethereum by ensuring that the benefits of MEV extraction are more evenly distributed across the ecosystem, including Ether holders who are not directly involved in MEV strategies.
+
+- **Alignment of Incentives**: Implementing an MEV burn mechanism could help align the incentives of various network participants, ensuring that the pursuit of MEV does not compromise network security or efficiency.
+
+The transition to ePBS from the current MEV-Boost system is driven by a combination of economic and security considerations, including concerns about MEV distribution, market efficiency, centralization risks, and the operational sustainability of relays. The potential implementation of an MEV burn mechanism further reflects Ethereum's commitment to aligning economic incentives with its core values of decentralization, security, and efficiency. This transition marks a pivotal moment in Ethereum's evolution, potentially reshaping the landscape of transaction ordering and MEV extraction in favor of a more secure, efficient, and equitable ecosystem.
+
+## Counterarguments to ePBS
+
+The discussion around the enshrinement of PBS (ePBS) within Ethereum's protocol has stirred significant debate, with various counterarguments presented by its critics. Proponents of ePBS, however, offer robust responses to these concerns, advocating for its necessity and integration into Ethereum's roadmap. Additionally, the discourse explores alternative methods for addressing miner extractable value (MEV), weighing their sufficiency against the proposed ePBS system[^3].
+
+### Primary Counterarguments Against ePBS
+
+- **Complexity and Technical Risk**: Critics argue that incorporating ePBS into Ethereum's core protocol significantly increases its complexity and introduces new technical risks, potentially jeopardizing network stability and security.
+
+- **Network Performance Concerns**: There is apprehension that ePBS could impact Ethereum's network performance, specifically relating to latency and block propagation times, which could, in turn, affect transaction processing efficiency.
+
+- **Reduced Flexibility for Validators**: Some contend that ePBS might limit validators' flexibility in choosing block proposals, potentially centralizing decision-making power among a few large builders.
+
+- **Premature Optimization**: Skeptics suggest that focusing on ePBS might be a case of premature optimization, diverting attention and resources from more pressing issues on Ethereum's roadmap.
+
+- **Bypassability**: Bypassability refers to the ability of participants within the Ethereum ecosystem—be it validators, proposers, builders, or others—to sidestep or bypass the rules and mechanisms established by ePBS. This could occur through off-protocol agreements, alternative transaction ordering systems, or other means that effectively operate outside the constraints set by ePBS. The protocol will have no easy way to enforce ePBS rules on them[^8].
+
+### If it ain't broke, don't fix it - counterarguments
+
+The "If it ain't broke, don't fix it" perspective emerges as a significant counterargument against the ePBS within Ethereum's protocol. This viewpoint is grounded in caution and a preference for maintaining the status quo unless there's an unequivocal necessity for change. Here’s how this perspective shapes the counterarguments against ePBS:
+
+**Reliance on Existing Systems**
+
+Critics holding this perspective argue that the current mechanisms for handling MEV, including MEV-Boost and the relay system, have proven functional and effective in their operational context. They suggest that these systems have not only stabilized but also facilitated a certain equilibrium within Ethereum's ecosystem, balancing efficiency, security, and validator autonomy without necessitating a profound protocol overhaul.
+
+**Risk of Unintended Consequences**
+
+A fundamental concern is the potential for unintended consequences that a significant alteration like ePBS might introduce to the network. This viewpoint highlights the complexity and interdependence within Ethereum's system, where modifications at the protocol level could precipitate unforeseen vulnerabilities, security risks, or compromises in network performance. The argument posits that the benefits of ePBS might not justify the risks associated with disrupting a functioning system.
+
+**Development Focus and Resource Allocation**
+
+From the "If it ain't broke, don't fix it" standpoint, the emphasis on developing and implementing ePBS might divert valuable resources and attention from other critical areas within Ethereum's ecosystem that require immediate attention or offer clearer benefits. Critics suggest that Ethereum's development focus should prioritize scalability solutions, Layer 2 enhancements, and other upgrades that directly contribute to user experience and network capacity without introducing the complexities associated with ePBS.
+
+**The Challenge of Proving Necessity**
+
+This perspective demands a higher standard of proof for the necessity of ePBS. Critics argue that for a change of this magnitude to be justified, it must be clear that existing systems are not merely suboptimal but fundamentally broken in a way that directly impedes Ethereum's operation or principles. The call for ePBS is seen as a solution seeking a problem, rather than a response to a critical need.
+
+**Emphasizing Evolution Over Revolution**
+
+Finally, the "If it ain't broke, don't fix it" argument is rooted in a preference for evolutionary rather than revolutionary changes within the Ethereum protocol. Proponents of this view prefer incremental improvements and optimizations to existing systems over wholesale architectural changes, advocating for a cautious approach that values stability and predictability.
+
+### Proponents' Responses and Advocacy for ePBS
+
+- **Mitigating Complexity and Technical Risk**: ePBS advocates argue that while the proposal introduces new elements to the protocol, these are manageable and outweighed by the benefits of enhanced fairness, security, and MEV distribution efficiency. Rigorous testing and phased implementation are proposed to mitigate risks.
+
+- **Addressing Network Performance**: Proponents maintain that ePBS can be designed with network efficiency in mind, leveraging advancements in technology and protocol engineering to minimize any adverse effects on latency or block propagation.
+
+- **Enhancing Validator Decision-Making**: ePBS supporters argue that by structuring the builder market more transparently and competitively, validators will actually have more informed choices, not less, promoting healthier decentralization.
+
+- **Strategic Importance on the Roadmap**: ePBS is considered by its advocates as not merely an optimization but a foundational improvement to Ethereum's economic and security models. It addresses pressing concerns related to MEV extraction practices and aligns with Ethereum's long-term goals of decentralization and scalability.
+
+**Alternatives to ePBS and Their Evaluation**
+
+- **Improved MEV-Boost and Relays**: Some suggest that refining the existing MEV-Boost system and enhancing relay operations could address many of the concerns ePBS aims to solve, without necessitating protocol-level changes.
+
+- **MEV Burn Mechanisms**: Another alternative is the implementation of MEV burn mechanisms, where a portion of MEV profits is burned, potentially reducing the incentive for manipulative practices.
+
+- **Layer 2 Solutions and Decentralized Relays**: Exploring layer 2 solutions for transaction ordering or developing decentralized relay networks are also proposed as ways to mitigate MEV issues without altering the core protocol.
+
+ePBS proponents argue that while these alternatives offer partial solutions, they do not comprehensively address the root issues of fairness, security, and decentralization that ePBS aims to solve. Moreover, they maintain that ePBS is a strategic enhancement that supports Ethereum's long-term vision, arguing for its prioritization amidst other developments.
+
+The debate over ePBS encapsulates a broader discussion about Ethereum's future direction, balancing innovation with caution. While counterarguments emphasize risks and alternatives, ePBS advocates underline its alignment with Ethereum's core principles and its necessity for ensuring a fair, secure, and efficient blockchain ecosystem[^5].
+
+## Designing ePBS
+
+### Desirable properties of ePBS mechanisms
+
+The debate on the optimal ePBS mechanism and the concept of a minimum viable ePBS (MVePBS) revolves around identifying the core features and properties that such a system must possess to effectively address the challenges it aims to solve within the Ethereum ecosystem. This involves balancing the goals of decentralization, efficiency, security, and fairness, while also considering the practical implications of implementation and adoption. Here's a look at the central aspects of this debate and the properties considered essential for a minimum viable ePBS[^6].
+
+**Core Properties of MVePBS**
+
+- **Decentralization and Fair Access:** MVePBS must ensure that the process of proposing and building blocks remains decentralized, preventing any single entity from gaining disproportionate control or influence. This includes fair access to MEV opportunities and block space for all participants, maintaining Ethereum's ethos of decentralization.
+
+- **Security and Integrity:** The design should not compromise the security of the Ethereum network. This includes safeguarding against attacks that could arise from the separation of proposing and building roles, such as censorship, double-spending, or reordering attacks that could undermine the integrity of transactions.
+
+- **Efficiency and Scalability:** MVePBS should enhance, or at least not significantly detract from, the network's efficiency and scalability. This involves minimizing the added computational and communication overhead, ensuring that the system can scale with Ethereum's growth and increasing demand.
+
+- **Transparency and Predictability:** The mechanism should provide transparency in transaction ordering and block production, allowing participants to understand how decisions are made within the ePBS framework. This predictability helps in managing MEV in a way that is consistent and fair to all network users.
+
+- **Reduced Trust Requirements:** By enshrining PBS into the protocol, the system aims to reduce reliance on trust between different parties (e.g., between proposers and builders, or between users and relays). The design should minimize opportunities for off-protocol agreements that could bypass the intended fairness of the system.
+
+- **Fairness in MEV Distribution:** ePBS should aim to level the playing field regarding access to MEV, ensuring that opportunities for value extraction are fairly distributed among participants. This involves creating mechanisms that prevent monopolistic control over MEV opportunities by a few large players.
+
+- **Minimal Trust Assumptions:** The design should minimize the need for trust between proposers, builders, and validators. By enshrining PBS into the Ethereum protocol, ePBS mechanisms should leverage cryptographic and game-theoretic principles to ensure that participants can operate in a trust-minimized environment.
+
+- **Economic Viability:** ePBS mechanisms must be economically viable for all participants, including proposers, builders, and validators. This involves ensuring that the costs associated with participating in the ePBS ecosystem (e.g., staking requirements, transaction fees) do not outweigh the potential benefits, thus encouraging broad participation.
+
+- **Flexibility and Compatibility:** The ePBS framework should be flexible enough to accommodate future innovations and changes within the Ethereum ecosystem, including upgrades and new layer-2 solutions. It should also be compatible with existing infrastructure to facilitate a smooth transition.
+
+- **Reduced Complexity for Users:** While ePBS introduces additional complexity at the protocol level, it should strive to minimize the impact of this complexity on end-users and developers. The system should be designed so that interacting with Ethereum remains as intuitive and straightforward as possible.
+
+- **Incentive Alignment:** The incentives within the ePBS mechanism should be carefully designed to align the interests of all network participants, including users, proposers, builders, and validators. This alignment is crucial for ensuring the long-term health and stability of the network.
+
+**Minimal trustless system for ePBS**
+
+Integrating these below constraints provides a comprehensive view of the minimal trustless system envisioned for ePBS[^6]. It underscores the need for robust protections for both builders and proposers, ensuring fairness, reducing reliance on trust, and maintaining Ethereum's decentralized principles. This refined approach addresses the complex interplay between economic incentives, security considerations, and the overarching goal of enhancing Ethereum's protocol efficiency and integrity.
+
+- **Honest Builder Publication Safety**: This constraint ensures that builders who follow protocol rules and publish their blocks in a timely manner are guaranteed that their blocks will be considered for inclusion in the blockchain, safeguarding against censorship and ensuring their efforts are recognized.
+
+- **Builder Reveal Safety**: Protects builders when they reveal their bids and blocks. This means that even after revealing their proposed block content, they are protected against proposer equivocation or other actions that might compromise their position.
+
+- **Mandatory Honest Reorgs**: Enforces that any reorganizations of the blockchain adhere to predefined rules that favor honesty, deterring malicious reorgs designed to censor or usurp valid transactions for MEV extraction.
+
+- **Builder Withholding Safety**: Guarantees that builders cannot be unfairly penalized for withholding a block as a strategic response to network conditions or potential censorship, provided they act within the protocol's guidelines.
+
+- **Unconditional Payment**: Ensures that builders receive payment for their work regardless of external factors, such as whether their block was ultimately included in the chain, provided they followed the protocol. This minimizes trust by making compensation mechanisms transparent and automatic.
+
+- **Proposer Safety**: Protects proposers by ensuring that they can safely commit to including a block without the risk of losing out on transaction fees or other forms of compensation. This encourages active participation in the block proposal process.
+
+- **Honest Builder Payment Safety**: This aspect guarantees compensation for builders who are selected and fulfill their block production duties according to the protocol's expectations.
+
+- **Permissionlessness**: Maintains the Ethereum ethos of open participation by allowing any entity to act as a builder or proposer without needing authorization from a central authority, fostering a competitive and decentralized environment.
+
+- **Censorship Resistance**: Essential for upholding Ethereum's decentralized nature by ensuring that blocks and transactions cannot be censored by a few powerful nodes, maintaining network integrity and openness.
+
+- **Roadmap Compatibility**: Ensures that any ePBS mechanism aligns with Ethereum's technical development path, supporting seamless integration with future upgrades and changes to the ecosystem.
+
+Additionally, in such a minimal trustless system for ePBS, there should be no inherent advantage for proposers, to sell their blocks to builders off-protocol.
+
+**Debating the Optimal Mechanism**
+
+The debate on the optimal ePBS mechanism involves weighing various design choices against these core properties, often requiring trade-offs[^9][^3].
+
+- **Auction Mechanisms:** There's significant discussion around the best way to conduct auctions for block space and MEV opportunities—whether through second-price auctions, or more complex mechanisms like frequent batch auctions. Each has implications for fairness, efficiency, and vulnerability to manipulation.
+
+- **Builder Selection and Staking:** Deciding how builders are selected for proposing blocks—whether through staking, reputation systems, or randomized selection—impacts decentralization and security. Staking, for example, could provide economic security but might also centralize opportunities among wealthier participants.
+
+- **Inclusion and Censorship Resistance:** Ensuring the system resists censorship and includes transactions equitably is crucial. This may involve mechanisms for anonymous transaction submission or commitments to include certain transactions (e.g. Inclusion Lists), balancing against the potential for spam or malicious transactions.
+
+- **Compatibility and Adaptability:** The ePBS must be compatible with existing Ethereum infrastructure and adaptable to future changes to meet the roadmap, including upgrades like sharding or new layer-2 solutions.
+
+Determining the minimum viable ePBS involves a delicate balance of these properties, necessitating a mechanism that promotes decentralization, ensures security and efficiency, maintains transparency and fairness, and reduces reliance on trust. Ongoing discussions and research within the Ethereum community are crucial for refining these concepts and moving towards a consensus on the optimal ePBS mechanism.
+
+## ePBS Solutions
+
+### The Two-Block HeadLock (TBHL) proposal
+
+The Two-Block HeadLock (TBHL) design represents an innovative approach to proposer-builder separation (PBS) within the Ethereum protocol, aiming to address both the operational and strategic issues posed by miner extractable value (MEV) [quote here Why enshrine Proposer-Builder Separation? A viable path to ePBS]. This design is a nuanced iteration of previous proposals, integrating elements of Vitalik Buterin's two-slot design and enhancing it with a headlock mechanism to safeguard builders from proposer equivocations. Here, we delve into the key components of TBHL and its operational mechanics, drawing on the detailed explanation provided[^4].
+
+**TBHL Design Overview**
+
+TBHL modifies the conventional slot structure in Ethereum, introducing a dual-block system within a single slot timeframe, effectively producing a proposer block and a builder block. This system retains the essence of a single execution payload per slot, though with an additional round of attestations, potentially extending the slot duration. TBHL aligns closely with Ethereum's existing LMD-GHOST mechanism and adheres to six specified design properties, ensuring compatibility and integrity within the Ethereum ecosystem.
+
+**Slot Anatomy and Operational Phases**
+
+
+
+_Figure – The slot anatomy of TBHL. Credit by mike neuder and justin drake._
+
+The operational framework of TBHL is structured around four critical timestamps within a slot, delineated for specific actions by proposers, builders, and attesters:
+
+1. **t=t0 - Proposal of the Winning Bid:** The proposer begins by evaluating bids within the bidpool, a peer-to-peer (P2P) topic where builders submit their bids. Upon selecting a bid, the proposer publishes a proposer block before moving to the next phase.
+
+2. **t=t1 - Attestation Deadline for Proposer Block:** Here, the attesting committee assesses the timeliness of the proposer block. They vote for the first observed block, or in its absence, vote for an empty slot.
+
+3. **t=t1.5 - Equivocation Check:** The attesting committee for the builder block evaluates the proposer blocks for equivocations. A unique proposer block prompts a proposer boost for the associated builder, enhancing the fairness and integrity of the process.
+
+4. **t=t2 - Builder's Verification and Block Publication:** Builders verify their selection as the unique winner. In the event of an equivocation, they can produce a block containing proof to revert their payment. Otherwise, they proceed to publish their builder block, containing the transaction contents.
+
+5. **t=t3 - Second Attestation Deadline:** This phase involves another round of attestations, this time for the builder block, solidifying its position within the blockchain.
+
+**Satisfying ePBS Design Properties**
+
+TBHL effectively addresses several critical ePBS design properties:
+
+- **Honest Builder Publication and Payment Safety:** Protection mechanisms ensure that builders can confidently publish blocks, with safeguards against proposer equivocations.
+
+- **Honest Proposer Safety:** Commitments made by honest proposers are respected, with their blocks receiving necessary attestations and unconditional payments proceeding unless equivocation proof is presented.
+
+- **Permissionlessness and Censorship Resistance:** The design promotes an open and competitive environment for builders while maintaining measures to combat censorship.
+
+- **Roadmap Compatibility:** TBHL is poised to integrate seamlessly with Ethereum's roadmap, including single-slot finality (SSF) and MEV-burn mechanisms, illustrating its adaptability and foresight in addressing future network needs.
+
+**Engineering Challenges of implementing TBHL**
+
+Implementing TBHL proposal introduces several nuanced challenges and engineering issues, reflective of the complex interplay between Ethereum's consensus mechanism, the dynamic MEV landscape, and the protocol's overarching design philosophy. Drawing from the detailed exploration within the ePBS discussion, here are the primary implementation issues and engineering drawbacks associated with TBHL:
+
+- **Increased Protocol Complexity** TBHL significantly alters the traditional slot structure by introducing a dual-block mechanism within a single slot, complicating the consensus process. This complexity arises from managing two distinct types of blocks (proposer and builder blocks) and necessitates additional rounds of attestations to validate each. The complexity is further amplified by the need to detect and manage proposer block equivocations, requiring robust mechanisms to ensure builder safety and payment security.
+
+- **Slot Timing and Network Latency** Implementing TBHL requires careful consideration of slot timing, as the additional attestation rounds could potentially extend the slot duration. This adjustment impacts network latency, potentially affecting the timeliness of block propagation and attestation aggregation. Ensuring the network's ability to efficiently handle these processes without introducing significant delays or vulnerabilities is a substantial engineering challenge. Besides increasing slot duration change is a very big engineering project in Ethereum post merge as it requires changes to CL, EL and other smart contracts layers.
+
+- **Equivocation and Builder Safety Mechanisms** One of the critical components of TBHL is its approach to managing proposer equivocations to safeguard builders. Designing and implementing robust mechanisms to detect equivocations, allow builders to provide proof of such occurrences, and revert payments accordingly, introduces significant complexity. These mechanisms must be foolproof to prevent exploitation and ensure the system's integrity, demanding rigorous testing and potential iterations in response to discovered vulnerabilities.
+
+- **Permissionlessness and Censorship Resistance** While TBHL aims to maintain a permissionless environment and combat censorship, achieving these goals within the new framework poses challenges. Ensuring that any builder can submit bids and that proposer blocks fairly represent the competitive landscape requires transparent and secure handling of the bidpool. Moreover, integrating forward inclusion lists or other censorship resistance mechanisms within the TBHL structure necessitates additional protocol considerations to prevent manipulation or exclusionary practices.
+
+- **Compatibility with Existing and Future Ethereum Features** TBHL must seamlessly integrate with Ethereum's current protocol features and be adaptable to future innovations, such as single-slot finality (SSF) and MEV-burn mechanisms. Ensuring compatibility with these evolving aspects of the Ethereum ecosystem demands a forward-looking approach to design and implementation, capable of accommodating adjustments and enhancements without undermining the TBHL framework's integrity or efficacy.
+
+- **Resource and Computational Overheads** The introduction of TBHL introduces new computational and resource overheads, particularly related to handling the increased data volume from the dual-block mechanism and the additional attestation rounds. Optimizing the protocol to manage these demands efficiently, without significantly increasing the computational burden on validators or compromising the network's performance, is an essential engineering concern.
+
+The TBHL proposal stands as a testament to the ongoing efforts to refine Ethereum's PBS mechanisms, striving for a balance between operational efficiency, security, and the overarching ethos of decentralization. By addressing the nuances of proposer-builder dynamics and introducing robust safeguards, TBHL marks a significant step forward in the evolution of Ethereum's protocol design, offering a promising avenue for mitigating the challenges posed by MEV while enhancing the network's resilience and integrity.
+
+### Payload-Timeliness Committee (PTC)
+
+The Payload-Timeliness Committee (PTC) proposal is a design for enshrining Proposer-Builder Separation (ePBS) within the Ethereum protocol. It represents an evolution of the mechanism to determine block validity and includes a subset of validators who vote on the timeliness of a block's payload[^7].
+
+#### High-Level Overview
+
+```mermaid
+sequenceDiagram
+ autonumber
+ rect rgb(240, 237, 225)
+ participant V as Validator (Proposer)
+
+ participant C as Attesting Committee
+ participant B as Builder
+ participant PTC as Payload-Timeliness Committee
+ participant N1 as Next Proposer (Slot N+1)
+
+ rect rgb(255, 190, 152)
+ Note over V: Slot N begins
+ V->>V: Proposes CL block with builder bid at t=t0
+ Note over V: Block contains no ExecutionPayload
+ end
+ rect rgb(219,188,157)
+ Note over C: Attestation deadline at t=t1
+ C->>C: Use fork-choice to determine chain head
+ C->>V: Attestation
+ end
+ rect rgb(212,202,205)
+ Note over B: At t=t2 Broadcast of Aggregate Attestations
+ C->>C: Begin broadcasting aggregate attestations
+ B-->>V: Publishes execution payload if no equivocation seen
+ end
+ rect rgb(177,176,159)
+ Note over PTC: At t=t3 Cast vote for payload timeliness
+ PTC->>PTC: Votes on payload release timeliness
+ end
+ rect rgb(203, 134, 143)
+ Note over N1: At t=t4 Propagation of next block
+ N1->>N1: Publishes block based on PT votes and attestations
+ end
+ end
+```
+
+_Payload-Timeliness Committee Flow_
+
+The proposal introduces a new slot anatomy with an additional phase for Payload-Timeliness (PT) votes to propagate. It aims to refine the roles of proposers and builders in the block creation process, ensuring that proposers remain lightweight and unsophisticated entities for the goal of decentralization, and specialized builders can create high-value blocks efficiently.
+
+1. **Block Propagation**: An elected Proof-of-Stake (PoS) validator, known as the proposer, broadcasts a CL block at the beginning of their slot (`t=t0`). This block contains a builder's bid but not the actual payload ( i.e. transactions).
+2. **Attestation Aggregation**: At the attestation deadline (`t=t1`), validators, known as attestors, vote on the perceived head of the chain using their local fork-choice rule.
+
+3. **Aggregation & Payload Propagation**: The builder sees the CL block and publishes the execution payload. The validator committee begins to broadcast aggregated attestations.
+
+4. **Payload-Timeliness Vote Propagation**: At (`t=t3`), the Payload-Timeliness Committee casts their votes on whether the payload was timely released.
+
+5. **Next Block Propagation**: At (`t=t4`), the next proposer publishes their block, deciding to build on either the full or empty block based on the PT votes they've observed.
+
+#### Honest Attesting Behavior
+
+Honest attestors will consider the payload-timeliness when casting their votes. Their behavior revolves around the PT votes, which influence the subsequent block choice. The votes indicate whether a payload is present, unavailable, or whether there's been an equivocation by the builder. The weight given to a full or empty block in the fork-choice is based on these PT votes.
+
+#### Properties and Potential New Attack Vectors
+
+**Properties**:
+
+- **Honest-Builder Payment Safety**: If a builder's bid is processed, their payload becomes canonical.
+
+- **Honest-Proposer Safety**: If a proposer commits to a single block on time, they will receive the payment.
+
+- **Honest-Builder Same-Slot Payload Safety**: An honest builder can ensure their payload for a slot cannot be overridden by another payload in the same slot.
+
+**Non-Properties**:
+
+- **Honest-Builder Payload Safety**: Builders can't be sure their payload will become canonical; the design does not protect from next-slot splitting.
+
+**Potential New Attack Vectors**:
+
+- **Proposer-Initiated Splitting**: A proposer could release their block close to the deadline, causing a split in the attesting committee's views.
+
+- **Builder-Initiated Splitting**: Builders could selectively reveal payloads to part of the committee to influence the next proposer’s block, potentially causing it to be orphaned if the committee’s votes differ significantly.
+
+**Builder Payment Processing**:
+
+- Payments are processed if the builder’s payload header is part of the canonical chain and there's no evidence of proposer equivocation.
+
+**Differences from Other Designs**:
+
+- The PT votes influence the fork-choice weight but do not create separate forks.
+- The payload view informs subsequent committee votes, which usually align with the proposer.
+- Builders do not receive a proposer boost or explicit fork-choice weight.
+
+### Protocol-Enforced Proposer Commitments (PEPC)
+
+PEPC, a conceptual extension and generalization of PBS, introduces a more flexible and secure way for proposers (validators) to commit to the construction of blocks. Unlike the existing MEV-Boost mechanism, which relies on out-of-protocol agreements between proposers and builders/relays, PEPC aims to enshrine these commitments within the Ethereum protocol itself, offering a trustless and permissionless infrastructure for these interactions[^10][^11].
+
+#### Benefits of PEPC
+
+The introduction of Protocol-Enforced Proposer Commitments (PEPC) into Ethereum's ecosystem carries both promising benefits and notable disadvantages, reflecting the complex balance between innovation, security, scalability, and usability. Here's a detailed look at these aspects:
+
+**Enhanced Security and Trustlessness:**
+
+PEPC's primary advantage lies in its ability to enforce agreements between proposers and builders within the Ethereum protocol itself, minimizing trust assumptions. This internalization of commitments enhances security by making it harder for external parties to manipulate transaction inclusion or exploit the proposer-builder relationship.
+
+**Increased Flexibility in Block Construction:**
+
+By allowing for programmable contracts between proposers and builders, PEPC introduces a high degree of flexibility. This can accommodate a variety of block construction scenarios, from full blocks to partial blocks and future slot auctions, enabling more efficient use of block space.
+
+**Decentralization of MEV Opportunities:**
+
+PEPC could potentially lead to a more equitable distribution of Maximal Extractable Value (MEV) opportunities among validators. By embedding diverse commitment mechanisms into the protocol, it reduces the risk of centralizing these opportunities in the hands of a few large operators.
+
+**Scalability and Efficiency Improvements:**
+
+The system aims to optimize the process of block construction and validation, potentially reducing the overhead associated with these tasks. This could contribute to the overall scalability and efficiency of the Ethereum network, aligning with its long-term goals.
+
+**Economic Innovation:**
+
+PEPC opens up new avenues for economic innovation within Ethereum. By enabling different types of transactions and block construction contracts, it could foster novel economic models and incentives, enhancing the dynamism and diversity of the Ethereum economy.
+
+#### Disadvantages of PEPC
+
+**Complexity and Implementation Challenges:**
+The flexible and generalized nature of PEPC introduces significant complexity into the Ethereum protocol. Designing, implementing, and maintaining such a system poses substantial technical challenges, increasing the risk of bugs, vulnerabilities, and unintended consequences.
+
+**Increased Computational Overhead:**
+Enforcing proposer commitments within the protocol could lead to increased computational overhead for validators, impacting the network's performance. This might necessitate more powerful hardware or sophisticated optimization techniques to maintain efficiency.
+
+**Potential for Centralization:**
+While PEPC aims to decentralize MEV opportunities, its complexity could inadvertently favor large, technically sophisticated operators capable of navigating the intricacies of the system. This could counteract efforts to decentralize the network further.
+
+**Economic Uncertainty:**
+The introduction of PEPC could disrupt existing economic models and incentives within Ethereum, leading to uncertainty. Adjusting to new mechanisms for transaction inclusion and block construction may require time, potentially impacting network stability and user experience.
+
+**Difficulty in Balancing Flexibility and Security:**
+Finding the right balance between the flexibility offered by PEPC and the need to maintain a secure, reliable network is challenging. Too much flexibility could make the system unwieldy and difficult to secure, while too little could stifle innovation and efficiency.
+
+#### Tradeoffs of Implementation of PEPC
+
+The implementation of PEPC in Ethereum involves several trade-offs, reflecting a balance between advancing the protocol's capabilities and managing new complexities and risks. These trade-offs highlight the nuanced considerations necessary to evolve Ethereum's infrastructure responsibly:
+
+**Trade-off 1: Flexibility vs. Complexity**
+
+- **Flexibility:** PEPC introduces a highly flexible framework for proposers and builders, allowing a variety of customized and programmable commitments. This flexibility can lead to more efficient use of block space and innovative economic arrangements.
+- **Complexity:** With increased flexibility comes heightened complexity in protocol design, implementation, and operation. This complexity can raise the barrier to entry for validators and builders, potentially centralizing participation to those with significant technical resources.
+
+**Trade-off 2: Security vs. Overhead**
+
+- **Security:** By embedding proposer commitments directly into the protocol, PEPC enhances the trustlessness and security of block construction, reducing reliance on external parties and minimizing the potential for manipulation.
+- **Overhead:** Implementing these commitments within the Ethereum protocol increases computational and operational overhead. Validators may face higher demands on processing and storage, impacting the network's efficiency and scalability.
+
+**Trade-off 3: Economic Innovation vs. Stability**
+
+- **Economic Innovation:** PEPC opens the door to new economic models and incentive structures within Ethereum, potentially improving the distribution of MEV and fostering a more dynamic and fair ecosystem.
+- **Stability:** These new economic models introduce uncertainty and may disrupt existing revenue streams and participation incentives. Adjusting to these changes could pose challenges for validators, builders, and users, affecting network stability and predictability.
+
+**Trade-off 4: Decentralization of MEV vs. Risk of Centralization**
+
+- **Decentralization of MEV:** By enabling a broader range of proposer-builder arrangements, PEPC aims to distribute MEV opportunities more widely among participants, aligning with Ethereum's decentralization goals.
+- **Risk of Centralization:** The complexity and technical demands of navigating PEPC could inadvertently favor larger, more sophisticated operators, potentially centralizing control and undermining the objective of broadening participation.
+
+**Trade-off 5: Long-term Scalability vs. Short-term Performance**
+
+- **Long-term Scalability:** PEPC's innovations could contribute to Ethereum's scalability over the long term by optimizing block space usage and enabling more sophisticated transaction inclusion mechanisms.
+- **Short-term Performance:** The introduction of PEPC and the transition to its mechanisms may initially impact the network's performance, as validators and the infrastructure adapt to the increased complexity and computational demands.
+
+#### How would PEPC work?
+
+```mermaid
+sequenceDiagram
+ participant V as Validator (Proposer)
+ participant B as Builders
+ participant P as Protocol
+ participant N as Network Validators
+
+ V->>V: Define Proposer Commitments (PCs)
+ rect rgb(240, 237, 225)
+
+ V->>P: Generate Commit-Block with PCs & Payload Template
+ loop Builder Submissions
+ B->>V: Submit Blocks/Parts fulfilling PCs
+ end
+ end
+
+ rect rgb(177,176,159)
+ V->>P: Verify Submissions against PCs
+ alt Submission satisfies PCs
+ V->>V: Incorporate Submission into Block
+ V->>N: Publish Finalized Block
+ N->>N: Validate Block (Consensus & PCs)
+ N->>P: Include Block in Blockchain
+ else Submission does not satisfy PCs
+ V->>V: Reject Submission
+ end
+ end
+```
+
+
+
+_Figure – PEPC flow._
+
+The operation of PEPC involves several key components and steps, which together ensure its seamless integration into the Ethereum ecosystem. Here’s an overview of how PEPC would work in practice:
+
+**Step 1: Commit Phase**
+
+- **Proposal Creation:** A validator (proposer) prepares to create a block by defining a set of commitments. These commitments represent agreements or contracts that specify how the block will be constructed. This could include, for example, commitments to include certain transactions, not to include others, or to structure the block in a specific way.
+
+- **Commit Block Generation:** The proposer generates a commit-block that includes these proposer commitments (PCs) alongside the usual consensus data like attestations. This commit-block does not yet contain the full execution payload but specifies a payload template or placeholders for the expected content based on the commitments.
+
+**Step 2: Reveal Phase**
+
+- **Builder Submissions:** Builders, in response to the commitments published by the proposer, submit their proposed blocks or block parts to fulfill the commitments. This might involve submitting specific transactions, execution payloads, or other block components as defined by the initial commitments.
+
+- **Commitment Verification:** Upon receiving submissions from builders, the proposer or the protocol itself verifies that these submissions satisfy the proposer commitments. This verification process ensures that only those blocks or block parts that meet the predefined criteria are considered for inclusion.
+
+- **Block Finalization:** Once a submission from a builder is verified to fulfill the proposer commitments, the proposer finalizes the block by incorporating the builder's submission into the payload template or placeholders defined in the commit phase. The finalized block is then published to the network.
+
+**Step 3: Validation and Inclusion**
+
+- **Network Validation:** Other validators on the network validate the finalized block, ensuring it adheres to the Ethereum protocol rules and the specific proposer commitments. This step may involve standard block validation procedures, along with additional checks for commitment fulfillment.
+
+- **Block Inclusion:** Upon successful validation, the block is included in the blockchain. This inclusion is contingent on the block satisfying both the usual Ethereum consensus rules and the specific proposer commitments outlined in the commit phase.
+
+**PEPC's Mechanisms for Flexibility and Security**
+
+- **Programmable Contracts:** PEPC allows proposers to enter into various programmable contracts with builders, ranging from full blocks to partial blocks, and even future slot auctions. This versatility enables a tailored approach to block construction, maximizing efficiency and optimizing block space usage.
+
+- **Atomicity and Trustlessness:** The commit-reveal scheme ensures that either all parts of a commitment are fulfilled, or the block is rejected, maintaining atomicity. This process is enforced by the protocol, reducing reliance on external trust and minimizing the risk of manipulation.
+
+- **Dynamic Block Construction:** By enabling a dynamic approach to block construction, PEPC allows for the real-time adjustment of block contents based on network conditions, user demands, and emerging opportunities, such as MEV extraction.
+
+#### PEPC Use Cases
+
+PEPC offers several compelling use cases[^11]:
+
+**Full-Block Auctions**
+
+- Validators auction the right to construct entire blocks to builders. This mirrors the current MEV-Boost mechanism but with enhanced security and trustlessness by embedding the auction within the Ethereum protocol.
+- Ensures a transparent and fair process for block construction, potentially leading to more competitive bidding and better rewards for validators.
+
+**Partial Block Auctions**
+
+- Validators can auction portions of a block's space to different builders, allowing multiple parties to contribute to a single block's construction.
+- Increases block space utilization efficiency and encourages diversity in transaction inclusion, mitigating potential centralization in block construction.
+
+**Parallel Block Auctions**
+
+- Similar to partial block auctions but with the auction focused on separate, parallel components of block space, enabling a more granular approach to block construction.
+- Offers validators more control over block contents and structure, potentially optimizing for various factors like gas usage, transaction priority, and MEV extraction.
+
+**Slot vs. Block Auctions**
+
+- Validators commit in advance to using blocks or block parts from specific builders, differentiating between commitments to "slots" (who will build) versus "blocks" (what will be built).
+- Enhances predictability and planning for both validators and builders, potentially leading to more strategic block construction and MEV extraction opportunities.
+
+**Future Slot Auctions**
+
+- Validators auction the rights to construct blocks for future slots, essentially creating futures contracts for block space.
+- Provides market participants with more tools for speculation and hedging, potentially stabilizing income for validators and offering builders advanced planning capabilities.
+
+**Inclusion Lists**
+
+- Validators commit to including specific transactions in their blocks, either through direct listing or by adhering to lists provided by third parties.
+- Increases transparency and predictability for transaction inclusion, potentially reducing gas price volatility and improving user experience.
+
+**Dynamic Block Configuration**
+
+- Validators use PEPC to adjust block configurations dynamically, responding to real-time network conditions and demands.
+- Enhances network responsiveness and efficiency, potentially improving throughput and reducing congestion during peak periods.
+
+**Censorship Resistance**
+
+- By making commitments to include certain transactions or follow specific inclusion patterns, validators can provide guarantees against censorship.
+- Strengthens Ethereum's censorship-resistant properties, ensuring that the network remains open and accessible to all users.
+
+**Protocol Upgrades and Feature Testing**
+
+- PEPC can be used to test new protocol features or upgrades in a live environment without risking network stability, by making commitments to include transactions that utilize these features.
+- Offers a safer pathway for innovation and evolution within the Ethereum protocol, allowing for more experimental approaches to development.
+
+#### Relationship and Differences to EigenLayer
+
+PEPC and Eigenlayer have a complementary relationship, each addressing different aspects of Ethereum's scalability, security, and decentralization, while also sharing a common goal of enhancing the network's efficiency and flexibility.
+
+- **Security Layering:** Eigenlayer introduces a mechanism to extend Ethereum's security to additional layers and services. In contrast, PEPC focuses on embedding more sophisticated and flexible commitment mechanisms within the Ethereum protocol itself. While Eigenlayer seeks to augment Ethereum's security model externally, PEPC aims to enhance the internal workings of the Ethereum main chain, specifically around block proposal and transaction inclusion processes.
+
+- **Validator Commitments:** Both PEPC and Eigenlayer involve validators making certain commitments, but the nature and scope of these commitments differ. In Eigenlayer, validators might commit to securing additional layers or services by restaking their ETH. In PEPC, validators make commitments regarding the construction of blocks, such as including certain transactions or adhering to specific block construction criteria.
+
+- **MEV and Transaction Inclusion:** Both projects indirectly address issues related to MEV and transaction inclusion fairness. Eigenlayer can facilitate solutions that mitigate the negative aspects of MEV or improve transaction inclusion through additional consensus layers. PEPC, by allowing for more dynamic and programmable proposer-builder agreements, could lead to a more equitable distribution of MEV opportunities and more transparent transaction inclusion mechanisms.
+
+**Economic Bound to Security in Eigenlayer**
+
+In principle, if the value at stake in activities or assets secured by Eigenlayer exceeds the value of staked ETH in Ethereum, the economic incentives could potentially become misaligned, leading to concerns about the sufficiency of security provided [^11].
+
+In a broader Ethereum ecosystem context, PEPC and Eigenlayer could be seen as complementary, with Eigenlayer expanding Ethereum's security and utility beyond its core protocol and PEPC enhancing the efficiency and flexibility within the core protocol itself. Implementing both could lead to a scenario where Ethereum not only becomes more efficient and adaptable in handling transactions and block construction but also extends its security guarantees to a broader range of decentralized applications and services.
+
+## Open Questions in ePBS
+
+There are some interesting and challenging open questions highlighted by Mike in enshrining PBS (ePBS) in Ethereum Protocol[^5].
+
+### What does bypassability imply?
+
+Bypassability highlights a crucial challenge in the transition to ePBS: the possibility that validators and builders might continue relying on external relays or solutions instead of the enshrined protocol. The concern here is twofold: first, it questions the efficacy of ePBS if a significant portion of network participants opts out; second, it probes the feasibility of designing a system that cannot be bypassed without imposing unreasonable constraints on validators' autonomy or Ethereum's decentralized ethos.
+
+### What does enshrining aim to achieve?
+
+Enshrining PBS aims to introduce a neutral, trustless relay within the Ethereum protocol to standardize and secure the proposer-builder relationship. This initiative seeks to mitigate centralization risks inherent in out-of-protocol solutions like MEV-Boost, enhance censorship resistance, and potentially serve as a foundational step towards addressing MEV-related issues more systematically. Enshrining PBS, despite bypassability, could provide a reliable fallback mechanism, encourage more validators to engage directly with the protocol, and align with long-term goals such as MEV redistribution mechanisms (e.g., MEV-burn).
+
+### What are the exact implications of not enshrining?
+
+Choosing not to enshrine PBS essentially yields significant control over block construction and MEV distribution to external systems, potentially exacerbating centralization and security vulnerabilities. This concession may necessitate prioritizing funding and support for neutral relays as critical infrastructure to maintain a level playing field and safeguard against monopolistic practices in the MEV market.
+
+### What is the real demand for ePBS?
+
+The real demand for ePBS within the Ethereum ecosystem is driven by multiple factors that address current limitations and future-proof the network for scalability, security, and decentralization. These demands stem from the evolving landscape of Ethereum's block production and the growing complexity of MEV opportunities. Quantifying the real demand for ePBS is big challenge but it is a reflection of the broader needs of the Ethereum community to address current challenges and anticipate future demands.
+
+### How much can we rely on altruism and the social layer?
+
+The social layer, Ethereum community norms and values, plays a pivotal role in guiding behavior that protocol mechanics alone cannot enforce. While altruism or long-term self-interest might motivate some large ETH holders to support the enshrined solution, relying solely on these motivations is unreliable. The integrity and decentralization of Ethereum should ideally be underpinned by robust, enforceable mechanisms rather than voluntary adherence to ideals.
+
+### How important is L1 ePBS in a future with L2s and OFAs?
+
+As Ethereum's roadmap evolves, with increasing activity on L2 solutions and the development of OFAs, the direct impact of L1 MEV might diminish. However, the principles and infrastructure laid out by ePBS could still play a critical role in shaping secure and decentralized mechanisms for managing MEV across layers, maintaining the relevance of ePBS in a multilayered ecosystem.
+
+### What priority should ePBS have in light of other protocol upgrades?
+
+Given the complex landscape and the potential for significant shifts in Ethereum's MEV dynamics, the prioritization of ePBS relative to other upgrades (e.g., censorship resistance enhancements, single-slot finality) necessitates a strategic approach. The community might consider focusing on upgrades with clearer immediate benefits and lower implementation risks, while continuing to research and develop ePBS frameworks that could be rapidly deployed if and when the need becomes more pressing.
+
+## [References]
+
+[^1]: https://barnabe.substack.com/p/pbs
+[^2]: https://www.youtube.com/watch?v=Ub8V7lILb_Q
+[^3]: https://www.youtube.com/watch?v=mEbK9AX7X7o
+[^4]: https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710/1
+[^5]: https://notes.ethereum.org/@mikeneuder/infinite-buffet
+[^6]: https://hackmd.io/ZNPG7xPFRnmMOf0j95Hl3w
+[^7]: https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054
+[^8]: https://notes.ethereum.org/@mikeneuder/consider-the-epbs
+[^9]: https://www.youtube.com/watch?v=63juNVzd1P4
+[^10]: https://ethresear.ch/t/unbundling-pbs-towards-protocol-enforced-proposer-commitments-pepc/13879/1
+[^11]: https://efdn.notion.site/PEPC-FAQ-0787ba2f77e14efba771ff2d903d67e4
diff --git a/docs/wiki/research/PBS/mev-boost.md b/docs/wiki/research/PBS/mev-boost.md
new file mode 100644
index 00000000..f24a1434
--- /dev/null
+++ b/docs/wiki/research/PBS/mev-boost.md
@@ -0,0 +1,60 @@
+# Mev-boost: A popular PBS Implementation
+
+[Mev-boost](https://github.com/flashbots/mev-boost) is a widely recognized, out-of-the-protocol, open-source implementation of Proposer-Builder Separation (PBS) for Ethereum. It allows validators to outsource block building to specialized builders, potentially leading to increased validator rewards and improved network efficiency.
+
+Here's how mev-boost works:
+
+
+
+ Current Block building. Source: Baranabé's article
+
+
+On one side, mev-boost implements the [builder API](https://github.com/ethereum/builder-specs) used by an Ethereum node to outsource it block production. On the other, it connects to a network of relays and handles the communication between builders and proposers.
+
+1. **Block Building:**
+ Specialized builders, known as "searchers" in mev-boost, compete to create the most profitable block for the proposer. They do this by optimizing transaction ordering and inclusion, taking into account factors like gas fees, transaction priority, and potential [MEV (Maximal Extractable Value)](/wiki/research/PBS/mev.md).
+ Searchers submit their constructed blocks to relays.
+2. **Relay Network:**
+ Mev-boost operates a network of relays that act as intermediaries between searchers and proposers.
+ Relays receive blocks from searchers and perform various functions like block validation, filtering, and propagation.
+ Relays ensure that only valid and high-quality blocks are sent to proposers.
+3. **Proposer Selection:**
+ Validators run mev-boost software connected to their beacon node. When validator is chosen to propose a block, they receive blocks from relays and choose the best one based on predefined criteria, typically the block that offers the highest reward.
+ The validator then proposes the selected block to the network for validation and inclusion in the blockchain.
+
+## PBS Block Creation
+
+The process of block creation through PBS works as follows:
+
+### Block Construction
+
+- Builders continuously monitor the transaction pool (mempool) for new transactions. They assess these transactions based on potential MEV opportunities. They select the transactions that best align with their MEV optimization criteria. Also, block builders can take transaction bundles from private orderflows, or from MEV searchers, just as miners did in PoW Ethereum with the original Flashbots auctions. In the latter case, builders accept sealed-price bids from searchers and include their bundles in the block.
+- Once the transactions are selected, builders assemble them into a block ensuring that the block adheres to the Ethereum protocol's rules, e. g., txs are valid, the gas limit is not surpassed.
+
+### Block Auction
+
+Instead of builders directly offering their assembled blocks to validators with a specified price, the standard practice is to use relays. Relays validate the transaction bundles before passing them onto the proposer (validator). Also, implementations can introduce escrows responsible for providing data availability by storing blocks sent by builders and commitments sent by validators.
+
+### Benefits of mev-boost:
+
+- **Increased validator rewards:** By outsourcing block building to specialized searchers, validators can potentially earn higher rewards through optimized transaction ordering and MEV extraction.
+- **Reduced centralization:** Mev-boost enables a more competitive block-building landscape, reducing the economy of scale of large mining pools and enabling home stakers achieve same kind of rewards.
+
+### Challenges and Considerations:
+
+While mev-boost offers certain benefits, it also raises some concerns:
+
+- **Security:** Introducing new actors and dependencies can create new attack vectors and vulnerabilities. There have been multiple [incidents](https://collective.flashbots.net/t/post-mortem-april-3rd-2023-mev-boost-relay-incident-and-related-timing-issue/1540) of missed blocks on mainnet due to mev-boost issues.
+- **Censorship resistance:** If only a few powerful searchers or relays dominate the ecosystem, it could lead to centralization and censorship concerns.
+- **Coordination:** Effective communication and coordination between searchers, relays, and proposers are crucial for the smooth functioning of mev-boost.
+
+It's important to note that mev-boost is just one implementation of PBS. Other implementations with different designs and features are also being developed and explored, for example [mev-rs](https://github.com/ralexstokes/mev-rs) is under development.
+
+Overall, mev-boost represents a significant step towards realizing the potential benefits of PBS in Ethereum. However, continuous research and development are crucial to address the challenges and ensure a secure, decentralized, and efficient implementation. One path towards more stable PBS model is [enshrining it in the protocol](/wiki/research/PBS/ePBS.md), adding mev-boost like features directly to the Ethereum clients.
+
+## Resources
+
+- [Flashbots docs on mev-boost](https://boost.flashbots.net/)
+- [Overview of censoring entities](https://censorship.pics/)
+- https://www.mevwatch.info/
+- [MEV-Boost: Merge ready Flashbots Architecture, 2021](https://ethresear.ch/t/mev-boost-merge-ready-flashbots-architecture/11177)
\ No newline at end of file
diff --git a/docs/wiki/research/PBS/mev.md b/docs/wiki/research/PBS/mev.md
new file mode 100644
index 00000000..44dec907
--- /dev/null
+++ b/docs/wiki/research/PBS/mev.md
@@ -0,0 +1,21 @@
+# Maximal Extractable Value (previously Miner Extractable Value)
+
+Maximal Extractable Value (MEV) refers to the the maximum value that can be extracted from block production beyond the standard block reward and gas fees by strategically ordering, including, or excluding transactions in a block.
+
+In Ethereum, MEV has gained greater attention as validators extract increasingly more value, especially in DeFi (Decentralized Finance) applications. Arbitrage opportunities facilitated by strategies like front-running, sandwiching or back-running are possible by ordering transactions in the block. This can also lead to negative consequences, such as unfair advantages for large-scale pools, censorship or increased slippage for DeFi users.
+
+[Proposer-builder separation (PBS)](/wiki/research/PBS/pbs.md) can change the dynamics of MEV extraction in that there could be a redistribution of MEV between the two roles, potentially changing the incentives and rewards associated with each. Since block builders are responsible for transaction ordering and inclusion, they may develop new strategies or promote increased competition that could result in more efficiency and fairer distribution of MEV across the network.
+
+## Evolution of MEV
+
+Maximal Extractable Value (MEV) originated during the proof-of-work era, where it was known as "Miner Extractable Value." This terminology reflected the miners' ability to influence transaction order in the block, including their inclusion, exclusion, and sequencing. Following Ethereum's transition to proof-of-stake with The Merge, validators have taken over the consensus, rendering mining obsolete within the protocol. Despite these changes, the mechanisms for value extraction remain in place, leading to the adoption of the term "Maximal Extractable Value" to address these activities.
+
+Although MEV has been possible since the inception of Ethereum, it gained significant attention with the rise of DeFi and more accessible tooling. In the early days, MEV opportunities were primarily seized by outbidding rivals in the public mempool, marking the era known as Priority Gas Auction or PGA. Details about this chaotic era is captured in [Flashboys 2.0](https://arxiv.org/abs/1904.05234). During that time, [Flashbots](https://www.flashbots.net/) came out as open R&D initiative to improve public knowledge and access to MEV tools.
+
+In the Post-Merge world, the concept of miners ceased to exist but their builder and proposer role is facilitated by validators, responsible to add blocks to the chain in the same way. Anticipating the changes after The Merge, Flashbots, along with the client teams and the Ethereum Foundation commenced the development of [mev-boost](/wiki/research/PBS/mev-boost.md). MEV-boost is an out-of-protocol implementation of Proposer-builder Separation. See the [section on PBS](/wiki/research/PBS/pbs.md).
+
+## Resources
+
+- [A study of the transaction supply chain from CryptoKitties to MEV-Boost to PBS - Barnabé Monnot](https://www.youtube.com/watch?v=jQjBNbEv9Mg)
+- [MEV Day playlist](https://www.youtube.com/playlist?list=PLRHMe0bxkuel3w3C7P_WVvp9ShLi3HKRI)
+- [How to light up dark forest - Flashbots](https://collective.flashbots.net/t/how-to-light-up-the-dark-forest-a-walkthrough-of-building-a-cryptopunk-mev-inspector/881)
\ No newline at end of file
diff --git a/docs/wiki/research/PBS/pbs.md b/docs/wiki/research/PBS/pbs.md
new file mode 100644
index 00000000..175005ec
--- /dev/null
+++ b/docs/wiki/research/PBS/pbs.md
@@ -0,0 +1,149 @@
+# Proposer Builder Separation (PBS)
+
+In Ethereum's current system, validators both create and broadcast blocks. They bundle together transactions that they have discovered through the gossip network and package them into a block which is then sent out to peers on the Ethereum network. **Proposer-builder separation (PBS)** splits these tasks across multiple validators. Block builders become responsible for creating blocks and offering them to the block proposer in each slot. The block proposer cannot see the contents of the block, they simply choose the most profitable one, paying a fee to the block builder before sending the block to its peers.
+
+This section will be covering details about PBS, roles of block proposers and block builders, current state - mev boost, relays, challenges and security issues, proposed solutions and further collection of resources related to the topic.
+
+## Why is PBS important?
+
+PBS is important to the decentralization of Ethereum because it minimizes the compute overhead that is required to become a validator. By doing this, the network lowers the barrier to entry for becoming a validator and incentives a more diverse group of participants. PBS also reflects an overall goal of The Merge to move Ethereum’s network towards a more modular future. Specifically, the transition to PoS is an aggressive move towards decentralization through modularity.
+
+When you break apart the different pieces of block construction, you can decentralize them individually. This allows different actors with different specialties to focus on their particular strengths. The net result is a more capable network with fewer external dependencies and a lower threshold for participation.
+
+## Understanding PBS and the Consensus layer
+
+As explained in this [article](https://ethos.dev/beacon-chain), slots are the time frames allowed in the consensus layer for a block to be added to the chain, they last 12 seconds and there are 32 of them per epoch. Epochs are significant for the consensus mechanism, serving as checkpoints where the network can finalize blocks, update validator committees, etc. For each slot, a validator is chosen through [RANDAO](https://inevitableeth.com/home/ethereum/network/consensus/randao) to propose a block. Once proposed and added to the canonical chain, the validators chosen for that slot's committees attest to the validity of the block, which shall eventually reach finality. The consensus layer supports Ethereum's network security and integrity. PBS interacts with this layer by dividing/isolating the duties of proposing and building blocks, thereby streamlining the transaction validation process.
+
+### The Role of the builder
+
+**Block builders** gather, validate, and assemble transactions into a block body. They review the mempool, validate the transactions by ensuring that they meet requirements like gas limits and nonce, and create a data structure containing the transaction data. Block builders are also responsible for ordering the transactions to optimize block space and gas usage. They then make the block body available to block proposers.
+
+### The Role of the proposer
+
+**Block proposers** take the block bodies provided by the block builders and create a complete block by adding necessary metadata, such as the block header. The header includes details such as the parent block's hash, timestamp, and other data. They also ensure the validity of the blocks by checking the correctness of the block body provided by the builders.
+
+## Current State
+
+Currently, PBS (Proposer Builder Separation) exists outside of the protocol by builders helping in block building through entities like relays. Please refer [mev-boost](/wiki/research/PBS/mev-boost.md) for more details on one of the widely used Out-of-protocol solution. This design relies on small set of trusted relays and even builders which introduces centralization risks and makes Ethereum more vulnerable to censorship.
+PBS is not yet implemented in the Ethereum mainnet which means validators act as both proposers and builders. So each validator is responsible for:
+
+1. **Selecting transactions:** Validators choose which transactions to include in a block based on factors like gas fees and transaction priority.
+2. **Building the block:** Validators assemble the chosen transactions into a block and perform necessary computations like verifying signatures and updating the state.
+3. **Proposing the block:** Validators propose the constructed block to the network for validation and inclusion in the blockchain.
+
+However, some clients are actively developing and testing PBS implementations. These implementations aim to separate the builder and proposer roles, allowing validators to outsource block construction to specialized builders. This can lead to several potential benefits:
+
+- **Increased validator rewards:** Builders can compete to create the most profitable block for the proposer, potentially leading to higher rewards for validators.
+- **Improved network efficiency:** Specialized builders can optimize block construction, leading to more efficient block propagation and processing.
+- **Reduced centralization:** By decoupling the roles, PBS can potentially reduce the influence of large mining pools or staking providers that currently dominate both block building and proposing.
+
+### PBS and the Relationship Between Relays, Builders, and Validators
+
+Proposer-Builder Separation (PBS) also introduces a more intricate relationship between different actors in the Ethereum network:
+
+1. **Builders:**
+ - Builders are specialized entities that focus on constructing blocks with optimal transaction ordering and inclusion. They compete with each other to create the most profitable block for the proposer, taking into account factors like gas fees, transaction priority, and potential MEV (Maximal Extractable Value).
+ - Builders do not directly interact with the blockchain. Instead, they submit their constructed blocks to relays.
+ - This submission includes the block's data (transactions, execution payload, etc.) and a bid that they are willing to pay to have their block proposed.
+2. **Relays:**
+ - Relays receive blocks from multiple builders, confirm their validity and submit the valid block with the highest bid to the escrow for the validator to sign.
+ - Relays act as intermediaries between builders and proposers. They receive blocks from builders and forward them to proposers.
+ - Relays can perform additional functions like block validation and filtering to ensure that only valid and high-quality blocks are sent to proposers.
+ - Some relays may specialize in specific types of blocks, such as those with high MEV potential.
+3. **Validators (Proposers):**
+ - Under PBS, validators take on the role of proposers. They receive blocks from relays and choose the best one based on predefined criteria, typically the block that offers the highest reward.
+ - Once the proposer selects a block, they propose it to the network for validation and inclusion in the blockchain.
+ - Validators are still responsible for securing the network and ensuring consensus on the blockchain's state.
+
+This whole process is illustrated in the figure below. See [Flashbots' docs](https://docs.flashbots.net/) for further explanations.
+
+
+
+ Outline of the communication between the MEV-Boost PBS participants. Source: ethresear.ch
+
+
+This separation of roles creates a more dynamic and specialized block-building process. Builders can focus on optimizing block construction and extracting MEV, while proposers can focus on selecting the best block and maintaining network security.
+
+However, this new relationship also introduces new challenges.
+
+### Relay Concerns
+
+A case can be made that relays oppose the following Ethereum's core tenets:
+
+- Decentralization: The fact that [six relays](https://www.relayscan.io/overview?t=7d) handle 99% of MEV-Boost blocks (that being nigh on 90% of Ethereum's blocks) gives rise to justified centralization concerns.
+- Censorship resistance: Relays _can_ censor blocks and, being centralized, can be coerced by regulators to do so. This happened, for instance, when they were pressured to censor transactions interacting with addresses on the [OFAC sanction list](https://home.treasury.gov/news/press-releases/jy0916).
+- Trustlessness: Validators trust relays to provide a valid block header and to publish the full block once signed; builders trust relays not to steal MEV. Although betrayal of either would be detectable, dishonesty can be profitable even through a one-time attack.
+
+### Third party dependency
+
+The fact that PBS entails outsourcing the building of the blocks to entities that do not directly participate in Ethereum consensus could potentially lead to unexpected or unwanted consequences stemming from relying on third parties, such as trust issues, operational dependency and the introduction of single points of failure. Particularly the fact that the use of MEV-Boost is so widespread could be viewed as a dangerous third party dependency, since such a huge portion of Ethereum's new blocks are created using Flashbot's software.
+
+On a very recent note, On March 27-28, Ethereum experienced a spike in missed slots due to slow blob propagation from bloXroute-relayed blocks. The issue stemmed from the Lighthouse client expecting blobs and blocks from the same source, a mismatch with bloXroute's BDN(Blockchain Distributed Network), which only transmits blocks. This discrepancy led nodes to ignore blocks without accompanying blobs, especially after a BDN update accelerated block propagation without blobs. Attempts to integrate blobs with these blocks were unsuccessful, often resulting in a 202 response where data was acknowledged but not used due to prior block reception.
+
+The core of the problem was identified in Lighthouse's HTTP API handling for blob distribution, separate from the P2P network. This incident underscores the potential pitfalls of relying on external services like bloXroute for critical blockchain operations, highlighting the importance of meticulous component management within blockchain networks to maintain operational integrity and avoid vulnerabilities. More details can be found [here](https://gist.github.com/benhenryhunter/687299bcfe064674537dc9348d771e83).
+
+### Security Concerns
+
+As seen in this entry, PBS involves many different entities taking part in the process of adding new blocks to the chain, which inevitably increases the number of potential attack vectors that could be exploited.
+
+PBS-related vulnerabilities, like faulty relays or escrows, risk causing missed blocks without endangering Ethereum's integrity. These missed blocks can affect users and validators. Despite this, Ethereum clients can revert to conventional block building if external builders fail, ensuring network stability.
+
+### Undermined Censorship Resistance
+
+Another issue builder centralization might bring is putting at risk Ethereum's censorship resistance and integrity, as these dominant builders could, in theory, collude or be coerced into manipulating transaction flows or excluding specific transactions from being included in blocks, undermining the open and permissionless nature of the Ethereum network. Although in current situation, even majority of parties choose to censor, still cannot prevent from submitting these transactions, but only delay their inclusion.
+
+To increase censorship resistance, mechanisms like anonymous block proposals, which would protect participants from being singled out for the transactions they handle, are being considered. Additionally, making commitments to include specific transactions mandatory in block proposals is also being explored to ensure essential transactions cannot be censored. A brief overview can found [here](https://censorship.pics).
+
+For a detailed discussion on these anti-censorship measures within PBS, see [Vitalik Buterin's comprehensive analysis](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance).
+
+## Research and Proposed Solutions
+
+PBS is one of the active research areas in the Ethereum ecosystem. It presents several challenges, including potential security vulnerabilities and the risk of centralization. Ongoing research focuses on addressing these concerns through innovations such as enshrined PBS (ePBS), inclusion lists, the Protocol-Enforced Proposer Commitments (PEPC).
+
+Enshrined Proposer-Builder Separation (ePBS) is supposed to address some of the limitations and centralization concerns associated with MEV-Boost, which currently facilitates PBS for about 90% of Ethereum blocks.
+
+
+
+ Evolution of the portion of blocks built through MEV-Boost since The Merge. Source: mevboost.pics
+
+
+### Enshrined Proposer-Builder Separation (ePBS)
+
+Enshrined PBS involves embedding PBS mechanisms directly into Ethereum's consensus layer, which would have two main potential advantages:
+
+- Reduction in centralization risks: Moving PBS into the protocol layer could potentially reduce reliance on third parties with a tendency for centralization, aligning with Ethereum’s core values of decentralization and censorship resistance.
+- Security and stability: External dependencies and out-of-protocol software, such as relays, have shown vulnerabilities (e.g., "Low-Carb Crusader" attack). Integrating PBS into the Ethereum protocol can mitigate these risks and reduce the coordination costs associated with maintaining compatibility between various components.
+
+Referring to this [eth research discussion](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710), ePBS, particularly through Two-Block HeadLock (TBHL) and optimistic relaying, presents a pathway towards addressing current challenges and enhancing the efficiency, security, and decentralization of block production and MEV extraction processes.
+
+For more detailed on ePBS check out this [ePBS wiki entry](/wiki/research/PBS/ePBS.md).
+
+### Protocol-Enforced Proposer Commitments (PEPC)
+
+PEPC is another proposed solution for the shortcomings of PBS and MEV-Boost which advocates for a more open-ended and flexible design than traditional PBS. As explained on this [Mirror post](https://mirror.xyz/ohotties.eth/lBEXiiU7yK91OuSn8QyJPM9Db8GuyDFzCEUAj60BWyI), PEPC aims to provide a generalized infrastructure for proposers to make credible commitments to any outsourced block-building task, which could potentially better accommodate the evolving needs of the Ethereum network, especially with the anticipated expansion of data sharding and rollup adoption.
+
+The goal is to allow proposers to register arbitrary commitments, expressed via EVM execution, that external parties can rely on. This way, anyone can provide services to proposers as long as they satisfy the registered commitments, fostering permissionless innovation. Also, unlike externals solutions such as MEV-Boost, PEPC would integrate commitment satisfaction into the core protocol, blocks being considered valid only if they fulfill the proposer's registered commitments, enhancing security and trustworthiness.
+
+Regarding the need for a flexible approach to proposer duties PEPC aims to provide, it is worth noting that a wide range of outsourcing smart contracts is supported, from full block construction to specific valid transaction inclusions and validity proofs for rollup blocks.
+
+All of this would also be complementary to existing out-of-protocol mechanisms like Eigenlayer, enhancing the credibility of proposer commitments by moving from an optimistic model to a pessimistic enforcement model where violating commitments inherently invalidates blocks.
+
+For more detailed explanation check out [PEPC](/wiki/research/PBS/ePBS?id=protocol-enforced-proposer-commitments-pepc).
+
+### EIP-7547: Inclusion Lists
+
+As explained in this [ethereum-magicians.org post](https://ethereum-magicians.org/t/eip-7547-inclusion-lists/17474), inclusion lists aim to provide a mechanism to improve the censorship resistance of Ethereum by allowing proposers to specify a set of transactions that must be promptly included for subsequent blocks to be considered valid.
+
+This way proposers retain some authority over block building without sacrificing MEV rewards, through a mechanism by which transactions can be forcibly included. The simplest approach would be for the proposer to specify a list of transactions they found themselves in the mempool that must be included by the block builder if they want their block to be proposed for the next slot. Although some issues stem from this, such as incentive incompatibilities and exposure of free-data availability, solutions like forward and multiple inclusion lists have been proposed and are being developed to address these challenges, demonstrating the Ethereum community's commitment to refining and advancing the protocol to uphold its core values of decentralization, fairness, and censorship resistance.
+
+### Further Reading and Resources
+
+Below are some further readings regarding PBS and related topics:
+
+- [Notes on Proposer-Builder Separation (PBS)](https://barnabe.substack.com/p/pbs)
+- [Timing Games and Implications on MEV extraction](https://chorus.one/articles/timing-games-and-implications-on-mev-extraction)
+- [Why ePBS?](https://ethresear.ch/t/why-enshrine-proposer-builder-separation-a-viable-path-to-epbs/15710)
+- [Vitalik on pbs censorship](https://notes.ethereum.org/@vbuterin/pbs_censorship_resistance)
+- [Payload timeliness committee(PTC) design for ePBS](https://ethresear.ch/t/payload-timeliness-committee-ptc-an-epbs-design/16054)
+- [2-slot PBS](https://ethresear.ch/t/two-slot-proposer-builder-separation/10980)
+- [Forward Inclusion Lists](https://notes.ethereum.org/@fradamt/forward-inclusion-lists)
diff --git a/docs/wiki/research/img/scaling/PEPC-workflow.png b/docs/wiki/research/img/scaling/PEPC-workflow.png
new file mode 100644
index 00000000..cafb5327
Binary files /dev/null and b/docs/wiki/research/img/scaling/PEPC-workflow.png differ
diff --git a/wordlist.txt b/wordlist.txt
index 126eb81c..f859cfaf 100644
--- a/wordlist.txt
+++ b/wordlist.txt
@@ -374,4 +374,46 @@ Yellowpaper
zk
Extractable
Consensys
-api's
\ No newline at end of file
+api's
+tldr
+cartelization
+bypassability
+suboptimal
+amidst
+mvepbs
+permissionlessness
+tbhl
+timeframe
+neuder
+attesters
+bidpool
+ptc
+attestors
+pepc
+trustlessness
+pepc's
+tradeoffs
+atomicity
+eigenlayer
+restaking
+lmd
+ghost
+addons
+Baranabé's
+Barnabé
+Flashbot's
+Flashbots
+orderflows
+DeFi
+Flashboys
+Flashloans
+PGA
+BDN
+OFAC
+Carb
+RANDAO
+bloXroute
+bloXroute's
+centralisation
+ethresear
+mevboost
+ 
+ 
+