hierarchical multisig: Patterns for Treasury Controls and Delegated Authority

---

TL;DR for decision‑makers

• Let’s kick things off with a layered “L0-L2” model: L0 treasury (this is your slow-moving vault that needs a high quorum and is time-locked), then we have L1 operational wallets (these run with a medium quorum and daily limits), and finally, L2 delegates/agents (they handle allowances and specific role scopes).
• Make sure to tap into the native building blocks specific to each chain: for EVM, you can use Safe modules (like Roles, Delay, Spending Limits), Guards, and 4337; on Solana, check out Squads v4 for roles, limits, and timelocks; for Bitcoin, there’s Miniscript + Taproot; and on Cosmos, look into x/group and x/authz for weighted/authorized execution. (docs.roles.gnosisguild.org)

---

Why hierarchical multisig now

Flat multisig setups are great for getting rid of the risks that come with single-key access, but they often struggle with how governance actually works in real life. Different teams have different needs when it comes to their powers, urgent fixes need to happen quickly, and low-risk spending shouldn't have to wait for everyone to weigh in.

That's where modular “smart accounts” come in! With timelocks, role-based permissions, and parameter-level scoping, we can now set up a clear separation of duties right on the blockchain without making things too complicated for users. On the EVM side, Safe modules and Guards add extra policy layers, account abstraction (like ERC-4337) introduces session keys and sponsored gas, and ERC-1271/6492 allow for contract signatures to be verified both on-chain and before deployment.

If you're looking for more details, check this out: (help.safe.global).

---

The building blocks by ecosystem

EVM (Ethereum, L2s)

• Modules and Guards on Safe
  • Modules can bring some serious authority beyond the basic n‑of‑m setup--this is super powerful but also really important for security. Guards are there to do pre/post-transaction checks on top of the quorum. You can read more about it here.
• Roles Modifier (Zodiac)
  • With this, you can create roles that whitelist specific target contracts, function selectors, and even set parameter ranges. It even comes with rate and threshold limits, giving you that fine-tuned least-privilege control for your operations and bots. Check it out here.
• Delay (Timelock)
  • This one helps you enforce some cool-down periods between when a proposal is made and when it actually gets executed. You can even combine it with invalidation to sidestep any malicious or faulty transactions. More details are available here.
• Spending Limits (Allowance module)
  • Here’s a handy feature: you can set time-limited ERC-20 allowances for any address (like 5,000 USDC a day). This allows some wiggle room for small expenses or bots without needing to go through the quorum. Learn how to set it up here.
• Off‑chain governance execution (Reality/SafeSnap)
  • This bridges Snapshot or other voting results to on-chain execution using the Reality.eth oracle, complete with bonds and cool-downs. Discover more here.
• Account abstraction (ERC‑4337)
  • You can enable Safe4337Module on Safe v1.4.1 or later to support UserOperations, bundlers, and paymasters. Plus, it retains the modularity for opting in or out of ERC‑4337. Detailed info can be found here.
• Contract signatures and counterfactual accounts
  • This relies on ERC‑1271 for smart-account signatures and uses ERC‑6492 to verify signatures for pre-deployed (counterfactual) accounts. For more on this, check here.
• TimelockController (OpenZeppelin)
  • This is a governance-grade timelock that includes proposer and executor roles. You can set the timelock as the owner of upgradable systems. Dive into the details here.

Solana

• Squads Protocol v4
  • It's an enterprise multisig setup that includes roles like proposer, approver, and executor, along with spending limits, whitelists, timelocks, batch payments, and a Fee Relayer to make things gasless for members. Check it out here: (squads.xyz)

Bitcoin

• Miniscript + Taproot
  • This combo allows you to lay out hierarchical policies like thresholds, timelocks, and recovery paths in a way that's easy to work with and analyze. Plus, modern wallets and tools are on board with it! You can check it out more at (bips.dev).
• MuSig2 Key Aggregation
  • MuSig2 combines cosigner keys into a single Schnorr signature, which is great for boosting both privacy and fee efficiency. It's particularly handy for those “fast path” sign-only branches. Dive deeper into it here: (developer.blockchaincommons.com).

Cosmos SDK chains

• x/group
  • This feature lets you create on-chain groups that come with their own weights and decision rules (like thresholds). When proposals are made, they get executed based on the group policy account. Check it out here: (docs.cosmos.network)
• x/authz
  • With this, you can manage specific delegated permissions, such as SendAuthorization, which allows you to set a spending limit and create an allow list. These authorizations can be scoped, temporary, and revocable. Dive deeper here: (docs.cosmos.network)

---

Reference patterns you can deploy

Pattern A: L0-L1-L2 Treasury Stack (EVM)

• L0 Strategic Treasury (Safe)
  • Owners: 7-9 execs/board; Threshold: 5-7; Add a Delay modifier (48-120h).
  • Guard: Pre-check target allowlists, block any unsafe opcodes or upgrade calls unless it's through a timelock. (zodiac.wiki)
• L1 Operational Safes (per business unit)
  • Owners: 3-5 managers; Threshold: 2-3; Set Spending Limits for petty cash (daily/weekly), and define Roles for the contracts/functions/params that are allowed. (help.safe.global)
• L2 Delegates/Agents
  • Give bots or contractors allowances (per token/timebox) issued from L1; make sure to rotate them regularly. Also, think about using 4337 session keys for those gas-sponsored automations. (docs.safe.global)
• Governance bridge
  • To gather community input, connect a Reality/SafeSnap module to a Snapshot space; set a bond and a 24h cooldown. (docs.snapshot.box)

Pattern B: “Fast lane / slow lane” on Bitcoin

• Fast lane: We're using the MuSig2 key path, where both the CFO and Controller sign off in just two rounds for those everyday expenses.
• Slow lane: This involves the Miniscript Tapscript branch that needs a threshold of 2 out of 3 signatures, plus a CSV timelock (like older(144)) for recovery or those higher-risk transactions. Check it out here.

Example Miniscript Policy

Here's a look at a sample policy written in a readable format using Miniscript:

---

Purpose

This policy outlines the guidelines and procedures for using company resources responsibly.

Scope

This applies to all employees and contractors while using company assets.

Guidelines

General Use

• Company resources should primarily be used for work-related activities.
• Personal use is okay but should be limited and not interfere with your job.

IT Resources

• Use strong, unique passwords and update them regularly.
• Don't share your login credentials with anyone.
• Report any suspicious activities to the IT team immediately.

Data Protection

• Always handle sensitive information with care.
• Follow the data encryption protocols when storing or transmitting sensitive data.

Social Media

• When posting on social media, ensure that you don’t disclose any company secrets or sensitive information.
• If you’re representing the company online, be professional and respectful.

Reporting Violations

If you notice any violations of this policy, please report them to your supervisor or the HR department.

Conclusion

Following these guidelines helps us maintain a secure and productive work environment. Thank you for your cooperation!

---

This format and style make it easier for everyone to read and understand the important aspects of the policy.

or(
  pk_k(agg_musig2(CFO,Controller)),     # fast path: aggregated key
  and(
    thresh(2, pk(CEO), pk(CFO), pk(COO)), # slow path: 2-of-3
    older(144)                             # ~1-day delay
  )
)

This creates cost-effective "normal" spending while maintaining a delayed branch that offers higher-quorum safety.

Pattern C: Cosmos “Board + Ops + Delegates”

• Set up a x/group with weighted members and apply a ThresholdDecisionPolicy on your group policy account for any big decisions.
• Utilize x/authz SendAuthorization to give Ops wallets some spending limits and approve allow-listed recipients; make sure to set expirations and revoke permissions when there's a turnover. (docs.cosmos.network)

Pattern D: Solana “Program Ops Squad”

• Squads v4 multisig with roles:
  • Proposers (our engineers) can kick off upgrades and mints; Approvers (the leads) sign off on them; Executors take it from there, running the process once we hit the threshold and the timelock clears.
  • You can establish spending limits for everyday vendor and validator operations, plus activate the Fee Relayer so that members don’t have to hold SOL just to give approvals. Check it out here: (squads.xyz)

---

Concrete configurations by company stage

Seed-Series A (lean team, high execution velocity)

• EVM
  • L0 Safe: We've got a 3/4 setup with a 48-hour delay for upgrades and token mints.
  • L1 Ops Safe: This one's set up as a 2/3 system. There are specific roles assigned to handle payroll and USDC transfers. Plus, we’ve got spending limits ranging from 10k to 25k USDC per week to fund the lead wallet. Check out more details here: (zodiac.wiki).
  • We’ll bring in SafeSnap only when the community governance kicks in. More info can be found here: (docs.snapshot.box).
• Bitcoin
  • We're using a 2-of-3 Miniscript that includes a branch for “1-of-2 recovery” after 90 days, ensuring a smooth founder succession process. You can read more about it here: (bips.dev).

Growth/Enterprise (multiple BUs, compliance)

• EVM
  • L0: We’re looking at a 5/9 setup with a 120-hour delay. The TimelockController is in charge of those upgradeable contracts, and for any policy changes, we can go with either the Governor or Reality-based execution. Check it out here.
  • L1 per BU: We're running a 3/5 system with Guards to keep external calls in check. We also have Roles in place to manage DEX trades based on parameters and only allow whitelisted custodians. Get more details here.
  • Agents: We’re using ERC-4337 with paymaster sponsorship to grab some bot support and making sure to rotate session keys every quarter. More info can be found here.
• Solana
  • We rolled out Squads v4, which includes timelocks for program upgrades, spending limits for operations, batch payrolls, and privacy settings for internal squads. Plus, we’ve got a Fee Relayer to improve the user experience for approvers. Check the details here.
• Cosmos
  • For policy management, we’ve got x/group; and for Finance and Ops, we're using x/authz with specific caps on messages and allow lists. Plus, we've set expirations connected to HR offboarding. You can dive deeper here.

---

Implementation recipes (EVM Safe)

1. Install a Delay (timelock)

• Go ahead and deploy or attach the Zodiac Delay, then set up a cooldown period along with an optional expiry. Keep in mind that transactions follow a FIFO order based on queue nonce, but the Safe can bypass this if there's an emergency by advancing the nonce. Check it out here: (github.com)

2) Set Spending Limits

• Turn on the Allowance module and easily set daily, weekly, or monthly limits for each token right from the Safe UI. This feature works wonders for managing finances, stipends, or agent wallets. Check it out here: (help.safe.global)

3) Scope Operations with Roles

• Take advantage of the Roles Modifier to keep things secure by whitelisting function selectors and setting limits on parameters (like approve(address spender, uint256 amount <= 50,000 USDC), but only for those whitelisted DEX routers). Plus, Roles has built-in rate and threshold limits to help manage usage effectively. Check out more details here.

4) Harden with a Guard

• The Transaction Guard is your go-to for checking things before and after execution. You can use it to block any random delegatecalls, reject non-whitelisted targets, or even set limits on transaction values. Check it out here!

1. Include off-chain vote execution if necessary

• Reality Module (SafeSnap): Set up a minimum bond and a 24-hour cooldown period; once the Snapshot proposal gets a “yes,” anyone can step in and execute it. Check out the details here.

1. Activate account abstraction for agents and adjust gas policy

• Switch on the Safe4337Module if you're on Safe v1.4.1 or later; get a bundler/paymaster set up through Safe4337Pack. For contract signature processes, use ERC‑1271 and for counterfactual signature verification, go with ERC‑6492. Check out the details here: (docs.safe.global)

---

Implementation notes (Solana Squads v4)

• Set up roles (like proposer, approver, executor), decide on thresholds, and establish timelocks for each vault.
• Define spending limits and manage whitelists for everyday tasks; turn on the Fee Relayer so members won’t have to worry about having SOL to sign off on things.
• Utilize batch payments for payroll; this way, you can track everything through on-chain program logs and event history from Squads. (squads.xyz)

---

Implementation notes (Bitcoin)

• Create a Miniscript policy that includes a “fast path” for MuSig2 key aggregation and a “slow path” that uses a threshold plus a timelock script.
• It's a good idea to use descriptors that capture Miniscript. Make sure to test your spending paths on regtest or signet before hitting mainnet. (bips.dev)

---

Implementation notes (Cosmos SDK)

• Set up a group policy that includes a threshold decision window and gives weights to the board members.
• Utilize x/authz to create a SendAuthorization for Ops, incorporating a spend_limit and an allow_list. Don’t forget to set expirations and automatically prune grants using module queueing. (docs.cosmos.network)

---

Emerging best practices for 2025

• Make sure to implement least-privilege not just at the overall system level but also at the function and parameter levels. Using the Roles Modifier on Safe and Cosmos x/authz can help you achieve this pretty easily. Check it out here: (docs.roles.gnosisguild.org).
• Don't forget to slap a timelock on those L0 powers (like upgrades or minting/burning). For EVM, standard options include TimelockController or Zodiac Delay, and on Solana, you can go with Squads timelocks. Bitcoin users should add a CSV timelock branch in Miniscript. More details at: (docs.openzeppelin.com).
• Keep approvals and execution separate. Use Executors that only take care of already-approved operations; it's smart to make these executors permission-less (anyone can step in) whenever it's safe--this way, you're not relying too much on specific individuals. Learn more here: (docs.openzeppelin.com).
• Think of modules like you would any other code changes. When you're dealing with Safe modules and Guards, they change authority, so treat them seriously; they need to go through review, staging, and sign-offs just like upgrades do. Check out this link for guidance: (help.safe.global).
• When it comes to bots, stick with 4337 session keys or Safe Allowance instead of making them owners. Also, don’t forget to rotate those keys regularly to keep things secure. More on this here: (docs.safe.global).
• Keep an eye out and automate where you can. If you’re still using Defender, be aware that new sign-ups ended on June 30, 2025, and they're planning a final shutdown on July 1, 2026. You might want to switch to open-source options like Relayer/Monitor or other alternatives. Read more about it here: (blog.openzeppelin.com).
• Don't forget to lay out your recovery paths. Consider adding delayed “break-glass” options (think higher quorum + timelock), and test these out with some tabletop exercises to make sure they work. You can use Miniscript and Guards for this purpose, making everything nice and clear. Get the details here: (bips.dev).

---

Common pitfalls and how to avoid them

• Bypassing the quorum unintentionally
  • Some modules are designed to run without owner signatures, which can lead to unexpected issues. It's super important to make sure that Guards and Roles are tightly scoped to control what modules can actually do. Check out more about this here.
• Unbounded approvals
  • One common pitfall is using ERC‑20’s approve() with unlimited allowances from treasury accounts, and this has led to some serious losses. To avoid this, it’s best to place caps through Roles parameter conditions and stick to pull-based spending limits. You can find more guidance on this here.
• Timelock without self‑administration
  • If an admin can swiftly change proposers or executors, then that timelock is basically just for show. To truly make it effective, follow the recommended role setup and let the timelock handle its own administration. Learn more about this approach here.
• Ignoring pre‑deploy signature flows
  • For counterfactual accounts, it's crucial to integrate ERC‑6492 in off-chain signatures, especially when dealing with OTC and market makers. This way, orders can still be verified before deployment. More details can be found here.

---

Migration to modular AA (EVM): from multisig to policy‑driven accounts

• You can easily adopt ERC‑4337 on your existing Safes using the Safe4337Module--no need to redeploy any accounts!
• If you're looking for that plugin-style flexibility across different accounts and vendors, keep an eye on ERC‑6900 for modular smart accounts. This includes standardized validation and execution hooks, plus cool plugins like session keys and weighted WebAuthn multisig. Check out more details here!

---

Quick checklists

• Technical
  • L0: We've got a timelock in place, a guard set up, and using Reality/Snapshot is optional.
  • L1: There are roles and spending limits established, along with a signer rotation policy and caps for each transaction and day.
  • L2: You can use 4337 session keys or the Allowance module for agents, along with expiry options and logs. (zodiac.wiki)
• Operational
  • We're utilizing multi-party HSM/hardware keys for our human owners. Just a heads-up--key issuance requires a video or in-person ceremony.
  • We're doing quarterly drills for our recovery branches, which include Bitcoin Miniscript and EVM Guard overrides. (bips.dev)
• Monitoring
  • Keep an eye out for alerts on any changes to modules or guards, owner shifts, threshold changes, and significant outbound transfers. Oh, and we're planning to migrate from Defender to OSS stacks by the first half of 2026. (blog.openzeppelin.com)

---

Example: parameter‑scoped role for a DEX trader (EVM Safe + Roles)

• Allowed targets:
  • 0x…UniswapV3Router
  • 0x…1inchRouter
• Allowed functions:
  • exactInputSingle(bytes)
  • swapExactTokensForTokens(uint256,uint256,address[],address,uint256)
• Parameter constraints:
  • tokenIn ∈ {USDC}; tokenOut ∈ {WETH};
  • amountIn ≤ 50,000 USDC;
  • deadline ≤ now + 10 minutes;
  • slippage ≥ 99.5% of quoted.
• Rate limits:
  • Max 10 calls per day;
  • Total outflow ≤ 300,000 USDC per day.

Make sure to implement this with Zodiac Roles conditions, and don't forget to set up a daily allowance for gas tokens if that's necessary! You can find more details in the Zodiac Roles documentation.

---

Final word

Hierarchical multisig goes beyond just having “more signers.” It’s all about creating a policy-as-code that reflects your organization’s real hierarchy. This setup includes clear slow and fast paths, delegated caps, and gives you better visibility into the process.

Begin with the L0-L2 stack mentioned above, roll out one layer at a time, and think of modules and guards as actual production code changes, not just wallet settings.

Looking for a custom architecture or some hands-on help with EVM, Solana, Bitcoin, or Cosmos? Look no further! At 7Block Labs, we can whip up, test, and deploy your treasury controls in just weeks--not months.