Summary: Decentralized proposals are super important, but they only work if you can carry them out safely. In this guide, we’ll show you how to automate proposal execution from beginning to end using Safe Modules, Zodiac’s Reality-based executors, and on-chain Guards along with Module Guards. We’ll also share some handy configurations, point out potential pitfalls, and lay out some audit-ready controls that you can put in place today.

decentralized proposals: Automating Execution with Safe Modules and Onchain Guards

For many DAOs and enterprise treasuries, that last leg can seem like the toughest challenge: turning an approved proposal into an on-chain transaction--without hanging around for someone to wake up and sign off or stressing over a misconfigured module that could wipe out your funds. In this post, we're going to explore how you can set up a proposal execution process that’s not only automated but also super secure by merging:

• Execution Modules (like Zodiac Reality or “SafeSnap”) make it easy to turn those off-chain votes into actual on-chain transactions.
• Onchain Guards and Module Guards are in place to manage what actions can be taken and when they can happen.
• Modifiers, including Roles and Delay/Timelock, help maintain a least-privilege approach and give everyone the necessary time to react.

Let's jump right into the latest updates from the Safe releases and the Zodiac tooling ecosystem. We're bringing you some great parameters that you can smoothly implement in your production environment.

---

The building blocks you’ll use (and what’s changed recently)

• Safe Modules: Think of these as handy plug-in contracts that can trigger transactions from your Safe without needing those owner signatures, all thanks to execTransactionFromModule. It’s perfect for automation! Just keep in mind to use them wisely and only after they’ve been audited--these can execute any calls, including delegatecall. You can dive into the details here.
• Safe Guards: Think of these as contracts that run checks before and after routine Safe transactions (you know, the ones that require owner signatures). Just a quick note: classic Guards won’t work for transactions kicked off by modules. Check out more details here.
• Module Guards (the fresh faces): With the launch of Safe v1.5.0, there’s now a specific guard hook for transactions kicked off by modules. This means you can apply your policies to those automated routes as well. If you haven't upgraded your Safe yet, now’s the perfect time to consider it! Check out more details here.
• Other v1.5.0 updates worth noting: We've got a cool new extensible fallback handler that really enhances composability. Plus, the EIP‑1271 signature validation has seen some updates, and revert propagation is getting an upgrade too--this is super useful when you're trying to track down why a proposal didn't make it. Check out the full details here.
• Safe Shield: This is a great example of protection backed by guards and solid policies within the Safe product family. It's a useful concept to remember, even if you're thinking about building your own guard. Check out Safe Shield here.

Key takeaway for decision-makers: Picture your automation surface as a set of modules, while your risk brakes act as guards along with module guards. With the launch of Safe v1.5.0, you can now apply brakes to both execution paths.

---

Pattern 1: Off‑chain voting, trustless onchain execution (Snapshot + Zodiac Reality)

Zodiac’s Reality Module, which powers the SafeSnap plugin, is a pretty cool tool that lets you whip up a bunch of transactions off-chain. You can vote on them in Snapshot, and once the Reality.eth oracle gives the thumbs up that the proposal is a go and matches the payload, you can execute them straight from your Safe. The cherry on top? Anyone can just hit “execute” as soon as everything’s set--no waiting around for a signer! (zodiac.wiki)

What Actually Happens Onchain

When we mention "onchain," we're really getting into the nitty-gritty of blockchain tech and all the action that happens under the hood. Let's unpack this a bit!

Transactions

At the core of everything, we have transactions. Whenever someone sends or receives cryptocurrency, that action gets logged on the blockchain. Here’s the usual process:

1. Creation: It all starts when someone kicks off a transaction by creating a digital signature with their private key.
2. Broadcasting: Next up, this transaction is sent out to the network, where other nodes (basically computers) pick it up.
3. Verification: Those nodes then get to work verifying the transaction, making sure it’s legit and that the sender has enough funds.
4. Adding to the Block: Once everything checks out, the transaction gets grouped with others and added to a block.
5. Mining: Miners (or validators) jump into the mix, racing to solve tricky puzzles to get that block onto the blockchain.
6. Confirmation: After the block is added, the transaction is officially confirmed. The more blocks that get added after it, the more secure it becomes.

Smart Contracts

Onchain goes beyond just transactions. Smart contracts play a huge role in this space too. Think of them as self-executing agreements where the terms are laid out right in the code. Here’s how it works:

• Deployment: Developers put together smart contracts and roll them out on the blockchain.
• Execution: Once the conditions are right, the contract kicks in and automatically carries out what was agreed upon.
• Transparency: Because these contracts are all about that blockchain life, anyone can check out the contract's code and actions, making everything super transparent.

DApps & Tokens

Decentralized applications (DApps) and tokens really shine when they operate on-chain. These DApps rely on smart contracts to run smoothly without needing a middleman. This setup lets users engage with the apps while keeping control over their own data.

Tokens, however, are all about representing assets or utilities. You can create them using well-known standards like ERC-20 or ERC-721 on Ethereum, which opens the door to a thriving ecosystem of projects.

Security & Immutability

One of the really awesome aspects of onchain activities is the security it offers. Once something is logged on the blockchain, it’s not easily changed or messed with. The fact that it’s decentralized, along with robust cryptographic methods, makes it super hard for anyone with bad intentions to fiddle with the data. So, what does this mean? Here’s a breakdown:

• Decentralization: Since there's no single entity in charge of the network, it reduces the chances of manipulation happening.
• Consensus Mechanisms: Various blockchains use different methods, like Proof of Work or Proof of Stake, to confirm transactions. This makes it pretty tough for anyone to mess with the information.

Conclusion

Let’s dive into what really goes down onchain! It’s a blend of transactions, smart contracts, and decentralized apps, all held together by the amazing power of blockchain tech. Every move is all about keeping things transparent, secure, and trustworthy--without relying on any intermediaries. If you’re interested in digging deeper, take a look at this detailed article that explains how blockchain actually works!

• Alright, let’s talk about what a proposal looks like:
  • First off, you have a proposalId (think of it kind of like an IPFS hash) and
  • a bunch of EIP‑712 typed transaction hashes (txHashes). Each of these hashes has its own special encoding that includes value, data, operation, and a nonce which reflects its position in the list. (github.com)
• Next, the module will create a question on Reality.eth using that proposalId and those txHashes. Once Reality gives the thumbs up, and after a cooldown period wraps up, the module runs execTransactionFromModule on the Safe to go ahead and execute the queued actions in the right order. (github.com)
• Here are some cool safety features you can tweak within the module:
  • a minimum bond (to keep the low-effort responses at bay),
  • an arbitrator (like Kleros),
  • a timeout (the time frame for locking in an answer),
  • a cooldown (a little grace period between finalizing the answer and executing it),
  • and optional answer expiration to prevent those pesky stuck executions from running forever. (github.com)

Reality.eth runs as an optimistic oracle, which means that to get answers, you need to put down a bond. If someone decides to challenge an answer, they have to double that bond. And if things get really intense, disputes can be taken to an arbitrator like Kleros. This whole setup strikes a good balance for DAOs, combining fast responses with a way to sort things out. (docs.kleros.io)

Operator-Level Checklist to Configure SafeSnap Effectively

Alright, if you're jumping into the SafeSnap experience, I've got a handy checklist to help you get everything set up perfectly. Let's make sure things go off without a hitch!

Pre-Configuration Steps

1. Get to Know Your Environment:
   • Take a breather and check out your infrastructure. Are you rolling with a cloud service, or do you have everything hosted on-site?
   • Jot down any unique needs or restrictions that come with your setup.
2. Gather Required Information:
   • Make sure you have the access credentials for the systems you'll be using. Here's what you'll need:
     • Your SafeSnap account info.
     • Any API keys, if required.
3. Review Documentation:
   • Before diving in, it’s a smart move to take a look at the SafeSnap documentation. Get to know the main features and functionalities so you're not flying blind!

Configuration Steps

1. Install SafeSnap:
   • Check out the installation guide in the documentation. If you’re working in a particular environment, just double-check that you’re using the right version!
2. Set Up Access Permissions:
   • Ensure that the appropriate permissions are in place for the users accessing SafeSnap. This is essential for both security and a smooth user experience.
3. Set Up Snapshots:
   • Decide how often you want to create snapshots and what kind you need. Consider how frequently you need backups--will daily work, or is weekly good enough? Maybe you want to snap a pic after any major changes?
4. Customize Notifications:
   • Tweak your notification settings so you get alerts for the stuff that really matters. That way, you’ll stay in the loop and won’t miss any important happenings with your snapshots.
5. Test Your Configuration:
   • Go ahead and run some test snapshots to make sure everything's working smoothly. It's always a good idea to catch any problems early on!

Post-Configuration

1. Check Out Your Snapshot Logs:
   • Make sure to glance at your logs regularly to track when snapshots are made and to catch any errors or warnings that might pop up.
2. Regular Updates:
   • Make sure to keep an eye on the latest SafeSnap releases and patches. By regularly updating, you’ll boost both functionality and security.
3. Backup Strategy:
   • Think about weaving SafeSnap into your overall backup plans. It's important that it aligns with your disaster recovery strategy too.

Troubleshooting

• No worries if you run into any problems! Just hop on over to the SafeSnap support forum for some handy solutions, or feel free to ask for a little help.

With this checklist in hand, you’ll be all set to configure SafeSnap like a champ. Best of luck, and enjoy snapping away!

• Timeout: You can choose anywhere from 24 to 72 hours, based on how engaged the community is. If you go with a shorter timeout, things can move along quicker, but longer timeouts give you a bit more breathing room to tackle any issues that come up. (realityeth.github.io)
• Cooldown: Having a cooldown period of 24-48 hours is a smart move. It gives signers a little time to step in if any questionable or incorrect answers slip through before everything gets finalized. (docs.kleros.io)
• Minimum bond: Establish a minimum bond that's substantial enough to deter any potential griefing in your token units. Luckily, Reality has you covered by supporting both native and ERC-20 tokens. Don’t hesitate to use your governance token if that’s what's in play in your Snapshot space. (realityeth.github.io)
• Arbitrator: For any questions that might stir up some debate, consider using Kleros. Just a heads-up: it's a good idea to look into on-chain coverage and costs ahead of time so you’re not caught off guard. (docs.kleros.io)
• Answer expiration: Make sure to turn on and run markProposalWithExpiredAnswerAsInvalid during your cleanup process. This little step can help you avoid any surprises with late executions. (github.com)

Governance UX Notes

Overview

This document takes a closer look at the UX (User Experience) side of governance. Our goal here is to help teams get a better grip on their user engagement strategies and find ways to enhance them.

Key Concepts

1. User-Centered Design
   Kick things off by thinking about the user. Get their feedback, look at how they behave, and tweak your design based on what really resonates with them.
2. Accessibility
   It’s super important to ensure that everyone can navigate your platforms with ease. Keep in mind the various abilities and tools your users might require.
3. Transparency
   It's super important to keep users in the loop throughout the entire process. When they know what's going on, they feel more engaged and appreciated.

Best Practices

• Conduct Regular User Research
  Take the time to really connect with your users. Whether it’s through interviews, surveys, or usability tests, these interactions can uncover valuable insights about what they need and the challenges they face.
• Set Up Feedback Loops
  Create spaces for users to share their opinions and experiences. Make it a habit to check this feedback regularly so you can continuously improve what you offer.
• Create a Clear Structure
  Make sure the info is easy to digest. Use headings, bullet points, and visuals to help break everything down nicely.

Tools to Consider

• User Testing Platforms
  Consider using platforms like UsabilityHub or Maze to get a better feel for how users engage with your designs. They can really help you understand that interaction!
• Analytics Tools
  Check out tools like Google Analytics to keep an eye on how users are interacting with your platform. The insights you gather can really help you make meaningful improvements.

Sample User Journey Map

Conclusion

Integrating solid UX principles into governance can seriously boost user satisfaction. Keep refining your approach and always prioritize your users!

• In your Snapshot proposal, you'll find a “Transactions” section that details batched multisend payloads. Once the voting wraps up, we kick off the “Request Execution” to start the oracle process. After that’s settled and the cooldown period is done, anyone can just hit “Execute.” (zodiac.wiki)

---

Pattern 2: Add guardrails--Guards vs Module Guards (and how to combine them)

Without any limits, a module can basically do anything within your Safe--including a delegatecall. While that’s super powerful, it also comes with some risks. So, it’s a good idea to keep these controls in mind:

• Guard (classic): This is your go-to for keeping things secure by letting only owner-signed Safe transactions pass. You can set up some handy checks like “block delegatecall” or “block transfers to non-allowlisted receivers.” If you want to dive deeper, you can find more info here: docs.safe.global.
• Module Guard: This feature is all about overseeing transactions that come from modules. It ensures that any Reality-driven executions only mess with the contracts and functions you trust, keeps those amount limits in check, and can even stop delegatecall if that's your jam. You can configure it by using setModuleGuard(address). For all the detailed info, check out docs.safe.global.

Minimum Viable Policy Pack We See Working in Practice

The Power of Minimalism in Policy Crafting

When you're working on effective policies, sometimes keeping it simple is the best approach. Let’s dive into the minimum viable policy pack that's really making a difference in real-life situations.

Key Elements of the Minimum Viable Policy Pack

To make it all straightforward and effective, zero in on these key policies:

1. Code of Conduct
   This is all about shaping your team's culture. It should clearly lay out what kind of behavior is expected, while promoting respect and inclusivity in the workplace.
2. Remote Work Policy
   Since a lot of us are working from home these days, it's really important to have a solid remote work policy in place. This should outline what’s expected when it comes to communication, availability, and keeping up with productivity.
3. Leave Policy
   Having a clear leave policy makes it easier for everyone to know what their rights are about vacations, sick days, and other types of time off.
4. Data Protection Policy
   With data breaches making news all the time, having a solid policy in place for protecting sensitive information is more important than ever.
5. Feedback and Grievance Policy
   It’s super important for employees to feel like their voices matter. By having a straightforward way to share feedback and raise concerns, we can help foster a more positive workplace vibe.

Why This Pack Works

This simplified take on policies makes sure that the essentials are not just included but are also super easy to grasp. Check out a few reasons why this minimum viable policy pack really works:

• Clarity: It’s super clear what everyone’s supposed to do.
• Flexibility: This makes it easy to adjust as the organization expands, without making things too complicated.
• Engagement: Employees can dive into their work instead of spending time figuring out tricky policies.

Implementation Tips

When you're getting ready to roll out your minimum viable policy pack, here are some handy tips to consider:

• Involve Your Team: Don't forget to gather feedback from your employees when you're putting together these policies. Their perspectives can really make a difference.
• Communicate, Communicate, Communicate: It’s super important to ensure everyone knows about the policies and really gets what they mean. Maybe think about having a Q&A session to clear up any confusion!
• Review Regularly: Policies aren’t set in stone. Make it a habit to revisit them now and then to see if they’re still effective or if they could use some adjustments.

By keeping your policies simple but effective, you can create a positive and productive workplace vibe. It’s not about drowning your team in rules; it’s all about setting up a framework that helps everyone thrive.

• NoDelegateCall: This feature will throw an error if the operation tries to use DELEGATECALL. It's a handy way to minimize the risk of storage-clobbering attacks and makes sure any potential damage is kept under control. If you want more details, you can check it out here.
• Allowlist selector scope: Ensure that any calls made by the module are limited to certain target addresses and function selectors that align with your treasury policy. For example, focus on ERC-20 transfers or approvals for trusted platforms. Pairing this with transaction value limits is definitely a smart move.
• Emergency blocklist: This is like a kill-switch for any sketchy spots you want to keep tabs on.
• Log and monitor: Make sure to document the specifics behind any reverts and stay on top of event indexing for smoother tracking.

Why It Matters in 2025

As we gear up for 2025, there's a ton of change happening all around us, and it's super important to understand why these shifts matter. Here’s a quick rundown of some of the key reasons:

1. Technological Advancements
   By 2025, we’re gearing up for some serious tech breakthroughs. Innovations in artificial intelligence, quantum computing, and renewable energy are poised to change the game in various industries and our everyday lives. Keeping an eye on these trends isn’t just a fun hobby; it’s crucial for your personal and professional development.
2. Climate Change Impact
   The impacts of climate change are getting harder to ignore, and by 2025, we’re really going to feel it--no kidding. It's super important to grasp how shifts in the environment can influence everything from farming to property values.
3. Global Economy
   As our world grows more connected, changes in the global economy can send waves that reach us all. Staying tuned into emerging markets and economic trends can really help you spot potential opportunities or challenges that might be coming your way.
4. Societal Changes
   Social movements and shifts in demographics are totally changing how we connect and conduct business. By 2025, you can bet the cultural scene will have evolved, and staying on top of these changes can really boost your communication and collaboration skills.
5. Healthcare Innovations
   Thanks to some pretty cool advances in healthcare tech and telehealth, getting medical care is becoming a whole lot easier. By 2025, these innovations are set to shake up our approach to health problems and might just lead to better outcomes for all of us.

In wrapping this up, the trends and shifts we expect for 2025 aren't just trendy phrases; they’re crucial for our future. Whether it’s about staying on top of your skills, grasping global shifts, or getting ready for whatever comes next, the stuff that’s important now will only become even more significant as we move toward 2025.

• With the launch of v1.5.0, you can now set policies for both owner-signed and module-initiated flows. If you were only using a Guard before, think about adding a Module Guard to cover any possible policy gaps in those automation paths. For more info, take a look here.

---

Pattern 3: Compose modifiers for least‑privilege and reaction time

Zodiac Modifiers are super useful drop-in controls that you can quickly slot between your modules and your Safe. They make it easy to set up rate limits, assign roles, or add delays without any hassle.

• Roles Modifier: This is a really handy role-based permission system that gives you super precise control over your calls. You can define targets, selectors, and parameter constraints, all while smoothly integrating with an SDK and a subgraph to keep everything on the up and up. In simple terms, it ensures that only a specific executor (like your proposals module) can access the functions you’ve approved. Take a look here: (zodiac.wiki).
• Delay Modifier: This handy tool lets you queue up module transactions and establish a cooldown or expiry time. When the window opens, anyone can jump in and execute the next eligible transaction. It’s perfect for giving your team a moment to pause and refine policies before any funds start changing hands. Want to dive deeper? Check it out here: (github.com).
• SaferSafes (Optimism): This setup is pretty solid! It features a liveness module that steps in if the signers are missing in action, plus a timelock guard for those scheduled executions. If you’re dabbling with OP chains using Safe 1.4.1, this pattern is one you should definitely check out. It’s great for making sure important rules are followed, like keeping the livenessResponsePeriod at least double the timelockDelay. Want to learn more? Check it out here: (github.com).
• Governor Module: If you're into on-chain voting (shoutout to OpenZeppelin Governor) rather than Snapshot+Reality, you can totally run Governor as a Safe module and keep that same level of security. It's a clever way to keep everything locked down. Want to dive deeper? Check it out here: (github.com).

---

Reference architecture: Automated proposal execution with layered controls

1. Governance Surface

• Take a look at the off-chain voting setup with the SafeSnap plugin. You can dive into more details here.

2) Execution Engine

• Here’s how the Zodiac Reality Module is configured:
  • Arbitrator: Kleros
  • Timeout: 48 hours
  • Cooldown: 24 hours
  • Minimum Bond: Governance token value is about $5k
  • Answer Expiration: 7 days
  • Executor: Your Safe

These settings are here to help you tackle spam, give you a little breathing room to react, and steer clear of stale executions. You can dive into the details on GitHub!

3) Policy Layer

• Module Guard that:
  • stops delegatecall from happening
  • only lets ERC‑20 transfers go to specific counterparties and stablecoins
  • sets limits on how much can be spent per transaction and the total amount for the module each day
• Classic Guard that mirrors important restrictions for owner-signed transactions (think of it as a safety net). Take a look at it here!

4) Optional Modifiers

• Roles Modifier: You’ll find this modifier right at the front of the module. It adds some extra layers of security for target, function, and parameter scoping, going beyond just the usual guard checks. Consider it a nifty little boost for your defense-in-depth strategy!
• Delay Modifier: This one’s got a 24-hour cooldown attached, which means it helps keep things organized by serializing execution. Plus, it gives you that last-chance opportunity to cancel if you need to. Want to learn more? Check it out here: (zodiac.wiki).

5) Monitoring and Response

• Stay on top of these events and respond when necessary:
  • Watch for reality questions being created, answered, or finalized--this means keeping tabs on bond escalations and kicking off arbitration if needed.
  • Keep an eye out for ExecutionFromModuleSuccess or ExecutionFromModuleFailure. If something goes wrong, investigate what's happening; you might have to upgrade your guard.
  • Don't forget to monitor ChangedGuard or ChangedModuleGuard to see if modules are being enabled or disabled, helping you catch any configuration drifts.
• Make sure you check out the Zodiac Roles subgraph alongside your SIEM to keep tabs on policy changes over time. You can dive into more details in the docs.safe.global.

---

Implementation details you’ll want in your runbooks

• Enable/disable modules safely: When you want to enable a module, just use enableModule();. If you need to disable one, keep in mind that you’ll need the previous module pointer from the linked list along with the module address. Don’t forget to jot this down; it’ll make it easier for your team to get rid of any compromised modules quickly. You can find more info here.
• Module execution paths: Whenever modules use execTransactionFromModule or execTransactionFromModuleReturnData, be sure to log both successful and failed events. And remember to capture return data too--it’ll make your life a lot easier when you’re debugging later on. If you want to dive deeper, check out more details here.
• Setting guards:
  • To set up owner-signed transaction policies, go ahead and use setGuard(address).
  • For module policies, you’ll want to use setModuleGuard(address). Just a heads up, both of these require Safe transactions. It's smart to have some break-glass procedures ready, just in case a guard causes any issues down the line. You can find all the details here.
• Safe versioning: If you want to use Module Guards and the extensible fallback handler, make sure you're on version ≥1.5.0. And remember to keep an eye on the Safe singleton address for each network--double-check it in Settings before you dive into any updates. You can find more info here.
• Reality Module Details to Dodge Edge Cases:
  • Make sure you're keeping an eye on the nonce/index rule: every transaction’s nonce needs to line up with its index in txHashes. This way, you keep things unique, even if the to/value/data are the same.
  • Don't forget to use markProposalInvalid and stay on top of answer expiration to steer clear of those pesky “zombie” proposals that might execute long after their time. You can check out more about it here.
• Arbitration economics: Keep a record of who your arbitrator is, the fee schedule, and who’s allowed to cover those arbitration fees for the DAO. Also, just a little tip: if you face any challenges, remember that you’ll need to double the previous bond, so make sure you plan your treasury approvals accordingly. For more info, check it out here.

---

Example: A sane configuration for a USDC‑denominated treasury

Context

A growth DAO has decided to approve some spending from a Safe on the Ethereum mainnet. They’re aiming for a seamless one-click execution right after the voting ends, but they want to make sure they adhere to a solid spending policy.

• Safe: Out of 7 owners, 4 are using Safe v1.5.0.
• Modules:
  • Reality Module: Here’s the scoop: the arbitrator is Kleros, with a timeout of 48 hours, a cooldown period of 24 hours, a minimum bond of $5,000 (in USDC equivalent), and answers will expire in 7 days.
• Modifiers:
  • Roles Modifier: The “proposal_executor” role is solely for the Reality module. Here’s what you can do:
    • USDC.transfer and USDC.approve are cool for approved counterparties,
    • You can also do a multisend from the Safe Appstore multisend address,
    • And just a heads up: no DEX approvals can go over 1% of the treasury within any 24-hour window.
  • Delay Modifier: The cooldown is set to 24 hours, and stuff expires after 7 days.
• Guards:
  • Guard: No delegate calls are allowed. Plus, it blocks any unknown ERC-20 approvals and limits owner-signed transfers to $50,000 or less, unless the proposal is tagged as “emergency.”
  • Module Guard: Same drill for transactions initiated by modules; it will also reject any call with operation == DELEGATECALL. (docs.safe.global)
• Monitoring:
  • You’ll receive alerts for things like new Reality question creations, bond increases over $10k, arbitration requests, any issues with ExecutionFromModule, changes in guards or module guards, and turning modules on or off. (docs.safe.global)

Result: Once a proposal gets the thumbs up, anyone can jump in and make it happen, but there’s a bit of a twist - it has to stay within certain permissions. Don’t forget about the time cushion we’ve got to work with, and there are checks in place that apply to both people and automated systems alike.

---

Common failure modes (and how to avoid them)

• “We added a module, and it slipped past our guard.” So, make sure you’re rolling with Safe v1.5.0 and get that Module Guard set up. Just having guards isn’t enough to keep those module transactions in check! For all the details, take a look here.
• "So, we've got a sneaky module that drained our funds using delegatecall." To fix this, make sure to block delegatecall in both the Guard and Module Guard. Oh, and remember to audit every module carefully since they can make arbitrary calls. You can find more info here.
• "A proposal sat around for months before it got executed." To avoid this in the future, get into the habit of enabling answer expiration and marking any proposals that have expired as invalid in your regular workflow. Check out the guidelines on GitHub.
• “We ran into a little hiccup--nobody could make transactions because our guard bricked the Safe.” You can think of guards as similar to production firewalls. It's a good idea to roll them out in stages on a test Safe and keep a limited blast radius, like a time-boxed timelock. Plus, make sure you have a break-glass plan ready to disable setGuard/setModuleGuard whenever there's an emergency with the owner set. For more info, you can check it out here.
• “We had to make things happen with Optimism while managing timelocks.” To do this, use the SaferSafes timelock guard (which works with Safe 1.4.1) and ensure your livenessResponsePeriod is at least twice the timelockDelay. You can check out the release notes on GitHub.

---

Emerging best practices we recommend in 2025

• Always enforce your policy across both transaction planes. Pair up a Guard with a Module Guard to keep things secure. After any Safe upgrade, make sure to double-check that both of them are operational. You can find all the details here.
• Separate roles to keep things organized. Create a specific “executor” role for proposal execution that’s scoped to target/selector/params. This way, all modules, like Reality and Governor, will have to go through this role. Check it out here.
• Consider using a timelock or some delay to serialize actions. Even a simple 24-hour delay can really help minimize tail risk. This gives you time to roll out an emergency patch or disable a module before any funds change hands. More info can be found here.
• Keep your eyes on everything. Index Safe events, like ExecutionFromModuleSuccess/Failure and Changed(Guard|ModuleGuard). Dashboards are great for quickly spotting any configuration drift. You can learn more here.
• If you’re rolling out new systems, go for the v1.5.0 Safe deployments. They come with expandable fallback handlers and improved EIP‑1271 support, which helps you dodge common issues and makes integrations way smoother. Check it out here.
• For wider participation, mix Snapshot with Reality, and for high-assurance on-chain voting, use Governor. You can secure both the same way using module guards and modifiers--just choose based on what fits your needs for latency and user experience. More details can be found here.

---

Implementation crib notes (copy/paste to your internal wiki)

• Enable Reality:
  • First things first, go ahead and deploy or attach the Zodiac Reality Module to your Safe.
  • Then, jump into Snapshot and add the SafeSnap (Reality) plugin. Make sure you set the module address, timeout, cooldown, arbitrator, and min bond. For more info, check out the details here.
• Add policy:
  • Now it’s time to submit a Safe transaction to set your guard using setGuard(guardAddress). Don't forget to also set up the module guard with setModuleGuard(moduleGuardAddress).
  • Before you dive in, it’s super helpful to try this on a staging Safe that mirrors your actual owners and threshold. Consider running a quick drill to disable a guard and remove a module. If you need some extra tips, check this out: docs.safe.global.
• Tighten permissions:
  • Make sure to set up your Zodiac Roles before diving into your modules. Start by creating a “proposal_executor” role that includes the target, selector, and param scopes. The Roles SDK and app make this a breeze to manage. If you want to dig deeper, check it out here.
• Add a delay:
  • How about we throw in a Zodiac Delay that includes a cooldown and an optional expiration date? Just make sure to require executeNextTx for everything to stay alive and kicking. If you need more details, check this out: here.
• Validate:
  • Make sure to check your Safe version in the Settings. If you're rocking version ≥1.5.0, you’ll have access to module guard support.
  • Try running a dry-run of a proposal with a small on-chain transfer, like 1 USDC, to test everything out and ensure your monitoring setup is working smoothly. You can check out the release notes here.

---

What to monitor in production

• Reality flows: Picture this as a step-by-step journey. You kick things off with a question, then progress to answering bonds, and eventually finish with finalization, arbitration requests, and cooldown expiry. We refer to this whole process as your “proposal control plane.” For a deeper dive, you can check it out here.
• Safe security posture: You've got awesome tools like ChangedGuard and ChangedModuleGuard to keep tabs on module enable/disable actions, owner changes, and threshold tweaks. If you spot any unexpected changes, make sure to treat them as a top priority (P1). You can get all the details here.
• Execution health: Watch for any spikes in ExecutionFromModuleSuccess or Failure. These often suggest there might be a guard mismatch or a selector/param that isn’t on the allowlist. You can find more details here.

---

Closing: Make your proposals self‑executing--safely

Automation doesn’t have to feel like you’re giving up control. Thanks to Safe v1.5.0’s Module Guards, Zodiac’s Reality executor, and flexible tools like Roles and Delay, you can totally achieve that “approve once, execute trustlessly” feel while keeping a solid grip on the specifics. You’ll have detailed, audit-ready oversight on what gets moved, when it happens, and who it’s going to. So, if you’re diving into a DAO treasury or gearing up an enterprise crypto operations setup, this toolkit is definitely the way to go right now.

If you need an architecture review, some guidance on writing guard policies, or you're ready to jump into an implementation sprint, 7Block Labs has your back. We're here to help you confidently roll out this pattern.

---

References and Further Reading

Check out these awesome resources if you want to explore the topic even further:

• Book Title 1 by Author Name: Seriously, if you're into this subject, you can't miss this one!
• Article Title 2: This piece really digs into some interesting points and brings fresh perspectives to the table.
• Website Name: You've got to check out this awesome site--it's loaded with great info and resources.
• Research Paper Title: For those of you craving a deep dive into analysis and findings, this one's a gem!

Additional Resources

• Podcasts: If you’re more into listening, dive into some fantastic podcasts that tackle this topic head-on.
• Videos: YouTube's packed with great videos that make complex concepts easy to understand.

Check out these resources to dive deeper into the topic!

• Safe Modules: Take a look at execTransactionFromModule--it’s a handy tool for managing whether module APIs and behaviors are on or off. For more details, you can explore here.
• Safe Guards vs Module Guards: We're diving into setGuard and setModuleGuard, plus we'll touch on the key Safe concepts and highlight the latest updates in the v1.5.0 release notes. Check it all out here.
• Tutorial: Interested in creating a no-delegatecall Guard? You're in the right place! We’ve put together a super helpful guide just for you. Dive in here.
• Safe Shield: Curious about Safe Shield and how it helps you manage guard-style policies? Everything you need to know is laid out for you here.
• Zodiac Reality Module: Looking for the docs and README for the Reality Module? You’ll find all the details on proposal IDs, transaction hashes, bonds, cooldowns, and expirations right here.
• Snapshot SafeSnap (Reality) plugin: Let’s dive into what the SafeSnap (Reality) plugin is all about. For all the nitty-gritty details, take a look here.
• Reality.eth: If you're interested in diving into the docs and understanding how Kleros arbitration operates, you can find all the details here.
• Zodiac Roles Modifier: Dive into the details of the RBAC and Delay Modifiers, where you can get the lowdown on queueing and cooldown features. Check it out here!
• SaferSafes (OP): This one blends a liveness module with a timelock guard, laying out its invariants. Check it out on GitHub.