The $58 million Radiant Capital exploit of October 2024 exposed critical weaknesses in how DeFi protocols configure and operate multi-signature wallets. For protocol administrators, treasury managers, and advanced DeFi users managing significant capital, understanding the technical architecture of multisig security is essential. This tutorial walks through the process of building a production-grade multisig setup that addresses the vulnerabilities highlighted by recent incidents, from signer isolation to transaction simulation and time-locked execution.
The Objective
This guide aims to help you configure a multi-signature wallet system that can withstand sophisticated attacks, including the device-level malware and social engineering techniques used in the Radiant Capital exploit. The configuration targets Gnosis Safe (now Safe), the most widely used multisig framework in Ethereum and EVM-compatible ecosystems, and covers deployment across multiple chains. With the current market environment showing Bitcoin at $67,300 and Ether at $2,620, even moderate-sized protocol treasuries justify the investment in a robust multisig configuration.
Prerequisites
Before beginning this configuration, ensure you have the following components ready. You need at least five team members who will serve as multisig signers, each equipped with a dedicated hardware wallet (Ledger Nano S Plus or Trezor Model T recommended). Each signer must have a dedicated computer — preferably running a privacy-focused operating system like Tails or a hardened Linux configuration — used exclusively for signing multisig transactions. You will need a Safe deployment on each target chain (Ethereum, Arbitrum, Optimism, Base, BSC, or others as needed), access to a transaction simulation service like Tenderly, and monitoring infrastructure that can watch for pending Safe transactions and alert the team.
Additionally, establish out-of-band communication channels for transaction coordination. Do not discuss multisig transaction details in the same channels where business communications occur. Use a separate Signal group or similar end-to-end encrypted channel specifically for multisig operations.
Step-by-Step Walkthrough
Step 1: Deploy with an appropriate threshold. Navigate to app.safe.global and create a new Safe on your target chain. For most protocol operations, a 4-of-6 or 5-of-7 configuration provides the right balance of security and operability. Avoid 3-of-N configurations, as the Radiant incident demonstrated that compromising just three devices is achievable for determined attackers. During setup, add each signer’s hardware wallet address and confirm the threshold.
Step 2: Enable transaction simulation. Before any signer approves a transaction, the proposed action must be simulated to reveal its exact effects. Integrate Tenderly simulation into your Safe workflow by enabling the Tenderly Safe App within the Safe interface. For every transaction that requires signing, run a simulation first and verify that the decoded output matches the intended action. Pay particular attention to any transaction that involves contract upgrades, ownership transfers, or large fund movements. If the simulation shows unexpected actions — particularly changes to contract ownership or code — treat it as a potential compromise and halt signing immediately.
Step 3: Configure a time lock. Deploy a time lock contract as an intermediary between your Safe and the protocol contracts it administers. A 48-hour time lock is recommended for production environments. This means that even if all signers approve a malicious transaction, it cannot execute for 48 hours, giving the community and automated monitors time to detect and respond. OpenZeppelin provides audited time lock contracts that integrate cleanly with Gnosis Safe.
Step 4: Set up monitoring and alerting. Deploy automated monitoring using a service like Forta, OpenZeppelin Defender, or a custom solution that watches your Safe address for pending transactions. Configure alerts for: any transaction that modifies contract ownership, any transaction that upgrades implementation contracts, any transaction that moves more than a threshold percentage of total treasury value, and any transaction proposed by an unrecognized address. Alerts should be sent to all signers through independent channels — email, Telegram, and Signal simultaneously.
Step 5: Implement key rotation procedures. Establish a quarterly key rotation schedule where one or two signers generate fresh hardware wallet addresses and update the Safe configuration. This limits the window during which a compromised key can be exploited. Document the rotation process and maintain a rotation log that tracks when each signer’s key was last rotated.
Troubleshooting
If a signer’s hardware wallet is lost or suspected of compromise, execute an emergency key replacement immediately. The Safe contract supports swapping signer addresses through a threshold-signed transaction. Prepare a replacement signer address in advance, and keep the transaction payload for a signer swap pre-drafted and accessible to all team members. If you suspect that your multisig system is under active attack — for example, if unexpected transactions appear in the Safe queue — immediately execute an emergency pause if your protocol supports one, and communicate with the community through official channels. Do not attempt to outmaneuver the attacker by rapidly signing counter-transactions, as this can create confusion and potentially authorize additional malicious actions.
Mastering the Skill
Advanced multisig security is an ongoing practice, not a one-time configuration. Schedule quarterly security reviews where the team assesses the current configuration, reviews recent transaction history for any anomalies, and updates procedures based on the latest attack patterns observed in the industry. Participate in the Safe ecosystem’s governance and community discussions to stay current on best practices and new security features. Consider engaging a professional security firm for periodic reviews of your multisig operational security, extending your audit coverage beyond smart contract code to include administrative infrastructure. The investment in robust multisig operations pays for itself many times over in the prevented losses and maintained user trust that result from a well-secured protocol administration layer.
Disclaimer: This article is for educational purposes only and does not constitute professional security advice. Consult with qualified security professionals before implementing critical infrastructure changes.
time-locked execution should be mandatory for anything over $1M. gives the team a window to catch suspicious txs
safebuilder $1M threshold for time locks is too generous. anything over $100K should require a 24hr delay at minimum
$100K threshold is arbitrary. the real question is whether the protocol can survive a 24h timelock during a black swan. liquidation risk works both ways
safebuilder the Radiant exploit proved time locks alone are not enough when the signers themselves are compromised. signer isolation is the real lesson
The signer isolation section is exactly what teams need to implement. No more shared laptops for treasury management.
shared laptops for treasury ops in 2024 is insane. the Radiant exploit proved device-level compromise is the new attack vector and most teams are years behind
transaction simulation before execution… how is this not standard practice already for every multisig