title: "Monitoring Gnosis Safe Events with the 'DAO Treasury Multisig' Forta" slug: "dao-treasury-multisig-forta-gnosis-and-dao-treasury-multisig-forta-monitoring-gnosis-safe-events" description: "## Quick Summary"

“DAO Treasury Multisig” Forta Gnosis and “DAO Treasury Multisig” Forta: Monitoring Gnosis Safe Events

Quick Summary

Here’s a handy, step-by-step guide to help you keep tabs on your DAO treasury multisigs by linking Forta alerts to Gnosis Safe (now called Safe) events. We’ll go through the key Safe events you should keep an eye on, show you how to subscribe or set up a Forta bot, and walk you through sending alerts to Slack or using Webhooks. Plus, we’ll dive into how to up your monitoring game with the Safe v1.5.0 Module Guards and Safe Shield to effectively block any sketchy transactions. For all the details, check it out here.

Why this matters now (January 2026)

Safe v1.5.0 just dropped, and it's packed with some really cool security features! We're talking about Module Guards, an updated EIP‑1271 validation, and a super flexible fallback handler. This update makes it a breeze to enforce global policies, even if transactions are starting from modules. If your DAO has recently upgraded from v1.3 or v1.4, or if you're in the process of setting up new Safes, you’ll definitely want to tweak your monitoring and prevention strategies. Check it out here: (github.com).
Forta has really upped its game as a reliable detection layer, now featuring over 1,000 scan nodes spread across seven major EVM chains. With more than 600 active bots buzzing around to send alerts, teams can easily get updates via email, Slack, Telegram, Discord, or even custom webhooks. The General Plan gives you access to the API and notifications, plus there are tons of “starter kit” bots that come ready to handle Safe events right off the bat! Want to dive deeper? Check it out here: (forta.org).
Safe Shield is here, offering some serious enterprise-level protection thanks to Hypernative, plus valuable transaction insights from Blockaid and Tenderly. It helps spot potential risks before any signers give their approval, which is a nice boost to Forta’s alerts after blocks are created. For DAOs, it's definitely worth considering a mix of pre-execution simulations and policy enforcement, alongside post-execution monitoring and forensic analysis, to really enhance safety. Check it out for more details: (safe.global).

What exactly to monitor on a Safe multisig

Your treasury Safe sends out canonical events whenever there's a shift in security-related settings or actions. Let's dive into getting these set up first:

Owner and Threshold Changes
- Stay on top of AddedOwner, RemovedOwner, and ChangedThreshold notifications. You definitely want to be alerted if the quorum dips (like going from 4-of-7 to 3-of-7), if you spot any new owners you don't recognize, or if there’s a sudden wave of owner changes. (docs.safe.global)
Execution outcomes
- ExecutionSuccess and ExecutionFailure keep you in the loop about what's going on with those multisig transactions on-chain. Just a heads-up, though--unexpected failures might be masking some pesky reverts in complex multisends or could be triggered by blocked guards. Check it out here: (docs.safe.global)
Module Lifecycle and Executions
- Keep an eye on events like EnabledModule and DisabledModule, as well as ExecutionFromModuleSuccess and ExecutionFromModuleFailure. Remember, modules have the ability to bypass signer thresholds. And with the release of v1.5.0, you can spice things up by adding Module Guards for more restrictions. It's definitely wise to set up alerts for any actions related to enabling or disabling modules, along with any executions initiated by modules. For more details, check out the docs.safe.global.
Guard Changes
- Each time you call setGuard, expect a ChangedGuard to pop up. It's crucial to see any guard removal or replacement as something significant. If there are malfunctioning or rogue guards hanging around, they could easily lead to a denial of service (DoS) or stealthily bypass your policies. Check out the details here: (docs.safe.global)
Hash approvals
- So, here’s the deal with ApproveHash events: they give a transaction hash a permanent VIP pass--once it’s approved, there’s no taking it back. Keep an eye out for any approvals coming from unexpected owners or at odd maintenance hours. Check it out here: (docs.safe.global)

Tip: With the launch of Safe v1.5.0, there’s a super handy new extensible fallback handler along with some internal updates. If you’re working with handler-based integrations, you’ll definitely want to look into ChangedFallbackHandler for keeping an eye on your baseline drift detection. For all the details, check it out here.

Two paths to Forta‑powered monitoring (pick one--or both)

Forta’s “OpenZeppelin‑Gnosis Safe Contract Events” bot family is here to keep you in the loop about important security happenings with Safes on popular EVM chains. Subscribing to these alerts is a breeze--you can have them sent right to your Slack, Email, or Webhook in just a few minutes:

Fire up the Forta App and search for the OpenZeppelin‑Gnosis Safe Contract Events bot (oz‑gnosis‑events). Just make sure to double-check the supported networks--Ethereum, Polygon, Avalanche, Arbitrum, and Optimism--to confirm that your treasury chain is covered. You can find all the details right here: (docs.forta.network).
Next, go ahead and hit that subscribe button, making sure to filter by your Safe address(es). Don’t forget to choose your notification channels! Forta offers a bunch of options like Slack, Email, Telegram, Discord, and Webhook for those on the paid plans. If you’re sticking with the General Plan, you’ll still get API access and notifications. Want more info? Check it out here: (docs.forta.network).
Now it’s time for a little test run! Generate a harmless event--like simulating a multisig transaction on a staging Safe--and confirm that alerts are flowing seamlessly from start to finish.
If you’re up for it, think about chaining in some extra starter-kit bots like “Monitor Function Calls” or “Time Series Analyzer.” These can help you stay on top of things like threshold drops, sudden owner changes, or any unexpected module activity. Dive into it here: (docs.forta.network).

With this, you can easily establish baseline coverage, and it integrates smoothly with other Forta feeds, such as stablecoins, bridges, and timelocks that might impact your treasury. Take a look here: (docs.forta.network)

Option B -- Low‑code: Build a tailored Forta bot focused on your policy

If you want to set up some custom severities, allowlists, and cross-bot logic, all you need to do is whip up a straightforward Forta Agent. This little guy will keep tabs on Safe events and ensure that your DAO’s policies are being followed.

Minimal TypeScript Example (Filtering a Safe for Owner/Threshold/Module/Guard Changes and Executions)

Here’s a simple TypeScript example that filters a Safe based on the owner, threshold, module, and guard changes, along with their executions. This can be really useful when you're diving into decentralized applications.

Setup

First things first, let’s ensure you’ve got the right packages installed:

npm install typescript @ethersproject/providers

Code Example

Here's a straightforward example that demonstrates how to filter changes and executions in a Safe:

import { providers } from '@ethersproject/providers';

// Define the types for the change events
interface ChangeEvent {
    owner: string;
    threshold: number;
    module: string;
    guard: string;
    executionTime: Date;
}

// Sample data
const changeEvents: ChangeEvent[] = [
    {
        owner: '0x123',
        threshold: 2,
        module: 'ModuleA',
        guard: 'GuardA',
        executionTime: new Date('2023-01-01T12:00:00Z'),
    },
    {
        owner: '0x456',
        threshold: 1,
        module: 'ModuleB',
        guard: 'GuardB',
        executionTime: new Date('2023-02-01T12:00:00Z'),
    },
    // Add more events as needed...
];

// Function to filter the Safe changes
function filterChanges(events: ChangeEvent[], owner: string, threshold: number): ChangeEvent[] {
    return events.filter(event => event.owner === owner && event.threshold >= threshold);
}

// Usage
const filteredChanges = filterChanges(changeEvents, '0x123', 1);
console.log(filteredChanges);

Explanation

In this example, we created a ChangeEvent type to keep our data organized. After that, we set up a few sample events to play around with. The filterChanges function takes an array of events, along with an owner and a threshold, and it filters out just the events that fit our criteria.

Conclusion

That's a wrap! You've got a simple TypeScript example ready to go for filtering Safe changes based on certain criteria. Don’t hesitate to adjust the sample data and functions to fit your requirements!

// forta-agent v0.x
import {
  Finding, FindingSeverity, FindingType,
  HandleTransaction, getEthersProvider, ethers
} from "forta-agent";

// Event signatures from Safe ABI
const sigs = {
  AddedOwner: "event AddedOwner(address owner)",
  RemovedOwner: "event RemovedOwner(address owner)",
  ChangedThreshold: "event ChangedThreshold(uint256 threshold)",
  EnabledModule: "event EnabledModule(address module)",
  DisabledModule: "event DisabledModule(address module)",
  ChangedGuard: "event ChangedGuard(address guard)",
  ExecutionSuccess: "event ExecutionSuccess(bytes32 txHash, uint256 payment)",
  ExecutionFailure: "event ExecutionFailure(bytes32 txHash, uint256 payment)",
  ExecutionFromModuleSuccess: "event ExecutionFromModuleSuccess(address to,uint256 value,bytes data)",
  ExecutionFromModuleFailure: "event ExecutionFromModuleFailure(address to,uint256 value,bytes data)"
};

const IFACE = new ethers.utils.Interface(Object.values(sigs));
const SAFE_ADDR = (process.env.SAFE_ADDR || "").toLowerCase();
const QUORUM_MIN = Number(process.env.QUORUM_MIN || 3); // policy floor

export const handleTransaction: HandleTransaction = async (txEvent) => {
  const findings: Finding[] = [];

  for (const log of txEvent.logs) {
    if (log.address.toLowerCase() !== SAFE_ADDR) continue;
    let parsed;
    try { parsed = IFACE.parseLog(log); } catch { continue; }

    const { name, args } = parsed;

    if (name === "ChangedThreshold") {
      const t = Number(args.threshold);
      if (t < QUORUM_MIN) {
        findings.push(Finding.fromObject({
          name: "Safe threshold decreased below policy",
          description: `Threshold set to ${t} (policy min: ${QUORUM_MIN})`,
          alertId: "SAFE-THRESHOLD-LOW",
          severity: FindingSeverity.High,
          type: FindingType.Suspicious,
          metadata: { threshold: String(t) }
        }));
      }
    }

    if (name === "AddedOwner" || name === "RemovedOwner") {
      findings.push(Finding.fromObject({
        name: `Owner set changed: ${name}`,
        description: `${name} => ${args.owner}`,
        alertId: "SAFE-OWNER-CHANGE",
        severity: FindingSeverity.Medium,
        type: FindingType.Info,
        metadata: { owner: args.owner }
      }));
    }

    if (name === "EnabledModule" || name === "DisabledModule") {
      findings.push(Finding.fromObject({
        name: `Module configuration: ${name}`,
        description: `${name} => ${args.module}`,
        alertId: "SAFE-MODULE-CHANGE",
        severity: FindingSeverity.High,
        type: FindingType.Suspicious,
        metadata: { module: args.module }
      }));
    }

    if (name === "ChangedGuard") {
      findings.push(Finding.fromObject({
        name: "Guard changed",
        description: `New guard: ${args.guard}`,
        alertId: "SAFE-GUARD-CHANGE",
        severity: FindingSeverity.Critical,
        type: FindingType.Suspicious,
        metadata: { guard: args.guard }
      }));
    }

    if (name.startsWith("Execution")) {
      findings.push(Finding.fromObject({
        name: `Safe execution: ${name}`,
        description: `Execution event ${name} on treasury Safe`,
        alertId: "SAFE-EXECUTION",
        severity: name.includes("Failure") ? FindingSeverity.Medium : FindingSeverity.Low,
        type: FindingType.Info
      }));
    }
  }
  return findings;
};

Make sure to link event signatures to Safe docs for better accuracy, and don't forget to set your policy thresholds so they're adjustable using environment variables. This method works great with Safe v1.4.1 and v1.5.0, keeping you away from any issues with ABI drift. You can dive deeper into it here: (docs.safe.global).

How to route alerts and build dashboards your finance team will actually use

You can receive push notifications in Slack, via email, or through webhooks directly from the Forta subscription UI. Want to step it up a bit? You can pull alerts with the Forta GraphQL API and amp them up with your own internal signer list and module allowlists. For more info, take a look at the details in the docs.forta.network.
Here’s a quick example: Use this Forta GraphQL query to grab today’s alerts for your Safe address:

query todaysAlerts($input: AlertsInput) {
  alerts(input: $input) {
    alerts {
      alertId
      name
      protocol
      chainId
      source {
        bot {
          id
          name
        }
      }
      description
      metadata
      addresses
      projects
      severity
      createdAt
    }
    pageInfo { hasNextPage endCursor { blockNumber alertId } }
  }
}

Variables:

{
  "input": {
    "addresses": ["0xYourTreasurySafeAddress"],
    "severities": ["CRITICAL","HIGH","MEDIUM","LOW"],
    "createdSince": "startOfDay"
  }
}

To paginate and easily export your weekly operations reviews into Notion or Google Sheets, you'll want to use endCursor. For all the nitty-gritty details, just click here.

If you want to stay on top of pending and executed transactions, along with signer confirmations, it's a good idea to connect to the Safe Transaction Service or its Events Service webhooks. You'll get organized events like NEW_CONFIRMATION and EXECUTED_MULTISIG_TRANSACTION, which are super handy for cross-referencing with Forta alerts. Take a look here: (docs.safe.global)

Pre‑execution prevention belongs in your stack

Monitoring is crucial, but it’s just one piece of the puzzle. To truly safeguard yourself, you need to throw in some pre-execution controls. This way, you’ll be preventing any malicious or out-of-policy transactions from even getting into the game:

Safe Shield
- Safe Shield brings you inline risk assessments and simulations directly within the Safe UI. If you're on the enterprise tier, it can even auto-block any transactions that don’t align with your policies. This feature is a game changer for signers who might not be security whizzes! Take a look at it here.
Simulation Providers
- Safe is joining forces with Tenderly to roll out simulations on a massive scale--around 67,000 each month! This is great news for signers and approvers, as they’ll now have a clear picture of state changes and can anticipate gas costs before taking any action. Make sure to add these simulation diffs to your must-do checklist in your runbook. You can dive deeper here.
Guards and Module Guards (Safe v1.5.0)
- Exciting news! You can now mix and match a Transaction Guard with a Module Guard to ensure that both owner-initiated and module-initiated actions follow the same rules. This means you can block any addresses that aren’t on your allowlist, set limits on stablecoin transfer sizes, or even require a timelock for those riskier selectors. If you want all the juicy details, check it out here.

Emerging best practices we’re implementing for DAOs in 2026

Stay alert for those seven "never ignore" Safe events
You’ll want to keep track of these: AddedOwner, RemovedOwner, ChangedThreshold, EnabledModule, DisabledModule, ChangedGuard, and all Execution* events. We’ve classified their severities for you: Critical for ChangedGuard and when the threshold drops below the floor; High for any module enablements or changes in ownership; and just Info for the non-threatening ExecutionSuccess. Check it out here: (docs.safe.global)
Enrich alerts before paging
Before sending out alerts, make sure to combine the alert payloads with:

Current owners and thresholds from the Safe API.
The approved module allowlist.
Familiar counterparties and token metadata.

Doing this can really help reduce the noise and make your triage process a lot quicker. If you need dependable transaction and confirmation data, take a look at the Safe Transaction Service APIs. (docs.safe.global)

3) Safe v1.5.0 as the Default for New Deployments

With v1.5.0, you’ll find some pretty exciting new features like Module Guards, improved signature validation, and enhanced support for extensible fallback handlers. All of this means you’ll have fewer chances for error and a more streamlined experience overall. If you’re already managing an existing DAO, be sure to sketch out your upgrade path and adjust your guards and modules accordingly. Dive into the details here: (github.com)

4) Pair Forta Alerts with Blocking Policies

Level up your Forta post-block alerts with Safe Shield and on-chain Guards! These tools can automatically block transactions or escalate issues when they step out of line. You can think of Forta alerts as your go-to audit trail and a super handy early warning system for any configuration drift. Dive in and explore more at (safe.global).

Stay Alert for ApproveHash and Snapshot-to-Execution Bridges
Don’t forget, ApproveHash is a permanent feature--so set up alerts to notify you whenever it’s in play. If you’re utilizing Snapshot along with SafeSnap or Reality, it's wise to keep an eye on those module executions. This helps ensure that only proposals backed by valid oracles get executed after their cooldown periods. Dive into the details here: (docs.safe.global)

6) Roles and Modules: Least Privilege

When you’re leveraging Zodiac Roles or similar modules to speed things up, it’s super important to tighten those permissions to just the contracts, selectors, and parameter ranges you really need. Also, try to implement rate-limiting whenever possible to keep things in check. And hey, don’t overlook using ExecutionFromModule* to keep an eye out for any possible misuse. For more info, head over to docs.roles.gnosisguild.org.

7) Multi-chain Parity

These days, you'll find that most treasuries are chilling on Ethereum, as well as on some Layer 2 solutions like Arbitrum, Optimism, and Polygon. The oz-gnosis-events bot is a great tool for keeping track of everything in that space, so make sure to see if it’s covering all your bases and subscribe with your address on each chain. It’s definitely worth your time to set up dashboards organized by chainId, just to ensure you don’t overlook anything. You can get all the details here!

Practical, policy‑driven alert rules you can copy

Threshold policy
If ChangedThreshold.threshold < policy_min OR (owners_count − threshold) < margin_of_safety, we've got ourselves a Critical issue. Time to get Security On‑Call involved! You can check out the details here: (docs.safe.global)
Owner Changes
If you spot {AddedOwner or RemovedOwner} happening outside the maintenance window, that’s a High alert! If it occurs during the window but you notice more than one change in a 24-hour period, it bumps down to a Medium alert with an “anomaly” label (thanks, Time Series Analyzer!). Check out the details here: (docs.forta.network)
Modules
When EnabledModule pops up and isn’t on the allowlist, it triggers a High alert. On the other hand, if we spot DisabledModule tied to a Guard or Module Guard, that's definitely a Critical situation. Check out the details here.
Guards
Whenever you make a change to a Guard, it triggers a Critical status, which means auto-escalation kicks in and the Safe Shield policy gets a speedy review. You can check out more details here: (docs.safe.global)
Executions
When you notice a spike in ExecutionFailure (like more than N failures within a 10-minute window), it could mean there’s a guard misconfiguration or someone might be trying to cause trouble. In that case, bump it up to Medium for further investigation. And don’t forget, ExecutionFromModule* always comes with the module address and decoded selector so you can take a closer look. (docs.safe.global)
ApproveHash
If you come across an ApproveHash from someone you don’t recognize or a new EOA that’s younger than 7 days, that’s definitely a High alert. Check out more details here.

Example: 48‑hour rollout for a $100M DAO treasury

Day 1 (3-4 hours)

First things first, let’s list all the treasury Safes you can find, covering both mainnet and L2s. Don’t forget to jot down the current owners, thresholds, guards, and modules for each one.
Next up, sign up for oz-gnosis-events on Forta for each address you just listed. Make sure those notifications are sent to the #treasury-alerts Slack channel, and set up a Webhook while you’re at it. Check out the details here: (docs.forta.network).
Now, get a basic Forta Agent up and running. Feel free to use the code snippet we talked about earlier, and make sure it’s set up with your chosen policy thresholds and module allowlist. Deploy it, and don’t forget to stake a small amount of FORT to activate it.
Finally, connect the Safe Events Service webhook to your internal incident system. This way, you’ll receive confirmations and execution feeds seamlessly. You can find more info here: (github.com).

Day 2 (3-4 hours)

Make sure to enable Safe Shield for all your production signer UIs. It’s super handy because it automatically blocks any known bad destinations and transfers that don’t follow policy. You can learn more about it here: (safe.global).
We're excited to roll out a Module Guard in version 1.5.0 that works seamlessly with your Transaction Guard policy for all module-initiated flows. Want to learn more? Check it out here: (safe.global).
Set up a dashboard in Notion or Google Sheets that grabs data from Forta's GraphQL. This should include weekly reports covering owner details, threshold changes, and module drift. Want to dive deeper? Check it out here: (docs.forta.network).

Don’t forget simulation and human factors

Before you give the thumbs up, ensure you've run a successful simulation using Tenderly or a similar tool. This step is super crucial for those high-stakes multisends or module transactions. Once you've got the simulation diff, share it in the Slack thread along with the Forta alert to provide some extra context. (blog.tenderly.co)
It's important for everyone involved to know that when Safe Shield tags something as “High risk,” it’s a definite no, not just a friendly suggestion. We definitely need to stick to this rule and reinforce it with guard logic wherever possible. (safe.global)

Chains, scale, and reliability notes

Supported networks: Forta scan nodes are here for you on Ethereum, Polygon, Avalanche, BNB, Arbitrum, Optimism, and Fantom. They're cranking out thousands of alerts every single hour! Just a heads up--make sure your Forta plan and RPC throughput are ready to handle all that alert activity. You can find more info here!
Node and plan hygiene: If you're operating your own Forta scan node to enjoy some solid dedicated latency, make sure to get those JSON-RPC endpoints set up for each blockchain (you know, like Blast or Bware). And don’t skip out on keeping that minimum stake of 2,500 FORT for your scan nodes. If you're on the General Plan, which is around 250 FORT, you’ll have subscriptions that take care of both API access and notifications. For more info, check it out here.

Extra: pulling Safe events directly when you need them

Sometimes, even with Forta in your toolkit, you really just want to dive into those raw event logs or grab some indexed data:

The Safe Transaction Service offers some really useful endpoints: “List Transactions” and “Module Transactions.” These let you dive into the full history of transactions for each Safe--whether they’re pending, executed, or failed--along with pagination and failure flags. It’s a lifesaver when you need to sort things out after something goes awry. Take a look here: (docs.safe.global)
On top of that, the Safe Events Service webhooks dish out real-time JSON notifications for NEW_CONFIRMATION, PENDING_MULTISIG_TRANSACTION, and EXECUTED_MULTISIG_TRANSACTION. You can easily link these up with Forta alerts for a smooth incident response. Check out the details here: (github.com)

Security hardening checklist (copy/paste)

Make sure everything's looking good with the safe contracts on v1.5.0. Double-check that the Guards and Module Guard are up and running, and have been thoroughly tested. (github.com)
Sign up for the oz-gnosis-events for all your treasury Safes, and route those notifications straight to Slack or a Webhook. (docs.forta.network)
Create a custom Forta bot that aligns with your policies, covering things like threshold floors, module allowlists, and any guard changes.
Ensure that Safe Shield is activated for all signer UIs, automatically blocking anything that violates your policies. (safe.global)
Run simulations for any transactions that seem high-risk and make sure to attach the evidence to the approval thread. (blog.tenderly.co)
Set up webhooks from the Safe Events Service to feed into your incident management system. Plus, get yourself a weekly drift report from Forta GraphQL. (github.com)
Keep an incident playbook close by: you'll want to know what steps to take if you spot a ChangedGuard, EnabledModule, or a dip in the threshold (think freeze flows, raise that threshold, or rotate owners).
And don’t forget to hold regular tabletop exercises that focus on signer compromises and module abuse.

Closing

A DAO's treasury really relies on how well you control changes. By mixing Forta's real-time detection abilities with Safe’s v1.5.0 preventative tools--like Module Guards, Guards, and Safe Shield--you can address risks right from the start. This way, you can stop any bad actions before they can even take place, all while keeping a reliable audit trail and a smooth analytics pipeline for your operations.

To kick things off, go ahead and snag the starter bot subscription, then throw in a light custom policy bot, and wrap it all up with some guards. It’s a simple 48-hour plan that teams usually get up and running in no time. If you want to dive deeper into the details, check it out here.

References and further reading

Check out the release notes and documentation for Safe v1.5.0, which covers events and guards. You can find all the details here.
Get the scoop on Forta with their network overview, subscription info, API GraphQL details, and a starting point for “oz‑gnosis‑events” here.
Discover Safe Shield and its awesome integration features with Hypernative, Blockaid, and Tenderly here.
Check out this handy guide to learn about the Safe Transaction Service and Events Service, including webhooks, here.
Dive into the growth of the Forta network and the chains it supports here.

“DAO Treasury Multisig” Forta Gnosis and “DAO Treasury Multisig” Forta: Monitoring Gnosis Safe Events

Quick Summary

Why this matters now (January 2026)

What exactly to monitor on a Safe multisig

Two paths to Forta‑powered monitoring (pick one--or both)

Option B -- Low‑code: Build a tailored Forta bot focused on your policy

Minimal TypeScript Example (Filtering a Safe for Owner/Threshold/Module/Guard Changes and Executions)

Setup

Code Example

Explanation

Conclusion

How to route alerts and build dashboards your finance team will actually use

Pre‑execution prevention belongs in your stack

Emerging best practices we’re implementing for DAOs in 2026

3) Safe v1.5.0 as the Default for New Deployments

4) Pair Forta Alerts with Blocking Policies

6) Roles and Modules: Least Privilege

7) Multi-chain Parity

Practical, policy‑driven alert rules you can copy

Example: 48‑hour rollout for a $100M DAO treasury

Day 1 (3-4 hours)

Day 2 (3-4 hours)

Don’t forget simulation and human factors

Chains, scale, and reliability notes

Extra: pulling Safe events directly when you need them

Security hardening checklist (copy/paste)

Closing

References and further reading

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

Related Posts

Building Supply Chain Trackers for Luxury Goods: A Step-by-Step Guide

Building 'Private Social Networks' with Onchain Keys

Tokenizing Intellectual Property for AI Models: A Simple Guide

“DAO Treasury Multisig” Forta Gnosis and “DAO Treasury Multisig” Forta: Monitoring Gnosis Safe Events

Quick Summary

Why this matters now (January 2026)

What exactly to monitor on a Safe multisig

Two paths to Forta‑powered monitoring (pick one--or both)

Option A -- No‑code: Subscribe to a Safe events bot in Forta

Option B -- Low‑code: Build a tailored Forta bot focused on your policy

Minimal TypeScript Example (Filtering a Safe for Owner/Threshold/Module/Guard Changes and Executions)

Setup

Code Example

Explanation

Conclusion

How to route alerts and build dashboards your finance team will actually use

Pre‑execution prevention belongs in your stack

Emerging best practices we’re implementing for DAOs in 2026

3) Safe v1.5.0 as the Default for New Deployments

4) Pair Forta Alerts with Blocking Policies

6) Roles and Modules: Least Privilege

7) Multi-chain Parity

Practical, policy‑driven alert rules you can copy

Example: 48‑hour rollout for a $100M DAO treasury

Day 1 (3-4 hours)

Day 2 (3-4 hours)

Don’t forget simulation and human factors

Chains, scale, and reliability notes

Extra: pulling Safe events directly when you need them

Security hardening checklist (copy/paste)

Closing

References and further reading

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

Related Posts

Building Supply Chain Trackers for Luxury Goods: A Step-by-Step Guide

Building 'Private Social Networks' with Onchain Keys

Tokenizing Intellectual Property for AI Models: A Simple Guide