We want to introduce account-configurable reserve balances by extending the reserve balance precompile at 0x1001. Accounts can select any uint256 amount, denominated in wei units. Accounts that do not configure a reserve will retain the existing global default of 10 MON.
Configuration changes will activate after the consensus-execution delay. Consensus accounts for scheduled reductions without treating scheduled increases as immediately available gas collateral. Existing emptying transaction eligibility and transaction-end reserve balance enforcement are otherwise preserved.
You can find the MIP here as a PR (link will be updated once merged):
From the wallet support side, a reserve that can differ per account seems like something users will need explained when a send fails. Two plain questions:
How would a wallet read an account’s current reserve, so it can show how much MON is actually sendable?
Could a dapp ask a user to sign a reserve change? If so, it seems worth flagging clearly in the signing prompt, since a very high reserve could stop someone from sending their MON.
How would a wallet read an account’s current reserve, so it can show how much MON is actually sendable?
The wallet application would do an eth_call to the 0x1001 precompile using the GET_RESERVE_BALANCE selector with the wallet address as the parameter. Sendability would then depend on current balance, in-flight transactions (gas reserved in consensus) and specified reserve balance (i.e. DEFAULT_RESERVE or a set value).
Could a dapp ask a user to sign a reserve change? If so, it seems worth flagging clearly in the signing prompt, since a very high reserve could stop someone from sending their MON.
Yes, since it’s essentially a normal transaction. Wallet applications would be expected to:
support setting a custom reserve balance, in which case the user would be made aware of what they are signing
not support setting a custom reserve balance, in which case the user would not be allowed to sign the transaction