Kudos to the team on posting a transparent post-mortem. Supply chain attacks are skyrocketing; you should do everything to ensure it doesn't happen, but operate under the assumption that it can. Developers install 100's of libraries, which in turn can have thousands of dependencies. It only takes one compromised lib to potentially get root on your machine or access CI/CD secrets. With this in mind, any asset issuer should do a threat model: what are the attack vectors? what's the blast radius for each? The most painful part in reading it is that it could have been prevented with onchain sanity checks and guardrails that take an afternoon to implement. For any asset issuers: - use a multisig for sensitive operations, especially mint/burn - add timelocks to those operations - add velocity-based sanity checks - i.e., a 40M USD mktcap token should not be able to mint 100m in a minute/hour/day; even if this adds operational friction! - use a proof of reserve oracle - these are relatively easy to implement and cheap - add risk oracles as circuit breakers For offchain opsec and cyber use, CrowdStrike / Palo Alto Networks, etc. These aren't bulletproof either, but this class of attacks is common, and many of these signatures and malwares have identifiable signatures that can potentially be blocked/caught. Monitoring is important, and everyone should have it, but the best actions are preventative. Good luck to the Resolv team and community with the continued investigation 🙏