Our investigation into the @DriftProtocol incident remains ongoing. Early evidence points to two compromised signers on Drift's admin multisig, which were used to execute a transaction modifying Drift's program configuration. Squads programs were not compromised. We have also found no evidence of compromise to Squads infrastructure, though we are actively investigating to confirm this with full confidence. We will share further findings as they become available. Best Practices for Operationally Critical Multisigs Thresholds: Any multisig with operational or administrative control over a program should have a signing threshold of 3 or above. This requires an attacker to concurrently compromise multiple independent signers, significantly raising the difficulty of this type of attack. Where possible, signers should also be geographically and organizationally dispersed. Signers sharing the same location, devices, or org structure introduce correlated risk. Timelocks: Multisigs with program-level control should implement a timelock (can be set up in Settings of your Squads multisig). It won't prevent a malicious transaction from being proposed, but it creates a window to detect and reject it before execution. The tradeoff: timelocks also slow down legitimate emergency responses to bugs or active exploits, so teams should factor this into their operational setup. Alerts & Monitoring: We encourage all operationally critical multisigs to set up monitoring and alerts through our security partner @RangeSecurity. Range provides two key things: an alternative interface for independently verifying transaction content outside of the Squads UI, and proactive Slack alerts so signers are notified before a proposal moves forward. If you want help getting set up, reach out and we'll connect you directly. A high threshold, a timelock, and monitoring are the foundation for any multisig with program-level control. Signing Process: Signers should use dedicated devices and hardware wallets, never a general-purpose machine. Additionally, signatures are only valid for approximately 2 minutes each, so introduce at least a 2 minute delay between each signer taking actions to ensure signatures cannot be collected & bundled by an attacker. Always verify transaction content independently across all three available sources: the Squads UI, Range's alternative interface, and Solana Explorer or Solscan On Durable Nonces 
The Drift attack exploited durable nonces to collect signatures without time pressure, bypassing the 2-minute transaction expiry that would otherwise limit this type of attack. We are actively exploring ways to block durable nonce usage across all of our programs, both at the program level and through other enforcement mechanisms, to ensure this protection extends to our immutable programs V3, V4, and our current Smart Account Program. Beyond this, the broader Solana ecosystem is taking steps to address this at the protocol level, with a new transaction format that drops durable nonces as a feature entirely. We will follow up with more information on this soon.

Beyond Multisig, Operational Security Technical controls only go so far. Most high-profile compromises lately have been social engineering attacks targeting the people behind the keys, not the contracts themselves. If you are running mission-critical protocol operations, invest in your internal opsec processes and team culture accordingly, how proposals are initiated, communicated, and approved all matter. We recommend engaging dedicated security advisors. @zeroshadow_io and @0xGroomLake are trusted starting points, and we are happy to connect you directly.