The $53 million Radiant Capital exploit exposed a fundamental weakness in how decentralized finance protocols manage their treasury operations. The attackers did not break any smart contract—they compromised the human operators of a 3-of-11 multisig wallet through targeted malware. For protocol operators and advanced DeFi users, this incident provides a clear mandate: multisig configurations must be hardened beyond their default settings. This tutorial walks you through setting up a production-grade multisig wallet architecture.
The Objective
This guide aims to help you configure a Gnosis Safe (now Safe) multisig wallet with enhanced security measures that would have prevented the Radiant Capital-style attack. You will learn how to set appropriate signer thresholds, implement transaction simulation before execution, configure spending limits, and establish monitoring systems that alert on suspicious activity.
The target audience is protocol operators, DAO treasury managers, and advanced DeFi users who manage significant on-chain positions. Basic familiarity with Ethereum, smart contracts, and command-line tools is assumed.
Prerequisites
Before starting, ensure you have the following: access to the Safe Transaction Builder, a hardware wallet for each designated signer (Ledger or Trezor), dedicated devices for transaction signing that are not used for general web browsing, and Ethereum or Base network ETH for gas fees. You will also need a monitoring solution—either a self-hosted instance of the Safe Transaction Service or a third-party monitoring tool like Tenderly or Forta.
Critical: each signer should have their own hardware wallet and dedicated signing device. Sharing devices between signers defeats the purpose of multisig security. The cost of additional hardware is negligible compared to the funds being protected.
Step-by-Step Walkthrough
Step 1: Create the Safe with an appropriate threshold. Navigate to app.safe.global and create a new Safe. Add your designated signer addresses. For most protocols managing more than $1 million, a threshold of at least 60 percent of the total signer count is recommended. For example, with 5 signers, use a 3-of-5 configuration. With 7 signers, use 5-of-7. The Radiant Capital attack succeeded with a 3-of-11 configuration, which is only a 27 percent threshold—far too low for the funds at stake.
Step 2: Configure spending limits. Safe modules allow you to set per-transaction and daily spending caps. Install the Spending Limit module and configure limits appropriate to your operational needs. For example, set a daily withdrawal limit of 5 percent of total treasury value. Any transaction exceeding this limit requires a full multisig confirmation, while routine operations below the threshold can proceed with fewer approvals.
Step 3: Implement transaction simulation. Before any signer approves a transaction, simulate it using Tenderly or the Safe Transaction Service simulation endpoint. This reveals exactly what state changes the transaction will execute, including any hidden token transfers or contract upgrades. The Radiant Capital attackers disguised a malicious contract upgrade as a routine operation—simulation would have immediately revealed the true nature of the transaction.
Step 4: Set up real-time monitoring. Configure alerts for the following events: any transaction submitted to the Safe queue, transactions that fail during simulation, changes to the Safe’s signer list or threshold, and transactions that interact with contracts not on your approved whitelist. Forta bots can be deployed to monitor your Safe address and send alerts via Telegram, Discord, or email when suspicious patterns are detected.
Step 5: Establish an emergency pause mechanism. Create a guard contract that can freeze all Safe operations if suspicious activity is detected. This guard should be triggerable by a single authorized address on a separate hardware wallet stored in a secure physical location. The ability to immediately halt all transactions during an active attack can mean the difference between a close call and a catastrophic loss.
Troubleshooting
Problem: Signers see different transaction data than what was simulated. This indicates potential malware on the signer’s device. Immediately stop all signing operations, isolate the device, and conduct a thorough security audit. Implement a verification step where the raw transaction calldata is compared against the simulation output on a separate, trusted device before any signer approves.
Problem: Transaction gas estimates are unusually high. Unexpectedly high gas consumption is a red flag for complex malicious operations hidden within transaction data. Always verify that the gas estimate aligns with the expected operation. A simple token transfer should not require millions of gas units.
Problem: Monitoring alerts are generating too many false positives. Refine your monitoring rules by whitelisting known operational addresses and common transaction patterns. Focus alerts on high-risk actions: contract interactions, new address approvals, and threshold changes. Quality of alerts matters more than quantity.
Mastering the Skill
Advanced multisig security is an ongoing discipline, not a one-time configuration. Conduct quarterly security reviews that audit signer device security, review monitoring alert logs for near-misses, test your emergency pause procedures, and rotate signer keys annually. Consider implementing a time-lock mechanism that delays execution of large transactions by 24 to 48 hours, giving your team and community time to review and flag concerns. The investment in operational security is always less expensive than the cost of a breach.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any financial decisions.
3-of-11 with malware compromise means the threshold was too low for the value at risk. Radiant should have been 5-of-11 minimum for a protocol holding nine figures
the radiance exploit proved that default multisig settings are basically theater. transaction simulation before execution should be standard
radiant got compromised because signers shared a single device for convenience. a 3-of-11 multisig is effectively 1-of-1 when all keys are on the same laptop. human error defeats the math every time
Dana Walsh hit the core issue. 3-of-11 with shared devices is just 1-of-1 with extra steps. hardware diversity matters more than signer count
the monitoring alerts section is underrated. real-time notifications on multisig activity would have caught the radiant attack before the third signer got hit
audit_nerd the monitoring only helps if someone is actually awake to see the alerts. radiant happened at 3am. need automated delays on large multisig txs not just alerts
fee_mantis_ automated delays on large txs would have stopped radiant cold. a 12 hour timelock on anything over 500k gives the team a window to respond
fee_mantis_ automated delays on large txs is the fix nobody wants to implement because it breaks the UX. a 24h timelock on anything over 500k would have saved Radiant
Yuki O. a 12h timelock sounds great until a legitimate time-sensitive tx gets stuck. emergency override procedures are where the real design work happens
fee_mantis_ 24h timelock would have saved Radiant but try telling that to a DAO that votes on everything. governance speed vs security is the real tradeoff nobody solves
3-of-11 sounds secure until you realize most signers use the same device. the malware angle is always the weak link
rekt_stoat_ same device problem is why air-gapped signing exists. a 3-of-11 multisig where signers use hardware wallets with manual relay is the only real fix
rekt_stoat_ exactly this. 11 signers across 11 jurisdictions with 11 different machines. the moment two signers use the same hardware wallet model the attack surface shrinks dramatically
rekt_stoat_ the same device problem is huge. a 3-of-11 multisig where 6 signers use the same laptop is just security theater with extra steps
Good walkthrough on spending limits. Most DAOs I have worked with skip that step entirely and then wonder why governance attacks happen.
most DAOs skip spending limits because the governance overhead of adjusting them every month is annoying. the fix is dynamic limits that auto-scale with treasury size
vault_ops_ dynamic limits that scale with treasury size is such an obvious fix. hardcoded limits become irrelevant after a token 3x and suddenly your 500k cap is pocket change
spending limits should be the first thing any DAO sets up after deploying a multisig. its wild how many skip it
transaction simulation before execution should be non-negotiable for any multisig above 6 figures. Safe has had this for a while and people still skip it because it adds 30 seconds to the workflow
transaction simulation adding 30 seconds is nothing compared to losing 53M. the fact that any multisig signer skips it is pure negligence
Sigrun H. 30 seconds of simulation would have saved $53M at Radiant. the fact that Safe shipped this feature and people still skip it is insane
transaction simulation adds 30 seconds and saves $53M. the fact that anyone skips it tells you everything about crypto opsec culture
the malware that hit Radiant went through the signers machines not the contract. your multisig config can be perfect on-chain and still fail if one key holder clicks a bad link