diff --git a/EIPS/eip-7805.md b/EIPS/eip-7805.md
index f0b3b4a01e32c5..425a22343695c9 100644
--- a/EIPS/eip-7805.md
+++ b/EIPS/eip-7805.md
@@ -40,7 +40,9 @@ This section outlines the workflow of FOCIL, detailing the roles and responsibil
 - **`Slot N`, `t=0 to 8s`**:
 IL committee members construct their ILs by including transactions pending in the public mempool, and broadcast them over the P2P network after processing the block for `slot N` and confirming it as the head. If no block is received by `t=7s`, they should run `get_head` and build and release their ILs based on the node’s local head.
 
-  By default, ILs are built by selecting raw transactions from the public mempool, ordered by priority fees, up to the IL’s maximum size in bytes of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB` per IL. Additional rules can be optionally applied to maximize censorship resistance, such as prioritizing valid transactions that have been pending in the mempool the longest.
+IL committee members may follow different strategies for constructing their ILs as discussed in [IL Building](#il-building).
+
+Each committee member is assigned an id from `0` to `f`. This is derived from the validator index, the lowest validator index is mapped to `0` and the highest to `f`.
 
 #### Validators
 
@@ -85,8 +87,7 @@ When validators receive ILs from the P2P network, they perform a series of valid
 
 ### Execution Layer
 
-On the execution layer, the block validity conditions are extended such that, after all of the transactions in the block have been executed, we attempt to execute each valid transaction from ILs that was not present in the block.
-If one of those transactions executes successfully, then the block is invalid.
+On the execution layer, an additional check is introduced for new payloads. After all of the transactions in the payload have been executed, we attempt to execute each valid transaction from ILs that was not present in the payload. If one of those transactions executes successfully, then an error is returned to the CL. Although the block is valid the CL will not attest to it.
 
 Let `B` denote the current block.
 Let `S` denote the execution state following the execution of the last transaction in `B`.
@@ -99,17 +100,35 @@ For each transaction `T` in ILs, perform the following:
 
   - If `T` is invalid, then continue to the next transaction. 
   
-  - If `T` is valid, terminate process and assert block `B` as invalid.
+  - If `T` is valid, terminate process and return an error.
 
 3. Execute `T` on state `S`. Assert that the execution of `T` fails.
 
-If `B` is full, the process terminates. Also note that we do not need to reset the state to `S`, since the only way for a transaction to alter the state is for it to execute successfully, in which case the block is invalid, and so the block will not be applied to the state.
+If `B` is full, the process terminates. Also note that the state `S` must be restored if a transaction from the IL is successfully executed against it.
+
+#### Engine API Changes
 
 We make the following changes to the engine API:
 
-- Add `engine_getInclusionList` endpoint to retrieve an IL from the `ExecutionEngine`
-- Modify `engine_newPayload` endpoint to include a parameter for transactions in ILs determined by the proposer
-- Modify `engine_forkchoiceUpdated` endpoint to include a field in the payload attributes for transactions in ILs determined by the proposer
+- Add `engine_getInclusionListV1` endpoint to retrieve an IL from the `ExecutionEngine`. It takes as an argument the IL committee member id.
+- Add `engine_getInclusionListV1` endpoint to retrieve an IL from the `ExecutionEngine`.
+- Add `engine_updatePayloadWithInclusionListV1` endpoint to update a payload with the IL that should be used to build the block. This takes as an argument an 8-byte `payloadId` of the ongoing payload build process, along with the IL itself.
+- Modify `engine_newPayload` endpoint to include a parameter for transactions in ILs determined by the proposer. If the IL is not satisfied an `INVALID_INCLUSION_LIST` error must be returned.
+
+The full Engine API changes can be found in the [Execution APIs](https://github.com/ethereum/execution-apis/blob/58b019ea5ee4a84d9767402145b9a88789f0359e/src/engine/experimental/eip7805.md) GitHub repository.
+
+#### IL Building
+
+The rules for building ILs are left to the discretion of implementers; a diverse set of strategies can strengthen censorship resistance. Transactions from the public mempool could be selected based on several factors such as:
+
+- Time spent pending in the mempool.
+- Nondeterminism: Introducing randomness can reduce overlap between ILs, leading to a larger IL when they are combined.
+- Bias: Picking some transactions more often than others in order to further reduce overlap between ILs. This should be done based on committee member id, for example the member with id `a` may be more likely to pick transactions with hashes that start with `a`.
+- Priority fee.
+- Byte size: prioritising smaller transactions.
+- The number of times a transaction has been included in reorged payloads.
+
+The selection process continues until the IL reaches its maximum size of `MAX_BYTES_PER_INCLUSION_LIST = 8 KiB`.
 
 ### Consensus Layer