DeFi security has become increasingly complex, with AI-based anomaly detection, behavioral analysis engines, and sophisticated threat intelligence platforms scanning for complex threat patterns. Yet major exploits continue to happen because essential invariant monitoring is missing to complement these systems.
Many DeFi protocols, such as AMMs and lending protocols, are built on invariants, mathematical foundations that define the correct contract behavior. When these invariants break, something is fundamentally wrong.
The Balancer exploit is one recent example of invariant-based attacks. Balancer V2 suffered a $121 million exploit that corrupted the protocol’s core invariant. This pattern can be found across the industry, with other examples including the Euler Finance and Bunni hacks.
For this reason, systematic real-time monitoring and testing of the core invariants could help protocol teams mitigate the damage of such attacks across chains. Plus, an invariant monitoring setup can be straightforward, involving even simple, no-code alerts.
How the Balancer exploit unfolded
On November 3, 2025, Balancer V2 lost over $121 million across Ethereum, Base, Arbitrum, Polygon, Avalanche, Gnosis, Berachain, Sonic, Optimism, Mode, and zkEVM. The attack involved two transactions on each affected pool, most likely to make the activity look less suspicious to AI-based anomaly detection, behavioral analysis systems, and threat-intelligence platforms:
- Transaction 1 – corruption: The attacker executed a sophisticated
batchSwapoperation that pushed token balances to near-zero. This extreme imbalance created precision and rounding errors that distorted Balancer’s core invariantD, which is meant to stay consistent and preserve the pool’s pricing logic. Once the invariant drifted, the pool’s pricing logic broke, allowing the attacker to drain the pool and credit the tokens to their internal vault balance. - Transaction 2 – extraction: In a later block, the attacker returned and simply withdrew the assets that were already in their custody from the vault.
How the invariant D works
The invariant D comes from the stableswap-style formula Balancer uses internally. You can think of D as the pool’s core measure of “total balanced liquidity.” The price of a Balancer Pool Token (BPT) is essentially: BPT Price = D/total BPT supply. So, the value of BPT grows as the invariant grows.
You receive the BPT token when you provide liquidity to a Balancer pool. In Balancer V2, BPT is also treated as one of the pool’s own assets, which is why adding or removing liquidity is expressed as “joining” or “exiting” the pool. This design is unusual but intentional because it makes Balancer pools composable with other protocols and with each other.
Once the invariant D was corrupted, that specific pool was already compromised, and much of the loss was already locked in. Plus, the attacker didn’t exploit the pools on all the networks at once. Instead, the attack was done in intervals across different chains.
During this window, invariant alerts could be helpful for containing the damage. By catching the violation early, invariant monitoring can alert a protocol team to a potential exploit and prompt them to pause all pools based on the same invariant across chains.
Which past exploits show the same pattern
Many major DeFi hacks over the last few years followed the same structure and steps: break a core invariant → repeat the attack across multiple markets, pools, and networks → extract value sequentially.
The Bunni hack
The Bunni v2 DEX exploit, which took place on September 2, 2025, is another example of an invariant-based attack. Similar to the Balancer hack, the Bunni exploit violated the protocol's core invariant: liquidity_decrease/initial_liquidity < shares_burned/total_shares
The attacker drained 84% of liquidity while burning minimal shares, leveraging compounded rounding errors. This violated the fundamental assumption that burning X% of shares can only decrease liquidity by at most X%.
Additionally, the Bunni exploit was executed on two separate chains, with a three-minute gap between the initial Unichain exploit and the subsequent Mainnet attack. While the Bunni protocol was paused, it was only after the hacks were executed.
With invariant monitoring, the alert system could be triggered after the attack on the first chain, prompting a protocol team to pause the protocol before the attacker moved to the second chain. Of course, such a short time frame between the attacks would require a unique, well-defined response setup that would enable prompt incident management.
The Euler Finance hack
The 2023 Euler Finance hack shows the same pattern. In this hack, the attacker didn’t exploit everything in a single step. Instead, they executed multiple attack transactions, each targeting a different Euler market on Ethereum. The hack involved six transactions of around $200M over 18 minutes, with the first transaction extracting $8M.
Euler had a simple solvency invariant at the market level: the total eTokens should never fall below the total dTokens for a given asset. With that invariant corrupted, the market became insolvent, and the liquidation logic no longer worked as designed.
As in the previous exploits, invariant monitoring could help mitigate financial losses by detecting the first invariant break and pausing all other markets based on the same invariant.
Why invariant monitoring is critical for protocol security
Invariants are the foundation of protocol security because they define correct protocol behavior and must always hold for the system to function as intended. In Balancer’s case, the core invariant D defines the balance and pricing integrity of the pool. So, when D suddenly dropped during what should have been a batch swap, it was a red flag that the pool’s logic was broken.
Block-level invariant monitoring can flag the anomaly early and mitigate potential attacks before they reach other pools relying on the same invariants. It enables detection at the pool, market, or vault level.
So, with an invariant monitoring setup, you can:
- Detect that the core invariant is broken in a way that should never occur under regular circumstances.
- Pause all pools relying on the same invariant across networks before the attacker reaches them.
Of course, invariant monitoring isn’t a replacement for AI-driven or behavior-based monitoring. Behavior-based monitoring can catch patterns that invariants can’t, and invariants can flag mathematical failures that complex heuristics might overlook. So, combining both approaches gives you a much stronger safety net, minimizing potential blind spots.
The challenge of defining invariants
Identifying and defining the right invariants requires economic understanding of the protocol’s logic, analyzing potential edge cases, and implementing the logic properly. For this reason, defining invariants should be a core step during protocol design and testing, as well as during security audits.
Once you’ve defined your protocol invariants, monitoring them can be straightforward. With the right monitoring infrastructure and tools, you can easily set up an alerting system that will continuously monitor and test your core invariants.
EIP-7825 and the growing importance of invariant monitoring
Ethereum’s upcoming Fusaka upgrade, planned for December 2025, will introduce EIP-7825, which sets a per-transaction gas cap of about 16.7 million gas. This change may make certain large or complex exploits harder to fit into a single transaction, increasing the likelihood that attackers split their actions across multiple transactions.
If that happens, this splitting could create short detection windows between the initial corruption and later extraction steps, where invariant monitoring could play an important role. Within these small windows of opportunity during invariant-based attacks, monitoring could allow you to detect corruption as soon as it happens in the first transaction, initiating your response mechanism to mitigate potential damage.
How to monitor your invariant every block with no-code alerts
With Tenderly’s monitoring and alerting, you can monitor invariants in real time without writing a single line of code. Simply set up an alert based on the “View Function” trigger to check the invariant’s value every block.
To do this, head over to the Tenderly Dashboard and follow these steps:
- Create a new alert and choose the “View Function” type.
- Choose the pool contract and the function that outputs the invariant’s value.
- Define the threshold, for example, when the value changes by more than 10%.
- Add a destination for your notifications, such as Slack, PagerDuty, and email, to alert your security team as soon as the configured alert is triggered.
- Deploy the alert and start monitoring, checking the invariants every block.
Here’s an example of an alert configured to monitor the Balancer’s pool:
In the Balancer exploit, when the attacker manipulated balances to corrupt the invariant D, the getRate() function would have shown a dramatic shift during what should have been a balanced swap.
If the invariant isn’t exposed as a view function, as in the Balancer exploit, you can still set up invariant monitoring using Tenderly Web3 Actions. This way, you can create custom triggers and conditions for monitoring your protocol.
Real-world example: Maple Finance
Maple Finance is one of the protocol teams that has implemented invariant monitoring using Tenderly. The Maple team documented critical protocol invariants, covering accounting, pool state, and loan timing.
Maple uses Tenderly Web3 Actions as a part of their monitoring setup to check these invariants every block. If a rule breaks, the team receives an immediate alert, ensuring real-time detection of potential issues.
How to respond to invariant violations
Catching a broken invariant is the first step. Responding quickly and in the correct way is the next critical step in mitigating a potential issue. However, since not every alert should pause the execution of a protocol, you can design a severity-based response procedure.
- Critical violations of core invariants, such as the Balancer hack exploit that caused a major fluctuation in invariant
D, are almost certainly exploits. In these high-severity cases, an automated guardian can pause the affected pools immediately before the extraction of funds. - For less severe deviations, an automated alert can send a notification to your security team for review. You can customize the notification to include details such as a transaction hash for easier inspection.
Here’s an example notification for Balancer’s Composable Stable Pool:
With a Tenderly alert, your team can open the transaction directly in Tenderly and use essential debugging tools to review the transaction trace, state changes, emitted events, and balance changes, gaining a deeper understanding of the root cause.
You can open the transaction in Tenderly Debugger to step through the transaction trace-by-trace and better understand its execution.
Additionally, your team can run automated checks to verify whether a large liquidity withdrawal, fee collection, or rebalance justifies the observed drop in the invariant. If the change cannot be explained by legitimate activity, the system should automatically pause the protocol as part of incident response.
This combined approach gives fast, automated protection while enabling you to maintain control when it matters. Additionally, by introducing multiple steps across your infrastructure providers and internal team reviews, you can address potential centralization concerns.
Set up an emergency response procedure proactively
Having strong, well-defined emergency response procedures in place is critical in the event of an exploit. Your team needs to know exactly what to do and in what order to investigate and mitigate a potential attack before it causes major financial losses.
For instance, Security Alliance (SEAL) runs emergency response drills to prepare protocol teams for worst-case scenarios in a systematic way. The process entails reviewing protocols and incident management procedures, setting up an emergency response, and simulating a real-world attack. The goal is to train protocol teams to respond in a quick, structured way.
By undergoing a SEAL drill, your team can even practice a cross-chain emergency response in a realistic setting. This way, you can have a strong incident management setup in place, ensuring your team knows exactly how to handle potential security breaches.
Validate protocol pausing procedures
As part of this step, you should also verify your emergency procedures for pausing the protocol. Specifically, you need to validate your pause windows for the protocol.
For instance, some older protocol versions, such as early Balancer V2 pools, used limited pause windows. In this case, after the window expires, the pool cannot be paused anymore and becomes fully permissionless. During the 2025 incident, a few long-lived Balancer pools could not be paused simply because their pause window had already expired.
While this is no longer a practice in recent protocol designs, it may still exist in previous protocol deployments. For this reason, your team should run quick simulations to understand and fully evaluate which actions are still available.
For example:
- 3 years ago, the specific Balancer pool could still be paused as demonstrated in this simulation.
- 10 months ago, this simulation shows that the pause call failed with the
BAL#403 error(PAUSE_WINDOW_EXPIRED).
Checks like these can complement a SEAL-style emergency drill by making sure your response plan matches the current state and lifecycle limits of your protocol.
Return to first principles with Tenderly’s alerts
Defining and implementing protocol invariants properly is crucial for ensuring the correct execution of contracts. However, this can be challenging due to the numerous edge cases inherent to the blockchain. Even then, pausing protocols and mitigating exploits is no easy feat.
Nonetheless, when a protocol’s invariant breaks, it’s a clear sign that something is wrong, prompting teams to react quickly. For this reason, protocol teams should implement several security layers, from proactively establishing emergency response procedures to setting up real-time invariant monitoring. While eliminating the risk of exploits isn’t possible, covering all the bases can at least minimize it.
Set up real-time alerts to monitor invariants in just a few simple, no-code steps.
