This is not about cryptocurrency, but smart contract transparency, which actually has very little to do with cryptography. There are standard interfaces like ER

This is not about cryptocurrency, but smart contract transparency, which actually has very little to do with cryptography. There are standard interfaces like ERC-20 and ERC-721, and there are marginally-standard contract templates like OpenZeppelin, and there are ways to verify the code generated by a certain compiler, but every implementation of the standard has unique code. This is absolutely silly, and a major oversight by the Foundation. Certik does great work (usually), but they really should not have nearly the level of business they do. A smart contract standard should specify the exact code used for deployment, and only allow variance in deployment data. This should be easily determinable from a wallet or smart contract itself, whether direct or by proxy. And execution behavior should be specified exactly, prior to signature, or rejected with minimal cost, and no benefit to the miner. There is some of this in the intent of EIP 1559, but, to my mind, the burn fee is too high to enable safe rejection of exploitive behavior. Also, nothing has been done about transaction ordering. This would be easy to fix by setting the order by the same random beacon that selects the validator, or perhaps a moderately difficult VDF puzzle starting from the beacon entropy. It seems that 1559 is moving in the direction of institutionalizing MEV and dark pooling. I don't see this as necessary to secure the network - although maybe it helps the price by boosting the validator yield. Okay, I've rambled long enough - could go longer. All this is and was both predictable and preventable.