On May 24, 2026, the stablecoin world witnessed a textbook operational security failure. StablR, a Malta-based issuer running on Tether’s Hadron platform with full MiCA compliance, was exploited through its 1-of-3 multisig wallet. The attacker compromised a single key, removed legitimate signers, added a controlled address, and minted approximately 8.35 million unbacked USDR and 4.5 million unbacked EURR tokens. Roughly $2.8 million was extracted in about 1,115 ETH before detection. EURR dropped to $0.85, USDR crashed to a low of $0.40. The stablecoin market, exceeding $323 billion in total capitalization, barely registered the event. But for any team running a multisig with a 1-of-N threshold, this is a five-alarm fire.
The Objective
This tutorial walks through configuring a production-grade multisig wallet using Gnosis Safe (now Safe), the industry standard for multi-signature Ethereum wallets. The goal is to establish a threshold configuration that would have prevented the StablR exploit: specifically, a 3-of-5 multisig setup with proper signer management, daily spending limits, and recovery procedures. By the end of this guide, you will have a hardened multisig deployment suitable for treasury management, token minting authority, or any high-value on-chain operation.
Prerequisites
Before proceeding, ensure you have the following ready. This guide assumes familiarity with Ethereum wallets and basic smart contract concepts.
- Five independent Ethereum wallets — each controlled by a different person or stored on separate hardware. These will serve as your five signers. Do not use wallets that share a seed phrase or hardware device.
- ETH for gas — each signer wallet needs a small amount of ETH (0.01-0.05 ETH is sufficient for Safe deployment and initial transactions). At the time of the StablR exploit, ETH was trading near $2,134.
- Safe Wallet web interface — access the official deployment at app.safe.global. Verify the URL carefully. Phishing sites targeting Safe users are common.
- A network — this guide covers Ethereum mainnet, but the same principles apply to any EVM-compatible chain (Arbitrum, Polygon, Base, etc.).
- An understanding of your use case — know what operations this multisig will authorize (treasury transfers, token minting, contract upgrades) so you can set appropriate thresholds and spending limits.
Step-by-Step Walkthrough
Step 1: Create the Safe
Navigate to app.safe.global and connect the first signer wallet. Click “Create new Safe” and select Ethereum mainnet. Enter a descriptive name — something like “Project Treasury — Prod” or “Minting Authority — Mainnet.” Avoid generic names that could cause confusion if you later create additional Safes.
When prompted for signers, add all five wallet addresses. Verify each address character by character. A single typo in a signer address means that address will never be able to sign transactions, reducing your effective signer count and potentially locking funds.
Set the threshold to 3. This means any transaction requires approval from at least 3 of the 5 signers before execution. This is the critical configuration that would have prevented the StablR exploit — even if one key is compromised, the attacker cannot authorize transactions alone.
Step 2: Fund the Safe
Send ETH and any tokens the Safe will manage to the newly created Safe address. Record this address in your project documentation. Multiple team members should independently verify the address.
Step 3: Configure Spending Limits
Safe supports module-based spending limits that allow individual signers to execute small transactions without requiring the full 3-of-5 threshold. Navigate to Settings and then Spending limits and configure a daily allowance per signer. For a treasury Safe, a reasonable starting point might be 0.5 ETH per signer per day. For a minting authority Safe, you may want to disable individual spending entirely, requiring the full threshold for any minting operation.
This layer of defense ensures that even if two keys are compromised simultaneously (approaching but not reaching the 3-of-5 threshold), the damage is bounded by the daily spending limit.
Step 4: Implement Signer Rotation Procedures
Document and rehearse the process for replacing a signer. If a team member leaves or a device is compromised, you need to swap the signer address promptly. This requires a 3-of-5 transaction to execute the swap. The procedure should include notification of all remaining signers, verification of the new signer address by at least two independent team members, and execution within 24 hours of the compromise or departure.
The StablR attacker removed legitimate signers after gaining access. With a 3-of-5 threshold, removing a signer still requires two additional compromised keys — a significantly harder attack vector.
Step 5: Enable Transaction Guards
Safe supports transaction guards — smart contracts that impose additional constraints on what transactions the Safe can execute. Consider deploying a guard that prevents signer swaps unless initiated by a separate governance process, or one that enforces a time-lock on high-value transactions. This adds a programmable layer of protection on top of the multisig threshold itself.
Step 6: Test with Small Transactions First
Before using the Safe for production operations, execute several small test transactions. Have different combinations of 3 signers approve and execute transactions. Verify that the spending limits work correctly. Attempt a transaction that should fail (e.g., exceeding the daily limit) and confirm it is rejected. This dry-run phase catches configuration errors before they matter.
Troubleshooting
“Transaction stuck pending” — A pending Safe transaction requires the threshold number of confirmations. If only 2 of 3 required signers have confirmed, the transaction waits indefinitely for the third. Contact the remaining signer. You can also reject a pending transaction by executing a new transaction with the same nonce, which replaces the stuck one.
“Signer cannot connect” — Ensure the signer’s wallet is connected to the correct network. A signer configured on Ethereum mainnet cannot sign transactions on Arbitrum, even though the Safe interface supports both. Also verify that the signer address matches an address listed in the Safe’s signer set.
“Accidentally added wrong signer address” — If the Safe was just created and has no funds, the easiest fix is to create a new Safe with the correct addresses. If the Safe already holds funds, you need a threshold-signer transaction to swap the incorrect address for the correct one. This is why the verification step during creation is critical.
“Threshold too high, cannot get enough signers” — If you set a 4-of-5 threshold and two signers are unavailable, you are temporarily locked out. This is by design — it means the funds are protected but inaccessible until enough signers are available. If this becomes a persistent problem, consider whether a 3-of-5 threshold better suits your operational reality. Never lower the threshold to 1-of-N to resolve a temporary availability issue.
Mastering the Skill
Configuring a secure multisig is not a one-time setup — it is an ongoing operational discipline. Schedule quarterly reviews of your multisig configuration. Verify that all signer addresses are still controlled by the intended parties. Check that spending limits still align with your operational needs. Review transaction history for any unusual patterns.
The StablR exploit exploited the gap between technological capability and operational practice. The tools for secure multisig management exist today — Gnosis Safe, hardware key storage, transaction guards, spending limits. The failure was in choosing convenience over security: a 1-of-3 threshold instead of a 2-of-3 or 3-of-5 configuration. Blockaid’s assessment was blunt — it was a “key management and governance failure,” not a technology failure.
As the stablecoin ecosystem continues to expand well beyond $323 billion in market capitalization, the attack surface grows proportionally. Every team managing on-chain assets should treat multisig configuration as a first-class security concern, subject to the same rigor and review as smart contract audits. The tools are mature. The best practices are well-documented. The only remaining variable is whether teams choose to implement them before or after an exploit forces their hand.
This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making financial decisions.
1-of-3 multisig for a stablecoin issuer with millions in TVL. thats not a multisig thats a single key with extra steps
single key with extra steps lmao. and they were MiCA compliant too. regulatory checkboxes mean nothing if your opsec is garbage
the tutorial format is actually helpful. 3-of-5 with daily spending limits and recovery should be the minimum for any protocol
daily spending limits are underrated. even with 3-of-5 you want circuit breakers so a compromised quorum cant drain everything in one tx
gnosis safe config with proper signer management would have stopped this cold. the tools exist, teams just dont use them properly
tools exist but teams cheap out on multisig setup. configuring proper signer rotation and daily limits takes actual effort
^ this. the tutorial covers recovery procedures but real time alerting on signer changes is what actually stops the bleed
the StablR attacker minted 8.35M USDR and 4.5M EURR. with proper signer rotation that second key would have triggered an alert before the mint