# How should MIP-4 integrations handle an already-active reserve violation? **URL:** \ **Category:** MIPs\ **Created:** [July 27, 2026, 1:30pm UTC](https://forum.monad.xyz/t/how-should-mip-4-integrations-handle-an-already-active-reserve-violation/511 "2026-07-27T13:30:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![Umoren](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/umoren/32/396_2.png) [@Umoren](https://forum.monad.xyz/u/Umoren)\ **Post date:** [July 27, 2026, 1:30pm UTC](https://forum.monad.xyz/t/how-should-mip-4-integrations-handle-an-already-active-reserve-violation/511/1 "2026-07-27T13:30:41Z")
Continuing the discussion from [MIP-4: Reserve Balance Introspection](https://forum.monad.xyz/t/mip-4-reserve-balance-introspection/363): I’ve been working with the Cortex Open Source Working Group’s MIPs subgroup on a reusable MIP-4 guard for smart accounts and application contracts. While implementing the guard, I found a case where `dippedIntoReserve()` does not provide enough information to judge one operation safely. The precompile returns one Boolean for the whole transaction. When an operation starts with `false`, the result is clear: ```auto false -> false: the operation did not introduce a violation false -> true: the operation introduced a violation ``` The problem starts when an operation begins with `true`. ```auto Account A dips below reserve -> true Account B performs an innocent call -> true ``` The result is also `true -> true` when Account B adds another violation: ```auto Account A dips below reserve -> true Account B also dips below reserve -> true ``` A contract can see the same result in both cases, but it cannot tell whether B was innocent or added a second violating account. The c++ client and monad-revm maintain the violating addresses internally. The `0x1001` precompile only exposes whether that set is empty. For EntryPoint or smart-account integrations that execute several operations in one transaction, what behavior does Category Labs recommend when an operation begins with `dippedIntoReserve() == true`? Should the integration reject the operation because it can no longer attribute the violation? Or is there an isolation pattern that Category Labs expects these integrations to follow? I documented the two-account case here: [Test multi-account reserve dips when the transaction is already in violation · Issue #21 · Cortex-XYZ/monad-mip-lab · GitHub](https://github.com/Cortex-XYZ/monad-mip-lab/issues/21) ---
**Author:** ![baltoli](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/baltoli/32/169_2.png) [@baltoli](https://forum.monad.xyz/u/baltoli)\ **Post date:** [July 27, 2026, 2:09pm UTC](https://forum.monad.xyz/t/how-should-mip-4-integrations-handle-an-already-active-reserve-violation/511/2 "2026-07-27T14:09:27Z")
Definitionally, a transaction can’t begin in a state where `dippedIntoReserve() == true`. The definition of reserve dipping in the [Monad Initial Spec](https://category-labs.github.io/category-research/monad-initial-spec-proposal.pdf) should clarify this: dipping occurs when an EOA spends below the minimum of its reserve threshold and its initial balance at the start of a transaction. It’s therefore not possible to begin in a dipping state. ---
**Author:** ![Umoren](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/umoren/32/396_2.png) [@Umoren](https://forum.monad.xyz/u/Umoren)\ **Post date:** [July 27, 2026, 2:47pm UTC](https://forum.monad.xyz/t/how-should-mip-4-integrations-handle-an-already-active-reserve-violation/511/3 "2026-07-27T14:47:52Z")
Thank you!. This clears up the top-level transaction boundary. I was referring to the boundary between `UserOperations` inside one `EntryPoint` transaction. Suppose UserOperation A changes a touched EOA below `min(10 MON, its balance at the start of the transaction)` and leaves that state in place. Before UserOperation B executes, would `dippedIntoReserve()` return `true`? If so, is the intended `EntryPoint` pattern to isolate each `UserOperation` in a revertible call frame, check the signal immediately after it runs, and unwind A before B begins? ---
**Author:** ![baltoli](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/baltoli/32/169_2.png) [@baltoli](https://forum.monad.xyz/u/baltoli)\ **Post date:** [July 27, 2026, 3:00pm UTC](https://forum.monad.xyz/t/how-should-mip-4-integrations-handle-an-already-active-reserve-violation/511/4 "2026-07-27T15:00:57Z")
> [@Umoren](#): > > If so, is the intended `EntryPoint` pattern to isolate each `UserOperation` in a revertible call frame, check the signal immediately after it runs, and unwind A before B begins? Yes, this is precisely the usage we intended when designing this precompile.