Hierarchical Multisig for Treasury and Governance: Design Patterns

---

Why hierarchical multisig now

The last couple of years have really laid down some solid foundations for treasury security and DAO operations. We’ve seen Safe modules come into their own with features like guards, roles, and delays. Plus, the Snapshot-to-onchain bridges have gone full circle and are now production-ready, thanks to Reality.eth and Kleros. On top of that, we’ve made strides in modular smart-account standards with ERC-6900 and ERC-7579. And let’s not forget how Layer 2s are putting together “security council” setups that carry some serious emergency powers with high thresholds. Your treasury design can now mix social governance, automated checks, cross-chain execution, and advanced cryptography that goes way beyond just plain k-of-n signatures. (help.safe.global)

This guide breaks down the specific patterns we use for our clients. You'll find details on parameters, contract options, and real-world examples that you can easily tweak for your own needs.

---

Core concept: hierarchical multisig

“Hierarchical multisig” means you’re not relying on a single flat k‑of‑n wallet to manage your whole organization’s funds. Instead, you create a more structured setup:

• A main treasury that has strict, high-security measures in place (think big thresholds and long wait times).
• Mid-level “program” safes that come with specific authorities and spending limits.
• Individual “ops” safes for each team, featuring detailed permissions, rate/amount caps, and quicker processes for everyday tasks.
• Emergency or guardian layers with limited powers to freeze, veto, or pause actions. (github.com)

The hierarchy is maintained using modules, guards, timelocks, and, when necessary, cross-chain message receivers.

---

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

• Wallet: Make sure you’re using Safe (≥1.3.0) with Timelock features, which you can set up through OpenZeppelin’s Governor or TimelockController.
• Powers: We’re talking upgrades, major asset transfers, and policy changes here--nothing for the everyday payments.
• Controls:
  • Execution delay: Expect a wait of 2 to 7 days. You can queue and execute through Governor + TimelockController, or go for GovernorTimelockAccess + AccessManager to set delays on specific functions without needing to put all your assets in a separate timelock. Check out the details in the OpenZeppelin docs.
  • Proposers/Executors: Only the governance contract can suggest or cancel proposals. For more transparency, you can keep execution “open” using a zero address executor. More info can be found in the OpenZeppelin docs.
  • Optional veto: We can introduce a community-elected “proposal guardian” who has a limited veto power over queued payloads. This keeps their role separate from any pause powers, reflecting what’s becoming a standard practice in DAOs. Take a look at the discussion on this over at Compound’s community.

Why this matters

Delays provide users with a chance to respond, while a minimal veto surface helps catch any accidental or malicious payloads that might get through token votes. OpenZeppelin’s documentation clearly lays out the specific roles and how updates work (remember, the updateDelay can only be changed by the timelock itself). Check it out here: (docs.openzeppelin.com).

Implementation notes:

• If you're looking to have the governor maintain asset custody, consider pairing it with AccessManager through GovernorTimelockAccess. This way, you can restrict certain target functions with delays while still allowing the governor to execute actions. It helps keep custody organized and ensures delays are in place. Check out the details in the OpenZeppelin docs.

---

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

• Wallet: We've got a Safe that features a Roles Modifier right in front of it (Zodiac Roles) to help manage calls by:
  • Target address
  • Function selector
  • Parameter constraints (think ABI-aware conditions)
  • Optional allowances (these include per-role spending limits and rate caps) (github.com)
• Guards: Implement a Safe Transaction Guard to check transactions before and after they go through (for instance, you can block upgrade calls or token approvals that aren’t on the allow-list). (help.safe.global)
• Delay: You can also add a Delay Modifier to introduce a fixed cooldown for programmatic actions (like 24 hours) along with a FIFO queue and nonce-skip option for those emergency situations. (github.com)

Why this matters

You now have the ability to give a team permission to use claim_rewards(address) for a specific gauge or to approve approve(token, spender, amount<=X) just once per period--without handing over full transfer rights. The Roles SDK has got your back with new annotations that let you group permission sets (like “cowswap swap DAI->WETH”) and makes it easy to diff or patch role JSON programmatically. Check out the details here: docs.roles.gnosisguild.org

Practical Defaults We Use:

• Allowances: The refill amount is set to the monthly budget (in wei), and the period lasts for 30 days. We also have different allowance IDs for stablecoins and volatile assets.
• Clearance: By default, we block all delegate calls; we only permit standard calls. We also make sure to explicitly allow multisend unwrapping when it’s necessary. Check it out on GitHub.

Risk note: The UI for Safe is designed to keep module and guard install flows hidden on purpose. This is because a faulty module could potentially brick or drain your Safe. Always stick to audited packages and make sure you follow sign-off procedures. For more details, check out this link: help.safe.global

---

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

When you're looking to promote community signaling but don’t want to give signers the ability to make discretionary decisions:

• Module: Zodiac Reality Module on a Safe.
• Flow:
  1. First up, create a proposal off-chain using Snapshot.
  2. Next, post a question on Reality.eth that includes the templateId, timeout, arbitrator, and the proposalId along with an array of EIP-712 txHashes for execution if the answer is “yes.”
  3. Once the resolution is in (including any bond escalation if it's challenged), anyone can fire up execution through the module’s immutable executor. Check it out on GitHub.
• Arbitrator: Kleros (ERC-792) is a go-to for handling disputes. The cool thing is, fees only kick in if someone decides to escalate things. It's been tried and tested and even supports cross-chain arbitration proxies. Learn more at Kleros Docs.
• Tuning:
  • timeout: Set it between 24 to 72 hours to give a chance for challenges.
  • arbitrator: Pick a DAO-approved court to keep it official.
  • maximum bond: Adjust this to discourage spam and encourage quick decisions. You can use Reality’s askQuestion(templateId, question, arbitrator, timeout, opening_ts, nonce) as your entry point on-chain. For more details, check out Reality Docs.

Outcome: changes a multisig into a community-managed treasury--signers shift their role from decision-makers to executors of the oracle outcome. (zodiac.wiki)

---

Pattern 4 -- Cross‑chain control with enforced cooldowns

Treasuries Live on Multiple Chains

Instead of assigning every chain a full set of signers, here’s a better approach:

• Receiver on destination: We're using a Safe with the Zodiac Bridge Module (you know, the AMB/Connext/Hashi variant) along with a Delay Modifier. So, when the origin DAO sends a message, the destination Safe puts a pause on things with a fixed cooldown -- think 48 hours -- before anything happens. (github.com)
• Concrete recipe (like what Unlock Protocol uses):
  • First up, add the Delay module with a cooldown of 2 days and an expiration of 90 days.
  • Next, throw in the Connext bridge receiver; don’t forget to set the origin sender (the DAO) and the origin domain ID.
  • After that, route from Connext → Delay (setTarget), and then go ahead and enable the module. If you’ve set everything up ahead of time, there’s no need for any signer approvals. (docs.unlock-protocol.com)
• Alternatives: You could also check out the Hashi oracle aggregator or a generic AMB; just make sure to evaluate the trust assumptions for each bridge. (hackmd.io)

Outcome: The main governance oversees the satellites, but each individual chain manages its own local time to spot errors before any funds are transferred.

---

Pattern 5 -- Emergency brakes by design (Guardians)

Leading protocols make a clear distinction between “upgrade policy” and “emergency policy”:

• Aave has set up two elected 5‑of‑9 multisigs:
  • Protocol Emergency Guardian (EMERGENCY_ADMIN): This one can quickly freeze or pause the protocol when needed.
  • Governance Emergency Guardian: This guardian's job is to cancel any malicious payloads that might sneak in. The members of these multisigs are service providers or delegates chosen by the DAO. You can check out more about it here.
• On the other hand, Compound has a Timelock in place along with a Pause Guardian. This guardian has the authority to pause actions like Minting, Borrowing, Transferring, and Liquidating, but they can't unpause or reverse proposals that have already been executed. Some DAOs are also bringing in a separate “proposal guardian” to veto any queued payloads in extreme situations. For more details, swing by this link.

Make sure to implement this approach at your core or program level: set up a tightly-focused guardian that has just the essential functions (like freezing markets or canceling a queued operation) and requires a higher threshold than your everyday operations.

---

Pattern 6 -- Thresholds that scale with risk

Arbitrum's Security Council is set up with 12 signers, and to take any emergency actions across its L2s, it requires the agreement of 9 out of 12. This setup shows that they’ve set a pretty high bar for upgrades. Plus, the DAO brings in new members through on-chain elections. Keep this in mind as you think about your own top-tier threshold. (docs.arbitrum.foundation)

For operational multisigs, it’s a good idea to set signing thresholds based on value bands. There’s a community proposal that lays it out like this: 6/12 for amounts under $1M, 7/12 for amounts between $1M and $5M, 8/12 for amounts from $5M to $10M, and 9/12 for amounts between $10M and $50M. Even if you decide not to follow this exact plan, the tiering concept really makes sense. (forum.arbitrum.foundation)

Threshold doesn’t equal safety when keys are in the same place: For example, Ronin’s bridge set up a 5/9 threshold, but attackers managed to grab five keys. On the flip side, Harmony’s bridge had a 2/5 setup, and two hot-wallet keys got compromised. It’s clear that how you distribute keys, use HSM/MPC, and keep an eye on everything is just as crucial as the threshold (k). (roninchain.com)

---

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

Modern signer stacks can now include Passkeys (WebAuthn, P‑256) as either owners or policy-bound “signers” within a Safe, using ERC‑1271 verification along with EIP‑7212 precompiles on supported networks. Safe offers passkey contracts and SDK flows, making it super easy for your executive team to work with hardware keys or device-bound passkeys without fumbling with raw seed phrases. Plus, when you pair this with ERC‑4337, you get some awesome gas abstractions and sponsor flows. Check out the details here: (docs.safe.global)

Tip: Make sure to keep gate passkey-only signers behind Roles and Guards; it’s best not to give them upgrade rights directly.

---

Pattern 8 -- Bitcoin treasury: Miniscript + MuSig2/FROST

If you're juggling BTC and EVM assets:

• Policy descriptors: Let’s talk about how to set up spending trees using Miniscript/Descriptors. Imagine a descriptor that goes something like this: “2-of-3 until height X; after 90 days, the CFO can spend alone with a CSV timelock; after 365 days, the recovery key can take over.” To keep everything clean and trackable, you can refer to BIP‑380/381/382/383/385 for serializing and auditing your policy. Check it out here: (bips.dev)
• Signature schemes: With Taproot, we have MuSig2, which does a great job of condensing multiple keys into one neat Schnorr signature--it's smaller and more private. Just a heads up, though: it requires nonce hygiene. On another note, FROST offers a two-round threshold Schnorr signature based on the standardized IRTF RFC 9591 (coming in June 2024). When picking libraries, make sure they’ve got good nonce handling baked in. More details can be found here: (bitcoinops.org)
• Tooling: For your tools, using rust-miniscript or descriptor toolkits is the way to go for parsing and generating PSBTs. Don't forget to script-review those spending paths to ensure everything checks out. You can find the toolkit on GitHub: (github.com)

---

Pattern 9 -- Cosmos/Solana equivalents you can plug in

• Cosmos SDK x/group: This lets you set up on-chain group policies like thresholds and percentages, with minimal execution windows. You can also define separate membership and decision policies, which fits perfectly into that “root vs sub-account” design concept. Check it out here.
• Solana SPL Governance (Realms): Here, you get a flexible governance setup with community and council tokens, plus handy plugins like NFT voting and treasuries. This is super useful for managing Solana programs, and if you need to add some hierarchical operations, just wire up a Squads multisig for execution. Learn more here.

---

Putting it together: a reference architecture

Here’s a solid, cross-chain setup that we roll out for high-growth teams:

1. Root Safe (Ethereum):
   • Governance: We’re using OpenZeppelin’s Governor along with a TimelockController that has a minimum delay of 2 to 7 days.
   • Optional veto: There’s also a Proposal Guardian, which is a separate multisig with limited powers. Check out the details here: (docs.openzeppelin.com)

2) Program Safes (by product or region)

• Modules: We’ve got Zodiac Roles and Delay, with Safe Guard turned on.
• Roles:
  • “Trader”: This role can swap using specific routers and has a slippage limit. They also get a monthly allowance of 500k USDC.
  • “Ops”: This role is set up to pay vendors from an approved list, with a transaction cap of 25k per transaction and a daily rate limit.
• Delay: There’s a 24-hour cooldown on module-driven transactions. If things get stuck, the CFO’s multisig can jump in and bump the nonce as a last resort. Check it out on GitHub.

1. Community execution lane:
   • Snapshot proposals kick things off → A question pops up on Reality.eth → The module will execute those pre-hashed Safe transactions when it gets a “yes.” The arbitrator here is Kleros DAO Court. There's a timeout of 48 hours, so keep that in mind. Make sure to set reasonable bonds. (zodiac.wiki)
2. Cross-chain satellites (Arbitrum/Base/Polygon):
   • Sending assets to a Safe using a Bridge Receiver with a 48-hour delay. The starting point? Ethereum DAO. Plus, you don't need any local signers for the everyday stuff. (docs.unlock-protocol.com)
3. Emergency Layer:
   • The Protocol Guardian (5‑of‑9) has the ability to freeze or cancel certain surfaces, along with clear playbooks and test transactions. You can check it out here.
4. Human UX:
   • Executives and finance leaders can easily authenticate using Passkeys. Custodial partners or MPC co-signers have the option to co-approve through policy engines. However, remember that on-chain rights are still limited by Roles and Guards. Check it out here: (docs.safe.global)

---

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

• Root Delay: Upgrades have a 72-hour delay, while finance operations have a 48-hour delay. Proposers are limited to just the Governor, but anyone can be the executor. (docs.openzeppelin.com)
• Program Role Limits:
  • USDC Vendor Payments: Each transaction is capped at $25k, with a monthly allowance of $250k. There's a limit of up to 10 calls per day for each role.
  • DEX Trades: We’re keeping slippage to a minimum at ≤ 0.5%. Only approved pools can be used, and just a reminder--no delegatecall allowed.
  • Approvals: Approvals are restricted to inventory wallets and curated routers, with a max allowance set at 2× the daily spend.
• Reality Module: There's a timeout of 48 hours. The arbitrator will be a Kleros court picked by the DAO. We also need an array of EIP-712 txHashes to avoid any proposal mutations. (github.com)
• Cross-Chain: A cooldown period of 48 hours is in place, and expiration is set for 90 days. Connext domain IDs are established for each chain, and the origin sender is hard-coded to the DAO/Root Safe. (docs.unlock-protocol.com)

---

Key‑management and monitoring hardening (non‑negotiable)

• Spread out your signers across different jurisdictions, organizations, and devices. It’s super important that no two keys share the same security domain--think same admin, same SSO, or same office. Just look at what happened with Ronin/Harmony for a real-life example of why this matters. (roninchain.com)
• When it comes to human signers, go for hardware-backed keys or passkeys if you can. And if you’re using MPC platforms, make sure to set up your policy engines properly. This means having allow-lists, velocity limits, and geofencing in place so that even if an MPC gives you a “yes,” it still checks against your on-chain Roles/Guards. (fireblocks.com)
• For alerts, make sure to queue up events like Timelock schedules, module enqueues, guard reconfigurations, role differences, and bridge messages--these should all notify humans through tools like PagerDuty or Slack. Just a heads up: Defender is set to sunset on July 1, 2026, so it’s time to start planning migrations to some open-source alternatives for relaying and monitoring. (docs.openzeppelin.com)
• Don’t forget to run fire drills! Aim for quarterly tests where you freeze, cancel, and recover; also simulate scenarios like a lost signer or a compromised key with your runbooks.

---

Bitcoin treasury example (Miniscript descriptor sketch)

• Spending Policy:
  • Days 0 to 30: Requires 2 out of 3 approvals (CFO, Controller, Chair).
  • After 30 Days: The Controller can handle spending alone if the CLTV is greater than or equal to blockHeight + 4,320.
  • After 365 Days: The Recovery key can spend with a CSV of 90 days.
• You should set this up as descriptors with miniscript branches. If privacy and fees are a concern, go for Taproot tr() with MuSig2 on the cooperative branch, and use a script path for the time-locked branches. Don’t forget to keep the nonce best practices in mind for MuSig2, and check out FROST libraries if you need a threshold signature across HSMs. (bips.dev)

---

Solana/Cosmos notes

• Solana SPL Governance: Start by defining a Realm that includes your council or community, and then set up those voting thresholds and timelocks. To handle operations, link it with a Squads multisig (v4) and assign plugin roles for each program. You can check out more details here.
• Cosmos x/group: It’s a good idea to keep “group membership” distinct from “decision policies.” You can create sub‑policies that have different thresholds and minimum execution windows, plus use x/authz for delegation. This approach aligns nicely with the whole “program safe” concept. More info can be found here.

---

Common pitfalls we see (and how to avoid them)

• Using a “Flat” 3‑of‑5 setup for everything can lead to signer fatigue and too much rubber-stamping. Instead, consider shifting routine ops to Roles + Delay, and save those high-threshold signers for when you really need them in a break-glass situation. (github.com)
• Don’t over-trust your bridges! Always pair a cross-chain receiver with a Delay. Treat those bridge relays as untrusted until the cooldown period is over. (docs.unlock-protocol.com)
• Lacking a veto lane can be tricky. Having a narrowly scoped guardian or veto can save you from a week-long governance back-and-forth when you realize a queued payload is a dud. (comp.xyz)
• Avoid installing modules or guards on the fly. Stick to the Safe guidance: install through reviewed transactions, keep a log and diff role configs, and always use audited commits. (help.safe.global)

---

30/60/90‑day rollout plan

• 30 days:
  • Set up the Root Safe, Governor, and Timelock with a minimum delay of 72 hours. Make sure to link asset ownership to the Timelock (or use GovernorTimelockAccess + AccessManager).
  • Choose your Proposal/Emergency guardians carefully, giving them specific powers. (docs.openzeppelin.com)
• 60 days:
  • Shift team payments to Program Safes and set up Roles and Delay. Let’s also codify those allow-lists and allowances and get those transaction guards in place.
  • Start implementing the Snapshot → Reality path, but let’s test it on a small operating budget for now. (zodiac.wiki)
• 90 days:
  • Roll out cross-chain receivers, but include a 48-hour cooldown.
  • Bring in passkeys for execs, ensure we’ve got a mix of signers, and run an emergency drill to be prepared. (docs.unlock-protocol.com)

---

Final thought

Hierarchical multisig isn’t just complicated for the heck of it--it's actually designed to help you move quickly at the edge while ensuring the core is super secure and hard to mess up. You start with basic, clear-cut modules that you can keep track of easily. Then, you can add just the permissions your teams need, with specific amounts, rates, and timeframes.

If you’re looking for a customized plan for your organization’s asset mix and chain footprint, 7Block Labs has got you covered. They can create models for thresholds, module graphs, and cross-chain cooldowns, plus they’ll provide a tried-and-true deployment script set.

---

References and further reading

• Safe modules, guards, SDK, and integration with ERC‑4337; plus, Passkeys/WebAuthn for Safe signers. Check it out here: (help.safe.global).
• Take a look at Zodiac Roles, Delay, Bridge, and Reality modules, along with their docs. You can find them on GitHub: (github.com).
• OpenZeppelin has some great resources on Governor, TimelockController, AccessManager, and a bunch of best practices to keep in mind. Dive in: (docs.openzeppelin.com).
• Curious about the Arbitrum Security Council? They have their constitution and details about elections laid out nicely. Check it out here: (docs.arbitrum.foundation).
• Here's what you need to know about the Aave Guardian structure and its powers. More info available here: (aave.com).
• Compound's got your back with the Timelock and Pause Guardian details. Learn more here: (stage.compound.finance).
• Reality.eth and Kleros arbitration (ERC‑792) is an interesting topic. Discover more about it here: (docs.kleros.io).
• If you’re into Bitcoin, check out Miniscript/Descriptors and MuSig2/FROST. Details are available here: (bips.dev).
• Explore the intersection of Cosmos x/group and Solana SPL Governance. There’s some solid documentation here: (evm.cosmos.network).
• Lastly, don't miss the post-mortems and analyses for the Ronin and Harmony bridge incidents. Learn more about it here: (roninchain.com).

---