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
multisig or die that assumption change is the whole ballgame. design for compromise, not for trust. every security model that assumes honest hardware is broken.
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
Igor M. the second laptop cost is trivial but getting signers to actually use it is the real challenge. our DAO bought 3 airgapped machines and 2 of them sit in a drawer
dao_treasury_ops the airgapped machines sitting in drawers is the real problem. security workflows that require effort from humans will always degrade over time
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
sig_guard the independent channel problem is real. we use Signal with pre-shared keys to hash-compare tx data out of band. malware on the signing machine cant touch that
sig_guard_ using Signal as independent channel is clever but now you added a SIM swap attack vector to your DAO treasury flow. defense in depth has diminishing returns
threat_model_ Signal adds SIM swap risk but at least it is a different attack vector. perfect security does not exist, you just raise the cost
safe_stack screen sharing during calls works until someone has a compromised display pipeline. hardware level verification via dedicated device is the only trustworthy path
three developers signed a malicious tx because their screens showed a normal emissions adjustment. the hardware wallets were connected to compromised machines. this is why clear signing on the device display matters more than the multisig threshold
blind_sig_ the terrifying part is the hardware wallet displayed a hash not the human readable tx. if your device cant show you what you are signing the multisig is theater
the Radiant exploit was $50M because 3 signers approved a malicious tx. the hardware wallets displayed the correct data but the middleware intercepted the actual signing
the middleware interception is the scary part. signers saw legit tx data on their hardware screens but the actual signed payload was different. blind signing was never fixed properly
Karthik S. middleware interception is the nightmare scenario. your hardware wallet shows the correct tx but signs something completely different and you never know until the funds are gone
the radi ant exploit changed how we think about multisig. your hardware wallet displaying the right info means nothing if the signing pipeline is compromised upstream
Radiant signers approved a malicious payload because the malware changed what was displayed on screen. hardware wallets dont help when the computer lies to you
50M from Radiant because 3 devs signed blind. the blind signing problem was known for years before this