client/asset/eth: handle swap fee rates below the network base fee#3615
Open
peterzen wants to merge 4 commits into
Open
client/asset/eth: handle swap fee rates below the network base fee#3615peterzen wants to merge 4 commits into
peterzen wants to merge 4 commits into
Conversation
The server-assigned swap fee rate becomes the transaction's gas fee cap verbatim. If the network's base fee exceeds it at broadcast time, the tx cannot be mined until the base fee recedes, and meanwhile occupies the nonce, blocking every subsequent transaction from the wallet until it is mined or replaced. Check the assigned rate against the current base fee before initiation and error instead of broadcasting, leaving the nonce unspent. Core retries the swap, which proceeds if the base fee recedes within the broadcast timeout. The already-initiated recovery path is unaffected. Redeem already handles this condition by raising its fee cap, funds permitting. Co-Authored-By: Claude Fable 5 <[email protected]>
Rather than refusing outright when the server-assigned swap fee rate is below the network's current base fee, attempt to raise the tx's gas fee cap to 2*baseFee, funds permitting, mirroring the existing rescue in Redeem. Under EIP-1559 the fee cap is not the fee paid, and the server's ValidateFeeRate only requires the cap to be at least the assigned rate, so a higher cap is protocol-legal. Refusal remains as a last resort when available balance cannot cover a minable cap. This also prepares for live (non-maximal) server fee rate assignment, where a fee spike between match time and broadcast time would otherwise strand honest traders. Co-Authored-By: Claude Fable 5 <[email protected]>
Address review: the base fee is provider-reported, so compute the rescue budget in big.Int to keep absurd values from overflowing the decision, and guard the gasLimit division. Co-Authored-By: Claude Fable 5 <[email protected]>
The initial maxFeeRate value derived from swaps.FeeRate was never read now that the rescue result determines the fee cap; declare it at the point of use instead. Fixes the ineffassign CI failure. Co-Authored-By: Claude Fable 5 <[email protected]>
hilljessica8787-dot
approved these changes
Jul 14, 2026
hilljessica8787-dot
approved these changes
Jul 14, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prevents stuck EVM swap settlements when the network base fee exceeds the server-assigned fee rate (the tx's gas fee cap).
Two commits: the first refuses to broadcast an unminable swap tx, leaving the nonce unspent so core can retry. The second improves on refusal: raise the fee cap to 2*baseFee funds permitting (the same rescue Redeem already uses; a higher cap is protocol-legal since ValidateFeeRate only enforces a floor), refusing only when balance cannot cover a minable cap. Applies to all EVM-family wallets (eth, polygon).
This is also the client-side prerequisite for live server fee-rate assignment (#3616).
Related issue #3608