Verfasst von Pablo Gómez
Founder & CEO von Metlabs · Geprüft am 11. Oktober 2026
EIP-1967 berechnet seine Slots als keccak256 eines Labels minus eins, damit sie für den Compiler unvorhersehbar sind und nie einer normalen Variablen zugewiesen werden. Er definiert drei konkrete und dauerhafte Slots: den Implementierungs-Slot, abgeleitet aus "eip1967.proxy.implementation"; den Admin-Slot aus "eip1967.proxy.admin"; und den Beacon-Slot aus "eip1967.proxy.beacon". Indem diese Metadaten außerhalb des regulären Speicherbereichs liegen, vermeidet er das klassische Problem der Slot-Kollision, eine schwerwiegende Schwachstelle, bei der die Implementierungsadresse eine Variable des Logik-Contracts überschrieb.
Das ist wichtig, weil die Slots neben der Sicherheit auch öffentlich und standardisiert sind. So können Explorer wie Etherscan, Audit-Tools und Wallets automatisch erkennen, dass ein Smart Contract ein Proxy ist, und dessen Implementierung und Administrator auslesen. Deshalb ist EIP-1967 eine ständige Referenz in Audits upgradefähiger Smart Contracts.
Die Referenzimplementierung bilden `ERC1967Proxy` und `ERC1967Utils` von OpenZeppelin, die Grundlage der Muster Transparent Proxy und UUPS (ERC-1822). Praktisch alle Protokolle mit upgradefähigen Smart Contracts verwenden dieses Muster; der USDC von Circle etwa ist ein Proxy, der diesem Slot-Muster folgt. Sinnvoll ist der Vergleich mit ERC-1167: Dieser ist ein minimaler, nicht upgradefähiger Proxy, der diese Slots nicht nutzt, während EIP-1967 der Kern des Upgrade-Musters ist.
Auch bekannt als
- ERC1967
- Proxy Storage Slots






