Repository navigation
fix(ethereum): check the allowance when the spender appears at prepare - #521
Merged
Merged
Conversation
…epare /stepTransaction can move estimate.approvalAddress after the allowance tasks approved the routing-time spender (Relay only knows the spender once it builds the executable transaction). The transaction then went out against a spender with no allowance and reverted. A new task after PrepareTransaction reads the allowance for the new spender and resets/sets it only if it falls short. In batched it drops the approval queued for the old spender. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
🦋 Changeset detectedLatest commit: 79f4854 The changes in this PR will be included in the next version bump. This PR includes changesets to release 2 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
📦 Bundle size✅ No significant changes. Every check is within budget. @lifi/sdk
Providers
Full integration
How to read this
|
…repare Narrow the post-prepare allowance task to a step that had no estimate.approvalAddress before prepare and gets one from /stepTransaction. A step that already had a spender behaves as before, even if the re-quote moves it. This lets a provider leave the spender empty at routing time instead of guessing, so the user never approves a wrong contract. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kayanski
marked this pull request as ready for review
October 15, 2026 12:02
Mirror the Ethereum post-prepare allowance task for Tron. A TRC-20 step that had no estimate.approvalAddress before prepare and gets one from /stepTransaction now reads the allowance for it and approves only if it falls short, before the transaction is signed. Relay on Tron only knows its depository spender once it builds the executable transaction. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…it2 chain Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
📦 Preview published under the Install the exact version(s) — npm i @lifi/sdk-provider-ethereum@0.0.0-preview-069261a2
npm i @lifi/sdk-provider-tron@0.0.0-preview-069261a2 |
chybisov
approved these changes
Oct 21, 2026
Merged
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
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.
Which Linear task is linked to this PR?
None yet. Follow-up to JUM-1642 (Relay routes asking users to approve the wrong spender).
Why was it implemented this way?
Some providers, like Relay, only know the ERC-20 spender once
/stepTransactionruns. The allowance tasks run before that, so today the backend has to guess the spender, and a wrong guess makes the transaction revert.Now the backend can leave
estimate.approvalAddressempty at routing time and set it in/stepTransaction. A newEthereumCheckAllowanceAfterPrepareTaskruns after PrepareTransaction, but only when the spender was empty before prepare and is set after it. It reuses the existing allowance tasks (and adds the approval to the batch inbatchedmode).Nothing changes for steps that already have a spender, native permits, Permit2, or steps that skip approval.
Rollout: only send an empty spender to clients on this SDK version. Older versions skip the approval and the transaction reverts.
Visual showcase (Screenshots or Videos)
New
approvalAddressAtPrepare.flow.spec.tscovers: approve needed, allowance already enough, batched, spender moved by the re-quote (unchanged), and no spender at all. Without the new task, the first three fail.Checklist before requesting a review
🤖 Generated with Claude Code