Multisig Best Practices in 2026: The Permission Is the Attack

A six million dollar allowlist edit

On Sunday, 4 October 2026, an anonymous vault on Base lost about 1,783 wstETH, worth roughly $6 million, in a sequence that looked, on-chain, completely routine. The vault was controlled by a 3-of-7 Safe multisig. That Safe signed a transaction removing a freshly deployed contract from the vault’s borrowing allowlist at 08:52 UTC, then signed a second transaction re-enabling the same contract one minute later, at 08:53 UTC. About seventy seconds after the re-enable, the newly whitelisted contract borrowed 1,783.067 aBaswstETH against the vault’s Aave v3 position on Base and redeemed it into wstETH, which left for an attacker address. Blockaid flagged the drain publicly at 09:20 UTC; PeckShield, CertiK, GoPlus Security and ExVul followed within the hour.

Nothing about that is a broken signature or a stolen seed phrase. On-chain, both allowlist transactions carried three valid ECDSA signatures from the same signing identities, exactly what a 3-of-7 is built to produce. The Safe had sat idle for twenty-five days before these two edits, which is why investigators lean toward compromised signer credentials or an insider rather than a protocol bug. There was no vulnerability in Aave’s lending contracts and none in Base. The multisig did precisely what it was designed to do: it authorized a change, and the change was the attack. Roughly $31.7 million reportedly remained exposed in related positions.

Two days earlier, on 2 October, the security firm SlowMist reported a different but rhyming loss: about 114.09 ETH drained from two Safe multisig wallets through the Loop Safe Module, a third-party adapter built on top of Aave v3. These two incidents opened October directly after September 2026 closed as the worst month of the year for crypto theft, around $766 million, led by the $387.5 million Bitget breach and the roughly $320 million Liquid Network exploit. For anyone running a multisig in 2026, the two October losses carry the same uncomfortable message, and it is not the one most best-practice guides still lead with.

The multisig did not break. It obeyed.

For most of multisig’s history, the security conversation has been about stopping a bad transfer: do not let an attacker move coins out of the wallet without the required signatures. That framing is now a decade out of date. The expensive failures of 2024, 2025 and 2026 did not forge signatures or crack keys. They got the legitimate signers to approve the wrong thing, or they abused a standing permission the wallet had already granted.

The distinction that matters is between a transfer and a privileged operation. A transfer empties the wallet once, for a fixed amount, to one address. A privileged operation, adding a contract to an allowlist, enabling a module, swapping an owner, changing a guard, pointing a proxy at new code, does something far worse: it hands someone a standing key to the wallet and everything it controls. The Base vault attacker did not ask the signers to send $6 million. They got one contract whitelisted, and let that contract pull the funds through Aave on its own schedule. Radiant Capital’s 2024 loss worked the same way; the signers authorized a transferOwnership call on a core contract, and ownership did the rest.

This is why the single most useful change you can make to a 2026 multisig policy is to stop treating configuration changes as administrative housekeeping and start treating them as the highest-risk transactions the wallet will ever sign. A $6 million withdrawal and a one-line allowlist edit should go through the same ceremony, the same timelock and the same out-of-band checks. In most of this year’s losses, they did not.

What the numbers actually say

The data backs the reframe. TRM Labs counted 207 hacks in the first half of 2026, with about $972 million stolen, down from $2.3 billion in H1 2025 even as the number of incidents more than doubled. Within that, smart-contract exploits made up the majority of incidents, 125 of 207, but only a small share of the value. Infrastructure, private-key and operational compromise accounted for roughly 15 percent of incidents and about 76 percent of the money. The median hack cost around $219,000; the mean was $4.7 million, skewed by a handful of enormous ones.

Translation: the cryptography almost never breaks. The approval and permission layer sitting on top of it breaks constantly, and when it breaks it is where the real money goes. North Korea-linked activity alone took an estimated $643 million, about two-thirds of H1 losses, concentrated in two April incidents, Drift Protocol at $285 million and the liquid-restaking protocol KelpDAO at $292 million. Bitcoin trading around $85,200 and Ether near $2,700 as this went out, with the market in a calmer Uptober mood, does not change the structural point: value keeps concentrating in multisigs, and the people who attack them have stopped bothering with the math.

The 2026 casebook: what was actually authorized

Line the year’s marquee losses up by what the multisig or its infrastructure actually authorized, rather than by headline dollar figure, and the pattern is hard to miss. In almost every case the keys themselves were fine.

Only Bybit and WazirX fit the classic blind-signed-transfer story. The rest are permission changes (Radiant, Base), pre-signed authority (Drift), key hygiene (Humanity), validity logic above the keys (Liquid) and backend infrastructure (Bitget). Bybit and Bitget bracket the range in dollar terms, and in every row the fix lives in operations, not in a cleverer signature scheme.

Best practice 1: know who holds the keys, and who answers for them

Start with the least technical question, because the Base vault turned on it: who are your signers? That vault was controlled by seven addresses whose owners are not publicly known, and when it drained there was no desk to call, no custodian on the hook and no regulator with standing. A 3-of-7 among strangers is not decentralization; it is a quorum of people you cannot audit, cannot vet and cannot subpoena.

Ethereum co-founder Vitalik Buterin has framed the whole problem in two questions. “Two key questions in using multi-sig wallets and social recovery wallets securely are: (i) whom do you choose as guardians, and (ii) what instructions do you give them?” he has written. Most 2026 post-mortems are, at root, a wrong answer to one of those two. Signers are targets, not just custodians: Drift’s attackers worked its council for months before a single transaction moved, the same patient relationship-building con that drives industrial-scale pig-butchering fraud.

The Security Alliance (SEAL) best-practices guidance is concrete about composition: at least three signers, a threshold of at least 50 percent, role diversity across executives, developers and operations, and for any high-value wallet at least one required signer external to the organization so a single compromised team cannot reach quorum alone. Each signer should use a dedicated address for each multisig, never a reused hot key. The point is accountability as much as arithmetic: you want to know, before anything goes wrong, exactly who can reach quorum and who you are trusting when a key goes missing.

Best practice 2: treat every permission change like a withdrawal

Here is the practice almost nobody enforces and almost every 2026 case punishes: a configuration change is a transaction too, and usually a more dangerous one. Enabling a module, adding an address to an allowlist, swapping an owner, changing a guard, upgrading a proxy implementation; each of these grants standing power. Yet teams routinely run transfers through a careful signing ceremony and wave configuration changes through as routine admin.

The Base vault is the clean example. The malicious contract was not stolen into the allowlist; it was added by a valid 3-of-7 Safe transaction, removed, then re-added seventy seconds before it struck. UXLINK’s 2025 loss used a delegatecall to swap the Safe’s owner before minting trillions of tokens. Radiant’s signers authorized a transferOwnership. In each, the attacker never needed to move a single coin with the owners’ signatures; they needed one privileged edit, and the protocol’s own logic did the draining.

SEAL’s guidance addresses this head-on, calling for out-of-band verification for admin changes through independent channels such as a video call plus a signed message, on top of the raw-data check every transaction already gets. In practice that means a configuration change should attract more scrutiny than a payment, not less: every signer independently decoding the calldata, confirming which contract is being granted what power, and confirming out of band that the change was actually requested by a human who can be named. A Safe dormant for twenty-five days that suddenly toggles an allowlist twice in two minutes should have been the loudest possible alarm.

Best practice 3: your modules are standing keys, so audit them

Safe’s module system is the most under-examined permission surface in the ecosystem. A module is code you enable on your Safe that can then execute transactions without going through the owners’ m-of-n signatures at all; it is, by design, a standing key with its own rules. Recurring payments, automated DeFi strategies and recovery flows all run as modules. The convenience is real. So is the exposure: once a module is enabled, that module’s own access control is your security boundary, not your threshold.

The 2 October loss is the textbook case. The Loop Safe Module, a third-party adapter, exposed functions that checked only whether the caller had the module enabled (a bare ISafe(msg.sender).isModuleEnabled(address(this)) test and nothing more). An attacker deployed a fake Safe hard-coded to return true for that check, satisfied the gate, and drove the module’s router with their own calldata to pull weETH and Aave collateral out of two real Safes. Aave founder Stani Kulechov was quick to draw the boundary, clarifying that “the contract with the vulnerability is not the Aave v3 contract, but rather a third-party external adapter built on top of Aave, which does not affect Aave v3 itself.” He is right, and that is exactly the lesson: the safety of a module you bolt onto your treasury is not inherited from the blue-chip protocol it talks to. It is the module author’s problem, and therefore yours.

Keep an inventory of every enabled module and guard, with the same twenty-four-hour update discipline SEAL’s multisig operations certification asks for. Review each module’s code and access control before enabling it, prefer audited and widely-used modules over bespoke adapters, and disable anything you are not actively using. A module you forgot you enabled is a key you forgot you handed out.

Best practice 4: thresholds and signer diversity still matter

None of this retires the basics; it layers on top of them. SEAL’s floor is a minimum of three signers and a threshold of at least 50 percent, rising to seven or more signers for any multisig holding over $1 million. Avoid N-of-N schemes entirely, because a single lost or bricked key then locks the funds forever. Signers should hold different hardware wallet models from different manufacturers, so one firmware bug or supply-chain compromise cannot take the whole set, and the devices and their seed backups should be geographically separated.

The diversity is not box-ticking. Ledger chief technology officer Charles Guillemet spent much of 2026 warning that more machinery is not automatically more safety. After a wave of teams rushed into multisig following a hardware-wallet scare, his standing line was blunt: “Multisig is not automatically the right answer.” Every added signer is another device, another human and another channel that can be phished; the goal is a threshold that survives one compromise, not a sprawling set that multiplies the ways in.

Best practice 5: verify what you sign, and understand what it means

Blind signing, approving a transaction your device cannot render in human terms, is the vector behind Bybit and WazirX, and it remains the default on too many setups. The fix shipped in 2026. On 12 May the Ethereum Foundation’s Trillion Dollar Security initiative launched a coordinated Clear Signing standard, built on ERC-7730 (a JSON format that lets wallets show a human-readable description of what a transaction does), a public registry of those descriptors, and an attestation system so independent auditors can vouch that a descriptor is accurate. The announcement put the stakes plainly: “Approving a transaction is meant to be the last line of defense when exercising control over your assets on the blockchain. When it is done blindly, that defense does not hold.” The goal, it said, is that “What You See Is What You Sign (WYSIWYS) must be our goal, and Clear Signing must be the default.”

Use it. Every signer should sign on a device that renders the actual target contract, function and parameters, and, for anything high-value, independently recompute the transaction hash on a separate clean machine and compare. But understand clear signing’s limit, because it is the limit the permission-surface cases expose: a tool can tell you in perfectly clear language that a transaction enables a module or adds an address to an allowlist, and you can still approve your own ruin if you do not grasp what that permission grants downstream. The Base signers, if compromised, may well have seen an accurate description of an allowlist edit. Clear signing defeats the swapped-display attack; it does not defeat a signer who does not understand that the clearly-described change is catastrophic. Reading the words is necessary; understanding the consequences is the actual skill.

Best practice 6: buy time with timelocks, simulation and monitoring

Speed is the attacker’s friend; every best practice that inserts a delay or a second look is worth more than it costs. A mandatory timelock, a fixed delay between approval and execution, turns an instant theft into a window in which humans can notice and intervene. Drift Protocol learned this in reverse: days before its $285 million loss, its Security Council migrated to a configuration with no timelock, removing exactly the detection window that might have caught the pre-signed transactions before they executed. The Base vault’s two allowlist edits, seventy seconds apart on a wallet idle for twenty-five days, would have been trivial to catch had a timelock or an alert stood between the re-enable and the first borrow.

Simulate before you sign, and simulate configuration changes specifically, not just transfers; a simulation that models what a newly whitelisted contract can subsequently do is worth far more than one that only confirms a transfer amount. Radiant is the cautionary note here: its signers did simulate, but the malware had compromised the signing machines themselves, so the simulation lied. Run monitoring and alerting on every on-chain action the multisig takes, as SEAL recommends, not only on outgoing value; an owner change or module toggle at 3am should page a human. The oracle-manipulation losses that went multi-chain this year are a reminder that the inputs to a signing decision, prices, simulations, the data on the screen, are themselves attack surfaces.

Best practice 7: isolate keys, plan recovery, rehearse

The Humanity Protocol loss in June is the lesson on key isolation stated as a negative. On paper it ran two independent thresholds, 3-of-6 on Ethereum and 3-of-5 on BNB Chain. In practice, several keys from both chains had been backed up to a single employee’s laptop, so one compromised device crossed both thresholds at once. Founder Terence Kwok was candid, telling reporters that “some of the keys were accidentally backed up to a compromised device during setup.” An M-of-N that lives on one machine is a 1-of-1 wearing a costume.

Each key belongs on its own dedicated, ideally air-gapped or hardened device, with backups stored separately and never co-located. SEAL’s multisig operations certification formalizes the surrounding discipline: a named operations owner and a full inventory, quarterly access reviews, 48-to-72-hour offboarding for emergency-class signers, a three-year audit trail, independent verification across two separate interfaces, and emergency playbooks rehearsed in regular drills with a target response under two hours. The recovery plan matters as much as the prevention: decide in advance how you rotate a suspected-compromised key, who can invoke an emergency veto quorum, and how you move funds to a fresh configuration, then rehearse it before you need it at 3am rather than during the incident.

Multisig, MPC, or both

A recurring 2026 question is whether to split the key on-chain with a multisig or off-chain with multi-party computation (MPC), where a single signature is produced from distributed shares that are, in Fireblocks’ phrasing, “never created, never stored, and never assembled at any point.” The honest answer is that they fail differently. Safe puts it well: “Multisig externalizes trust into verifiable code. MPC internalizes trust into systems and infrastructure that cannot be fully verified on-chain.” A multisig fails at the approval screen, which is why clear signing matters so much; an MPC or backend-authorization system fails at an unverifiable backend, which is what happened at Bitget, where attackers fed spoofed data to the exchange’s own authorization infrastructure and it released $387.5 million without a single key being stolen.

Most production custody in 2026 uses both: an on-chain multisig where each key is itself protected by MPC, or MPC signing gated by on-chain policy. For a DAO or DeFi treasury that values public auditability, multisig’s fully on-chain transparency is usually worth its higher gas and coordination cost. For an exchange moving at machine speed, MPC’s flexibility is the draw, with the Bitget caveat that the backend then has to be defended like the vault it is. Neither model saves a signer who approves the wrong permission, which is the thread running through every case above.

The accountability gap: who you call when it goes wrong

The Base vault exposed the other half of the problem: recourse. When funds leave a self-custodied multisig of anonymous signers, there is no custodian, no insurance desk and no regulator with jurisdiction. That is the trade self-custody makes, and it is defensible, but it has to be a choice made with open eyes rather than a default nobody examined.

In the United States, the Securities and Exchange Commission’s Custody Rule under the Investment Advisers Act (Rule 206(4)-2) requires registered advisers to hold client assets with a qualified custodian. A no-action letter from the SEC’s Division of Investment Management in late September 2025 let state-chartered trust companies qualify as bank custodians for crypto, conditioned on written key-management and cybersecurity policies, SOC-1 and SOC-2 audits, asset segregation and no rehypothecation without consent. Crucially, that guidance still does not resolve whether assets sitting in a multisig or an MPC arrangement satisfy the Custody Rule at all. None of this year’s marquee losses, Bybit, WazirX, Drift, Humanity, Liquid, Bitget or the Base vault, happened at an SEC-regulated custodian, which is both why the money was reachable and why there is no official remedy. For investors who want that backstop, the custody fine print behind crypto ETFs is now part of the decision. The regulatory perimeter and the attack surface still do not line up.

A practical 2026 multisig checklist

None of this is exotic. Put together, the year’s lessons collapse into a short operational checklist that treats permissions, not just transfers, as the thing to defend:

• Treat every permission change (module, allowlist, owner, guard, proxy) as higher-risk than any transfer, with the same ceremony, timelock and out-of-band confirmation.
• Keep a live inventory of enabled modules and guards; review each one’s access control before enabling it and disable anything unused.
• Know your signers by name; include at least one external signer for high-value wallets; give each signer a dedicated address.
• Use at least three signers and a threshold of 50 percent or more; seven or more for over $1 million; never N-of-N.
• Diversify hardware wallet models and manufacturers; separate devices and backups geographically; never co-locate keys on one machine.
• Sign on a dedicated air-gapped or hardened device; enable clear signing and recompute high-value transaction hashes on a separate clean machine.
• Put a mandatory timelock between approval and execution; simulate configuration changes, not just transfers.
• Monitor and alert on every on-chain action, including owner and module changes, around the clock.
• Write and rehearse a recovery plan: key rotation, an emergency veto quorum and migration to a fresh configuration.
• Decide consciously whether you have any recourse if it fails, and document who is accountable.

Frequently Asked Questions

What is the most common cause of multisig losses in 2026?

Not broken cryptography or stolen seed phrases, but the approval and permission layer. TRM Labs found that infrastructure, key and operational compromise caused about 76 percent of the value stolen in the first half of 2026 despite being only around 15 percent of incidents. In practice that means signers approving a malicious transfer or, increasingly, a privileged configuration change such as an allowlist edit or a module install.

Why was the Base vault hack possible if the multisig worked correctly?

Because the multisig did work correctly; it authorized the attack. On 4 October 2026 a 3-of-7 Safe signed a valid transaction adding a malicious contract to the vault’s borrowing allowlist, then re-enabled it seconds before it drained about $6 million through the vault’s Aave position. The signatures were genuine. The failure was that signers, most likely compromised, approved a permission change that handed a standing key to an attacker-controlled contract.

Are Safe modules safe to use?

Modules are useful but they are standing keys: once enabled, a module can move funds without the owners’ m-of-n signatures, so the module’s own access control becomes your security boundary. The 2 October Aave Loop Safe Module loss of about 114 ETH came from a third-party adapter whose access check could be satisfied by a fake Safe. Review every module’s code before enabling it, prefer audited and widely-used modules, and disable anything you are not using.

How many signers should a multisig have?

Security Alliance guidance recommends a minimum of three signers with a threshold of at least 50 percent, rising to seven or more signers for any wallet holding over $1 million, and never an N-of-N scheme, which locks funds permanently if one key is lost. More signers is not automatically safer, though: each one adds a device and a person who can be phished, so aim for a threshold that survives one compromise rather than the largest set you can assemble.

Does clear signing prevent multisig hacks?

Clear signing, the Ethereum Foundation’s 2026 standard built on ERC-7730, defeats the swapped-display attacks behind Bybit and WazirX by showing signers a human-readable description of what they are approving. It does not, by itself, stop a signer from approving a clearly-described but catastrophic permission change, and it does nothing for compromised signer credentials. It is necessary, not sufficient; pair it with timelocks, permission-change discipline and monitoring.

By Anneke de Vries, security desk, HOGE Wire.