DAO Treasury Multisig, DAO Treasury Governance, and DAO Treasuries: Design Patterns That Work

Description: Here’s your ultimate playbook for launching DAO treasuries in 2026! Inside, you’ll find everything you need, like easy multisig setups, smart combos of onchain and offchain governance, hassle-free streaming payouts, cross-chain management strategies, risk management tips, and incident playbooks. Plus, we’ve got detailed setup advice inspired by the pros at ENS, Arbitrum, Yearn, Aave, Safe, OpenZeppelin, and Zodiac.

TL;DR for decision‑makers

• Take a look at the winning setup for 2026: it’s all about a modular Safe-based treasury! This features a high-threshold “Root” Safe, complemented by some lower-threshold program Safes that are monitored by Guards and Roles. We’ve also got a handy timelock/delay feature and the choice for optimistic execution via Reality.eth for Snapshot voters. This entire framework is already being utilized by leading DAOs and comes with clear, verifiable parameters that you can start using right now. (docs.safe.global)
• Starting in 2025, we’ve watched some awesome new features roll out--check out EIP‑7702 delegated EOAs, ERC‑6900 modular accounts, and even more robust OpenZeppelin Governor extensions. These tools empower you to create policies directly at the account level, moving beyond just social processes. You can design your treasury to include enforceable limits, revocable roles, and challenge windows. (ercs.eips.fyi)

---

1) What changed recently (and why it matters to treasuries)

• Safe is currently managing more than $100 billion in assets spread across millions of smart accounts, and it keeps its operational metrics fresh and up-to-date. This is super important since almost every DAO treasury pattern we’ll cover below depends on Safe contracts and Zodiac modules. Take a look here: (safe.global).
• The governor frameworks have definitely stepped up their game: OpenZeppelin Contracts v5.x introduced enhanced quorum and time abstractions (ERC‑6372), plus late-quorum fixes and timelock integrations. This means you have everything you need for robust on-chain governance while keeping delays and roles nice and predictable. Want to learn more? Check it out here: (docs.openzeppelin.com).
• EIP‑7702, which came into effect on May 7, 2025, introduced some cool features like native, temporary, and persistent delegation for EOAs. For treasuries, this basically means that signers can have their personal wallets managed by policy modules during specific tasks, like staged deployments, without needing to make the full leap to smart accounts. However, there's a trade-off--you'll be increasing your attack surface, so it's a good idea to think about adding revocation and monitoring procedures to your runbooks. If you're curious for more details, check it out here: (7blocklabs.com).

---

2) A multisig topology that actually scales

Use a three-tier Safe architecture with explicit thresholds and code-enforced limits:

Setting up a three-tier Safe architecture is a solid move to make sure everything operates smoothly and securely. Here’s a straightforward guide to help you get it right:

1. Define Explicit Thresholds:
   First things first, get those thresholds nailed down for your app. It’s super important to know exactly what limits to put in place for various actions or data. Whether you’re dealing with user access levels or resource usage, being clear about these boundaries can save you from any unexpected surprises later on.
2. Implement Code-Enforced Limits:
   Just keeping thresholds in your head isn’t going to cut it; they really should be integrated directly into your code. By setting these limits within your code itself, you ensure that your application sticks to the rules every single time. This approach not only boosts security but also enhances reliability.
3. Regularly Review and Update:
   Remember, it’s not a “set it and forget it” situation! Get into the routine of checking your thresholds and enforced limits regularly. As your application develops and changes, you’ll want to tweak those settings to keep everything running smoothly.

By following these steps, you can build a solid Safe architecture that ensures everything runs smoothly and securely!

• Root Treasury Safe (RTS)
  • Threshold: It operates on a 5/9, 7/11, or 9/12 basis, depending on assets under management (AUM) and velocity.
  • Modules: Features a Delay/Timelock module that can be set for 24-96 hours, a Zodiac Roles Modifier ahead of all modules, and monitoring hooks for added oversight.
  • Duties: This safe is responsible for looking after core asset custody, owning protocol contracts and the TimelockController, managing the minting and burning process, and overseeing signer and role management. You can dive deeper here.
• Program/Working Group Safes (PWS)
  • Threshold: 3 out of 5 or 4 out of 7.
  • Guard: You'll use Safe Guard with defined spend or target limits. Plus, you can throw in optional rate limits using Roles “allowances.”
  • Duties: This takes care of your regular operations like grants, events, and bounties, all while sticking to those set limits and whitelisted targets. To dive deeper, check it out here.
• Payments/Payroll Safe (PPS)
  • Threshold: 2/3 or 3/5.
  • Payout rail: It works with Superfluid streams featuring Auto-Wrap and Stream Scheduler to keep payments flowing smoothly and automatically manage starting and stopping them.
  • Duties: Takes care of contributor salaries, vendor payments, and streaming grants. Want to know more? Check it out here.

Why This Works

High-value authority usually sticks around at the RTS, which can lead to some pretty lengthy delays. Meanwhile, execution agility thrives out at the edge (think PWS/PPS), but it runs into some limitations due to code (like Guards and Roles). If a module or a signer runs into trouble, those constraints and delays can actually help you manage your losses.

Check out this handy config you can quickly grab and use:

• Delay: Kick things off with a 48-hour window. After you've got your incident response process nailed down, feel free to stretch that to 72-96 hours.
• Roles conditions:
  • Token transfers: Make sure you have a clear token list, and remember to reset the per-role allowance every day. Steer clear of using approve() with unlimited allowances, and don't even think about allowing delegatecall.
  • DeFi: Stick to approving only the whitelisted routers and vaults. Keep an eye on function selectors and the ranges of parameters, like slippage bps.
  • Module chaining: Make sure that all modules (like Reality and Governor) go through the Roles Modifier. You can check it out here: (docs.roles.gnosisguild.org)

---

3) Optimistic execution that’s actually safe (Snapshot + Reality.eth + Safe)

Pattern: So here's how it works: Token holders vote off-chain using Snapshot. If the proposal passes, Reality.eth takes over to make sure the batch transactions match what was proposed. After a brief cooldown, anyone can swoop in and execute that batch on your Safe using the Zodiac Reality Module, also known as SafeSnap. (github.com)

Implementation specifics:

• Bond token: When you're using your governance token, just a heads up--the minimum bond requirement is likely to increase during tense times.
• Cooldown: You’ll have at least 24 hours to make a move, but if a proposal could shake up more than 1% of the treasury, brace yourself for a full 72-hour wait.
• Arbitrator: Kick things off with a centralized method (think of Reality Keys); when your organization feels ready, you can switch things over to Kleros or set up a Security Council to handle it.
• Monitoring: Stay alert for events like “ProposalQuestionCreated,” “ChangedGuard/ChangedModule,” and execution happenings. All the juicy details are waiting for you in the docs.snapshot.box.

Why Optimistic?

Optimistic layers are a game changer when it comes to tackling those annoying signer bottlenecks. They do this while still maintaining a challenge window and a straightforward way to handle arbitration. They’re already being put to good use in various DAOs and play nicely with Safe Guards and Roles. Take a look at it on GitHub!

---

4) Onchain governance when you need it (and how to wire it)

If you're handling upgradeable protocol contracts or overseeing large grant programs, it’s smart to set up a full on-chain Governor and a Timelock.

• Contracts: Make sure to use OpenZeppelin's Governor, GovernorPreventLateQuorum, and TimelockController.
• Common parameters that many DAOs tend to stick with include: a votingDelay of about 1-2 days, a votingPeriod that usually lasts around 5-7 days, a timelock of roughly 2 days, quorum set between 2-5% of the total supply, and a proposal threshold that aligns with the delegate landscape.
• Execution: Just a friendly reminder, the Timelock--rather than the Governor--should be the one managing the protocol contracts and any funds. You can take a closer look here.

Want to link your multisig setup today with the Governor solution you’re eyeing for tomorrow? Check out the Zodiac Governor Module! It allows you to roll out on-chain voting step by step without messing with your treasuries. Get all the juicy details right here: (zodiac.wiki)

---

5) Cross‑chain treasury control that won’t bite you later

If you're managing governance on a budget-friendly chain but still want to keep your assets on the mainnet, the Zodiac Bridge Module is a great choice, especially when paired with an Arbitrary Message Bridge. You can handle Governor/Reality tasks on Layer 2 and then carry out transactions on the mainnet via a bridged control path linked to your Safe avatar. Just remember to establish this pathway with the right Roles and set a Delay on your mainnet Safe. Check out the details here: (zodiac.wiki).

---

6) Streaming payments that don’t break payroll

Superfluid’s money streaming really shines when it comes to DAOs. Here are a couple of automation features you can kick off right from the get-go:

• Auto-Wrap: This cool feature automatically wraps your USDCx/DAIx directly from your USDC/DAI treasury, so you can say goodbye to the hassle of manual wrapping.
• Stream Scheduler: It takes care of starting and stopping your streams on set dates (like when you’re doing payroll or hitting grant deadlines), helping to reduce those pesky human errors. You can learn more about it here: (docs.superfluid.org)

Production Gotcha (Example)

We ran into a bit of a snag between August and September 2025 when an Auto-Wrap failure threw a wrench in the ENS DAO streams. This meant we had to sort out backpay for everyone involved. To avoid this kind of mess in the future, it’s crucial to whip up runbooks for stream liquidation and reactivation. Plus, having a stablecoin buffer on the PPS is definitely a smart move. If you want to dive deeper into the details, check it out here.

---

7) Case studies with real numbers you can benchmark

• The ENS DAO's working groups are on top of managing a bunch of Safes, each with their own clear H1/H2 budgets and sub-multisigs set aside for hackathons, bounties, and newsletters. Here’s a quick rundown of the numbers:
  • For H1 2024, the Ecosystem WG has snagged a budget of $994k, which breaks down to $275k for Bug Bounty and $100k earmarked for audits.
  • As we head into H2 2024, that number dips to $758k; no worries though, all balances are up for public viewing on dashboards, and they’ve successfully wrapped up the Immunefi migration with a sweet $250k top-up.
  • Looking ahead to H1 2025, the budget is projected at $832k; they keep things transparent by sharing balances across main, hackathon, IRL, and newsletter Safes, including ETH counts and USD conversions.
    These budget lines and multi-wallet setups are pretty robust and could easily be templated. (discuss.ens.domains)
• Yearn's main ops multisig, ychad.eth, is organized as a 6-of-9 setup. It has a solid signer rotation plan and a straightforward compensation policy laid out in YIP-79 and YIP-84. This approach is really smart since it keeps the signer keys up-to-date and in sync. You can check it out here: (gov.yearn.fi).
• Lido has set up some pretty neat committees along with a dual-governance model, giving stakers the ability to veto or slow down decisions. On top of that, they’ve introduced explicit timelock states, which is definitely something to keep in mind for any big changes that might affect non-token holders. (outposts.io)
• Over at the Arbitrum DAO:
  • They've got a Security Council made up of 12 members, and they follow a 9-of-12 voting system for any emergency actions. This setup includes documented elections, rotations, and clear procedures for changing key members.
  • As part of their Treasury diversification STEP 2.0, they've decided to put 35M ARB (which was about $11.6M when they made the call) into tokenized T-bills, teaming up with Franklin Templeton, Spiko, and WisdomTree. This comes after STEP 1 brought in roughly $700k in yield from over $30M.
    It really shows how they're taking a solid, governance-backed approach to move away from relying too much on native tokens and towards earning some uncorrelated yield. (docs.arbitrum.foundation)

---

8) Policy engines: enforce rules before and after signing

You’re looking to create two layers:

• On-chain policy (within the account): Safe Guards + Zodiac Roles Modifier
  • Block any calls from sources that aren’t on the whitelist, limit the selectors and parameters you can use, cap spending with rate-limited allowances, deny those delegate calls, and make sure all modules have to follow a controlled path.
  • Use ERC-7484 registries to only add trusted modules. Check it out here: (docs.safe.global)
• Off-chain policy (at the signing layer): institutional MPC custody (Fireblocks, Coinbase Prime, BitGo)
  • You can set up individual roles for users, define consensus thresholds, and enforce limits on transaction speed and amounts. Plus, you can create address allowlists and run compliance checks before a key signs anything.
  • These platforms are equipped with auditable rule engines and HSM/TEE protections to keep everything secure. For any governance actions, don’t forget to require extra consensus--think of it as a separate “governance voting consensus” from trading. (developers.fireblocks.com)

Design note: Many DAOs tend to keep their treasury assets in self-custodial Safes. On top of that, they often utilize MPC policy engines to manage certain operations, mainly around accounting, compliance, and access control on an enterprise scale. That’s all fine and dandy, as long as the on-chain Guards/Roles are still set up to restrict which actions can be taken.

---

9) Monitoring and incident response (2026 reality)

• Defender Sunset: OpenZeppelin's hosted Defender is sticking around until July 1, 2026, so it's a good idea to start planning your moves to the open-source Relayer/Monitor. Make sure your current alerts and incident playbooks continue to run smoothly while you make the switch. (blog.openzeppelin.com)
• What to Keep an Eye on with Your Treasury Fleet:
  • Safe Config Drift: Make sure to check for any changes in guards or modules, and keep tabs on updates to thresholds and ownership.
  • Governor Events: Stay in the loop about the proposal lifecycle, including the timelock queue and execution, plus any role grants or revokes.
  • Streaming Health: Keep track of token balances against your run-rate, along with Auto-Wrap events and scheduler triggers.
  • Security Council Activity: Stay alert for any emergency function calls or bridge control messages.

To boost your peace of mind, consider integrating with Forta or a similar tool. It’s a good idea to set up high-severity alerts for those emergency situations that might require pausing operations, causing delays, or disabling modules. Check it out here: (openzeppelin.com)

Runbook Snippets for Pre-Approval (Store as Signed but Not Executed Transactions)

When we’re dealing with transactions that need pre-approval, it’s super important to keep them organized. Here are some handy snippets to help you store these as signed transactions without executing them just yet:

Signing the Transaction

First, we need to sign the transaction. Here's a quick snippet to do just that:

signed_tx = sign_transaction(transaction)

Storing the Transaction

Once we have our signed transaction, it's time to save it for later execution. Use the following snippet to store it securely:

store_transaction(signed_tx, status='pending')

Retrieving Pending Transactions

When you’re ready to check on pending transactions, this little piece of code will come in handy:

pending_transactions = get_transactions(status='pending')

Executing Approved Transactions

Once a transaction gets the green light, here’s how you can execute it:

if is_approved(transaction_id):
    execute_transaction(transaction_id)

Cancellation of Pending Transactions

If something changes and you need to cancel a pending transaction, here’s how:

cancel_transaction(transaction_id)

Summary

These snippets should help you easily manage pre-approved transactions. Keep everything organized, and you’ll have smooth sailing ahead!

Feel free to customize these snippets based on your specific needs!

• Disable the faulty module (Reality/Governor/Bridge).
• Activate a backup Guard.
• Extend the Delay from 48 hours to 96 hours.
• Update signer keys and revoke any compromised EOA delegations (if you're on EIP-7702). (docs.safe.global)

---

10) Budget execution patterns that avoid governance gridlock

• Token-holder controlled caps, committee-controlled execution:
  • Token holders have a say in what the budget looks like each year or every quarter, which means they can set limits and guidelines. There’s a Treasury Committee that uses a multisig to manage the spending within those boundaries, all backed by some pretty solid code-enforced rules (think Roles/Guards).
  • A few cool examples of this in action are the ENS working groups (they have multi-wallet budgets and are all about transparency), Lido’s committee model, and Aave’s “SwapSteward,” which makes it easier to handle governance proposals. Check it out here: (discuss.ens.domains).
• Streaming disbursements with automated stop conditions:
  • If you're dealing with grants or stipends, you can stream stablecoins that come with defined cliffs and end dates. On top of that, you can configure Streams to automatically pause if a performance oracle sends out an alert or if a Safe Guard’s budget runs out. (docs.superfluid.org)

---

11) Diversification and yield--what’s defensible in 2026

• It’s smart to stash away around 18-24 months’ worth of your operational expenses in a mix of stablecoins from at least two different issuers--like USDC and DAI. If the governance team is on board, you might also think about tossing in some tokenized T-bill products. To find the best providers, consider using STEP-like RFPs. (theblock.co)
• If you’re looking to tackle protocol risks, take a look at Aave’s Umbrella redesign. They’ve made slashing automatic, mixed up their staked assets, and cut down the cost per dollar of coverage. DAOs could definitely take a page from their book with the idea of an “automated, asset-aligned backstop” for their own risk buffers. (aave.org)

---

12) Practical checklists you can ship this quarter

Signer Hygiene and Thresholds

• Don't forget to use hardware wallets for all the signers. It’s wise to think about a rotation schedule--maybe every 6 to 12 months--and implement a compensation policy like Yearn’s.
• When it comes to thresholds, shoot for at least 60% for RTS and 50% for PWS. Also, let's make sure we're mixing it up with some geographic and organizational diversity. You can find more info here.

Safe configuration

• First up, grab the Roles Modifier and get it set up so that you can:
  • Specify the tokens/targets you want to allow, set up allowances based on roles that refresh daily, turn off delegatecall, cap the maximum transaction value for each role, and create frequency limits.
• After that, make sure to install Guard on every Safe. Start off by testing a “deny by default” approach, then only unlock access to what’s truly necessary.
• And don’t forget to add the Delay module to your RTS and to any PWS that can handle over 0.5% of the treasury. You can find all the nitty-gritty details here.

Governance Wiring

• Onchain: Set up a Governor along with a Timelock using PreventLateQuorum. Just remember to assign the proposer and executor roles correctly. The ownership should be managed by the Timelock.
• Offchain: Use Snapshot with the Reality Module. Make sure to implement bond escalations and set a cooldown period of 24 to 72 hours. Also, choose an arbitrator and define the fee structure. (docs.openzeppelin.com)

Streams and Operations

• Switch your PPS to Superfluid and turn on Auto-Wrap and the Scheduler. It's a good idea to keep a buffer of 2-4 weeks’ worth of stablecoins to avoid any stream liquidation surprises. And hey, remember to check those backpay calculations too! (docs.superfluid.org)

Monitoring and IR

• Stay tuned for any updates on Safe configurations, shifts in proposal states, streaming balances, and any moves from the Security Council. It’s smart to pre-stage emergency transactions and go through a few practice scenarios just in case.
• Get a head start on the Defender migration! You’ll want to ensure your alerts are safe during the transition in 2025-2026. Check out this helpful article: (blog.openzeppelin.com)

---

13) Brief deep dive: Security Councils the right way

When Your Protocol Can Brick Itself (L2s, Bridges)

To handle the risks of your protocol possibly bricking itself--especially when it comes to Layer 2 solutions and bridges--think about setting up a Security Council. This council should have clearly defined powers to navigate these tricky situations smoothly. Here’s a quick rundown of what that could entail:

• Limited Authority: The council should really focus on emergency situations and crisis management to keep things in check and avoid stepping out of bounds.
• Quick Response: They need to be ready to jump into action when problems pop up, so we can keep any potential damage to a minimum.
• Transparency and Accountability: Keeping the community in the loop with regular updates and clear communication is key to building and maintaining trust.
• Community Input: It's important to open the floor for community feedback, so decisions align with what the wider user base actually wants.

Setting up a Security Council with these guidelines can really help create a safety net for your protocol, making it easier to tackle any potential failures down the line.

• Take a look at the Arbitrum Security Council--it's a group of 12 members, and they have to get a 9-out-of-12 majority to take any emergency actions. Their powers are pretty clearly defined for both Layer 1 and governed Layer 2s. They also rotate their keys and keep their election and compliance processes transparent. Oh, and your Governor has the authority to adjust or even replace the Council with a constitutional vote. You can dive into all the details here.
• Over on the Optimism side, their Council aims for a high bar and has a charter that keeps them laser-focused on rolling out upgrades that have the green light from governance. They've set up a cool “oracle of governance” model to steer clear of any mission creep. You can check it out here: (gov.optimism.io).

---

14) Don’t ignore EIP‑7702 in your risk model

If any signer wallets are leaning towards 7702-style delegation--which is actually pretty common in wallets by 2026--here are a few things to keep in mind:

• Stay vigilant about any changes in delegation across all chains.
• Create a revocation playbook that outlines how to reset EOAs to null code in case of any suspicious, phishing-style delegations.
• Set up a guideline that prohibits signer EOAs from delegating during high-risk periods, such as when proposals are being executed or when signers are being rotated.

This isn't just some theory anymore; research uncovered actual patterns of exploitation in the real world back in late 2025. Take a look at it here: (arxiv.org)

---

15) Putting it together: a reference wiring diagram

• Root Treasury Safe (9/12)
  • Modules: Roles (deny-by-default), Delay 72h
  • Holds: long-term assets; this is where the TimelockController is kept
• TimelockController (2 days)
  • Proposer: Governor
  • Executor: open (0x0) or can be handled by the Governor for those time-sensitive tasks
• Governor (onchain) or Reality Module (offchain)
  • Either of these will go through Roles to trigger actions on the RTS or a specific PWS.
• Program Safes (3/5, role‑scoped)
  • Includes Guard and Allowances, plus you have the option for a 24-hour Delay if you want.
• Payroll Safe (2/3)
  • This feature handles Superfluid streams and comes packed with Auto-Wrap and a Scheduler. Plus, it has a Guard that lets you set daily limits!

This is totally composable, can be tested out on its own, and we've seen it work really well in a bunch of DAOs we've mentioned earlier. Give it a look here: (docs.openzeppelin.com)

---

Appendix: concrete examples to copy/paste into your RFP or charter

• Guard Policy Skeleton (human‑readable)
  • ERC20 Transfers: We’re cool with tokens like [USDC, DAI, LUSD]. You can send up to $50k per transaction, and the daily limit is $250k. Just make sure your recipients are listed on allowlist v1.2.
  • Approvals: The max amount is set to 0; you can only use increaseAllowance to bring it down to 0 when you want to revoke permissions.
  • DeFi: Just stick to calling the exact function selectors on the whitelisted routers. Keep slippage to ≤50 bps, set the value to 0, and remember, no delegate calls are allowed.
  • Module Enforcement: Every module execution needs to use the Roles exec method. The module list is locked to the approved ERC‑7484 registry. You can check it out here: (docs.roles.gnosisguild.org)
• Snapshot + Reality Parameters
  • So, here’s the deal: we've got a timeout window that runs from 24 to 72 hours. The minimum bond is set anywhere from 5,000 to 25,000 governance tokens. At the start, Reality Keys will act as our arbitrator, and we've got a clear escalation path laid out. The process for marking proposals as invalid is managed by RTS through Roles. If you want to dive deeper, check this out: (github.com)
• Governor Parameters (OpenZeppelin)
  • Voting Delay: 1 day; Voting Period: 7 days; Quorum: 4%. We’ve also got the PreventLateQuorum module ready to roll. The Timelock is set for 2 days, and we're sticking to the rules for proposer/executor roles as outlined in the docs. If you want to dive deeper, check out the details here: (docs.openzeppelin.com)

---

At 7Block Labs, we’ve got your back every step of the way. Whether you need safe deployments, Zodiac Roles/Guards, or help with setting up Governor/Timelock systems, we’re on it. We’ll also integrate Snapshot/Reality for you, and handle Superfluid streaming.

Plus, we’ll align your MPC policies and keep an eye on everything to ensure your Defender migration plans are rock solid. You’ll get complete incident runbooks and configs that you can easily audit.

Looking for a custom configuration pack? Just give us a shout! We’ll start with the reference above and fine-tune the thresholds, modules, and budgets to match your unique risk and regulatory requirements.

Sources and Further Reading:

• Take a look at the safe metrics and documentation, as well as the Zodiac modules such as Reality, Bridge, and Roles. Don't forget to explore Safe Guards and Delay too! (safe.global)
• Check out OpenZeppelin's Governor, Timelock, and PreventLateQuorum. And hey, make sure you’re aware of the Defender sunset timeline! You can find all the details right here: (docs.openzeppelin.com)
• Check out the scoop on ENS working-group budgets and balances, along with the details on Yearn multisig rotations and their compensation. (discuss.ens.domains)
• Check out the Arbitrum Security Council charter to learn more about STEP 2.0 RWA allocations and the yield results. You can find all the details here: (docs.arbitrum.foundation)
• Dive into Superfluid’s Auto-Wrap and Stream Scheduler, plus check out a case study on reactivating ENS streams. You can find all the details here: docs.superfluid.org
• Check out EIP‑7702 and the new risks it highlights, along with those ERC‑6900 modular accounts and ERC‑7484 registries. You can find more info here: (7blocklabs.com).
• Take a look at the institutional policy engines such as Fireblocks, Coinbase Prime, and BitGo to handle your off-chain approvals and compliance requirements. You can find more info here.

If you need a thorough red-team review of your treasury wiring setup, 7Block Labs has got your back! We’ll create a gap report that points out the exact transactions you should pre-stage--think things like disabling modules, rotating keys, and ramping up delays. On top of that, we'll also hook you up with a signer rotation calendar and a policy matrix for your Guards, Roles, and MPC engines.