# MIP-4: Reserve Balance Introspection

**URL:** <https://forum.monad.xyz/t/mip-4-reserve-balance-introspection/363>\
**Category:** MIPs\
**Created:** [January 8, 2026, 12:53pm UTC](https://forum.monad.xyz/t/mip-4-reserve-balance-introspection/363 "2026-01-08T12:53:53Z")\
**Posts on this page:** 1\
**Showing post:** 4

<div class="post-metadata">

**Author:** ![pdobacz](https://yyz1.discourse-cdn.com/flex035/user_avatar/forum.monad.xyz/pdobacz/32/171_2.png) [@pdobacz](https://forum.monad.xyz/u/pdobacz)\
**Post date:** [January 15, 2026, 1:10pm UTC](https://forum.monad.xyz/t/mip-4-reserve-balance-introspection/363/4 "2026-01-15T13:10:35Z")

</div>

Re gas cost

> Expected to be `O(N)` in the number of warm accounts (i.e., accounts with modified balances).

Would it be feasible to:

1. Keep a cache of reserve balance check results per warm account address (with a count of failed checks for quick lookup)
2. Run the reserve balance check only on crossing boundaries where it actually might change. I think that is at transaction start (after auth processing) `CALL`with `value!=0 `and `CREATE` and `SELFDESTRUCT` and call frame reverting.
3. Run the check and update cache only for affected addresses (1 or 2 max per such op)
4. Have `CHECKRESERVEBALANCE` just return the cached result

Then it would be possible to price `CHECKRESERVEBALANCE` at O(1) (and as cheap as an environment opcode)?

The cost of checking and updating would be assumed to be included in the (expensive) ops from (2.). Cost of memory to hold the extra execution state included in cold access cost.

### Motivation

- simpler testing
- cheaper for users
- scales better with # of UserOps in a bundle, i.e. gas cost of a UserOp doesn’t depend on previous ones executed

---

_[View the full topic](https://forum.monad.xyz/t/mip-4-reserve-balance-introspection/363)._