My 2c on the Curve/Vyper drama over the last few days: 1. Public open protocols and communities are getting incredibly robust in spotting and reacting to hacks/exploits. This should be a point of pride for the whole space - while mistakes made in public are more painful than those made behind closed doors, they are also picked up and responded to far more quickly as a result of the collective mind and independent ability to act of the community that makes up that system. No system is immune to errors or mistakes. The measure of a system’s robustness is not just how infrequently issue occur, but how quickly critical issues are resolved. 2. The heart of the issue is more than programming language related. Most people’s take away from this is that there was a problem with Vyper - narrowly this is correct - but it is also just highlighting the wider issue of how assets and asset handling logic is architected for smart contracts in the EVM world. On Radix, the Radix Engine provides tools for (and therefore handles) concepts such as safe reentrancy. The Radix Engine, and the safe asset logic it provides, is separate to (and a tool of) the Radix programming language, Scrypto. As a result if someone created an alternative to Scrypto on Radix (which theoretically they can), an error in the compiler of this type would not have exposed users to this kind of exploit, as it would still benefit from the low level functions and guard rails provided by the Radix Engine. This does not replace the need for a robust, vigilant community, but my god, it makes it a lot less like building on sand. For more information about architectural issues with EVM based smart contracts, start here: radixdlt.com/blog/the-proble… To learn more about the Radix Engine and how that helps, start here: radixdlt.com/blog/radix-engi…