# MONAD-RESERVE: Reserve Balance Mechanism Source: https://www.eipsfordesigners.com/standards/MONAD-RESERVE Agent brief: https://www.eipsfordesigners.com/standards/MONAD-RESERVE/agent.md Machine-readable JSON: https://www.eipsfordesigners.com/api/standards/MONAD-RESERVE Last reviewed: 2026-04-05 Last updated: 2026-04-05 | Field | Value | | --- | --- | | Status | Active | | Chain | monad | | Category | Transaction Friction | | Journey stages | Asset Discovery & Display, Executing Transactions, Gas & Fees | | Detailed guide | Yes | ## UX Impact Every EOA must maintain a 10 MON reserve for async execution safety. Two-layer enforcement: consensus-time (inflight tx budget) and execution-time (revert if ending balance < reserve). Undelegated accounts get one emptying transaction per ~3 blocks that bypasses the reserve; delegated accounts (EIP-7702) cannot. Design implications: show spendable vs total balance, account for reserve in MAX buttons, detect delegation status for emptying tx eligibility, handle transactions that revert after block inclusion, warn when approaching reserve threshold. Design decisions: whether to surface emptying transaction option for sub-10-MON balances vs. simply prompting to add funds. ## Summary Monad requires every EOA to maintain a 10 MON reserve balance to preserve safety under asynchronous execution. During execution, transactions revert if the account's ending balance dips below the reserve — preventing race conditions where concurrent transactions drain an account. Undelegated accounts get one exception: an "emptying transaction" that can bypass the reserve once per k-block period (k=3 blocks). Delegated accounts (EIP-7702) cannot use this exception. Wallets must show "spendable balance" not just "total balance" so users understand what they can actually use. ## For Designers - You can design UI that delivers reserve balance guarantees a gas budget even under concurrent execution. - You can design UI that delivers can't spend below reserve (unless using emptying transaction). - You can design UI that delivers "100 MON total, 90 MON spendable" is explicit. ## Applicability ### When to Use - Your product addresses: async execution can cause concurrent balance drains. - Your users accidentally drain accounts completely. - The flow should deliver: reserve balance guarantees a gas budget even under concurrent execution. - You are designing a balance display with reserve experience with visible states and recovery paths. ### When to Avoid - Always show spendable as primary, total as secondary. - MAX = spendable, estimated gas. - Detect reverts, explain the cause, and offer retry with updated amounts. - The flow is a single low-risk transfer where batching adds confusion. ## Problems It Solves ### Async execution can cause concurrent balance drains Impact: critical Old way: Sequential execution prevents double-spend by ordering New way: Reserve balance guarantees a gas budget even under concurrent execution ### Users accidentally drain accounts completely Impact: high Old way: MAX button sends everything, account now useless New way: Can't spend below reserve (unless using emptying transaction) ### New users confused by different balance types Impact: medium Old way: "I have 100 ETH" (but actually 100 is fully spendable) New way: "100 MON total, 90 MON spendable" is explicit ### DeFi positions risk trapping users Impact: medium Old way: Stake everything, can't afford gas to unstake New way: Reserve prevents full lockup for most transactions ## Anti-Patterns ### Showing only total balance Severity: critical Users think they can spend 100 MON when only 90 is spendable Instead: Always show spendable as primary, total as secondary ### MAX button sending total balance Severity: critical Transaction will revert during execution, user loses gas fees Instead: MAX = spendable - estimated gas ### Ignoring transaction reverts from concurrent execution Severity: high Under async execution, balance can change between submission and execution — valid transactions can be included in a block but still revert Instead: Detect reverts, explain the cause, and offer retry with updated amounts ### No explanation of reserve Severity: high Users confused why balance is "locked" Instead: Clear info icon explaining reserve protects against async execution risks ### Hiding the emptying transaction option Severity: high Users with <10 MON think they can't transact at all Instead: Show emptying transaction eligibility and cooldown for undelegated accounts ### Treating delegated and undelegated accounts the same Severity: high Delegated accounts (EIP-7702) cannot use emptying transactions — different rules apply Instead: Check delegation status and show appropriate balance/send constraints ### Using Ethereum wallet UX patterns unchanged Severity: high Monad has different balance semantics and two-layer enforcement (consensus + execution) Instead: Design specifically for reserve model ### Letting users feel "trapped" by reserve Severity: medium Negative UX, feels like funds are inaccessible Instead: Frame positively: "Always able to transact" and mention emptying tx escape hatch ## UI Components ### BalanceBreakdown Shows total, spendable, and reserved amounts States: loading, healthy, low, critical Props: total, spendable, reserved, showDetails ### ReserveIndicator Visual indicator of reserved amount States: normal, highlighted, tooltip-open Props: amount, onClick ### SpendableAmountInput Input that validates against spendable balance States: valid, exceeds-spendable, exceeds-total Props: value, spendable, onChange, onMax ### LowBalanceAlert Warning banner for low spendable balance States: hidden, warning, critical Props: spendable, threshold, onAddFunds, onDismiss ### ReserveExplainerModal Educational modal about reserve system States: closed, open Props: reserveAmount, onClose ### EmptyingTxBanner Shows emptying transaction eligibility and rules for sub-reserve accounts States: eligible, ineligible-delegated, ineligible-cooldown, hidden Props: balance, isDelegated, blocksSinceLastTx, kBlocks ### TransactionRevertNotice Explains why a transaction was included in a block but reverted during execution States: hidden, shown Props: txHash, revertReason, currentSpendable, gasUsed, onRetry ## On Monad ### Balance Model Ethereum: Balance is fully spendable Monad: 10 MON minimum reserve required per EOA Design implication: All balance UIs must show spendable vs total ### Enforcement Ethereum: Sequential execution prevents double-spend by ordering Monad: Two-layer enforcement: consensus-time (inflight tx budget over k=3 blocks) and execution-time (revert if ending balance < reserve) Design implication: Transactions can be included in blocks but still revert — design for this edge case ### Emptying Exception Ethereum: No concept — balance fully spendable down to zero Monad: Undelegated accounts get one emptying tx per k-block period that bypasses reserve Design implication: Show emptying tx eligibility for sub-10-MON accounts; explain cooldown period ### MAX Calculations Ethereum: MAX = balance - gas Monad: MAX = balance - reserve - gas (or full balance via emptying tx if eligible) Design implication: MAX button logic must check delegation status and emptying tx eligibility ### Smart Wallets (EIP-7702) Ethereum: Can delegate entire balance Monad: Delegated accounts cannot use emptying exception — reserve strictly enforced Design implication: Delegated accounts have stricter constraints; session keys can't bypass reserve ## Key Takeaways - Monad requires 10 MON minimum reserve per EOA for async execution safety - ALWAYS show spendable balance, not just total - MAX button must account for reserve AND check emptying tx eligibility - Undelegated accounts can bypass reserve once per ~3 blocks (emptying transaction) - Delegated accounts (EIP-7702) cannot use the emptying exception - Transactions can be included in blocks but revert during execution — handle this gracefully - Frame reserve as benefit: "Always able to transact" ## UX Patterns ### Balance Display with Reserve Show both total and spendable balances User flow: - User opens wallet - App fetches total balance - Subtracts reserve amount - Displays both clearly - Tooltip explains reserve Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page). ### Reserve-Aware Send Form Prevent sending more than spendable User flow: - User opens send form - Shows spendable, not total - MAX calculates safely - Validates against spendable - Prevents invalid sends Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page). ### Low Balance Warning Alert when approaching reserve threshold User flow: - App monitors spendable balance - When below threshold, show warning - Estimate remaining transactions - Offer easy add funds action - User can dismiss or act Mockup registry key: `generic/balance-display` (React UI on the live standard page). ### Emptying Transaction Flow Allow undelegated accounts to send their full balance once per k-block period User flow: - User has balance below 10 MON reserve - App checks emptying tx eligibility (undelegated, no recent txs) - Shows explanation of emptying transaction rules - User sends full balance in single transaction - App shows cooldown notice: wait ~3 blocks before next tx Mockup registry key: `generic/balance-display` (React UI on the live standard page). ### Transaction Revert Notice Handle transactions that are included in a block but revert during execution User flow: - Transaction submitted and included in block - Execution reverts due to balance falling below reserve - App detects revert and shows clear explanation - Shows current spendable balance for context - Offers retry with updated amounts Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page). ### Reserve Explanation Modal Educate users on why reserve exists User flow: - User clicks "?" on reserve - Modal explains concept - Shows with/without comparison - User understands and dismisses Mockup registry key: `concept/gas-abstraction` (React UI on the live standard page). ## Technical Notes Monad enforces a minimum balance reserve (10 MON per EOA) to preserve safety under asynchronous execution. Enforcement happens at two layers: (1) Consensus-time — validates that inflight transactions (included less than k=3 blocks ago) don't exceed a gas spend budget equal to the reserve balance or the account's lagged-state balance, whichever is lower. (2) Execution-time — transactions revert when the account's ending balance (before refunds) dips below the reserve, except for emptying transactions. Emptying transactions allow undelegated accounts to bypass the reserve once per k-block period, provided: the account has been undelegated for k blocks, has no pending delegation changes, and hasn't sent a transaction in the last k blocks. Delegated accounts (EIP-7702) cannot use the emptying exception and are strictly bound by the reserve. Note: valid transactions can be included in blocks but still revert during execution because consensus cannot access current state during validation.