.png)
- Institutions verify transaction safety before execution by running two checks in the seconds between drafting and signing: simulation, which interprets what a transaction will actually do, and policy enforcement, which checks that outcome against pre-approved rules.
- Simulation catches risks that address whitelists miss, including malicious approvals, poisoned destination addresses and hidden logic buried inside a contract's inner calls.
- Policy enforcement blocks any transaction outside approved scope, whether that means an unrecognized counterparty, a disallowed function or a value above a set threshold.
- Hedge funds Edge Capital and M1 Capital, and stablecoin issuer Ethena, run this check through Hypernative Transaction Guard across custody infrastructure that includes Fireblocks and Fordefi.
Institutions verify a transaction is safe before it executes by running two checks in the window between drafting and signing. The first is simulation: interpreting a transaction's full outcome, including calls buried inside its logic that a reviewer would not catch by reading the destination address alone. The second is policy enforcement: checking that outcome against rules the institution set in advance, and blocking anything that falls outside them.
Edge Capital, a hedge fund with more than $380 in assets under management, and M1 Capital, a fund with more than $190M in assets under management, both run these checks through Hypernative Transaction Guard before a transaction ever reaches a signer.
What does pre-transaction simulation actually check?
Simulation interprets what a transaction will actually do before anyone signs it, not just where it is going. Edge Capital, which executes an average of 300 transactions a day across protocols including Aave, Morpho, CowSwap and Hyperliquid, built a manual framework of hundreds of protocol-specific parameters to catch bad transactions before the fund adopted Transaction Guard. The framework worked for direct calls, but it could not see malicious logic hidden inside a contract's inner calls, offchain messages or bridge instructions, the categories of risk that don't surface in a simple counterparty check.
That gap is why simulation has to interpret intent, not just destination. Transaction Guard evaluates the full effect of a proposed transaction, including Permit and IncreaseAllowance misuse that can hand an attacker standing approval to drain a wallet without a second signature. Gleb Zverev, a blockchain developer at Edge Capital, said the fund needed a system that could interpret intent directly rather than rely on address matching alone: "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."
Read more: How Edge Capital Scaled Transaction Security and Expanded DeFi Reach With Hypernative Guardian
How does policy enforcement work at the point of signing?
Policy enforcement is the second check, and it runs against the output of the simulation rather than the transaction as submitted. M1 Capital, an Amsterdam-based hedge fund, set a requirement that any transaction leaving a vault had to be fully understood, policy-compliant and risk-screened before a dollar moved onchain. The fund now allows only known, pre-approved actions involving trusted contracts and addresses, and Transaction Guard blocks anything outside that scope automatically.
Steven Wisbrun, co-founder at M1 Capital, said address whitelisting alone was never the goal: "We weren't just looking to whitelist addresses and smart contracts. Our priority was to protect every transaction with proactive, DeFi-aware threat detection." That distinction, between allowing a destination and verifying an outcome, is what separates policy enforcement from a static allowlist, and it is the piece compliance officers and heads of risk are increasingly asking custody and transaction policy teams to document.
Why doesn't post-transaction monitoring cover this risk?
Post-transaction monitoring answers a different question. It tells a team what happened after a transaction has already settled onchain, which is valuable for catching an exploit in progress but too late for a transaction that only needed one signature to drain a wallet. Blind signing, approving a transaction without independently verifying what it does, is the specific failure mode pre-transaction verification is built to close, and it matters most for multisig and high-value transfers where a single bad approval can move a large sum at once.
Ethena, which issues a synthetic dollar stablecoin, deployed Transaction Guard specifically to address blind signing risk across its multisig and high-value transaction flow, vetting transactions for intent and impact before approval rather than after settlement.
Read more: Ethena Turns to Hypernative to Protect Transactions Across Its $15B Ecosystem
The policy layer itself is where institutions get specific. Edge Capital's technical team uses Transaction Guard's software development kit to define dozens of transaction-level checks, including sender and recipient mismatches and protocol-specific behavior across each DeFi application the fund touches, rather than relying on one generic ruleset applied to every transaction. That granularity is what lets a policy catch a fund-specific risk, like an unexpected recipient on a routine withdrawal, without generating false positives on legitimate day-to-day activity.
What should institutions look for in a pre-transaction verification platform?
- Simulation depth that reaches inner calls, typed messages and bridge instructions, not just the top-level function call, since that is where whitelisting-based controls miss risk.
- Policy granularity fine enough to define approved counterparties, functions and value thresholds per protocol, rather than one ruleset applied across every transaction type.
- Native integration with existing custody infrastructure, including MPC wallets and multisig setups, so enforcement does not require rebuilding the signing workflow.
- Coverage broad enough to address blind signing across all high-value and multisig transactions, not a subset selected for convenience.
- Enforcement fast enough to avoid adding approval latency to time-sensitive DeFi activity, since a control that slows execution down gets bypassed under pressure.
Explore Hypernative for financial institutions, reach out for a demo of our solutions, tune into Hypernative’s blog and our social channels to keep up with the latest on cybersecurity in Web3.
Proactive security for onchain finance.
