TL;DR: Mellow’s vault infrastructure now uses continuous onchain monitoring across its contracts and routing dependencies, and live detection helped contain a flash-loan exploit against legacy third-party vault deployments before funds were fully drained, according to Blockaid. The case shows that vault security depends on the full dependency graph, not just the contracts teams directly deploy.
At a glance
What this is: This is an analysis of how continuous onchain monitoring changes the security posture of vault infrastructure that routes assets across multiple DeFi dependencies.
Why it matters: It matters because teams running structured products need detection and response that covers not only their own contracts but also the protocols and legacy deployments their capital touches.
By the numbers:
- Blockaid says Mellow's Core Vaults architecture holds more than $250+ million in TVL.
- Blockaid says it scanned over 6.3 billion transactions since 2025.
- Blockaid says it blocked 585 million attacks since 2025.
Context
Vault infrastructure in DeFi is only as strong as the contracts, venues, and integrations it depends on. When strategies route capital through lending markets, DEXs, and yield venues, the security problem becomes dependency-wide monitoring and response rather than simple contract hardening.
For identity and access practitioners, the parallel is governance of delegated power and trusted pathways. In this case, the risk is not a human account or a service credential, but the same control question applies: what can act, where can it act, and how quickly can abnormal behaviour be contained?
That makes this a useful case for teams evaluating operational controls around onchain financial infrastructure. The starting point is atypical only in its implementation detail; the underlying governance problem, watching the whole trust graph, is increasingly common.
Key questions
Q: What breaks when vault monitoring stops at the contracts a team directly deploys?
A: Teams miss the dependencies that can still move user capital or corrupt accounting, especially third-party protocols and legacy deployments. In DeFi vaults, the effective attack surface includes every venue the strategy can touch, so contract-only monitoring leaves a gap between observed code and actual economic exposure.
Q: Why do flash-loan exploits create such a severe containment problem for vault operators?
A: They compress attack, accounting manipulation, and value extraction into a short execution window that can repeat before manual review catches up. That speed means the first malicious transaction is often the only practical containment point, which is why response authority must be tied to live detection.
Q: What are the signs that share accounting is being manipulated in a vault?
A: Look for repeated redemption patterns, deposits followed by outsized withdrawals, and fund movements that do not match the expected strategy behaviour. When those signals appear across a dependent vault or a sibling deployment, operators should treat them as active exploitation rather than normal market activity.
Q: Who should be able to pause vault activity when exploit transactions appear?
A: The people responsible for vault operations should have pre-approved authority to pause deposits and withdrawals, because containment depends on acting before the exploit cycle completes. Governance should make that authority explicit, tested, and reachable from the same workflow that receives alerts.
Technical breakdown
How onchain vault dependencies expand the attack surface
A vault protocol is not a single contract in practice. It is a control plane that routes capital across multiple venues, each with its own assumptions, accounting logic, and failure modes. When a strategy allocates into lending markets or other DeFi protocols, the vault inherits those downstream risks even if the core vault code remains unchanged. Continuous monitoring therefore has to look at the vault, the positions inside it, and the external protocols that can affect state transitions. That is why detection must be graph-aware rather than contract-local.
Practical implication: map every external dependency that can change vault state and monitor it as part of the same control surface.
Why flash-loan manipulation breaks share accounting
Flash loans let attackers borrow large capital briefly, use it to distort onchain state, and unwind the position inside the same execution window. In vaults that rely on share accounting, this can let an attacker redeem more value than they contributed by pushing the accounting model out of equilibrium during a transaction. The exploit class is dangerous because it is repeatable and fast, which leaves little room for manual review after the fact. The control problem is not just detecting loss, but detecting the first malicious state change before it compounds.
Practical implication: treat abnormal share-price or redemption behaviour as an immediate containment trigger, not a post-incident artifact.
How real-time alerting shortens time to containment
Monitoring only helps when it connects detection to response. In this case, alerts carried the attacker address, affected contracts, and recommended actions into the team’s workflow while the exploit was still active. That matters because onchain attacks often unfold in minutes, and the first transaction is frequently the best containment opportunity. Shared-channel alerting is useful only if it is operationally tied to actions such as pausing deposits, pausing withdrawals, or blacklisting known exploit addresses. The architecture is as much response design as it is detection design.
Practical implication: wire alerts directly to response authority so the first malicious transaction can trigger containment without delay.
Threat narrative
Attacker objective: The attacker aimed to drain funds from exposed vault deployments by exploiting share accounting under flash-loan conditions.
- Entry occurred through legacy third-party vault deployments built on early Mellow contracts that still held liquidity and were exposed to the same accounting weakness.
- The attacker used flash loans to manipulate share accounting and redeem more than they deposited, creating a repeatable exploit cycle.
- The exploit drained funds from vulnerable vaults until deposits were paused and the attack was contained.
- The attacker’s objective was to extract value from legacy vault liquidity before operators could stop the draining pattern.
Breaches seen in the wild
- Azure Key Vault Contributor escalation 2024: Datadog found Azure Key Vault Contributor could add itself to access policies and read every secret, key and certificate in a vault.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Vault governance fails when teams monitor only what they deploy. The article shows that the real control boundary is the full dependency graph, including legacy deployments and third-party protocols. For DeFi infrastructure, that means governance has to extend to downstream venues and dormant contracts, not just active code.
Continuous detection is now part of vault assurance, not a nice-to-have alert layer. The exploit was contained because monitoring surfaced the first malicious transactions in time for action. In systems where value can move and settle within minutes, delayed review is not governance, it is hindsight.
Share accounting manipulation is the named failure mode this case exposes. The breach worked because value accounting could be distorted faster than human operators could react. That is a control gap in state-transition monitoring, and it belongs alongside the contract logic itself in any serious assurance model.
Operational response must be coupled to detection authority. Alerts that do not trigger containment actions leave the exploit window open. Practitioners should treat pause rights, blacklist capability, and escalation routing as part of the security model, because response latency is the difference between an event and a loss.
Onchain vault security is converging with identity governance in one important way. The question is no longer only who has access, but which dependencies are trusted to act on behalf of the vault. That makes provenance, delegation, and runtime monitoring central to any institutional DeFi programme.
From our research library:
- 73% of vaults are misconfigured, leading to unauthorised access and exposure of sensitive data, according to the Ultimate Guide to NHIs.
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
- Read next: Guide to the Secret Sprawl Challenge
What this signals
Vault dependency sprawl: as structured products route capital across more venues, security programmes have to treat external protocols as part of the monitored control plane. The immediate implication is that operators need evidence of who can affect vault state, not just who owns the deployment.
Detection-only programmes are not enough when exploitation and asset movement happen in the same execution window. The operational standard is moving toward monitored containment, where pause rights, blacklist capability, and alert routing are designed before the first incident.
The article reinforces a broader DeFi governance lesson: trust boundaries do not end at the contracts a team deploys. As more value is concentrated in a smaller set of vault infrastructures, the cost of missing one dependency rises sharply.
For practitioners
- Map the full vault dependency graph Inventory every lending market, DEX, yield venue, and legacy deployment that can influence vault state, then classify which dependencies can change capital flows or share accounting.
- Add real-time exploit monitoring to vault operations Monitor abnormal fund movements, repeated exploit transactions, and share accounting anomalies across both current and legacy contracts, with alerts routed to responders immediately.
- Pre-authorise containment actions Define who can pause deposits, pause withdrawals, and blacklist known exploit addresses before an attack occurs, and ensure those actions can be executed from the alerting workflow.
- Separate live infrastructure from legacy deployments Isolate older contracts that are no longer actively operated, but still hold assets, so exposure in dormant code does not become a live production risk.
Key takeaways
- Vault operators need to monitor the full dependency graph because legacy deployments and routed protocols can still expose live assets.
- The article shows more than $250+ million in TVL at stake and highlights how quickly exploit attempts can repeat once share accounting is manipulated.
- Practitioners should pair continuous monitoring with pre-authorised containment so the first malicious transaction can trigger action before losses compound.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | TA0006; TA0040 — Credential Access; Impact | The article describes a live exploit chain that manipulates onchain state and drains value. |
| Recommendation — Map exploit behaviour to TA0006 and TA0040 to prioritise detection of manipulation that leads to loss. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitoring for Anomalies and Events | Continuous monitoring is the core control discussed across vaults and their dependencies. |
| RS.MA-01 — Incident Mitigation | The article emphasises pausing deposits and withdrawals as the containment response. | |
| Recommendation — Use DE.CM-01 to monitor vault activity and dependent protocol behaviour for anomalous transactions. Apply RS.MA-01 to pre-authorise mitigation actions that stop exploit propagation quickly. | ||
| CIS Controls v8 | CIS-8 — Audit Log Management | Operational response depends on forensic context and traceable alerting across the vault stack. |
| Recommendation — Use CIS-8 to centralise logs and preserve traces that support rapid exploit triage. | ||
Key terms
- Vault Dependency Graph: The set of contracts, venues, and external protocols that can influence how a vault holds, prices, or moves assets. In DeFi, the real security boundary extends across that graph because each dependency can change the vault’s risk even when the vault code itself is unchanged.
- Share Accounting Manipulation: A failure mode where an attacker distorts how a vault calculates ownership shares so redemptions become mispriced. It is especially dangerous in transaction-compressed environments because the attacker can extract value before operators can verify the state change.
- Containment Authority: The level of permission a provider or internal team has to take direct response action during an incident. It includes actions such as isolating a host, revoking a session, or resetting credentials, and it is often the control that decides whether a threat is stopped quickly or only documented.
- Legacy Deployment Exposure: Risk created when older contracts or systems remain reachable and hold assets even after a team no longer actively operates them. These dormant deployments can become live attack surfaces if they are not isolated, monitored, or retired in line with their residual risk.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, secrets management, and lifecycle control. It is useful for practitioners who need to connect identity discipline to broader security operations.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org