diff --git a/EIPS/eip-6873.md b/EIPS/eip-6873.md
new file mode 100644
index 00000000000000..22a7894c78149b
--- /dev/null
+++ b/EIPS/eip-6873.md
@@ -0,0 +1,64 @@
+---
+eip: 6873
+title: Preimage retention
+description: Execution clients must retain the preimages of addresses and slots accessed between the fork preceding the verge, and the verge itself.
+author: Guillaume Ballet (@gballet)
+discussions-to: https://ethereum-magicians.org/t/eip-6873-preimage-retention-in-the-fork-preceding-the-verge/15830
+status: Draft
+type: Standards Track
+category: Core
+created: 2023-04-14
+---
+
+## Abstract
+
+Enforce preimage collection by every node on the network from the fork preceding the verge, up to the fork. This is needed in case each node is responsible for their own conversion.
+
+## Specification
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+Let `T_p` be the timestamp of the fork preceding the verge, and `T_v` the timestamp of the verge. 
+
+ * EL clients MUST save the preimage of each address and slot hashes they produce during the execution of all blocks produced between `T_p` and `T_v`
+
+ * EL clients MAY start storing preimages outside of this time range as well
+
+ * Given a hash produced between `T_p` and `T_v`, EL clients SHOULD be able to show they have the preimage for that hash in their database
+
+ * EL clients SHOULD be able to download the preimages of the address and slot hashes that were produced before `T_v` from a publicly-available datastore
+
+## Rationale
+
+Switching to verkle trees require a complete rehashing of all tree keys. Most execution clients store all keys hashed, without their preimages, which as the time of print take up 70GB on mainnet. In order to make these preimages available to everyone, the following course of action are available to each user:
+
+ * Restart a full-sync with preimage retention enabled
+ * Download the preimages as a file
+
+The second option is the only acceptable option in practice, as a full-sync requires the syncing machine to be offline for several days, and therefore should not be simultaneously imposed to the entire network. A file download, however, poses a problem of data obsolecense as new preimages will immediately need to be added to the list as the chain progresses and new addresses are accessed. Updating the preimage file is not sufficient, since it takes more than a slot time to download over 70GB.
+
+To guarantee a timely availability of all preimages around the verkle transition time, each node is therefore responsible for updating the list of preimages between the fork preceding the Verge, and the Verge itself.
+
+## Backwards Compatibility
+
+No backward compatibility issues found.
+
+<!--
+
+## Test Cases
+
+TODO
+
+-->
+
+## Reference Implementation
+
+All clients already implement preimage retention, at least as an option.
+
+## Security Considerations
+
+Needs discussion. <!-- TODO -->
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).