The $50 million Radiant Capital exploit in October 2024 shattered a widely held assumption in the cryptocurrency community: that multi-signature wallets backed by hardware devices provide an impenetrable layer of security. The attack demonstrated that when malware infects the signing environment—the computer connected to the hardware wallet—attackers can manipulate what signers see and approve without their knowledge. For DAOs, protocol teams, and advanced users managing significant treasuries, this attack vector demands a fundamental rethinking of multi-sig security architecture. This advanced tutorial walks through the technical countermeasures that protect against device-level compromise.
The Objective
The goal is to design a multi-signature workflow that remains secure even when one or more signing devices are compromised by malware. This requires eliminating the trust assumption that the computer displaying transaction details to the signer is honest. In the Radiant Capital attack, three developers signed what they believed was a routine emissions adjustment. Their hardware wallets displayed a legitimate-looking transaction, but the malware on their computers had replaced the actual transaction data between the interface and the signing process. The hardware wallets signed the malicious transaction because the attack manipulated the data pipeline before it reached the secure element.
Prerequisites
Before implementing the security measures described in this tutorial, you should have experience with multi-signature wallet platforms such as Safe (formerly Gnosis Safe), understand how Ethereum transaction encoding works at the ABI level, and be comfortable using command-line tools for transaction decoding. You will need access to at least two independent computing devices for the verification workflow, a hardware wallet such as Ledger or Trezor, and familiarity with blockchain explorers like Etherscan for independent transaction verification. This tutorial assumes you are working with an Ethereum-based multi-sig, but the principles apply to any blockchain with multi-signature support.
Step-by-Step Walkthrough
Step 1: Establish an air-gapped verification environment. Set up a dedicated computer that is never connected to the internet. Install a minimal operating system—Tails OS or a fresh Ubuntu installation with no additional packages. This device will serve as your offline transaction verification station. Transfer transaction data to this machine via USB drive or QR code, never via network connection. On this isolated system, decode the raw transaction hex to verify exactly what operations the transaction will perform, including all contract interactions, token transfers, and approval changes.
Step 2: Implement independent hash verification. Before signing any multi-sig transaction, compute its hash on at least two independent systems using different software implementations. For example, compute the hash using both the ethers.js library in a Node.js environment and the web3.py library in Python. If the hashes match, you can be confident that the transaction data has not been tampered with. This cross-verification makes it astronomically difficult for an attacker to manipulate the transaction on both systems simultaneously unless both are compromised through the same vector.
Step 3: Deploy transaction simulation as a mandatory checkpoint. Use Tenderly Simulation API or the debug_traceTransaction RPC method to simulate the exact state changes the transaction will produce before any signer approves it. This simulation reveals hidden operations—such as token approvals to unknown addresses, ownership transfers, or proxy upgrades—that might be invisible in the transaction summary displayed by the multi-sig interface. Automate this simulation as a pre-signing requirement: no signer should approve a transaction until the simulation report has been independently reviewed.
Step 4: Implement time-locked execution with security review windows. Configure your multi-sig to require a minimum delay between the last signature and on-chain execution—24 to 72 hours for high-value operations. During this window, an independent security reviewer who did not participate in the signing process examines the pending transaction using their own verification stack. If any anomaly is detected, the transaction can be cancelled before execution. This time lock would have prevented the Radiant Capital attack entirely: the malicious transaction would have been caught during the review period.
Step 5: Create a transaction allowlist framework. For recurring operations like emissions adjustments, salary payments, or routine rebalancing, pre-define the exact contract addresses, function signatures, and parameter ranges that are acceptable. Any transaction that falls outside these predefined parameters requires an elevated approval process with additional signers and a longer time lock. This framework limits the blast radius of a compromised signer—their infected device can only approve transactions within the allowlisted parameters.
Troubleshooting
If your organization resists the additional friction of multi-layer verification, frame the security measures in terms of risk quantification. The Radiant Capital attack cost $50 million. The additional time required for air-gapped verification—perhaps 15 to 30 minutes per transaction—is trivial compared to the potential loss from a single compromised signing event. For organizations using Safe multisigs on Ethereum, the Safe Transaction Service API provides programmatic access to pending transactions, enabling automated security checks that reduce the manual burden on signers while maintaining rigorous verification standards.
A common implementation challenge is managing the offline verification environment in a team setting. Use a shared USB drive with a clear chain of custody, or implement QR-code-based data transfer between online and offline systems. Ensure that the offline verification tools—transaction decoders, hash calculators, and simulation reports—are regularly updated to support new contract interfaces and function signatures as your protocol evolves.
Mastering the Skill
Advanced multi-sig security is not a destination but a practice. Regularly conduct tabletop exercises simulating attack scenarios like the Radiant Capital breach—have team members attempt to identify malicious transactions embedded in batches of legitimate-looking operations. Rotate signing devices and verification environments periodically to prevent long-lived compromises. Stay current with the latest attack techniques by following security research from firms like Trail of Bits, OpenZeppelin, and Spearbit. The attackers are continuously evolving their methods. Your defense must evolve faster.
Disclaimer: This article is for educational purposes only and does not constitute security advice. Implement these measures at your own risk and consult with qualified blockchain security professionals for guidance specific to your organization.
the Radiant attack proved that multi-sig with hardware wallets is not enough. you need to assume the signing machine is already compromised. that changes everything about how you design the workflow
airgapped verification with a second independent device decoding raw transaction data is the only real defense against display manipulation. expensive to implement but cheaper than losing $50M
airgapped decoding of raw tx hex should be standard for any DAO treasury over $1M. the cost of a second laptop is negligible compared to a $50M loss
we implemented video call verification for any tx over 100k at our DAO. all signers share their screens showing the raw tx hex and compare independently. clunky but it works
video call verification is clever but what stops the malware from feeding different data to each participant in the call? you need an independent channel to cross-reference