7Block Labs
Blockchain Security

ByAUJay

hierarchical multisig: Patterns for Treasury Controls and Delegated Authority

Summary: Hierarchical multisig replaces flat “n-of-m” wallets with layered controls that map to real org charts: board-level vetoes, CFO time locks, ops allowances, session keys for bots, and emergency break‑glass. This guide gives concrete, chain‑specific designs and implementation recipes decision‑makers can ship this quarter.


TL;DR for decision‑makers

  • Start with a layered “L0–L2” model: L0 treasury (slow, high quorum, time locked), L1 operational wallets (medium quorum, daily limits), L2 delegates/agents (allowances, role scopes).
  • Use the native building blocks per chain: Safe modules (Roles, Delay, Spending Limits), Guards, and 4337 for EVM; Squads v4 roles/limits/timelocks on Solana; Miniscript + Taproot on Bitcoin; Cosmos x/group and x/authz for weighted/authorized execution. (docs.roles.gnosisguild.org)

Why hierarchical multisig now

Flat multisigs excel at eliminating single‑key risk but struggle with real‑world governance: different teams need different powers, urgent fixes need faster paths, and low‑risk spend shouldn’t block on full quorum. Modular “smart accounts,” timelocks, role‑based permissions, and parameter‑level scoping now make it practical to encode separation‑of‑duties on‑chain without sacrificing UX. On EVM, Safe modules and Guards add policy layers; account abstraction (ERC‑4337) brings session keys and sponsored gas; ERC‑1271/6492 make contract signatures verifiable on and pre‑deployment. (help.safe.global)


The building blocks by ecosystem

EVM (Ethereum, L2s)

  • Modules and Guards on Safe
    • Modules can add authority outside the base n‑of‑m (powerful but security‑critical). Guards enforce pre/post‑transaction checks on top of the quorum. (help.safe.global)
  • Roles Modifier (Zodiac)
    • Create roles that whitelist target contracts, function selectors, and parameter ranges; includes rate/threshold limits—fine‑grained least‑privilege for ops and bots. (docs.roles.gnosisguild.org)
  • Delay (Timelock)
    • Enforce cool‑downs between proposal and execution; combine with invalidation to skip malicious or broken txs. (zodiac.wiki)
  • Spending Limits (Allowance module)
    • Give any address time‑boxed ERC‑20 allowances (e.g., 5,000 USDC/day) that bypass the quorum for petty cash or bots. (help.safe.global)
  • Off‑chain governance execution (Reality/SafeSnap)
    • Bridge Snapshot or other votes to on‑chain execution via Reality.eth oracle with bonds and cooldowns. (docs.snapshot.box)
  • Account abstraction (ERC‑4337)
    • Enable Safe4337Module on Safe v1.4.1+ to support UserOperations, bundlers, and paymasters; keep ERC‑4337 opt‑in/out modularity. (docs.safe.global)
  • Contract signatures and counterfactual accounts
    • Rely on ERC‑1271 for smart‑account signatures; use ERC‑6492 to verify signatures for pre‑deployed (counterfactual) accounts. (eips.ethereum.org)
  • TimelockController (OpenZeppelin)
    • Governance‑grade timelock with proposer/executor roles; set timelock as owner of upgradable systems. (docs.openzeppelin.com)

Solana

  • Squads Protocol v4
    • Enterprise multisig with roles (proposer/approver/executor), spending limits, whitelists, timelocks, batch payments, and a Fee Relayer for gasless member UX. (squads.xyz)

Bitcoin

  • Miniscript + Taproot
    • Express hierarchical policies (thresholds, timelocks, recovery paths) in a composable, analyzable way; modern wallets and tooling support it. (bips.dev)
  • MuSig2 key aggregation
    • Aggregates cosigner keys into one Schnorr signature (privacy and fee efficiency); useful for “fast path” sign‑only branches. (developer.blockchaincommons.com)

Cosmos SDK chains

  • x/group
    • On‑chain groups with weights and decision policies (e.g., threshold); proposals execute messages from a group policy account. (docs.cosmos.network)
  • x/authz
    • Granular delegated authorizations (e.g., SendAuthorization with spend_limit and allow_list) for scoped, expiring, revocable powers. (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 unsafe opcodes or upgrade calls except via timelock. (zodiac.wiki)
  • L1 Operational Safes (per business unit)
    • Owners: 3–5 managers; Threshold: 2–3; Spending Limits for petty cash (daily/weekly), and Roles for permitted contracts/functions/params. (help.safe.global)
  • L2 Delegates/Agents
    • Give bots or contractors allowances (per token/timebox) issued from L1; rotate regularly; consider 4337 session keys for gas‑sponsored automations. (docs.safe.global)
  • Governance bridge
    • For community input, wire a Reality/SafeSnap module to a Snapshot space; set bond and a 24h cooldown. (docs.snapshot.box)

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

  • Fast lane: MuSig2 key path (e.g., CFO + Controller both sign, 2 rounds) for routine spends.
  • Slow lane: Miniscript Tapscript branch requiring thresh(2-of-3) plus CSV timelock (e.g., older(144)) for recovery or high‑risk moves. (bitgo.com)

Example Miniscript policy (readable policy format):

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 yields fee‑efficient “normal” spends while keeping a delayed, higher‑quorum safety branch.

Pattern C: Cosmos “Board + Ops + Delegates”

  • Create a x/group with weighted members; set a ThresholdDecisionPolicy on the group policy account for major actions.
  • Use x/authz SendAuthorization to grant Ops wallets spend limits and allow_listed recipients; set expirations and revoke on turnover. (docs.cosmos.network)

Pattern D: Solana “Program Ops Squad”

  • Squads v4 multisig with roles:
    • Proposers (engineers) can initiate upgrades/mints; Approvers (leads) sign; Executors run once threshold+timelock satisfied.
    • Set spending limits for routine vendor/validator ops; enable Fee Relayer so members don’t need SOL for approvals. (squads.xyz)

Concrete configurations by company stage

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

  • EVM
    • L0 Safe: 3/4 with 48h Delay for upgrades/token mints.
    • L1 Ops Safe: 2/3; Roles to call payroll/USDC transfer functions; Spending Limits of 10–25k USDC/week to finance lead wallet. (zodiac.wiki)
    • Add SafeSnap only after community governance is needed. (docs.snapshot.box)
  • Bitcoin
    • 2‑of‑3 Miniscript with an “after 90 days, 1‑of‑2 recovery” branch for founder succession. (bips.dev)

Growth/Enterprise (multiple BUs, compliance)

  • EVM
    • L0: 5/9 + 120h Delay; TimelockController owns upgradeable contracts; Governor or Reality‑based execution for policy changes. (docs.openzeppelin.com)
    • L1 per BU: 3/5 with Guards that restrict external calls; instrument Roles to parameter‑bound DEX trades and whitelisted custodians. (help.safe.global)
    • Agents: ERC‑4337 with paymaster sponsorship for bots; rotate session keys quarterly. (docs.safe.global)
  • Solana
    • Squads v4 with timelocks for program upgrades, spending limits for ops, batch payrolls, Members‑view privacy for internal squads; Fee Relayer for approver UX. (squads.xyz)
  • Cosmos
    • x/group for Board policy; x/authz for Finance and Ops with per‑message caps and allow_lists; set expirations tied to HR offboarding. (docs.cosmos.network)

Implementation recipes (EVM Safe)

  1. Install a Delay (timelock)
  • Deploy/attach Zodiac Delay and set a cooldown + optional expiry; remember transactions execute FIFO by queue nonce, and the Safe can skip with nonce advancement in emergencies. (github.com)
  1. Add Spending Limits
  • Enable Allowance module; set per‑token daily/weekly/monthly limits from the Safe UI. Great for finance/stipends/agent wallets. (help.safe.global)
  1. Scope operations with Roles
  • Use Roles Modifier to whitelist function selectors and bound parameters (e.g., approve(address spender, uint256 amount <= 50,000 USDC), only to whitelisted DEX routers). Roles supports rate/threshold limits to throttle usage. (docs.roles.gnosisguild.org)
  1. Harden with a Guard
  • Transaction Guard checks pre‑ and post‑execution; use it to block arbitrary delegatecalls, deny non‑whitelisted targets, or enforce per‑tx value caps. (help.safe.global)
  1. Add off‑chain vote execution if needed
  • Reality Module (SafeSnap): define minimum bond and a 24h cooldown; anyone can execute once the Snapshot proposal resolves “yes.” (docs.snapshot.box)
  1. Turn on account abstraction for agents and gas policy
  • Enable Safe4337Module on Safe v1.4.1+; integrate a bundler/paymaster via Safe4337Pack. Use ERC‑1271 for contract signature flows and ERC‑6492 for counterfactual signature verification. (docs.safe.global)

Implementation notes (Solana Squads v4)

  • Configure roles (proposer/approver/executor), thresholds, and timelocks per vault.
  • Set spending limits and whitelists for routine ops; enable Fee Relayer so members don’t need SOL for signing interactions.
  • Use batch payments for payroll; audit trails come from on‑chain program logs and Squads event history. (squads.xyz)

Implementation notes (Bitcoin)

  • Author a Miniscript policy with a “fast path” MuSig2 key aggregation and a “slow path” threshold+timelock script path.
  • Prefer descriptors that encode Miniscript; test spends on regtest/signet before mainnet. (bips.dev)

Implementation notes (Cosmos SDK)

  • Create a group policy with a threshold decision window; assign weights to board members.
  • Use x/authz to create SendAuthorization for Ops with spend_limit and allow_list, set expirations, and prune grants automatically via module queueing. (docs.cosmos.network)

Emerging best practices for 2025

  • Encode least‑privilege at the function and parameter level, not just “address allowlists.” Roles Modifier on Safe and Cosmos x/authz give you this granularity. (docs.roles.gnosisguild.org)
  • Always add a timelock to L0 powers (upgrades, mint/burn). On EVM, TimelockController or Zodiac Delay are standard; on Solana use Squads timelocks; on Bitcoin add a CSV timelock branch in Miniscript. (docs.openzeppelin.com)
  • Separate approvals from execution. Use Executors who only execute already‑approved ops; make executors permission‑less (anyone) where safe to reduce reliance on individuals. (docs.openzeppelin.com)
  • Treat modules as code changes. Safe modules and Guards alter authority; require review, staging, and sign‑off like upgrades. (help.safe.global)
  • Session keys and agents. For bots, prefer 4337 session keys or Safe Allowance over adding them as owners; rotate keys on a schedule. (docs.safe.global)
  • Monitor and automate. If you rely on Defender, note new sign‑ups closed June 30, 2025 and final shutdown is planned July 1, 2026; consider migrating to open‑source Relayer/Monitor or alternatives. (blog.openzeppelin.com)
  • Document recovery paths. Add delayed “break‑glass” branches (e.g., higher quorum + timelock), and test them with tabletop exercises. Miniscript and Guards make this explicit. (bips.dev)

Common pitfalls and how to avoid them

  • Bypassing the quorum unintentionally
    • Some modules can execute without owner signatures by design; ensure Guards and Roles strictly scope what modules can do. (help.safe.global)
  • Unbounded approvals
    • ERC‑20 approve() with unlimited allowances from treasury accounts is a recurring root cause of losses; cap via Roles parameter conditions and use pull‑based spend limits. (docs.roles.gnosisguild.org)
  • Timelock without self‑administration
    • If the admin can change proposers/executors instantly, the timelock is cosmetic; follow the recommended role setup and let the timelock administer itself. (docs.openzeppelin.com)
  • Ignoring pre‑deploy signature flows
    • For counterfactual accounts, integrate ERC‑6492 in off‑chain signatures (e.g., OTC, market makers) so orders remain verifiable pre‑deployment. (eips.ethereum.org)

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

  • Adopt ERC‑4337 on existing Safes via Safe4337Module (no need to redeploy accounts).
  • Where you want plugin‑style extensibility across accounts and vendors, track ERC‑6900 adoption for modular smart accounts (standardized validation/execution hooks and plugins like session keys and weighted WebAuthn multisig). (docs.safe.global)

Quick checklists

  • Technical
    • L0: Timelock attached, Guard installed, Reality/Snapshot optional.
    • L1: Roles + Spending Limits; signer rotation policy; per‑tx and per‑day caps.
    • L2: 4337 session keys or Allowance module for agents; expiry and logs. (zodiac.wiki)
  • Operational
    • Multi‑party HSM/hardware keys for human owners; require video/IRL ceremony for key issuance.
    • Quarterly drills for recovery branches (Bitcoin Miniscript, EVM Guard overrides). (bips.dev)
  • Monitoring
    • Alerts on module/guard changes, owner changes, threshold changes, and large outbound transfers; plan migration from Defender to OSS stacks by H1 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/day; total outflow ≤ 300,000 USDC/day.
    Implement with Zodiac Roles conditions and a daily Allowance for gas tokens if needed. (docs.roles.gnosisguild.org)

Final word

Hierarchical multisig isn’t just “more signers”; it’s policy‑as‑code that mirrors your org’s real authority structure, with explicit slow/fast paths, delegated caps, and observability. Start with the L0–L2 stack above, ship one layer at a time, and treat modules and guards as production code changes—not wallet settings.

If you want a tailored architecture or hands‑on implementation across EVM, Solana, Bitcoin, and Cosmos, 7Block Labs can design, test, and ship your treasury controls in weeks, not quarters.

Like what you're reading? Let's build together.

Get a free 30‑minute consultation with our engineering team.

Related Posts

7BlockLabs

Full-stack blockchain product studio: DeFi, dApps, audits, integrations.

7Block Labs is a trading name of JAYANTH TECHNOLOGIES LIMITED.

Registered in England and Wales (Company No. 16589283).

Registered Office address: Office 13536, 182-184 High Street North, East Ham, London, E6 2JA.

© 2025 7BlockLabs. All rights reserved.