DEV Community: 0xrivet

What Your Multisig Threshold Actually Protects

0xrivet — Fri, 21 Aug 2026 18:45:11 +0000

I've been digging into multisig configurations for bridge and protocol security reviews. The threshold gets all the attention — 3-of-5, 4-of-7, whatever. But after checking a few dozen Safes on mainnet, the threshold is rarely the weakest link. There are five other things that determine whether a Gnosis Safe actually protects funds, and most people only check the first one.

This post walks through all of them, with cast commands you can run yourself.

What the threshold does

The threshold sets the minimum number of owner signatures required to execute a transaction through execTransaction(). If threshold is 3 and you have 2 signatures, the call reverts. Simple.

# check threshold and owners
cast call <SAFE> "getThreshold()(uint256)"
cast call <SAFE> "getOwners()(address[])"

This is the part everyone understlse.

What the threshold does NOT protect

1. Modules

This is the biggest blind spot in multisig security.

Safe modules are contracts authorFromModule()`. A module can execute*any transaction from the safe without a single owner signature*. The threshold is irrelevant. The module has its own authority.

`bash

if this returns anything other than an empty array, investigate

cast call "getModulesPagin[],address)" \
0x0000000000000000000000000000000000000001 10
`

Modules are legitimate — timelockation. But a malicious or compromisedmodule is a full bypass of every threshold. Your 7-of-10 means nothing if a module can move funds independently.

2. Guard

A guard contract implements checerExecution(). It adds validation on top of the threshold — restricting destinations, limiting values, blocking certain operations.

The guard address lives at a specific storage slot. If it's 0x00, there's no guard. No additional checks beyond threshold + signatu

`bash

guard storage slot (keccak256("guard_manager.guard.address"))

cast storage \
0x4a204f620c8c5ccdca3fd54d003badd85ba500436a431f0cbda4f558c93c34c8

0x000...000 = no guard installe

A guard can enforce things like "no transfers above X without delay" or "no delegatecalls ever."
Without one, the threshold alone lly isn't enough.

3. Fallback handler

The fallback handler processes annize — EIP-1271 signaturevalidation, token callbacks (onERC721Received, onERC1155Received), anything routed through the fallback() function.

`bash

fallback handler slot (keccak256("fallback_manager.handler.address"))

cast storage \
0x6c9a6c4a39284e37ed1cf53d337577d14212a4870fb976a4366c693b939918d5
`

A compromised fallback handler caion, manipulate token reception logic, or introduce re-entrancy vectors. It runs in the context of calls to the safe, not calls from it — a different attack surface terous.

4. Delegatecall (operation=1)

This is how Bybit lost $1.46B.

execTransaction takes an operaular call. 1` is a delegatecall — the target contract's code executes in the safe's storage context. The target can rewrite ownership, change the threshold, drain everyn.

The signers approved what appearehe transaction payload containedoperation: 1. The target contract ran DELEGATECALL in the safe's context, replacing the implementation with an attacker-chold was met. Every signature wasvalid. It just didn't matter — the signers didn't understand what they were signing.

# execTransaction signature — noteter
# execTransaction(address to, uint256 value, bytes data, uint8 operation,
#   uint256 safeTxGas, uint256 ba
#   address gasToken, address refundReceiver, bytes signatures)
#
# operation: 0 = Call, 1 = DelegateCall
# if your guard doesn't block openg
# set of signers can delegatecall arbitrary code

Without a guard that explicitly bold-meeting quorum of signers —whether compromised, socially engineered, or just not reading the payload — can execute a delegatecall that rewrites the en

5. Organizational independence

Not on-chain, but worth more than

Ronin Bridge ran 5-of-9. Four keyfth was an allowlisted key from agas-free RPC arrangement in November 2021 — never revoked. One compromised developer machine yielded 5 of 9 signatures. The threshold s not.

You can't verify this with castwner addresses share a common fundingsource, were deployed by the same address, or interact with the same contracts. Same deployer funding multiple "independent" si

# check if owners share a funding origin
cast call <SAFE> "getOwners()(add
# for each owner, trace the first inbound ETH transfer
# common source → likely same org

The Safe Safe Checklist

Five things to verify beyond the threshold. I run these on every safe I audit.

#	Check	Command	Red flag
1	modules	`getModulesPaginated()`	any unknown contract
2	guard	storage slot read
3	fallback	storage slot read	unverified contract
4	delegatecall	guard configll restriction
5	independence	owner funding trace	common deployer/funder

The full check in one shot:

SAFE="<SAFE_ADDRESS>"

# threshold + owners
cast call $SAFE "getThreshold()(uint256)"
cast call $SAFE "getOwners()(address[])"

# modules (bypass threshold entirely)
cast call $SAFE "getModulesPaginated(address,uint256)(address[],address)" \
  0x0000000000000000000000000000000000000001 10

# guard (additional validation layer)
cast storage $SAFE \
  0x4a204f620c8c5ccdca3fd54d003badd85ba500436a431f0cbda4f558c93c34c8

# fallback handler (processes unknown calls)
cast storage $SAFE \
  0x6c9a6c4a39284e37ed1cf53d337577d14212a4870fb976a4366c693b939918d5

The threshold is the door lock. Modules are the window you forgot to close. The guard is the deadbolt you never installed. The fallback handler is the mail slot big enough to reach through. And delegatecall is the landlord's master key — works even when every lock is engaged.

Check all five. Or don't, and hope nobody else does either.

More posts and tooling on 0xrivet.xyz. The cast snippets above and some other safe-audit scripts are on GitHub. If you're auditing bridge multisigs or building guard contracts, feel free to reach out — always happy to compare notes.
cast call $SAFE "getOwners()(addr

modules (bypass threshold entir

cast call $SAFE "getModulesPaginated(address,uint256)(address[],address)" \
0x00000000000000000000000000000

guard (additional validation la

cast storage $SAFE \
0x4a204f620c8c5ccdca3fd54d003ba3c34c8

fallback handler (processes unk

cast storage $SAFE \
0x6c9a6c4a39284e37ed1cf53d337579918d5



---                                                                                          
The threshold is the door lock. Modules are the window you forgot to close. The guard is the deadbolt you never installed. The slot big enough to reach through. And delegatecall is the landlord's master key — works even when every lock is engaged.

Check all five. Or don't, and hope nobody else does either.

---

*More posts and tooling on [0xrivet.xyz](https://0xrivet.xyz). The cast snippets above and some other safe-audit scripts are on [rivet). If you're auditing bridgemultisigs or building guard contracts, feel free to reach out — always happy to compare notes.*

Your Bridge's Security Page Is Lying to You

0xrivet — Thu, 20 Aug 2026 19:41:14 +0000

I spent the last few months pulling apart bridge security pages and comparing what they claim to what the contracts actually enforce on-chain. It's not pretty.

This post is the scoring framework I ended up building. Everything here you can verify yourself with cast and an RPC endpoint — no trust required.

(Originally published at https://0xrivet.xyz/bridge-trust-score)

Bridge Trust Score

Five layers, each scored 0-4. The composite score is the minimum — because attackers go for the weakest one, not the strongest.

Layer	What it protects	Where it failed
L1 Verification	Message authenticity	Wormhole $326M
L2 Independence	Validator diversity	Ronin $625M
L3 Upgrade	Contract mutation	Nomad $190M
L4 Timelock	Reaction window	Harmony $100M
L5 Circuit Breaker	Drain velocity	Bybit $1.46B

Security here is multiplicative. One zero makes the whole thing zero.

L1 — Verification

How does the destination chain know a message is actually real?

0 = single signer, 1 = multisig under 5, 2 = 5-12 independent validators, 3 = 13+ or multi-method ISM, 4 = ZK light client.

The thing nobody talks about — LayerZero V2 DVN configuration is per pathway. I've seen bridges running 2-of-3 DVN on their main Ethereum→Arbitrum route and 1-of-1 on a smaller chain. The docs never break this down at the pathway level. You have to check:


bash
cast call <SEND_LIBRARY> \
  "getUlnConfig(address,uint32)((uint64,uint8,uint8,uint8,address[],address[]))" \
  <OAPP_ADDRESS> <DST_EID>

If requiredDVNCount comes back as 1 with 0 optionals — that's a single point of failure right there.

Wormhole has 19 guardians, 13-of-19 quorum. Sounds solid. But in January 2024 a researcher found that the genesis guardian set — one key — was never expired on Wormchain. One key bypassing the entire quorum. It was allegedly destroyed before discovery. "Allegedly"
isn't a security model. They fixed it within 48h, but it had been sitting there for years.

L2 — Independence

Everyone cites Ronin's 5-of-9 but nobody explains the actual mechanism. Four of the nine validators were Sky Mavis infrastructure. The fifth was a signing allowlist from November
2021 that was created for a transaction surge, expired in December, and was never revoked. Lazarus compromised one developer laptop and got 5 of 9 keys.

L3 — Upgrade Authority

Most people check "is it a multisig?" and stop there. Don't.

You need to trace the whole chain:

Proxy → EIP-1967 admin slot → ProxyAdmin → owner()
  → Timelock? → proposer role → Multisig → threshold/owners

# Step 1: who controls upgrades?
cast storage <PROXY> \
  0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103

# Step 2: is it an EOA or contract?
cast code <ADMIN> | head -c 10
# "0x" means EOA. That's a score of 0 right there.

L4 — Timelock

Here's the thing — the delay value isn't what matters. What matters is who can change it.

cast call <TIMELOCK> "getMinDelay()(uint256)"
# 86400 = 24 hours. Looks good.

# But wait — can the admin set it to zero?
cast call <TIMELOCK> "hasRole(bytes32,address)(bool)" \
  $(cast keccak "TIMELOCK_ADMIN_ROLE") <ADMIN>
# If true, your timelock is theater.

A timelock whose delay can be zeroed without its own delay is the same as no timelock.

L5 — Circuit Breaker

Bybit lost $1.46B in a single batch. No rate limit triggered. No pause. Nothing.

Most bridges I've checked score 0 here. It's the least deployed layer and probably the one that would've mattered most.

---
Patterns I Keep Seeing

Asymmetric pathways. The flagship route is well-secured. The secondary chain nobody audited runs 1-of-1 DVN. Guess which one the attacker uses.

Timelock illusion. There's a 48h timelock. The admin holds
TIMELOCK_ADMIN_ROLE. One call to updateDelay(0) and it's gone.

Orphaned guardians. Validator set gets rotated on mainnet. Old set never expires on some alt-L1. The Wormchain bug was exactly this.

The Safe blind spot. Threshold and owners get checked. Modules don't. A module can execute transactions without meeting the threshold at all.

cast call <SAFE> "getModules()(address[])"
# If this returns anything — investigate immediately.

---
The 60-Second Version

Five commands. Run these and you'll know more than the security page tells you.

B="<BRIDGE_PROXY>"

# 1 — Upgrade admin
cast storage $B 0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103

# 2 — EOA or contract?
cast code <ADMIN> | head -c 10

# 3 — Multisig threshold
cast call <ADMIN> "getThreshold()(uint256)" 2>/dev/null

# 4 — Timelock delay
cast call <ADMIN> "getMinDelay()(uint256)" 2>/dev/null

# 5 — Can it be paused?
cast call $B "paused()(bool)" 2>/dev/null

If the admin is an EOA, you already know more than the docs told you.

---
The toolkit that automates these checks is open source:
bridge-security-toolkit.
PRs welcome.

— 0xrivet / 0xrivet.xyz