# MIP-4: Reserve Balance Introspection

Source: https://www.eipsfordesigners.com/standards/MIP-4
Agent brief: https://www.eipsfordesigners.com/standards/MIP-4/agent.md
Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/MIP-4
Last reviewed: 2026-04-05
Last updated: 2026-04-05

| Field | Value |
| --- | --- |
| Status | Proposed |
| Chain | monad |
| Category | Transaction Friction |
| Journey stages | Asset Discovery & Display, Executing Transactions, Gas & Fees |
| Detailed guide | Yes |
| Official specification | https://github.com/monad-crypto/MIPs/blob/main/MIPS/MIP-4.md |

## UX Impact

Pre-check if a transaction would fail before sending — apps can query spendable balance accounting for the 10 MON reserve. Design implications: show spendable vs total balance, disable send when amount exceeds spendable, pre-validate before wallet popup, explain reserve with clear tooltips. Design decisions: whether MAX subtracts reserve + gas automatically; how to surface pre-check failures without blocking power users.

## Summary

MIP-4 adds a way to check if a transaction would fail BEFORE sending it. Specifically, it lets apps check if your account has enough "spendable" balance (accounting for the reserve requirement). Instead of sending a transaction and having it revert, wallets can pre-check and show "Insufficient spendable balance" before you waste time or gas.

## For Designers

- You can design UI that delivers check fails instantly before submission.
- You can shows "Spendable: 90 MON" (10 reserved for async execution safety) in the interface.
- You can design UI that delivers light introspection without full simulation.

## Applicability

### When to Use

- Your product addresses: transactions fail after user confirms.
- Your product addresses: confusing when balance looks sufficient but tx fails.
- The flow should deliver: check fails instantly before submission.
- You are designing a pre-send validation experience with visible states and recovery paths.

### When to Avoid

- Always subtract reserve for spendable amount.
- MAX = balance, reserve, gas.
- Clear tooltip: "Reserved for async execution safety".

## Problems It Solves

### Transactions fail after user confirms

Impact: high

Old way: Click send → wait → "Transaction reverted: insufficient funds"

New way: Check fails instantly before submission

### Confusing when balance looks sufficient but tx fails

Impact: high

Old way: "I have 100 MON, why can't I send 100 MON?"

New way: Shows "Spendable: 90 MON" (10 reserved for async execution safety)

### No way to pre-validate complex operations

Impact: medium

Old way: Submit and pray, or use expensive simulation

New way: Light introspection without full simulation

### Smart wallets can't predict failures accurately

Impact: medium

Old way: UserOp submitted, bundler rejects, user confused

New way: Pre-check reserve before UserOp creation

## Anti-Patterns

### Using total balance for validation

Severity: critical

Ignores reserve, tx will fail

Instead: Always subtract reserve for spendable amount

### MAX button ignoring reserve

Severity: critical

User sends MAX → tx fails → frustration

Instead: MAX = balance - reserve - gas

### No explanation of reserve

Severity: high

User confused why they can't spend their balance

Instead: Clear tooltip: "Reserved for async execution safety"

### Only checking balance client-side

Severity: medium

Race conditions, stale data

Instead: Call introspection function for real-time check

## UI Components

### SpendableBalanceDisplay

Shows spendable vs total balance with reserve
States: loading, healthy, low, insufficient
Props: totalBalance, reserveAmount, spendable

### ReserveExplainer

Tooltip explaining what reserve is for
States: collapsed, expanded
Props: reserveAmount, reason

### PreTransactionCheck

Checklist of validations before sending
States: checking, passed, failed
Props: checks[], onRetry

### SmartMaxButton

Calculates max considering reserve and gas
States: calculating, ready, zero
Props: balance, reserve, estimatedGas, onMax

## On Monad

### Reserve Introspection

Ethereum: No equivalent — balance is fully spendable

Monad: Can query exact reserve amount

Design implication: Always show spendable vs total on Monad

### Pre-validation

Ethereum: Simulate with eth_call (expensive)

Monad: Light introspection available

Design implication: Pre-validate all transactions efficiently

### Smart Wallet Integration

Ethereum: UserOps can drain to zero

Monad: Must account for reserve in UserOps

Design implication: Paymaster logic needs reserve awareness

## Key Takeaways

- MIP-4 = pre-check if transaction would fail
- On Monad, always show SPENDABLE balance, not total
- MAX button must subtract reserve + gas
- Pre-validate before showing wallet popup
- Explain reserve with clear UI tooltips

## UX Patterns

### Pre-Send Validation

Check if transaction would succeed before sending

User flow:

- User enters amount
- App calls reserve introspection
- Calculates spendable = balance - reserve
- If amount > spendable: show error
- Prevent submission of failing tx

Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page).

### Smart MAX Button

MAX accounts for reserve and gas

User flow:

- User clicks MAX
- App queries total balance
- Subtracts reserve (from MIP-4)
- Subtracts estimated gas
- Fills in maximum safe amount

Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page).

### Transaction Pre-Check

Validate before wallet popup

User flow:

- User initiates swap
- App runs pre-checks
- Includes reserve balance check
- Shows pass/fail for each
- Only enable confirm if all pass

Mockup registry key: `generic/token-approval` (React UI on the live standard page).

## Technical Notes

MIP-4 adds an introspection method to query account reserve requirements. On Monad, EOAs must maintain a 10 MON minimum reserve to preserve safety under asynchronous execution — preventing race conditions where concurrent transactions drain an account. The introspection returns the current reserve amount, allowing apps to calculate spendable = balance - reserve. Undelegated accounts can bypass the reserve via a one-time "emptying transaction" per k-block period (k=3), but delegated accounts (EIP-7702) cannot.