{"kind":"chain-guide","id":"MONAD-RESERVE","name":"Reserve balances on Monad","searchAliases":["Reserve Balance Mechanism"],"status":null,"chain":"monad","category":{"id":"transaction-friction","name":"Transaction Friction","description":"Reducing clicks, signatures, and mental overhead"},"journeyStages":[{"id":"asset-display","name":"Asset Discovery & Display","description":"Seeing tokens, NFTs, and balances"},{"id":"executing","name":"Executing Transactions","description":"Performing on-chain actions"},{"id":"gas","name":"Gas & Fees","description":"Paying for transactions"}],"uxImpact":"Monad's Reserve Balance mechanism coordinates consensus-time inflight gas budgets with execution-time ending-balance checks. The current system parameter is user_reserve_balance = 10 MON, but outcomes depend on lagged and starting balances, gas and value spend, delegation, recent activity, and emptying eligibility. It is not a universal balance-minus-10-MON formula or an upfront deposit.","officialUrl":"https://docs.monad.xyz/developer-essentials/reserve-balance","lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","hasDetailedContent":true,"content":{"id":"MONAD-RESERVE","specConstraints":[{"id":"inflight-fee-budget","constraint":"Consensus checks an inflight gas budget rather than assuming the latest execution balance is available.","appliesTo":"infrastructure","normativity":"normative","specQuote":"* *Consensus time*: For each account, consensus has a budget for the **gas spend** for all inflight\n  transactions; this budget is `user_reserve_balance` (or the account's balance from the lagged\n  execution state, whichever is lower). The budget is further reduced if the first inflight\n  transaction earned the exception mentioned above, by that transaction's **value spend**.\n  When performing block validity checks for block `n`, consensus checks that the budget is not exceeded.","specSection":"Summary","specUrl":"https://docs.monad.xyz/developer-essentials/reserve-balance#summary","designImplication":"Estimate the intended transaction using its actual fee payer, recent activity, and lagged state. Do not turn the 10 MON system parameter into a deposit requirement or assume sponsorship makes the sender's inflight gas budget irrelevant."},{"id":"ending-balance-check","constraint":"Reserve enforcement checks the ending balance before gas refunds, with different allowances for sender and non-sender accounts.","appliesTo":"application","normativity":"normative","specQuote":"* *Execution time*: after execution (before gas refunds), a reserve-balance check is applied to\n  the ending balance. For a non-sender account, the ending balance must not be lower than\n  `min(balance at transaction start, user_reserve_balance)`. For the sender, the ending balance may be lower\n  by at most the transaction's **gas spend** (unless the emptying exception below applies).\n  Excessive intermediate debits during execution are allowed as long as the ending balance is sufficient.","specSection":"Reserve balance as the solution / Simple version","specUrl":"https://docs.monad.xyz/developer-essentials/reserve-balance#simple-version","designImplication":"Keep total balance separate from a transaction-specific sendable estimate. Check the complete operation and distinguish the sender's gas allowance from value spent by a called delegated account; neither a static subtraction nor an intermediate balance alone establishes the result."},{"id":"emptying-eligibility","constraint":"Emptying eligibility requires an undelegated sender and no recent sender transaction or delegation request in the relevant block window.","appliesTo":"application","normativity":"normative","specQuote":"A transaction is an **\"emptying transaction\"** iff\n\n  * the sender is undelegated.\n  * the sender has not sent any other transaction within the past `k` blocks.\n  * nobody has sent a delegation or undelegation request for the sender within the past `k` blocks, including in this transaction.","specSection":"Reserve balance as the solution / Addressing the drawback","specUrl":"https://docs.monad.xyz/developer-essentials/reserve-balance#addressing-the-drawback","designImplication":"Do not promise immediate full-balance withdrawal after undelegation. Explain the actual eligibility condition and refresh the estimate when the relevant block and activity state changes instead of treating a timer as proof of eligibility."}],"sources":[{"label":"Monad Reserve Balance documentation","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"official-doc"},{"label":"Monad EIP-7702 documentation","url":"https://docs.monad.xyz/developer-essentials/eip-7702","type":"official-doc"},{"label":"Monad block states documentation","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad JSON-RPC API reference","url":"https://docs.monad.xyz/reference/json-rpc/api","type":"official-doc"},{"label":"Canonical MIP-4 specification","url":"https://github.com/monad-crypto/MIPs/blob/7c95e69cb26d43d82e50d06199d4810067a3a2e0/MIPs/MIP-4.md","type":"official-spec"}],"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21","summary":"Monad's Reserve Balance mechanism coordinates consensus-time inflight gas budgets with execution-time ending-balance checks. The current system parameter is user_reserve_balance = 10 MON, but outcomes depend on lagged and starting balances, gas and value spend, delegation, recent activity, and emptying eligibility. It is not a universal balance-minus-10-MON formula or an upfront deposit.","chainContext":{"behavior":"Monad applies Reserve Balance rules to every EOA by default: consensus budgets gas for inflight transactions from a k-block-delayed state, and execution checks ending balances before refunds. The current user_reserve_balance is 10 MON; only an eligible undelegated sender can use the emptying exception. Wallet estimates and sponsorship may expose these rules, but they do not change them.","whenRelevant":["A wallet or dapp shows a native MON balance, send-max action, transaction preview, or execution result.","An operation can spend MON through a direct transfer, contract call, swap, or delegated account.","The product needs to explain why a transaction was included, executed, reverted, or is waiting for a later block state.","A recovery, undelegation, sponsorship, or low-balance flow needs to show current emptying eligibility and recent activity."],"pitfalls":["Treating 10 MON as a deposit or exposing balance minus 10 MON as a universal spendable amount.","Assuming a low or zero balance is unusable, or that sponsorship overrides reserve checks for a delegated account whose balance decreases.","Treating undelegation as immediate emptying eligibility without checking the prior k blocks and recent delegation or undelegation requests.","Treating eth_call or gas estimation at one block tag as a guarantee of inclusion or execution; balances, inflight activity, and block state can change.","Treating inclusion or finality as execution success. A transaction can be included and later revert while still paying gas."]},"designerTakeaways":["Show total balance, a transaction-specific estimate, and the reason it is conditional or stale instead of presenting a static spendable number.","Your MAX flow should account for transaction value, gas spend, delegation, inflight and recent activity, and emptying eligibility before signing; treat the result as an estimate, not a guarantee.","You can explain that 10 MON is the current protocol reserve parameter, not a deposit that every account must fund or lock.","A zero or low-balance delegated EOA may participate in a sponsored workflow when the call leaves its balance unchanged or increases it, subject to other execution checks; do not block that path with a universal deposit gate.","After undelegation, show reserve eligibility as pending until the required k-block and recent-activity conditions are satisfied, then re-check the current state before signing."],"problemsSolved":[{"problem":"A balance display hides delayed state","oldWay":"Show the latest balance as if it proves the next transaction can be included and executed.","newWay":"Show a transaction-specific estimate with its block or state freshness, and refresh it before signing.","impact":"critical"},{"problem":"A static send-max rule misstates what a transaction can spend","oldWay":"Subtract 10 MON from every balance and call the result spendable.","newWay":"Show a transaction-specific estimate using starting balance, value, gas, delegation, recent activity, and emptying eligibility, and label it as conditional.","impact":"critical"},{"problem":"Small accounts appear trapped even when an emptying transaction may be allowed","oldWay":"Block every account below 10 MON from sending value.","newWay":"Check whether the undelegated sender has no recent transaction or delegation change in the current k-block window, then show the eligible full-balance action with its conditions.","impact":"high"},{"problem":"Sponsored workflows are blocked by a false deposit requirement","oldWay":"Require a delegated EOA to hold 10 MON before a sponsor can call it.","newWay":"Separate the sponsor from the delegated account and keep a zero or low-balance path available when the delegated balance is unchanged or increased and other checks pass.","impact":"high"},{"problem":"A preview or inclusion is treated as a guarantee","oldWay":"Treat a successful simulation or inclusion as proof that the signed transaction will later execute successfully.","newWay":"Show the preview's freshness, then separate inclusion, execution, and finality states; explain that an included transaction can revert and still charge gas.","impact":"high"}],"uxPatterns":[{"name":"Stateful Balance Display","description":"Show total balance alongside a transaction-specific estimate and the state that controls it.","userFlow":["Fetch current balance and account status.","For the intended action, account for value spend, gas limit and price, delegation, inflight activity, and recent requests.","Show an estimated, conditional, or unavailable result rather than subtracting a fixed amount.","Show the block or state freshness and explain that a simulation does not guarantee later inclusion or execution.","Explain the current 10 MON system parameter as reserve context, not as a held deposit.","Re-check when the user changes the amount, gas, destination, or account state."]},{"name":"Reserve-Aware Send Form","description":"Prevent avoidable reserve-related failure while preserving eligible emptying and sponsored paths.","userFlow":["Read destination, value, and gas inputs.","Check delegation state, inflight transactions, recent transactions, and recent delegation or undelegation requests.","If the sender is eligible for an emptying transaction, explain the one-transaction exception and current k-block window.","If delegated, distinguish a balance-decreasing action from a sponsored call that leaves the balance unchanged or increases it.","Re-simulate or re-check immediately before signing, label the result as conditional, and show why it changed if it is stale."]},{"name":"Low Balance Warning","description":"Warn about the current action's reserve risk without declaring every sub-10-MON account unusable.","userFlow":["Show the account balance and the action that may decrement it.","Explain whether the account is delegated and whether the transaction can leave the balance unchanged or increased.","Offer an eligible emptying path when the undelegated account meets all conditions.","Show a state-specific reason and a funding, waiting, or retry action when the estimate is unavailable."]},{"name":"Conditional Full-Balance Send","description":"Offer a full-balance action only after the product verifies the current protocol conditions for an undelegated sender.","userFlow":["Confirm that the sender is undelegated in the relevant prior k blocks.","Confirm that there is no other transaction from the sender in the prior k blocks.","Confirm that there is no delegation or undelegation request for the sender in the prior k blocks, including this transaction.","Show the action as an eligible emptying transaction only after all checks pass.","After submission, show that another action may be limited until the k-block window advances."]},{"name":"Transaction Revert Notice","description":"Handle a transaction that was included but reverted during execution because its ending balance or gas requirements failed the reserve rules.","userFlow":["Show submitted and included before the execution result is known.","If execution reverts, explain the action-specific reserve condition and show that gas may still be charged; do not label inclusion or finality as execution success.","Show the latest balance and eligibility state used for the explanation.","Offer retry with updated value, gas, delegation, or timing when possible."]},{"name":"Reserve Explanation Modal","description":"Explain the two-layer mechanism and its exceptions in plain language.","userFlow":["Explain consensus-time inflight gas budgeting and execution-time ending-balance checks.","Explain the 10 MON parameter without calling it a universal deposit.","Explain delegation, sponsored calls, and emptying eligibility separately.","Link to current Monad documentation and show the account's reason for the current state."]}],"uiComponents":[{"name":"BalanceBreakdown","description":"Shows total balance, transaction-specific estimated sendable, and reserve eligibility context.","states":["loading","estimated","conditional","low","unknown"],"props":["total","estimatedSendable","reserveParameter","eligibilityState","showDetails"]},{"name":"ReserveIndicator","description":"Shows the current reserve constraint and the reason it applies to this account and action.","states":["normal","conditional","blocked","tooltip-open"],"props":["reserveParameter","delegationState","reason","onClick"]},{"name":"SpendableAmountInput","description":"Validates an amount against the latest transaction-specific estimate and emptying eligibility.","states":["valid","exceeds-estimate","emptying-eligible","stale"],"props":["value","estimatedSendable","eligibilityState","onChange","onMax"]},{"name":"LowBalanceAlert","description":"Warns when the current action may fail or when a low-balance account needs a specific next step.","states":["hidden","warning","critical","sponsored-eligible"],"props":["balance","estimatedSendable","delegationState","reason","onAddFunds","onDismiss"]},{"name":"ReserveExplainerModal","description":"Educational modal about the two-layer reserve mechanism, the 10 MON parameter, and its exceptions.","states":["closed","open"],"props":["reserveParameter","eligibilityState","onClose"]},{"name":"EmptyingTxBanner","description":"Shows whether an undelegated account currently meets the emptying-transaction conditions.","states":["eligible","ineligible-delegated","ineligible-recent-activity","ineligible-recent-delegation-change","ineligible-inflight","hidden"],"props":["balance","isDelegated","blocksSinceLastTx","blocksSinceDelegationChange","kBlocks"]},{"name":"TransactionRevertNotice","description":"Explains why a transaction was included but reverted during execution and gives a state-specific retry path.","states":["hidden","shown"],"props":["txHash","revertReason","currentBalance","estimatedSendable","gasCharged","onRetry"]}],"antiPatterns":[{"pattern":"Showing only total balance","why":"Users cannot tell whether this action is allowed under the current gas, value, delegation, and recent-activity state.","instead":"Show total, a transaction-specific estimate, and the reason or freshness of that estimate.","severity":"critical"},{"pattern":"MAX button sending total balance","why":"The transaction may exceed its gas or reserve allowance, while an eligible emptying transaction has different conditions.","instead":"Compute MAX from the current transaction and eligibility state, then re-check before signing.","severity":"critical"},{"pattern":"Hard-coding balance minus 10 MON","why":"The current user_reserve_balance parameter is not a universal spendable amount; account start balance, gas, value, delegation, and inflight state matter.","instead":"Use chain-aware simulation or a documented stateful estimate and label unknown cases.","severity":"critical"},{"pattern":"Treating simulation as a guarantee","why":"eth_call and gas estimates run against a selected block state; later balances, inflight activity, delegation, or consensus timing can differ.","instead":"Show the simulation's block or state freshness, re-check before signing, and confirm execution separately from inclusion and finality.","severity":"high"},{"pattern":"Ignoring transaction reverts from asynchronous execution","why":"A valid transaction can be included and still revert during execution; gas can still be charged.","instead":"Show submitted, included, executed, and reverted states with a retry that uses refreshed state.","severity":"high"},{"pattern":"Hiding the emptying transaction option","why":"An eligible undelegated account may be allowed to dip below the reserve once per k-block window.","instead":"Show the exception only after checking undelegation, recent activity, and recent delegation changes.","severity":"high"},{"pattern":"Treating delegated and undelegated accounts the same","why":"Delegated accounts cannot use the emptying exception, while a low or zero-balance sponsored call can still succeed when the balance is unchanged or increased.","instead":"Branch on delegation and balance direction, then explain the specific state to the user.","severity":"high"},{"pattern":"Using Ethereum balance UX unchanged","why":"Monad's asynchronous execution adds consensus-time inflight budgeting and execution-time reserve checks.","instead":"Model the two layers and keep eligibility visible at send, simulation, and result states.","severity":"high"},{"pattern":"Promising immediate full-balance access after undelegation","why":"Recent delegation or undelegation requests and recent transactions can keep the account from qualifying for the emptying exception.","instead":"Show pending reserve eligibility and re-check once the current k-block conditions are satisfied.","severity":"high"}],"onMonad":[{"aspect":"Balance model","ethereum":"Wallets generally estimate spendable balance from the transaction's value and gas requirements.","monad":"Monad currently uses user_reserve_balance = 10 MON as a protocol parameter, but the effective result also depends on account state and transaction timing.","designImplication":"Never expose balance minus 10 MON as a universal rule or as an upfront deposit requirement."},{"aspect":"Two-layer enforcement","ethereum":"Transaction inclusion and execution use the chain's ordinary balance and gas rules.","monad":"Consensus budgets gas spend for inflight transactions from a lagged state; execution checks ending balance before refunds and may revert value spend.","designImplication":"Keep inclusion, execution, and finality as separate UI states and refresh estimates as blocks advance."},{"aspect":"Emptying exception","ethereum":"There is no Monad-style k-block emptying exception.","monad":"An undelegated sender may qualify to dip below the reserve when no transaction or delegation change has occurred in the prior k blocks; k is currently 3.","designImplication":"Show eligibility and the cooldown conditions; do not grant it immediately after undelegation."},{"aspect":"Delegated and sponsored accounts","ethereum":"EIP-7702 reserve behavior is chain-specific.","monad":"Delegated accounts cannot use the emptying exception, but a zero or low-balance account can be called by a sponsor when the call leaves its balance unchanged or increased.","designImplication":"Do not require a universal 10 MON deposit; explain whether the action decreases the delegated account's balance."},{"aspect":"Contract-level introspection","ethereum":"Wallets and contracts use the chain's own simulation and failure semantics.","monad":"MIP-4 provides an in-execution bool at 0x1001 for the current touched-account reserve state.","designImplication":"Keep MIP-4's contract check separate from wallet sendable-balance and emptying eligibility UI."},{"aspect":"Simulation and result states","ethereum":"A simulation or gas estimate describes the selected state and does not decide later inclusion or execution.","monad":"eth_call and gas estimation can run against a selected Monad block tag, while consensus inclusion, asynchronous execution, and finality remain separate states.","designImplication":"Show previews as conditional, include their block or state freshness, and confirm execution after inclusion."}],"keyTakeaways":["10 MON is the current user_reserve_balance parameter, not a universal amount every account must deposit or hold.","Effective sendability depends on starting and lagged balance, value and gas spend, delegation, inflight and recent k-block activity, and emptying eligibility.","k is currently 3; an eligible undelegated sender can use one emptying transaction in the relevant window.","Delegated accounts cannot use the emptying exception, but zero or low-balance sponsored calls can work when the account balance is unchanged or increased, subject to other execution checks.","Undelegation does not make emptying eligibility immediate; recent requests and transactions still matter.","A transaction can be included and still revert during execution, so result states must remain explicit.","A simulation or gas estimate describes a selected block state; it does not guarantee later inclusion or execution."],"technicalNotes":"Monad's Reserve Balance mechanism coordinates consensus and execution across asynchronous blocks. The current user_reserve_balance parameter is 10 MON. At consensus time, each account's inflight gas-spend budget is the lower of that parameter and the account balance from the lagged execution state, with adjustments for an emptying transaction. At execution time, reserve checks use the transaction's starting balance and distinguish gas spend from value spend; a sender may end below the reserve by at most its gas spend unless the emptying exception applies. An emptying transaction requires an undelegated sender, no other transaction from that sender in the prior k blocks, and no delegation or undelegation request in that window; k is currently 3. Delegated accounts cannot use the exception, but the official EIP-7702 documentation says a delegated EOA need not hold 10 MON and can participate in a sponsored call from zero or low balance when its balance is unchanged or increased, subject to other execution checks. Wallets should treat eth_call and gas estimates as state-specific previews, re-check before signing, and show inclusion, execution, and finality separately. MIP-4's dippedIntoReserve() at 0x1001 is a separate in-execution bool for all accounts touched by a transaction.","relatedStandards":[{"id":"MIP-4","relationship":"Execution-time reserve-dip introspection"},{"id":"EIP-7702","relationship":"Delegation and sponsored-workflow constraints"}]},"sources":[{"label":"Official documentation","url":"https://docs.monad.xyz/developer-essentials/reserve-balance","type":"official-doc"},{"label":"Monad EIP-7702 documentation","url":"https://docs.monad.xyz/developer-essentials/eip-7702","type":"official-doc"},{"label":"Monad block states documentation","url":"https://docs.monad.xyz/monad-arch/consensus/block-states","type":"official-doc"},{"label":"Monad JSON-RPC API reference","url":"https://docs.monad.xyz/reference/json-rpc/api","type":"official-doc"},{"label":"Canonical MIP-4 specification","url":"https://github.com/monad-crypto/MIPs/blob/7c95e69cb26d43d82e50d06199d4810067a3a2e0/MIPs/MIP-4.md","type":"official-spec"}],"urls":{"canonical":"https://www.eipsfordesigners.com/standards/MONAD-RESERVE","markdown":"https://www.eipsfordesigners.com/standards/MONAD-RESERVE/content.md","agent":"https://www.eipsfordesigners.com/standards/MONAD-RESERVE/agent.md","api":"https://www.eipsfordesigners.com/api/standards/MONAD-RESERVE","official":"https://docs.monad.xyz/developer-essentials/reserve-balance"},"freshness":{"lastReviewed":"2026-09-21","lastUpdated":"2026-09-21"}}