Hierarchical Multisig for Treasury and Governance: Design Patterns

Short description: A practical playbook for decision‑makers to design hierarchical multisig systems that scale from small product teams to global DAOs—covering Safe modules, Zodiac roles, cross‑chain execution, timelocks, passkeys, Bitcoin Miniscript/MuSig, and real‑world thresholds, with hardening lessons from major exploits.

Why hierarchical multisig now

The last two years brought major building blocks for treasury security and DAO operations: Safe modules matured (guards, roles, delays), Snapshot-to-onchain bridges became production‑grade (Reality.eth + Kleros), modular smart‑account standards advanced (ERC‑6900, ERC‑7579), and L2s formalized “security council” patterns with high‑threshold emergency powers. Your treasury design can now combine social governance, automated checks, cross‑chain execution, and cryptography beyond plain k‑of‑n signatures. (help.safe.global)

This guide lays out concrete patterns we deploy for clients, with parameters, contract knobs, and real examples you can adapt.

Core concept: hierarchical multisig

“Hierarchical multisig” means you don’t run your entire organization off one flat k‑of‑n wallet. Instead, you compose:

A root treasury with slow, high‑assurance controls (big thresholds, long delays).
Mid‑tier “program” safes with scoped authorities and spending ceilings.
Per‑team “ops” safes with fine‑grained permissions, rate/amount limits, and faster paths for routine activity.
Emergency/guardian layers with narrowly‑scoped powers to freeze, veto, or pause. (github.com)

The hierarchy is enforced by modules, guards, timelocks, and—when needed—cross‑chain message receivers.

Pattern 1 — Root Safe with delay + veto: “Slow money, strong brakes”

Wallet: Safe (≥1.3.0) with Timelock semantics via OpenZeppelin Governor or TimelockController.
Powers: upgrades, major transfers, policy changes; no day‑to‑day payments.
Controls:
- Execution delay: 2–7 days (queue/execute via Governor + TimelockController), or GovernorTimelockAccess + AccessManager to apply per‑function delay without forcing all assets into a separate timelock. (docs.openzeppelin.com)
- Proposers/Executors: Only the governance contract can propose/cancel; execution can be “open” (zero address executor) for transparency. (docs.openzeppelin.com)
- Optional veto: a community‑elected “proposal guardian” with a limited‑use veto on queued payloads (kept separate from pause powers), mirroring emerging DAO practice. (comp.xyz)

Why this matters: delays give users time to react; a minimal veto surface catches fat‑finger or malicious payloads that slip past token votes. OpenZeppelin’s docs outline exact roles and delay updates (updateDelay only by the timelock itself). (docs.openzeppelin.com)

Implementation notes:

If you want the governor to keep asset custody, pair it with AccessManager using GovernorTimelockAccess so certain target functions are delay‑restricted while the governor still executes. This avoids scattered custody while preserving delays. (docs.openzeppelin.com)

Pattern 2 — Program Safes with granular permissions: “Define what, where, and how much”

Wallet: Safe with a Roles Modifier in front of it (Zodiac Roles) to scope calls by:
- Target address
- Function selector
- Parameter constraints (ABI‑aware conditions)
- Optional allowances (per‑role spending quotas and rate limits) (github.com)
Guards: Safe Transaction Guard to pre‑/post‑check transactions (e.g., disallow upgrade calls or token approvals outside allow‑list). (help.safe.global)
Delay: Add a Delay Modifier for a fixed cooldown on programmatic actions (e.g., 24h) with FIFO queue and nonce‑skip for emergencies. (github.com)

Why this matters: you can grant a team the right to “claim_rewards(address)” only for a specific gauge, or “approve(token, spender, amount<=X)” once per period—without giving blanket transfer power. The Roles SDK now supports annotations to group permission sets (e.g., “cowswap swap DAI->WETH”) and programmatic diffing/patching of role JSON. (docs.roles.gnosisguild.org)

Practical defaults we use:

Allowances: refill = monthly budget (in wei), period = 30d; distinct allowance IDs for stablecoins vs volatile assets.
Clearance: block all delegatecalls by default; only allow call; explicitly allow multisend unwrapping where needed. (github.com)

Risk footnote: Safe’s own UI intentionally doesn’t expose module/guard install flows because a bad module can brick/drain a Safe. Use audited packages and explicit sign‑off procedures. (help.safe.global)

Pattern 3 — Off‑chain voting to on‑chain execution: Snapshot → Reality.eth → Safe

When you want community signaling without granting signers discretionary power:

Module: Zodiac Reality Module on a Safe.
Flow:
1. Create proposal off‑chain (Snapshot).
2. Post a Reality.eth question with templateId, timeout, arbitrator, and a proposalId + array of EIP‑712 txHashes to execute if “yes.”
3. After resolution (bond escalation if challenged), anyone can trigger execution via the module’s immutable executor. (github.com)
Arbitrator: Kleros (ERC‑792) is commonly used for disputes; fees kick in only if someone escalates. This is battle‑tested and supports cross‑chain arbitration proxies. (docs.kleros.io)
Tuning:
- timeout: 24–72h to allow challenges;
- arbitrator: a DAO‑approved court;
- maximum bond: set to deter spam and incentivize finality. Reality’s askQuestion(templateId, question, arbitrator, timeout, opening_ts, nonce) is the on‑chain entrypoint. (realitio.github.io)

Outcome: transforms a multisig into a community‑run treasury—signers become executors of the oracle outcome rather than deciders. (zodiac.wiki)

Pattern 4 — Cross‑chain control with enforced cooldowns

Treasuries live on multiple chains. Don’t give every chain a full signer set—instead:

Receiver on destination: Safe with Zodiac Bridge Module (AMB/Connext/Hashi variant), plus Delay Modifier. The origin DAO sends a message; the destination Safe enforces a fixed cooldown (e.g., 48h) before executing. (github.com)
Concrete recipe (as used by Unlock Protocol):
- Add Delay module with cooldown = 2 days, expiration = 90 days.
- Add Connext bridge receiver; set origin sender (DAO) and origin domain ID.
- Route Connext → Delay (setTarget), then enable the module. No signer approvals are required if modules are pre‑configured. (docs.unlock-protocol.com)
Alternatives: Hashi oracle aggregator or generic AMB; evaluate trust assumptions per bridge. (hackmd.io)

Outcome: the origin governance controls satellites, but each chain enforces local time to detect mistakes before funds move.

Pattern 5 — Emergency brakes by design (Guardians)

Leading protocols separate “upgrade policy” from “emergency policy”:

Aave runs two elected 5‑of‑9 multisigs:
- Protocol Emergency Guardian (EMERGENCY_ADMIN): can freeze/pause quickly;
- Governance Emergency Guardian: can cancel malicious payloads;
  members are service providers/delegates, elected by DAO. (governance.aave.com)
Compound ships a Timelock and a Pause Guardian; the guardian can pause Mint/Borrow/Transfer/Liquidate but cannot unpause or reverse executed proposals. Some DAOs are adding a separate “proposal guardian” to veto queued payloads in extremis. (stage.compound.finance)

Adopt this pattern at your root or program level: give a narrowly‑scoped guardian the minimum callable surface (e.g., freeze markets, cancel a queued op), with higher threshold than routine ops.

Pattern 6 — Thresholds that scale with risk

Arbitrum’s Security Council is a 12‑signer structure requiring 9/12 for emergency actions across its L2s, reflecting a high upgrade bar; the DAO renews members via on‑chain elections. Use this as a reference for your top‑tier threshold. (docs.arbitrum.foundation)

For operational multisigs, set signing thresholds by value bands. One community proposal suggests: 6/12 <$1M, 7/12 $1–5M, 8/12 $5–10M, 9/12 $10–50M. Even if you don’t adopt this verbatim, the tiering logic is sound. (forum.arbitrum.foundation)

Threshold ≠ safety if keys colocate: Ronin’s bridge used 5/9 but attackers seized five keys; Harmony’s bridge used 2/5 and two hot‑wallet keys were compromised. Key distribution, HSM/MPC, and monitoring are as important as k. (roninchain.com)

Pattern 7 — Passkeys and account abstraction for human‑friendly signers

Modern signer stacks can include Passkeys (WebAuthn, P‑256) as owners or as policy‑bound “signers” inside a Safe via ERC‑1271 verification, with EIP‑7212 precompiles on supported networks. Safe provides passkey contracts and SDK flows so your exec team can use hardware keys or device‑bound passkeys without raw seed phrases. Pair with ERC‑4337 for gas abstractions and sponsor flows. (docs.safe.global)

Tip: gate passkey‑only signers behind Roles and Guards; never give them upgrade rights directly.

Pattern 8 — Bitcoin treasury: Miniscript + MuSig2/FROST

If you manage BTC alongside EVM assets:

Policy descriptors: encode spending trees with Miniscript/Descriptors (e.g., sortedmulti, timelocks). Example descriptor idea: “2‑of‑3 until height X; after 90 days, CFO alone can spend with CSV timelock; after 365 days, recovery key can spend.” Use BIP‑380/381/382/383/385 reference to serialize and audit the policy. (bips.dev)
Signature schemes: under Taproot, MuSig2 compresses multiple keys into a single Schnorr signature (smaller, more private) but demands nonce hygiene; FROST gives a two‑round threshold Schnorr with standardized IRTF RFC 9591 (June 2024). Choose libraries with audited nonce handling. (bitcoinops.org)
Tooling: use rust‑miniscript or descriptor toolkits for parsing and PSBT generation; script‑review the spending paths. (github.com)

Pattern 9 — Cosmos/Solana equivalents you can plug in

Cosmos SDK x/group: on‑chain group policies (threshold/percentage), min execution windows, and separate membership vs decision policies—cleanly mapping to “root vs sub‑account” designs. (evm.cosmos.network)
Solana SPL Governance (Realms): modular governance with council/community tokens, plugins (e.g., NFT voting), and treasuries—use for Solana programs and wire a Squads multisig for execution if you need hierarchical ops. (splgovernance.com)

Putting it together: a reference architecture

Here’s a concrete, cross‑chain setup we deploy for high‑growth teams:

Root Safe (Ethereum):
- Governance: OpenZeppelin Governor + TimelockController, 2–7 day min delay.
- Optional veto: Proposal Guardian (separate multisig, narrow power). (docs.openzeppelin.com)
Program Safes (per product or region):
- Modules: Zodiac Roles + Delay; Safe Guard enabled.
- Roles:
  - “Trader”: allowed to swap via specific routers with parameter‑constrained slippage; monthly allowance 500k USDC.
  - “Ops”: allowed to pay vendors from allow‑list, per‑tx cap 25k, rate limit daily.
- Delay: 24h cooldown on module‑driven tx; CFO multisig can skip a stuck tx by bumping nonce as last resort. (github.com)
Community execution lane:
- Snapshot proposals → Reality.eth question → Module executes pre‑hashed Safe transactions on “yes.” Arbitrator: Kleros DAO Court. timeout: 48h. Set reasonable bonds. (zodiac.wiki)
Cross‑chain satellites (Arbitrum/Base/Polygon):
- Destination Safe with Bridge Receiver + Delay (48h). Origin = Ethereum DAO. No local signers required for routine actions. (docs.unlock-protocol.com)
Emergency layer:
- Protocol Guardian (5‑of‑9) can freeze or cancel limited surfaces; explicit playbooks and test transactions. (aave.com)
Human UX:
- Execs and finance leads authenticate with Passkeys; custodial partners or MPC co‑signers may co‑approve via policy engines, but onchain rights remain constrained by Roles/Guards. (docs.safe.global)

Parameter cheat‑sheet (start here, tighten over time)

Root delay: 72h for upgrades, 48h for finance ops; proposers = Governor only; executor = anyone. (docs.openzeppelin.com)
Program role limits:
- USDC vendor payments: per‑tx cap = $25k; monthly allowance = $250k; rate = max 10 calls/day/role.
- DEX trades: slippage ≤ 0.5%; approved pools only; no delegatecall.
- Approvals: only to inventory wallets and curated routers, max allowance = 2× daily spend.
Reality module: timeout = 48h; arbitrator = DAO’s chosen Kleros court; require EIP‑712 txHashes array to mitigate proposal mutation. (github.com)
Cross‑chain: cooldown = 48h; expiration = 90d; Connext domain IDs set per chain; origin sender hard‑coded to the DAO/Root Safe. (docs.unlock-protocol.com)

Key‑management and monitoring hardening (non‑negotiable)

Distribute signers across jurisdictions, orgs, and devices; don’t let any two keys share a security domain (same admin, same SSO, same office). Ronin/Harmony show why. (roninchain.com)
Prefer hardware‑backed keys or passkeys for human signers; if using MPC platforms, configure policy engines (address allow‑lists, velocity limits, geofencing) so an MPC “yes” still hits onchain Roles/Guards. (fireblocks.com)
Alerts: queue events (Timelock scheduled), module enqueue, guard reconfig, role diffs, and bridge messages should page humans (PagerDuty/Slack). Defender is being sunset (July 1, 2026); plan migrations for relaying/monitoring to open‑source equivalents. (docs.openzeppelin.com)
Fire drills: quarterly tests to freeze, cancel, and recover; simulate lost signer and compromised key runbooks.

Bitcoin treasury example (Miniscript descriptor sketch)

Spending policy:
- Day 0–30: 2‑of‑3 (CFO, Controller, Chair).
- After 30 days: Controller alone with CLTV >= blockHeight+4,320.
- After 365 days: Recovery key can spend with CSV 90 days.
Implement as descriptors with miniscript branches; if privacy/fees matter, use Taproot tr() with MuSig2 on cooperative branch and script path for time‑locked branches. Be mindful of nonce best practices in MuSig2; consider FROST libs where a threshold signature across HSMs is required. (bips.dev)

Solana/Cosmos notes

Solana SPL Governance: define a Realm with council/community, configure voting thresholds and timelocks; for ops execution, couple with a Squads multisig (v4) and assign plugin roles per program. (splgovernance.com)
Cosmos x/group: keep “group membership” separate from “decision policies.” Create sub‑policies with different thresholds and minExecution windows and delegate via x/authz. This mirrors the “program safe” concept nicely. (evm.cosmos.network)

Common pitfalls we see (and how to avoid them)

“Flat” 3‑of‑5 for everything: creates signer fatigue and rubber‑stamping; move routine ops to Roles + Delay, reserve high‑threshold signers for break‑glass only. (github.com)
Over‑trusting bridges: always pair a cross‑chain receiver with a Delay; treat bridge relays as untrusted until the cooldown elapses. (docs.unlock-protocol.com)
No veto lane: a narrowly scoped guardian or veto saves you a week‑long governance roundtrip when a queued payload is bad. (comp.xyz)
Modules/guards installed ad hoc: follow Safe guidance—install via reviewed transactions; log and diff role configs; use audited commits. (help.safe.global)

30/60/90‑day rollout plan

30 days:
- Stand up Root Safe + Governor + Timelock with 72h minDelay; map asset ownership to Timelock (or GovernorTimelockAccess + AccessManager).
- Elect Proposal/Emergency guardians with tightly scoped powers. (docs.openzeppelin.com)
60 days:
- Migrate team payments to Program Safes; install Roles and Delay; codify allow‑lists and allowances; wire transaction guards.
- Implement Snapshot → Reality path on a small operating budget first. (zodiac.wiki)
90 days:
- Add cross‑chain receivers with 48h cooldowns.
- Introduce passkeys for execs; enforce signer diversity; run an emergency drill. (docs.unlock-protocol.com)

Final thought

Hierarchical multisig isn’t more complicated for the sake of it—it lets you move fast at the edge while making the core almost impossible to move by accident. Start from minimal, auditable modules and add only the powers your teams need, with explicit amounts, rates, and time.

If you want a tailored blueprint for your org’s asset mix and chain footprint, 7Block Labs can model thresholds, module graphs, and cross‑chain cooldowns—and deliver a tested deployment script set.

References and further reading

Safe modules, guards, SDK, and ERC‑4337 integration; Passkeys/WebAuthn for Safe signers. (help.safe.global)
Zodiac Roles / Delay / Bridge / Reality modules and docs. (github.com)
OpenZeppelin Governor, TimelockController, AccessManager, and best practices. (docs.openzeppelin.com)
Arbitrum Security Council constitution and elections. (docs.arbitrum.foundation)
Aave Guardian structure and powers. (aave.com)
Compound Timelock and Pause Guardian. (stage.compound.finance)
Reality.eth + Kleros arbitration (ERC‑792). (docs.kleros.io)
Bitcoin Miniscript/Descriptors and MuSig2/FROST. (bips.dev)
Cosmos x/group and Solana SPL Governance. (evm.cosmos.network)
Post‑mortems and analyses of Ronin and Harmony bridge incidents. (roninchain.com)