Devine și mai fantezist: modul în care Etherscan a fost păcălit arătând contractul de implementare greșit se bazează pe setarea a 2 sloturi proxy diferite în același top tx. Deci, Etherscan folosește o anumită euristică care încorporează diferite sloturi de stocare pentru a prelua contractul de implementare. Există un proxy vechi de la OpenZeppelin care folosea următorul slot: 'keccak256("org.zeppelinos.proxy.implementation")' = '0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3' Acum avem și slotul standard EIP-1967 'bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)' = '0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc' Deci ceea ce s-a întâmplat este că vechiul slot proxy OpenZeppelin a fost scris cu adresa de implementare benignă _și_ slotul standard EIP-1967 a fost scris și el cu adresa de implementare rău intenționată. Deoarece Etherscan interoghează mai întâi vechiul slot proxy, l-a recuperat mai întâi pe cel cu aspect benign și astfel l-a afișat.

- vechiul slot proxy OZ: - vechiul blog Etherscan despre suportul proxy: - Exemplu Frontrun TX: