Het wordt nog fancier: de manier waarop Etherscan werd misleid om het verkeerde implementatiecontract te tonen, is gebaseerd op het instellen van 2 verschillende proxy slots in dezelfde frontrunning tx. Etherscan gebruikt een bepaalde heuristiek die verschillende opslagslots incorporeert om het implementatiecontract op te halen. Er is een oude proxy van OpenZeppelin die de volgende slot gebruikte: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` We hebben nu ook de standaard EIP-1967 slot `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` Wat er gebeurde, is dat de oude OpenZeppelin proxy slot werd geschreven met het onschuldige implementatieadres _en_ de standaard EIP-1967 slot ook werd geschreven met het kwaadaardige implementatieadres. Aangezien Etherscan eerst de oude proxy slot opvraagt, haalde het eerst het onschuldige uitziende adres op en toonde het dus.

- oude OZ proxy slot: - oude Etherscan blog over proxy ondersteuning: - voorbeeld frontrun tx: