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.
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
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
3-of-11 sounds secure until you realize most signers use the same device. the malware angle is always the weak link
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
spending limits should be the first thing any DAO sets up after deploying a multisig. its wild how many skip it