fix: send native token as value transfer in EIP-5792 batch#27
Open
dawsbot wants to merge 1 commit into
Open
Conversation
The batched (sendCalls) path encoded every selected token as an ERC-20 transfer() call, including the chain's native currency (ETH, MATIC, …), which lives at a pseudo-address (0xeee…) with no transfer() method. That call reverts, and because the batch is atomic, it takes every other transfer down with it. The sequential fallback was already fixed in b875374 to move the native token with a plain value transfer and a gas reserve; the batched path was left behind. This applies the equivalent fix by extracting a pure buildTokenCalls() helper that both understands: ERC-20 tokens become encoded transfer() calls, the native token becomes a value transfer to the destination with a 21000×2 gas reserve, and native balances too small to cover gas are skipped and surfaced to the user. Adds unit tests covering ERC-20 encoding, native value transfer, a mixed batch, and the insufficient-gas skip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
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
1 participant
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.
What
The batched (EIP-5792
sendCalls) path incomponents/contract/SendTokens.tsxencoded every selected token as an ERC-20transfer()call — including the chain's native currency (ETH, MATIC, AVAX, …). The native token lives at a pseudo-address (0xeee…) that has notransfer()method, so that call reverts. Because the batch is atomic (forceAtomic: true), one reverting call takes every other transfer down with it.This PR fixes the batched path to move the native token with a plain value transfer to the destination, reserving gas the same way the sequential path does.
Why
The sequential fallback path was already fixed for this exact bug in b875374 ("Send native/default token as a value transfer, not an ERC-20 transfer"), but the batched path was left behind and still constructs a doomed ERC-20 call for the native token. This closes that regression gap so both code paths handle the native token identically.
How
buildTokenCalls()helper (src/build-token-calls.ts):transfer()calls targeting the token contract.{ to: destination, value }value transfer, reservinggasPrice × 21000 × 2for gas (mirrors the sequential path's reserve).sendBatchedTokensnow builds calls via the helper and only marks the actually-sent tokens as pending.src/build-token-calls.test.ts: ERC-20 encoding, native value transfer, a mixed native + ERC-20 batch, and the insufficient-gas skip.Verification
tsc --noEmitcleaneslint .cleanvitest run src/build-token-calls.test.ts— 4/4 passingnext buildsucceeds🤖 Generated with Claude Code