.png)
- Custodians close the insider-threat gap with an independent transaction-verification layer that sits outside the MPC or multisig signing process itself.
- The layer inspects transaction intent before signature and enforces policy that no individual signer or quorum can override.
- Edge Capital and M1 Capital run this model in production on Hypernative Transaction Guard across Fireblocks, Fordefi, and internally managed wallets.
- The kpk-Resolv incident shows what happens when that layer is missing upstream of a signing process.
MPC and multisig wallets verify who is authorized to sign a transaction. They do not verify whether that signer, or a colluding group of signers, should be trusted with a specific transaction at a specific moment, which is precisely the gap an insider threat exploits. Custodians can close that gap with Hypernative Transaction Guard, an independent policy layer that inspects transaction intent before signature and enforces escalation rules no individual signer can bypass, regardless of the custody infrastructure underneath.
Why doesn't MPC or multisig signing stop an insider threat?
MPC and multisig were built to solve a narrower problem than the one custodians now face. Both distribute signing authority so no single private key is a point of failure, and both assume that once a valid signature or quorum is produced, the request behind it is legitimate. Neither tests what the transaction actually does, and neither questions whether the party producing a valid signature should be trusted with that specific action.
The Resolv incident illustrates what happens when that assumption fails. On March 22, 2026, attackers compromised Resolv’s off-chain signing infrastructure and used the protocol’s normal minting path to execute two illicit transactions, minting 80M USR against only about $200K in deposited collateral. The transactions themselves were valid. Nothing in the signing layer flagged them, because nothing in the signing layer was designed to.
kpk, a Morpho vault curator with limited exposure to Resolv's RLP market through its USDC Yield vaults, was not the party whose signing process was compromised, but the incident shows why detection has to sit independently of whoever holds signing authority upstream. Hypernative's Onchain Monitoring & Automated Response layer generated multiple detections as the exploit unfolded, including a significant-mint alert and an exploit-suspected flag raised by a known whitehat actor, and an additional price monitor caught the RLP price drop within minutes of the first mint, before the attacker executed the second one. kpk's exit agent, triggered through the Hypernative API, set risk tolerance on the affected market to zero and blocked new allocations without a human in the loop. All Ethereum and Arbitrum funds were fully recovered.
Read more: When the Resolv Exploit Hit, kpk's Depositors Lost Nothing
The compromise sat at the authorization layer, upstream of any wallet security kpk had in place. No signing safeguard could have caught it there. Detection and automated response contained the exposure once it reached kpk's markets.
How do custodians enforce transaction policy independent of who signs?
Edge Capital and M1 Capital run this control in two different forms. One blocks transactions through automated co-signer enforcement. The other routes transactions by risk tier, so no single signer or reviewer can move high-risk funds alone. Both hold to the same principle: what the transaction does, not who signed it, determines whether it goes through.
How does co-signer enforcement work at Edge Capital?
Edge Capital, a market-neutral hedge fund managing more than $380M across DeFi, runs an average of 300 transactions a day across Fireblocks, Fordefi, and internally managed wallets. Before adopting Transaction Guard, the fund maintained a manual framework of hundreds of protocol-specific parameters to catch bad transactions, a system that couldn't scale once inner-call risks and offchain messaging complexity grew past what a spreadsheet-based review could track.
Transaction Guard now inspects every transaction draft before signing, across all three custody environments at once, and enforces co-signer policy through automated block actions when a transaction violates Edge's rules. The multisig or MPC quorum still has to approve. The policy layer sits alongside it and can stop a transaction none of the signers flagged as a problem.
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.
Gleb Zverev, Blockchain Developer @ Edge Capital
Read more: How Edge Capital Scaled Transaction Security and Expanded DeFi Reach With Hypernative Guardian
How does tiered escalation stop a single signer from moving high-risk funds?
M1 Capital, an Amsterdam-based hedge fund with more than $190 million in AUM, built its policy framework around a different control: no single reviewer or signer combination should be able to move high-risk funds without a second, more senior check. Transactions with no detected risk are automatically approved, cutting manual review workload by 99%. Low- and medium-risk transactions route to designated reviewers. High-risk transactions escalate to senior review before any funds leave the vault.
That escalation structure is a segregation-of-duties control as much as it is a detection tool. Steven Wisbrun, co-founder at M1 Capital, said the goal was never just a blocklist: "We weren't just looking to whitelist addresses and smart contracts. Our priority was to protect every transaction with proactive, DeFi-aware threat detection."
What detection signals catch insider activity before a transaction executes?
The signals underneath both deployments go beyond matching addresses against a blacklist. M1's detection layer combines malicious address detection that flags addresses at the block they're deployed, dynamic address reputation that updates continuously against scam network activity, and abnormal execution flow detection that catches unexpected token approvals hidden inside routine interactions like staking or LP deposits. Edge's deployment surfaces Permit and IncreaseAllowance misuse specifically, the kind of hidden authorization grant that lets a technically valid, properly signed transaction quietly expand what an attacker, or a compromised insider, can later do without a second signature.
None of this depends on knowing in advance which signer might go bad. It depends on evaluating what a transaction does, independent of who or how many people already approved it, which is the only check that holds regardless of who the insider turns out to be.
What should institutional custodians look for in an insider-threat control layer?
- Coverage across every custody environment in use, not just one. A policy layer that only watches internally managed wallets and misses MPC or third-party custody infrastructure leaves the largest attack surface unchecked.
- Enforcement independent of signer identity or quorum size. The check has to hold whether one signer, a colluding group, or a compromised credential produced the request.
- Tiered escalation matched to risk severity, not a single approve-or-deny gate. A framework that routes no-risk activity to automatic approval and high-risk activity to senior review, rather than treating every transaction the same, is what keeps the control usable at volume.
- Behavioral detection tied to transaction intent, not just address reputation. Hidden allowance changes and abnormal execution flows are the patterns that matter for insider risk, and a blacklist alone won't catch either.
- Automated response bound directly to detection. A control that requires a human to notice and act before blocking a transaction degrades exactly when volume or urgency is highest, which is when insider risk is most likely to be tested.
Reach out for a demo of Hypernative’s 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.
