Build a Max button that leaves gas available

For native currency, Max cannot simply copy the wallet balance into the sell amount. The same balance usually funds both the swap's value and its network fee.

Use an explicit spend budget

A proposed calculation starts with native balance, subtracts a bounded fee reserve, and quotes the remainder. The resulting route may have a different gas requirement, so update the reserve and requote if necessary. Put a limit on this refinement loop and show the final spendable amount before signing.

The transaction fields distinguish gas limit, fee parameters and value. Preserve that distinction in the budget. With a fee-cap transaction, affordability checks can involve the maximum authorized fee even though actual paid cost may be lower.

A hypothetical calculation

Assume a balance of 0.50 native units and a chosen fee reserve of 0.004. The provisional input is 0.496. If the executable route requires a reserve of 0.006, the application should lower the input to 0.494 and obtain a compatible route. These figures illustrate arithmetic, not recommended reserves for any network.

Do not subtract a native fee from the amount of an unrelated ERC-20 token. An ERC-20 Max button can use the token balance while separately checking the native balance for approvals and execution. Tokens with transfer fees or changing balances can need additional provider-specific treatment.

Keep user intent stable

Store that the user selected Max, not just the first calculated number. Recompute after an approval transaction spends gas or a refreshed fee estimate changes the budget. If the final amount changes materially, update the review screen.

Test a zero spendable balance, a pending approval, a fee spike and an account switch. Never fall back to spending the entire native balance when estimation fails.