Summary: So, you’re managing a DAO treasury with a Gnosis Safe, huh? Well, here’s something to keep in mind: each ExecutionFromModuleSuccess event intentionally skips the owner confirmations. Don’t worry, though--this guide is here to help you leverage Forta “findings” for that particular event. We’ll dive into using the oz-gnosis-events bot, Forta GraphQL, and SDK workflows to get you set up with alerts, troubleshoot issues, and even automate responses in mere seconds, whether you’re on L1 or L2 networks.

“DAO Treasury Multisig” Forta GetFindings: Using Forta DAO‑Multisig ExecutionFromModuleSuccess Alerts

Decision-makers definitely need to keep tabs on the modules in a Gnosis Safe. When you spot the ExecutionFromModuleSuccess signal, it indicates that a module has executed a transaction without hitting the usual threshold of owner approvals. Sometimes, that's perfectly fine--like with Zodiac Delay, Reality, Roles, and SafeSnap. But here’s where it gets tricky: this is also the moment when bad actors could take advantage if a malicious module slips in or if a legitimate one isn’t configured correctly.

Great news! Forta has the ability to transform those raw on-chain events into speedy, actionable alerts. You can easily send these alerts to platforms like Slack or PagerDuty, or even set up some automated responses to keep things running smoothly. If you're curious to learn more, take a look at the details here: (gnosisscan.io).

Here's a quick guide to get you started:

1. Get the right Forta bot subscription.
2. Dive into the “findings” using GraphQL and the SDK.
3. Filter for ExecutionFromModuleSuccess in real-time.
4. Link the responses to OpenZeppelin Defender or your SIEM.

You’ll find all the specific queries, code snippets, and operational runbooks you need right here. Don't forget to check out the details at (docs.forta.network).

---

Why ExecutionFromModuleSuccess belongs on your P0 watchlist

• What it means: A Safe module just did its thing by executing a transaction through execTransactionFromModule. The ModuleManager contract confirmed the success with ExecutionFromModuleSuccess(module). The best part? There’s no need for any multisig threshold here. (gnosisscan.io)
• Why it’s risky: So, here’s the scoop--modules can sometimes have more control than their actual owners. If a module turns out to be malicious or gets tampered with, it might easily shuffle assets or mess with the setup of the Safe. This kind of governance or treasury risk has been a hot topic since 2020. (blog.openzeppelin.com)
• What “good” looks like: You want your familiar modules--like Zodiac Delay, Reality, or Roles--performing their tasks as expected, hitting the right targets at the right moments and in the right amounts. If something seems off, it’s time to step in and address it. (github.com)

---

The Forta building blocks you’ll use

• Take a look at this awesome bot you should definitely subscribe to: OpenZeppelin-Gnosis Safe Contract Events (often called oz-gnosis-events). This handy little tool keeps you in the loop with updates about “ALL events” going down in the OpenZeppelin and Gnosis Safe repositories. It tracks everything from ExecutionFromModuleSuccess/Failure to EnabledModule, DisabledModule, and ExecutionSuccess. Oh, and it runs on mainnet as well as big Layer 2s like Polygon, Arbitrum, Optimism, and Avalanche. For more details, check it out here.
• So, how does Forta actually deliver the data to you? Well, it’s all thanks to decentralized scan nodes that run detection bots and send out alerts--these awesome bits of info are what we call “findings.” You can snag these findings using the Forta GraphQL API or SDK. If you're curious for more info, take a closer look at the details here.
• Access control is actually quite simple. You can easily generate an API key in the Forta App to check out alerts or even use them in your own bots. Plus, there are plenty of ways to filter your results! You can sort by bot IDs, alert names/IDs, chains, date/time, addresses, and scanner confirmations. For all the detailed info, check out this link.

---

Step 1 -- Identify the DAO multisig and its modules

Before Wiring Alerts, Inventory Your Safe(s):

Take a minute to browse through what you have tucked away in your safe(s):

• Safe address(es) and chain IDs: Think of it like this - chain IDs you’ll want are 1 for Ethereum, 137 for Polygon, 42161 for Arbitrum, and 10 for Optimism.
• Expected module allowlist: This is where it gets interesting! We'll include addresses for Zodiac modules like Delay, Reality, and Roles. Don't forget bridges and guards, plus the targets they can interact with.
• Required routing destinations: We're eyeing places like Slack/Discord, PagerDuty/Datadog, email, and webhooks.

This baseline helps you set up alert filters that will only go off when there’s something out of the ordinary compared to the policy. This could be things like an unknown module, a target you don’t recognize, an unusual amount or frequency, or if it's on the wrong blockchain.

Pro tip: Make sure to monitor the EnabledModule/DisabledModule events for your Safe. This way, you’ll stay in the loop whenever there are any tweaks to the module setup. And just a quick reminder, the oz‑gnosis‑events bot also sends out these events! You can check it out here: (docs.forta.network).

---

Step 2 -- Subscribe to the oz‑gnosis‑events bot in Forta

• Swing by the Forta App, search for the oz‑gnosis‑events bot, and smash that Subscribe button! You can customize your experience with address filters and choose your favorite channels--whether that’s Slack, Discord, Email, Telegram, or even Webhook. Just a quick note: you’ll need the right Forta plan to get started. (gate.com)
• Want to access things programmatically? You can either use GraphQL to make your queries or tap into the SDK's getAlerts method, like this example below. (docs.forta.network)

---

Step 3 -- Query “findings” (alerts) for ExecutionFromModuleSuccess via GraphQL

Forta’s GraphQL “alerts” query is your go-to API. You can easily filter your results with these parameters:

• bots: the ID(s) of the oz‑gnosis‑events bot
• alertName: ExecutionFromModuleSuccess
• optional: addresses (your Safe), chainId, scanNodeConfirmations, date/blocks

Operation:

query moduleExecAlerts($input: AlertsInput) {
  alerts(input: $input) {
    pageInfo {
      hasNextPage
      endCursor { alertId blockNumber }
    }
    alerts {
      createdAt
      name
      severity
      findingType
      metadata
      addresses
      chainId
      source {
        transactionHash
        block { number chainId timestamp }
        bot { id }
      }
      scanNodeCount
    }
  }
}

Example Variables for a Mainnet Safe

When you're getting your mainnet Safe up and running, here are a few example variables you might want to think about:

• Owner Address: This is the Ethereum address for the owner or the account that's in charge of the Safe.
• Threshold: This is basically the magic number that tells you how many owners need to give a thumbs up for a transaction to happen. So, if you’ve got 3 owners and only need 2 of them to approve, your threshold is set to 2.
• Guardians: Think of these as backup accounts that can swoop in and help you get back into your Safe if you ever misplace your keys. It’s a good idea to add a few friends you trust as guardians.
• Modules: These are extra features you can add to your Safe to boost its functionality. Think of things like setting transaction limits or controlling spending.
• Fallback Handler: Think of this as a safety net for your transactions. It’s a smart contract designed to handle any transactions that don’t go through the usual channels.
• Nonce: Think of this as a counter that monitors how many transactions have been sent from the Safe. It plays a crucial role in preventing double-spending.

This setup is a great way to make sure your mainnet Safe operates smoothly and securely. Make sure you take your time to think through these variables!

{
  "input": {
    "first": 50,
    "bots": ["<OZ_GNOSIS_EVENTS_BOT_ID>"],
    "alertName": "ExecutionFromModuleSuccess",
    "addresses": ["0xYourDaoSafe"],
    "chainId": 1,
    "scanNodeConfirmations": { "gte": 2, "lte": 10 },
    "blockSortDirection": "desc",
    "createdSince": 600000
  }
}

• The createdSince parameter is measured in milliseconds (for instance, 600000 means the last 10 minutes). The scanNodeConfirmations feature is useful for reducing false positives. And if you need to paginate, just use the endCursor when there's a hasNextPage. Dive deeper into it on the Forta API docs!

Reference: The AlertsInput for GraphQL is your go-to for managing bots. With it, you can set the alertName, provide alertIds, add addresses, pick a chainId, specify createdSince, define block ranges, and confirm those scanner checks. If you want to dive in, the endpoint is right here: https://api.forta.network/graphql (just don’t forget to include your Authorization: Bearer API_KEY). For all the details, check out the documentation.

---

Step 4 -- Pull the same data from application code (JS/TS SDK)

When you’re ready to jazz up your service alerts, just dive into the SDK and grab those alerts using getAlerts:

import { getAlerts, InitializeResponse } from "forta-agent";

// fetch latest module execs for a DAO safe on mainnet
const OZ_GNOSIS_EVENTS = "<OZ_GNOSIS_EVENTS_BOT_ID>";
const DAO_SAFE = "0xYourDaoSafe";

const res = await getAlerts({
  botIds: [OZ_GNOSIS_EVENTS],
  alertId: undefined,                 // use alertName filters post-query
  addresses: [DAO_SAFE],
  chainId: 1,
  createdSince: 10 * 60 * 1000,       // last 10 minutes
  first: 100,
  scanNodeConfirmations: { gte: 2 }   // reliability over speed
});

const moduleExecs = res.alerts.filter(a => a.name === "ExecutionFromModuleSuccess");

Notes:

• To get started with getAlerts, make sure you've got your Forta API key ready and set it up in your forta.config.json file or as an environment variable. The SDK is pretty cool and also comes with other useful functions like getLabels, sendAlerts, and a bunch of handy helpers. If you want to dive deeper, check out the complete details in the Forta documentation.

---

Step 5 -- Tie Alert → Action with Defender or your incident tooling

Two Proven Paths:

1. The Traditional Route
   This method revolves around classic techniques that have stood the test of time. You really get into the nitty-gritty of foundational skills, ensuring you have a solid grip on the basics. It's all about laying down a sturdy base that you can count on as you move forward in your journey.
2. The Modern Approach
   If you're after something a bit more current, this route is all about jumping on the latest trends and technologies. It focuses on adjusting to the ever-evolving landscape and using new tools to keep you ahead of the game. This approach lets you keep things lively while still hitting your targets!

• OpenZeppelin Defender has just rolled out a fantastic new integration with “Forta Sentinels.” Now, you can easily connect a monitor to specific Forta Bot ID(s) and even add some optional filters for Alert ID or Name. When there's a match, you can kick off Actions or Autotasks--like pausing, setting caps, revoking roles--and send out notifications too. Want to dive deeper? Check out the details here.
• Using Defender Monitor + Actions (or your SIEM), you can set up an HTTP webhook to catch the Forta alert payload and run it through your own policy rules. If the module or target isn’t on your allowlist, or if it hits specific thresholds, you can block actions downstream, notify a responder, or even trigger an emergency Safe transaction. For more details, check it out here.

---

What “good” filtering looks like (practical recipes)

Absolutely! Here’s a laid-back way to mix these predicates so you can reduce the noise while still picking up on the important stuff:

• Known-module allowlist: You’ll only get through this check if the module is one of these: {Delay, Reality, Roles, SafeSnap, …}. If it doesn’t match, you’ll need to escalate. Don’t forget to enforce those chain-specific module addresses. (github.com)
• Known-target allowlist: Make sure to maintain a list of the valid target contracts and function selectors for every module. If you stumble upon any unknown targets, that’s your cue to escalate the situation.
• Cadence guards: If a single module fires up more than N times within T minutes for one Safe, it’s time to raise a flag. This could point to either draining behavior or just some pesky spam.
• Value guards: Establish some value limits for specific actions. For example, you could set up alerts for ERC20 transfers that exceed a certain amount (let's say X), bridge transfers that go beyond Y, or even any high-value calls that happen.
• Change correlation: Keep an eye out for an EnabledModule appearing in the last N blocks. If you then spot an ExecutionFromModuleSuccess coming from that same module, it's time to escalate further. (docs.forta.network)
• Multi-signal combo: Team up the ExecutionFromModuleSuccess with detection systems for exploiter labels, Tornado funding, or the Attack Detector to boost the priority on your alerts. Check it out here: (docs.forta.network)

---

Example: Minimal “GetFindings” pipeline for a DAO Safe

1. Check out the newest insights from the final moments of ExecutionFromModuleSuccess for a Safe:

{
  "input": {
    "first": 25,
    "bots": ["<OZ_GNOSIS_EVENTS_BOT_ID>"],
    "alertName": "ExecutionFromModuleSuccess",
    "addresses": ["0xYourDaoSafe"],
    "chainId": 1,
    "createdSince": 60000,
    "scanNodeConfirmations": { "gte": 2, "lte": 10 }
  }
}

1. For each alert, you’ll want to decode the metadata to extract the following details:

• The module address (emitter), the target/to, the value, the function selector, and the logs.
• Don’t forget to double-check the module and target against your allowlists.

1. If you find an unfamiliar module or target, or if something seems off with the value or cadence:

• Shoot a message in the “security” channel on Slack.
• If the value exceeds the threshold, don’t hesitate to page the on-call team.
• Kick off a Defender Action to “pause” the protocol contract or temporarily disable the module using your Security Council Safe.

You can have all this up and running every 15 to 30 seconds without any problems, keeping the overhead nice and low, and hitting a mean time to detection (MTTD) of less than a minute. Give it a look here: (forta-network.github.io).

---

Under the hood: why Forta is reliable for this signal

• Think of decentralized scan nodes as your trusty watchdogs. They keep an eye on each block with their detection bots and send out alerts when something pops up. If you’re all about playing it safe, consider bumping the scanNodeConfirmations up to 2 or 3. Sure, you might experience a tiny slowdown, but it’s worth it for that extra peace of mind. It’s all about striking a balance between speed and reliability. (docs.forta.network)
• The oz‑gnosis‑events bot is a handy tool that keeps tabs on important happenings with Gnosis Safe. It lets you know when modules are activated or deactivated, and also tracks whether module executions are successful or hit a snag. On top of that, it monitors OpenZeppelin library events across key EVM chains. This means you can easily set it up on L2s where your DAOs manage their funds, giving you tons of flexibility! (docs.forta.network)

---

Robustness tips for production

• Rate limiting and pagination: When you're running queries, make sure to use first and after together with endCursor. And keep in mind that if you're dealing with big backfills, you might not get everything all at once! For more info, take a look here.
• Time vs. block windows: If you're after results that are almost real-time, you’ll want to use createdSince. On the other hand, if you’re looking into audits or doing some forensic checks, it’s best to go with blockDateRange or blockNumberRange. You can find more details here.
• Bot IDs: To keep your queries running without a hitch, you'll need to grab the Bot IDs. You can find the oz‑gnosis‑events Bot ID by heading over to its Stats page in the Forta App. For more info, check it out here.
• Auth: Don’t forget to include Authorization: Bearer for GraphQL. Keeping those keys secure is super important--think of them like treasures in a vault! Also, make sure you're rotating them regularly. You can check out more details on that here.
• SDK vs GraphQL: The SDK’s getAlerts function is basically a convenient wrapper around the GraphQL functionality. For most app development situations, it’s usually smarter to stick with the SDK. However, if you're just looking to whip up some quick analyses or dashboards, GraphQL is totally the way to go. Want more details? Check it out here.
• Scanner confirmations: As you go through alerts, try setting gte to 2 or 3. If you’re in a rush and need to automate some mitigations quickly, it’s fine to temporarily go with gte = 1. Just remember to circle back and confirm later. You can find more details here.

---

Emerging best practices we’re seeing across DAOs

• Separate “info” and “pager” channels: If you receive an ExecutionFromModuleSuccess with a recognized module and target, just drop that into the info channel. But if anything seems off, make sure to ping PagerDuty and include a link to the playbook.
• Defense in depth: Stay vigilant for ExecutionFromModuleFailure, as it could signal someone is poking around. Also, watch out for any shifts in EnabledModule/DisabledModule and any changes to owners on your Safe. Let’s compile all this into a convenient “DAO Multisig Posture” dashboard.
• Combine with Attack Detector feed: When you see a module execution that matches up with funding, prep, or exploitation signals (like a Tornado-funded account poking around in your contracts), don’t hesitate to increase the severity. You can dive deeper into this topic here: (docs.forta.network)
• Governance hygiene: When it comes to adding or removing modules, think of it like a constitutional amendment. That means you should have clear, scheduled votes and keep everyone in the loop about what's happening. Don’t forget to use Forta to verify on-chain that what you announced actually went down as planned.
• Post-mortem ready logs: Don’t forget to save those Forta alert payloads and decoded traces with your incident tickets. Having this info handy will really help you respond to incidents more quickly!

---

Worked example: Arbitrum DAO Safe, Roles module

Scenario:

You’ve got your Arbitrum Treasury Safe, which we’ll refer to as 0xYourDaoSafe. This thing has a cool Zodiac Roles module chilling over at 0xRolesMod. It’s all set to top off a bridged treasury contract and handle payments to auditors without a hitch.

• Expected behavior: We're on the hunt for ExecutionFromModuleSuccess where the module is 0xRolesMod, the target is either BridgeTreasury or AuditorPayout, and the function selectors are {deposit(uint256), transfer(address,uint256)}. Just a heads up, the amounts should be under 500k USD equivalent within a 24-hour period.
• Forta query: Let's set it up with chainId = 42161, alertName = "ExecutionFromModuleSuccess", addresses = [0xYourDaoSafe], and bots = [oz‑gnosis‑events].
• Escalate if:
  • the module isn’t on the allowlist, or
  • the target isn’t on the allowlist, or
  • the amount goes over 500k, or
  • there are more than 3 executions in a 10-minute span, or
  • the module was just enabled in the last 100 blocks and is now executing. (For further details, check out the docs.forta.network.)

---

Going beyond: consuming Forta alerts inside your own bots

You can set up a Forta “combiner” bot that connects to oz‑gnosis‑events and sends a single, clear alert known as “DAO-MULTISIG-MODULE-EXEC-ANOMALY” whenever your policy flags something as risky. Just stick to the v2 handleAlert pattern:

• When you get started, don’t forget to subscribe to oz-gnosis-events and filter for the alert IDs or names that really matter to you--think along the lines of ExecutionFromModuleSuccess, ExecutionFromModuleFailure, EnabledModule, and DisabledModule.
• In your handleAlert function, it's time to put your policy logic to work. If you catch a violation, make sure to create a high-severity Finding that includes all the detailed metadata. This way, the folks who respond down the line will have all the accurate info they need. (docs.forta.network)

---

Bonus: pull the broader context around a firing

When ExecutionFromModuleSuccess triggers, don’t forget to grab the last 50-200 blocks for these:

• Additional Safe events such as EnabledModule, DisabledModule, and ExecutionSuccess
• Labels associated with the interacting addresses (like exploiter, sanctioned, newly deployed) using Forta labels
• Insights from the Attack Detector linked to the same group of addresses

You can tap into everything with just one Forta API/SDK. By consolidating them in your incident timeline, you’ll not only enhance your analysts' confidence but also speed up the Mean Time to Resolution (MTTR). For more info, take a look here: (docs.forta.network)

---

Checklist: make “module exec” alerts production-grade in one sprint

• Forta
  • First things first, make sure you snag your API key and confirm that you've got GraphQL access in the Sandbox. All the details you need are right here.
  • After that, go ahead and grab the Bot ID for oz‑gnosis‑events. Give the sample query linked above a spin with a dry run. You can check it out here.
  • For scanner confirmations, kick things off with gte=2 for paging. You can find more about that here.
• Policy
  • It's time to get your module and target allowlists sorted out for each Safe/chain.
  • Don’t forget to set your thresholds--this means figuring out the amounts and how frequently triggers should happen, along with your escalation paths.
• Integrations
  • Want to stay in the loop? You can easily connect Slack or Discord to get notifications and set up PagerDuty or Datadog to alert you on pages. For a step-by-step guide on how to do this, just click here.
  • If you're looking to level up even more, think about adding Defender Actions to automatically pause or queue mitigations. You can find all the details here.
• QA
  • Go ahead and run a few simulations of benign module executions to confirm there aren’t any surprises popping up.
  • Additionally, run a simulation for a policy breach (you can use an unknown target) to check that your escalation process is operating smoothly.
• Operate
  • Try to make it a weekly routine to check in on your module and target allowlists, plus take a look at your thresholds.
  • Oh, and don’t skip out on scheduling a quarterly practice session! Plan a game day to go over emergency module disablement with the Security Council Safe.

---

Appendix -- Known gotchas

• Naming vs IDs: With Forta, you can filter alerts using either alertName or alertIds. If you're working with oz‑gnosis‑events, the simplest option is to use alertName=ExecutionFromModuleSuccess. But if your team prefers using alertIds, go ahead and include that as well. You can find more details here.
• Chain forks/reorgs: If you get stressed out by gte=1 scanner confirmations, just a heads-up--there’s a slight chance you’ll see some disruptive alerts when reorgs happen. It’s always smart to take a moment and double-check scanNodeCount before jumping into any actions.
• Private alerts: Certain bots have the ability to send private alerts that you can access through the API by just using the bot ID. Although this doesn't really pertain to oz‑gnosis‑events specifically, it’s worth remembering if you're working on bigger projects down the line. You can find more details here.

---

Closing thought

For DAO treasuries, modules play a super important role. The ExecutionFromModuleSuccess event lets you know exactly when that power is being utilized--no matter if it’s a smart move or not. Forta is here to provide you with the fastest and most dependable alerts across various chains. By keeping a tight allowlist, verifying with scanners, and setting up an automated response plan, you can really cut down your Mean Time to Detection (MTTD) to just minutes (or even faster) and your Mean Time to Recovery (MTTR) could be as simple as a single action in Safe.

---

References and further reading

• Take a look at Forta’s GraphQL and AlertsInput! This feature gives you access to bots, alert names and IDs, addresses, creation dates, and confirmations. You can explore all the nitty-gritty details here.
• Curious about some example GraphQL queries? You can check out queries for recent alerts, pagination, and confirmations right here.
• If you want to get the lowdown on the Forta SDK’s getAlerts function and those bot consumption patterns, just head over to this link.
• There’s this bot called oz‑gnosis‑events that keeps an eye on ALL OpenZeppelin and Gnosis Safe events, like EnabledModule, DisabledModule, ExecutionFromModuleSuccess, and Failure. You can get all the specifics here.
• Interested in Gnosis Safe ModuleManager events such as ExecutionFromModuleSuccess and Failure? You can check those out on GnosisScan.
• Ever wondered why module power is such a hot topic? It's super important for preventing backdooring of the Safe during setup. Get the complete details on the blog.
• Integrating Forta alerts with OpenZeppelin Defender is a smart way to keep your notifications and actions all in one place. Find out how to get it set up in this forum post.
• Lastly, if you're trying to wrap your head around how Forta operates--think scan nodes, bots, alerts, and subscriptions--you can read all about it here.

7Block Labs has got you covered from A to Z. We're talking about everything you need: subscriptions, queries, filters, incident routing, and automated responses. Plus, it works seamlessly with your main DAO Safe and any sub-treasury Safes on L2s.