Fica ainda mais sofisticado: a forma como o Etherscan foi enganado a mostrar o contrato de implementação errado baseia-se na definição de 2 slots de proxy diferentes na mesma transação de frontrunning. Assim, o Etherscan utiliza uma certa heurística que incorpora diferentes slots de armazenamento para recuperar o contrato de implementação. Há um proxy antigo da OpenZeppelin que usou o seguinte slot: `keccak256("org.zeppelinos.proxy.implementation")` = `0x7050c9e0f4ca769c69bd3a8ef740bc37934f8e2c036e5a723fd8ee048ed3f8c3` Agora também temos o slot padrão EIP-1967 `bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1)` = `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc` O que aconteceu foi que o slot do proxy antigo da OpenZeppelin foi escrito com o endereço de implementação benigno _e_ o slot padrão EIP-1967 também foi escrito com o endereço de implementação malicioso. Como o Etherscan consulta primeiro o slot do proxy antigo, ele recuperou o que parecia benigno primeiro e, assim, o exibiu.

- slot de proxy antigo OZ: - blog antigo do Etherscan sobre suporte a proxy: - exemplo de tx de frontrun: