Multisig wallets are the foundation of treasury infrastructure for DAOs, asset managers, and institutional crypto teams, but the multisig itself is a governance control, not a security control. A well-configured Safe or Fireblocks vault prevents unilateral movement of funds; it does not prevent the signers from approving a transaction that interacts with a malicious contract, signing a phishing payload, or sending funds into a protocol that gets exploited the next block.
The platforms treasury teams use to close this gap combine real-time monitoring of every wallet, vault, and contract a treasury touches with pre-transaction policy enforcement that interprets transaction intent before signatures are committed. Wave Digital Assets, Edge Capital, and M1 Capital have each built this layered architecture on Hypernative's platform, and their deployments illustrate the operational floor that institutional treasury operations now treat as standard.
Why isn't multisig governance alone enough to protect a treasury?
The multisig threat model assumes that the threat comes from a compromised individual signer. It does not anticipate threats that come through legitimate, properly-quorumed transactions. A treasury team approving a routine vault deposit, a yield strategy rebalance, or a token allowance update can still lose funds if the contract being interacted with is malicious, if the payload contains hidden authorization to drain approvals, or if the protocol is exploited shortly after the position is taken.
This is the failure mode that pre-transaction security is designed to address. Edge Capital, a market-neutral hedge fund managing more than $700M across DeFi, runs an average of 300 transactions per day and previously enforced approval through a manual spreadsheet-based framework of hundreds of protocol-specific rules. Gleb Zverev, blockchain developer at Edge Capital, said the manual approach hit its limit as DeFi complexity grew: "We needed real-time interpretation and enforcement across all our vaults to protect against both external and internal threats. Hypernative is uniquely positioned to simulate transaction intent, plug into our infrastructure, and let us define approval logic and automation that fit our operations securely."
The Hypernative Transaction Guard layer Edge Capital deployed inspects every transaction draft before signing across Fireblocks, Fordefi, and internally managed wallets. It surfaces hidden risks like Permit and IncreaseAllowance misuse, identifies malicious contracts at the block they are deployed, and enforces co-signer policy through automated block actions when transactions violate Edge's rules. The multisig still requires its quorum. The transaction is also held against a policy framework that catches what the signers cannot see.
Read more: How Edge Capital Scaled Transaction Security and Expanded DeFi Reach With Hypernative Guardian
How do treasuries layer real-time monitoring on top of multisig controls?
Pre-transaction checks catch threats at the moment of execution. Real-time monitoring catches threats that emerge after a position is taken, which is where most treasury losses actually occur. Treasury teams running this layer well treat their position exposure as a graph of dependencies rather than a list of holdings, and instrument monitoring for each node.
Wave Digital Assets, an SEC-registered investment adviser, uses Hypernative to monitor more than 20 corporate treasuries deployed across DeFi. The setup covers four distinct coverage types running simultaneously: cross-chain price divergence monitoring for liquid staking tokens and vault assets, liquidity and balance monitoring for capital inflows and outflows across protocols, custom watchlists for protocol-specific risk detection, and protocol and vault-specific coverage across staking, lending, and AMM strategies. Each coverage type runs independently across every treasury Wave manages.
Read more: How Wave Manages DeFi Risk for 20+ Treasuries With Hypernative
How do pre-transaction policies extend multisig security across complex DeFi operations?
The most active treasury teams cannot review every transaction manually, but they also cannot afford to approve transactions on autopilot. Pre-transaction policy is the architecture that resolves this tension. The policy framework defines what is permissible, the transaction screening enforces it, and only transactions that fall outside the policy reach human reviewers.
M1 Capital, a $100M AUM hedge fund running market-neutral strategies across EVM and Solana, has codified a tiered policy framework on Hypernative Transaction Guard that routes transactions based on detected risk. Transactions with no detected risk are automatically approved, reducing manual review workload by 99 percent. Low to medium risk transactions route to designated reviewers. High risk transactions escalate to senior review before any funds leave the vault. The detection layer combines malicious address detection that flags addresses at the block they are deployed, dynamic address reputation that updates continuously based on scam network activity, and abnormal execution flow detection that catches suspicious behavior like unexpected token approvals embedded in routine interactions.
Steven Wisbrun, co-founder at M1 Capital, said the platform's value showed up in the customization: "Hypernative didn't just check boxes. They worked with us to model our risks, tune our policy logic, and integrate real-time signals that catch threats we wouldn't see on our own. Guardian has made it possible to scale our DeFi operations with precision, speed, and a level of safety that fits our standards."
This is what institutional-grade treasury operations look like in practice. The multisig provides governance. The pre-transaction policy provides enforcement. The real-time monitoring provides ongoing visibility. Each layer addresses a different threat class, and none of the three alone is sufficient.
What should DAO and institutional treasury teams look for in a monitoring platform?
Treasury teams evaluating platforms for multisig and treasury monitoring should test for five capabilities.
First, coverage across all custody infrastructure the treasury uses. The platform should integrate with the specific MPC, multisig, and custom wallet providers the treasury operates, not require migration away from them.
Second, pre-transaction simulation that interprets transaction intent, not just transaction syntax. Surface checks against known malicious addresses are insufficient. The platform should detect Permit and IncreaseAllowance misuse, inner call risks, and protocol-specific anomalies.
Third, custom agent capabilities that the treasury's own engineering team can build and deploy. Generic detection templates cover generic risks. The protocol-specific events that matter for a particular treasury's strategies require purpose-built logic.
Fourth, automated co-signer and pause enforcement bound directly to detection signals. Policy that requires manual enforcement degrades under pressure. The enforcement should execute at the block level when policy conditions are met.
Fifth, false positive discipline measurable in operational terms. Ask any platform under evaluation for its false positive rate, the methodology behind that figure, and named customer references on how often the on-call team gets paged for noise versus signal.
The treasury operations teams that test for these capabilities end up with infrastructure that operates as a control system for the entire treasury, not a security layer bolted onto the side. The teams that skip the evaluation typically discover the gap after an incident.
Request a demo to see how Hypernative protects multisig wallets and digital asset treasury operations.
Proactive security for onchain finance.
