[dependabot]

Bumps the lifi-depts group with 5 updates in the / directory:

Package	From	To
@bigmi/client	0.9.0	0.10.5
@lifi/sdk	4.1.0	4.12.0
@lifi/sdk-provider-bitcoin	4.0.2	4.1.1
@lifi/sdk-provider-ethereum	4.0.3	4.2.8
@lifi/sdk-provider-solana	4.0.2	4.3.5

Updates @bigmi/client from 0.9.0 to 0.10.5

Release notes

Sourced from @​bigmi/client's releases.

@​bigmi/client@​0.10.5

Patch Changes

• Updated dependencies [5b52eb3, 5b52eb3]:
  • @​bigmi/core@​0.9.3

@​bigmi/client@​0.10.4

Patch Changes

• #80 c3bff6a Thanks @​chybisov! - Detect Binance when window.binancew3w carries no bitcoin provider but window.unisat reports isBinance. The check returned early on binancew3w alone, so that build fell through and Binance was reported unavailable.

• #80 c3bff6a Thanks @​chybisov! - Clear a connection even when the connector's disconnect() throws. xverse, oyl and leather throw ProviderNotFoundError once their provider is gone, which skipped the delete and left the connection to be promoted to current — so the store still reported an account that could never sign, and the next disconnect failed too. The state is now consistent and the error still reaches the caller. The connector's own storage shim is cleared on that path too, so the store and storage cannot disagree and a later reconnect cannot silently restore what the user disconnected.

• #80 c3bff6a Thanks @​chybisov! - Stop MetaMask Bitcoin from opening the extension on page load. connect() ignored the isReconnecting flag and read accounts through the interactive bitcoin:connect, so reconnect() prompted a returning user whose wallet was locked. It now reads the session the wallet already restored, matching unisat, okx, binance, bitget and onekey.

  The wallet fills its accounts from a session lookup it does not await, so that read is polled briefly rather than taken as a first snapshot — otherwise a wallet that registers after the app mounts reports no session and never recovers. An absent session now rejects with ConnectorNotConnectedError instead of UserRejectedRequestError, since nothing was shown to the user.

  isAuthorized() deliberately gates on the storage shim and the wallet's presence, not on its accounts: the wallet fills its accounts from a lookup it does not await, so reading them there would race the restore, report false on every reload and skip reconnect entirely. connect({ isReconnecting: true }) is what waits for the session and rejects when it never arrives. A failure while reconnecting keeps its own error type rather than becoming UserRejectedRequestError, and an account that cannot be parsed is skipped instead of ending the poll.

  A change event no longer throws out of MetaMask's emitter when one account cannot be parsed, and a batch where nothing parses is treated as the transient half-initialized state rather than a disconnect, and a selection that leaves no payment address now disconnects instead of reporting a connected wallet with no usable address. The connected shim is cleared when the wallet itself disconnects, so revoking the site inside MetaMask is not retried on every load.

  An empty selection — a user with no Bitcoin account — now rejects with ConnectorNotConnectedError on the interactive path too, rather than a TypeError relabelled as a rejection. A reconnect that finds no session keeps the connected shim, because the poll cannot tell an absent session from a wallet that has not answered yet and dropping it would permanently sign out a user whose session is valid; a genuine revoke still clears it through onDisconnect. Only the interactive bitcoin:connect maps to UserRejectedRequestError, so a blocked storage write no longer reports a successful connect as a rejection, and onDisconnect releases the events subscription so a later connect rebinds to the current wallet object.

@​bigmi/client@​0.10.3

Patch Changes

• #77 381ec46 Thanks @​chybisov! - Detect BitKeep when it injects only as window.unisat with isBitKeep, not just as window.bitkeep.
• Updated dependencies [381ec46]:
  • @​bigmi/core@​0.9.2

@​bigmi/client@​0.10.2

Patch Changes

• #75 c9f3cd2 Thanks @​chybisov! - Bump runtime dependencies: bitcoinjs-lib 7.0.1 → 7.0.2 and zustand 5.0.14 → 5.0.15.

  @noble/hashes stays on ^1.8.0 on purpose. bitcoinjs-lib@7.0.2 and bs58check@4.0.0 both declare @noble/hashes: ^1.2.0, so moving @bigmi/core to v2 would put two copies of the library in every consumer's tree. v2 is also ESM-only and drops the ./sha256, ./sha1 and ./ripemd160 subpaths that bitcoinjs-lib imports, so an overrides pin to v2 would break it at runtime. Revisit once bitcoinjs-lib widens its range.

• Updated dependencies [c9f3cd2]:

  • @​bigmi/core@​0.9.1

@​bigmi/client@​0.10.1

Patch Changes

• #67 3532b51 Thanks @​arentant! - Prevent UniSat reconnect from opening the extension popup on page load.

• #70 f427391 Thanks @​chybisov! - Stop the Binance, Bitget, OKX and OneKey connectors from opening their wallet extension on page load. connect() now honours isReconnecting and verifies authorization through passive getAccounts() access, matching the UniSat, Xverse and Unhosted connectors. Bitget and OKX additionally confirm the extension still exposes an account instead of trusting the connected storage shim alone, and getAccounts() returns an empty list rather than throwing when no account is exposed. All five connectors now report an account-less extension as ConnectorNotConnectedError instead of mislabelling it a user rejection: the try wraps only requestAccounts(), the one step a user can actually reject. This also fixes OKX persisting a disconnected shim — and so silently disabling its own auto-reconnect for good — when a reconnect found no accounts.

... (truncated)

Changelog

Sourced from @​bigmi/client's changelog.

0.10.5

Patch Changes

• Updated dependencies [5b52eb3, 5b52eb3]:
  • @​bigmi/core@​0.9.3

0.10.4

Patch Changes

• #80 c3bff6a Thanks @​chybisov! - Detect Binance when window.binancew3w carries no bitcoin provider but window.unisat reports isBinance. The check returned early on binancew3w alone, so that build fell through and Binance was reported unavailable.

• #80 c3bff6a Thanks @​chybisov! - Clear a connection even when the connector's disconnect() throws. xverse, oyl and leather throw ProviderNotFoundError once their provider is gone, which skipped the delete and left the connection to be promoted to current — so the store still reported an account that could never sign, and the next disconnect failed too. The state is now consistent and the error still reaches the caller. The connector's own storage shim is cleared on that path too, so the store and storage cannot disagree and a later reconnect cannot silently restore what the user disconnected.

• #80 c3bff6a Thanks @​chybisov! - Stop MetaMask Bitcoin from opening the extension on page load. connect() ignored the isReconnecting flag and read accounts through the interactive bitcoin:connect, so reconnect() prompted a returning user whose wallet was locked. It now reads the session the wallet already restored, matching unisat, okx, binance, bitget and onekey.

  The wallet fills its accounts from a session lookup it does not await, so that read is polled briefly rather than taken as a first snapshot — otherwise a wallet that registers after the app mounts reports no session and never recovers. An absent session now rejects with ConnectorNotConnectedError instead of UserRejectedRequestError, since nothing was shown to the user.

  isAuthorized() deliberately gates on the storage shim and the wallet's presence, not on its accounts: the wallet fills its accounts from a lookup it does not await, so reading them there would race the restore, report false on every reload and skip reconnect entirely. connect({ isReconnecting: true }) is what waits for the session and rejects when it never arrives. A failure while reconnecting keeps its own error type rather than becoming UserRejectedRequestError, and an account that cannot be parsed is skipped instead of ending the poll.

  A change event no longer throws out of MetaMask's emitter when one account cannot be parsed, and a batch where nothing parses is treated as the transient half-initialized state rather than a disconnect, and a selection that leaves no payment address now disconnects instead of reporting a connected wallet with no usable address. The connected shim is cleared when the wallet itself disconnects, so revoking the site inside MetaMask is not retried on every load.

  An empty selection — a user with no Bitcoin account — now rejects with ConnectorNotConnectedError on the interactive path too, rather than a TypeError relabelled as a rejection. A reconnect that finds no session keeps the connected shim, because the poll cannot tell an absent session from a wallet that has not answered yet and dropping it would permanently sign out a user whose session is valid; a genuine revoke still clears it through onDisconnect. Only the interactive bitcoin:connect maps to UserRejectedRequestError, so a blocked storage write no longer reports a successful connect as a rejection, and onDisconnect releases the events subscription so a later connect rebinds to the current wallet object.

0.10.3

Patch Changes

• #77 381ec46 Thanks @​chybisov! - Detect BitKeep when it injects only as window.unisat with isBitKeep, not just as window.bitkeep.
• Updated dependencies [381ec46]:
  • @​bigmi/core@​0.9.2

0.10.2

Patch Changes

• #75 c9f3cd2 Thanks @​chybisov! - Bump runtime dependencies: bitcoinjs-lib 7.0.1 → 7.0.2 and zustand 5.0.14 → 5.0.15.

  @noble/hashes stays on ^1.8.0 on purpose. bitcoinjs-lib@7.0.2 and bs58check@4.0.0 both declare @noble/hashes: ^1.2.0, so moving @bigmi/core to v2 would put two copies of the library in every consumer's tree. v2 is also ESM-only and drops the ./sha256, ./sha1 and ./ripemd160 subpaths that bitcoinjs-lib imports, so an overrides pin to v2 would break it at runtime. Revisit once bitcoinjs-lib widens its range.

• Updated dependencies [c9f3cd2]:

  • @​bigmi/core@​0.9.1

0.10.1

Patch Changes

... (truncated)

Commits

• 18dbf83 chore: version packages (#84)
• f5b3e9f chore(deps): bump dependencies and pinned GitHub Actions (#83)
• b657acc chore: version packages (#81)
• c3bff6a fix(client): Bitcoin connector detection and reconnect correctness (#80)
• dfddc8e chore: version packages (#78)
• 2ea6684 chore(deps): bump dependencies and pinned GitHub Actions (#79)
• 381ec46 fix: Bitcoin connector detection and user-rejection mapping (#77)
• 783a785 chore: version packages (#76)
• c9f3cd2 chore(deps): bump dependencies, regen lockfile, move to pnpm 12 (#75)
• 7144e14 chore(deps): bump dependencies and migrate Changesets to v3 (#73)
• Additional commits viewable in compare view

Updates @lifi/sdk from 4.1.0 to 4.12.0

Release notes

Sourced from @​lifi/sdk's releases.

@​lifi/sdk@​4.12.0

Minor Changes

• #514 5dc9cc5 Thanks @​chybisov! - LiFiErrorCode has a new code, CallBundleNotFound (1028). A step fails with this code when the wallet has no record of an EIP-5792 bundle. The SDK uses it only when it cannot prove that the wallet did not send the bundle. The outcome stays unknown: the action keeps the bundle id, and a resume waits for the bundle again and does not sign.

  ExecutionAction has a new optional field, callCount. It is the number of calls of a batched (EIP-5792) transaction. The Ethereum provider sets it together with taskId for a batched transaction.

@​lifi/sdk@​4.11.0

Minor Changes

• #492 48af3ae Thanks @​chybisov! - SDKProvider.isAddress accepts an optional chainId. Without it, a provider answers as before. With it, a provider whose chains use different address formats accepts only that chain's format and refuses a chain it does not know. A provider must never forward the chain ID to a library function whose second parameter means something else. A custom provider that assigns such a function directly as isAddress, for example viem's isAddress or bigmi's isUTXOAddress, no longer type-checks; wrap it in a one-argument function, as EthereumProvider and BitcoinProvider do.

  A provider can declare the chainIds it serves, so a chain-specific provider can sit beside the generic provider of the same chain type. client.getProvider(type, chainId?) returns the provider that lists the chain, otherwise the provider of that type that lists no chains; getProvider(type) answers as before. The new findProvider(providers, chainType, chainId?) applies the same rule to any provider list. setProviders replaces only a provider with the same type and the same chainIds.

• #507 14f4ecc Thanks @​chybisov! - Never sign a second transaction on resume while the first one may still land.

  • prepareRestart keeps a FAILED action with an unknown outcome and re-checks it on chain. Only a final outcome is dropped, so "Try again" signs anew.
  • After stopRouteExecution, updateRouteHook can still be called for a route whose task was running, but only for a write that changes txHash, txHex, taskId or txFinal. An integrator that deleted the route should ignore that call. An error the hook throws in such a late call does not reach the run; in development it is logged with console.debug. If a new execution of the same route is running, a late transaction that may still land is merged into its action instead, so it does not sign again unless its wallet call has already started. If a newer execution already ended, the late transaction is merged into the route of the last ended execution, and that execution's updateRouteHook is called.
  • The new ExecutionAction.txFinal flags a final outcome.
  • TransactionError takes a new final option. Every TransactionError now has an own final property (false unless set), which changes its JSON shape.
  • resumeRoute no longer mutates the route it is given. A restart keeps execution.signedAt while a transaction is open.
  • In the EVM relayed lane and in the Solana, Sui, Tron, Bitcoin and Stellar providers, the SDK sends the transaction and checks the action again after the wallet returns. A prompt that was already open can still be signed, but when the late transaction merged first, those bytes are never sent or stored. A caught merge makes the newer run fail with TransactionConflict, and "Try again" then resumes and waits for the transaction. A step that asks for a replay (ExecuteStepRetryError) after such a merge also fails with TransactionConflict.
  • An older run no longer stops or ends a newer execution of the same route.
  • After stopRouteExecution, a run that waits for /status stops polling. Before, it polled every few seconds until the API answered DONE, and forever on FAILED, INVALID, NOT_FOUND or HTTP/network errors. The wait ends at once without a write to the route, so the step stays PENDING, and the run's executeRoute promise resolves with the route. A resume waits for the outcome of the same transaction.
  • A stop during the first attempt of a step that then asks for a replay (ExecuteStepRetryError) also ends the run. The step does not run again, so the replay's re-quote, chain reads and integrator callbacks do not run after the stop, and executeRoute resolves with the route.
  • waitForResult and StepExecutor.executeStep take an optional signal. Provider authors get it as StepExecutorBaseContext.signal, which aborts on stopRouteExecution. Give it only to a wait that starts after the transaction is broadcast, never to a sign, send or wallet call.
  • New hasOpenTransaction. assertNoOpenTransaction, isKnownToStatusApi, isFinalTransactionError, isResendAllowed, isOldEnoughToDrop, CLEARED_TRANSACTION_FIELDS, MAX_RESEND_AGE_MS, DROPPED_FALLBACK_AGE_MS and CLOCK_SKEW_MARGIN_MS are exported for provider packages; they are not part of the integrator API (@internal).
  • Remaining limits:
    • In the lanes where the SDK sends, if the newer prompt is approved before the older run stores its transaction (in the EVM relayed lane, before the older run's relay request returns), nothing is merged yet, and both transactions can be sent.
    • In the EVM standard and batched lanes the wallet sends, so a wallet call that has already started can still send a second transaction.
    • A FAILED route from before the upgrade, or one resumed after node history no longer covers its signing time, can stay unknown. The exit is to delete the route.

Patch Changes

• #510 bb964c0 Thanks @​chybisov! - Bump runtime dependencies: viem to 2.57.3, @​stellar/stellar-sdk to 17.2.1, @​mysten/sui to 2.35.0, @​lifi/types to 18.13.0 and @​bigmi/core to 0.9.3.

@​lifi/sdk@​4.10.0

Minor Changes

• #499 2d60ab4 Thanks @​chybisov! - sleep takes an optional { signal }. It rejects with the abort reason as soon as the signal aborts.

Patch Changes

• #496 dcbbdcc Thanks @​chybisov! - Bump the @lifi/types pin to ^18.12.1, which adds slippageScope and the route-wide slippage commitment types.

• #499 2d60ab4 Thanks @​chybisov! - Stop the balance check's retry loop once its 10 s timeout rejects, so a late balance read can no longer change step.action.fromAmount.

• #499 2d60ab4 Thanks @​chybisov! - LruMap now evicts the least recently used entry instead of the oldest one, and no longer grows past its size on iOS 18.

... (truncated)

Changelog

Sourced from @​lifi/sdk's changelog.

4.12.0

Minor Changes

• #514 5dc9cc5 Thanks @​chybisov! - LiFiErrorCode has a new code, CallBundleNotFound (1028). A step fails with this code when the wallet has no record of an EIP-5792 bundle. The SDK uses it only when it cannot prove that the wallet did not send the bundle. The outcome stays unknown: the action keeps the bundle id, and a resume waits for the bundle again and does not sign.

  ExecutionAction has a new optional field, callCount. It is the number of calls of a batched (EIP-5792) transaction. The Ethereum provider sets it together with taskId for a batched transaction.

4.11.0

Minor Changes

• #492 48af3ae Thanks @​chybisov! - SDKProvider.isAddress accepts an optional chainId. Without it, a provider answers as before. With it, a provider whose chains use different address formats accepts only that chain's format and refuses a chain it does not know. A provider must never forward the chain ID to a library function whose second parameter means something else. A custom provider that assigns such a function directly as isAddress, for example viem's isAddress or bigmi's isUTXOAddress, no longer type-checks; wrap it in a one-argument function, as EthereumProvider and BitcoinProvider do.

  A provider can declare the chainIds it serves, so a chain-specific provider can sit beside the generic provider of the same chain type. client.getProvider(type, chainId?) returns the provider that lists the chain, otherwise the provider of that type that lists no chains; getProvider(type) answers as before. The new findProvider(providers, chainType, chainId?) applies the same rule to any provider list. setProviders replaces only a provider with the same type and the same chainIds.

• #507 14f4ecc Thanks @​chybisov! - Never sign a second transaction on resume while the first one may still land.

  • prepareRestart keeps a FAILED action with an unknown outcome and re-checks it on chain. Only a final outcome is dropped, so "Try again" signs anew.
  • After stopRouteExecution, updateRouteHook can still be called for a route whose task was running, but only for a write that changes txHash, txHex, taskId or txFinal. An integrator that deleted the route should ignore that call. An error the hook throws in such a late call does not reach the run; in development it is logged with console.debug. If a new execution of the same route is running, a late transaction that may still land is merged into its action instead, so it does not sign again unless its wallet call has already started. If a newer execution already ended, the late transaction is merged into the route of the last ended execution, and that execution's updateRouteHook is called.
  • The new ExecutionAction.txFinal flags a final outcome.
  • TransactionError takes a new final option. Every TransactionError now has an own final property (false unless set), which changes its JSON shape.
  • resumeRoute no longer mutates the route it is given. A restart keeps execution.signedAt while a transaction is open.
  • In the EVM relayed lane and in the Solana, Sui, Tron, Bitcoin and Stellar providers, the SDK sends the transaction and checks the action again after the wallet returns. A prompt that was already open can still be signed, but when the late transaction merged first, those bytes are never sent or stored. A caught merge makes the newer run fail with TransactionConflict, and "Try again" then resumes and waits for the transaction. A step that asks for a replay (ExecuteStepRetryError) after such a merge also fails with TransactionConflict.
  • An older run no longer stops or ends a newer execution of the same route.
  • After stopRouteExecution, a run that waits for /status stops polling. Before, it polled every few seconds until the API answered DONE, and forever on FAILED, INVALID, NOT_FOUND or HTTP/network errors. The wait ends at once without a write to the route, so the step stays PENDING, and the run's executeRoute promise resolves with the route. A resume waits for the outcome of the same transaction.
  • A stop during the first attempt of a step that then asks for a replay (ExecuteStepRetryError) also ends the run. The step does not run again, so the replay's re-quote, chain reads and integrator callbacks do not run after the stop, and executeRoute resolves with the route.
  • waitForResult and StepExecutor.executeStep take an optional signal. Provider authors get it as StepExecutorBaseContext.signal, which aborts on stopRouteExecution. Give it only to a wait that starts after the transaction is broadcast, never to a sign, send or wallet call.
  • New hasOpenTransaction. assertNoOpenTransaction, isKnownToStatusApi, isFinalTransactionError, isResendAllowed, isOldEnoughToDrop, CLEARED_TRANSACTION_FIELDS, MAX_RESEND_AGE_MS, DROPPED_FALLBACK_AGE_MS and CLOCK_SKEW_MARGIN_MS are exported for provider packages; they are not part of the integrator API (@internal).
  • Remaining limits:
    • In the lanes where the SDK sends, if the newer prompt is approved before the older run stores its transaction (in the EVM relayed lane, before the older run's relay request returns), nothing is merged yet, and both transactions can be sent.
    • In the EVM standard and batched lanes the wallet sends, so a wallet call that has already started can still send a second transaction.
    • A FAILED route from before the upgrade, or one resumed after node history no longer covers its signing time, can stay unknown. The exit is to delete the route.

Patch Changes

• #510 bb964c0 Thanks @​chybisov! - Bump runtime dependencies: viem to 2.57.3, @​stellar/stellar-sdk to 17.2.1, @​mysten/sui to 2.35.0, @​lifi/types to 18.13.0 and @​bigmi/core to 0.9.3.

4.10.0

Minor Changes

• #499 2d60ab4 Thanks @​chybisov! - sleep takes an optional { signal }. It rejects with the abort reason as soon as the signal aborts.

Patch Changes

• #496 dcbbdcc Thanks @​chybisov! - Bump the @lifi/types pin to ^18.12.1, which adds slippageScope and the route-wide slippage commitment types.

... (truncated)

Commits

• 05ddf90 chore: version packages (#515)
• 5dc9cc5 fix(ethereum): sign again after a wallet drops a rejected call bundle (JUMEMB...
• e120c8e chore: version packages (#508)
• 14f4ecc fix: resume a signed transaction instead of signing it again (JUMEMB-79) (#507)
• bb964c0 chore: bump packages and pinned GitHub Actions (#510)
• 48af3ae feat(sdk): validate an address against its destination chain, starting with Z...
• 6ffd1be chore: bump packages (#500)
• 8065041 chore: version packages (#497)
• 2d60ab4 feat(sdk): add an abort signal to sleep and fix the unit, cache and timeout h...
• dcbbdcc chore: bump packages (#496)
• Additional commits viewable in compare view

Updates @lifi/sdk-provider-bitcoin from 4.0.2 to 4.1.1

Release notes

Sourced from @​lifi/sdk-provider-bitcoin's releases.

@​lifi/sdk-provider-bitcoin@​4.1.1

Patch Changes

• Updated dependencies [5dc9cc5]:
  • @​lifi/sdk@​4.12.0

@​lifi/sdk-provider-bitcoin@​4.1.0

Minor Changes

• #492 48af3ae Thanks @​chybisov! - BitcoinProvider.isAddress(address, chainId) refuses every UTXO chain other than BTC, so a Bitcoin address never passes as the receiver of a chain whose format the provider does not know; ZEC receivers are validated by @lifi/sdk-provider-zcash. getBitcoinBalance leaves the amount of a non-BTC token unknown instead of reporting the Bitcoin balance for it. isBitcoinProvider no longer matches another UTXO provider, such as ZcashProvider.

Patch Changes

• #507 14f4ecc Thanks @​chybisov! - Require @bigmi/core 0.9.3, which fixes waitForTransaction. A wait whose block budget ran out no longer stops the shared block watcher, so a resumed Bitcoin route, and every later wait on the same client, can no longer wait forever. Finished waits release their observers and timers. A transaction that a lagging node still reports as unconfirmed is no longer reported as its own replacement, and a replacement is always compared with the awaited transaction, so a fee bump of a cancel is still reported as cancelled.

• #510 bb964c0 Thanks @​chybisov! - Bump runtime dependencies: viem to 2.57.3, @​stellar/stellar-sdk to 17.2.1, @​mysten/sui to 2.35.0, @​lifi/types to 18.13.0 and @​bigmi/core to 0.9.3.

• #507 14f4ecc Thanks @​chybisov! - Mark a cancelled replacement as final so "Try again" signs a new transaction; any other failure after broadcast is re-checked instead. The sign task refuses to sign while the step has an open transaction. It checks the action again after the wallet returns: if a stopped run's transaction merged into it while the prompt was open, the step fails with TransactionConflict and the new signature is neither stored nor sent. The signed transaction (txHex, txHash, signedAt) is now stored before it is sent, so a reload during the send resumes it instead of signing again. A first send that every configured node refuses for a reason that proves none of them holds it (bytes that do not decode, consensus or standardness rules, a fee above the cap or below the floor, or a full mempool), and that no node knows by txid, clears it, so "Try again" signs anew; any other send failure is re-checked, and the stored transaction is resent on a resume (a reload or "Try again") only within two minutes of signing. If the first send's outcome stays unknown and no resend happens within two minutes of signing, a resume only waits; the wait ends after about ten blocks with an error that is not final, and the exit is to delete the route.

• Updated dependencies [bb964c0, 48af3ae, 14f4ecc]:

  • @​lifi/sdk@​4.11.0

@​lifi/sdk-provider-bitcoin@​4.0.16

Patch Changes

• #505 56f9913 Thanks @​chybisov! - Pick the first pipeline task by class reference instead of by class name. In builds that mangle class names, a step could start or resume at the wrong task — for example, an unneeded approve() before a native-token swap.

@​lifi/sdk-provider-bitcoin@​4.0.15

Patch Changes

• Updated dependencies [dcbbdcc, 2d60ab4, 2d60ab4, 2d60ab4, 2d60ab4, 2d60ab4]:
  • @​lifi/sdk@​4.10.0

@​lifi/sdk-provider-bitcoin@​4.0.14

Patch Changes

• Updated dependencies [a65b003, 9e815bd, 145f2b4]:
  • @​lifi/sdk@​4.9.0

@​lifi/sdk-provider-bitcoin@​4.0.13

Patch Changes

• Updated dependencies [1a7c966, b17e93e]:
  • @​lifi/sdk@​4.8.2

@​lifi/sdk-provider-bitcoin@​4.0.12

Patch Changes

• Updated dependencies [621d410]:
  • @​lifi/sdk@​4.8.1

... (truncated)

Changelog

Sourced from @​lifi/sdk-provider-bitcoin's changelog.

4.1.1

Patch Changes

• Updated dependencies [5dc9cc5]:
  • @​lifi/sdk@​4.12.0

4.1.0

Minor Changes

• #492 48af3ae Thanks @​chybisov! - BitcoinProvider.isAddress(address, chainId) refuses every UTXO chain other than BTC, so a Bitcoin address never passes as the receiver of a chain whose format the provider does not know; ZEC receivers are validated by @lifi/sdk-provider-zcash. getBitcoinBalance leaves the amount of a non-BTC token unknown instead of reporting the Bitcoin balance for it. isBitcoinProvider no longer matches another UTXO provider, such as ZcashProvider.

Patch Changes

• #507 14f4ecc Thanks @​chybisov! - Require @bigmi/core 0.9.3, which fixes waitForTransaction. A wait whose block budget ran out no longer stops the shared block watcher, so a resumed Bitcoin route, and every later wait on the same client, can no longer wait forever. Finished waits release their observers and timers. A transaction that a lagging node still reports as unconfirmed is no longer reported as its own replacement, and a replacement is always compared with the awaited transaction, so a fee bump of a cancel is still reported as cancelled.

• #510 bb964c0 Thanks @​chybisov! - Bump runtime dependencies: viem to 2.57.3, @​stellar/stellar-sdk to 17.2.1, @​mysten/sui to 2.35.0, @​lifi/types to 18.13.0 and @​bigmi/core to 0.9.3.

• #507 14f4ecc Thanks @​chybisov! - Mark a cancelled replacement as final so "Try again" signs a new transaction; any other failure after broadcast is re-checked instead. The sign task refuses to sign while the step has an open transaction. It checks the action again after the wallet returns: if a stopped run's transaction merged into it while the prompt was open, the step fails with TransactionConflict and the new signature is neither stored nor sent. The signed transaction (txHex, txHash, signedAt) is now stored before it is sent, so a reload during the send resumes it instead of signing again. A first send that every configured node refuses for a reason that proves none of them holds it (bytes that do not decode, consensus or standardness rules, a fee above the cap or below the floor, or a full mempool), and that no node knows by txid, clears it, so "Try again" signs anew; any other send failure is re-checked, and the stored transaction is resent on a resume (a reload or "Try again") only within two minutes of signing. If the first send's outcome stays unknown and no resend happens within two minutes of signing, a resume only waits; the wait ends after about ten blocks with an error that is not final, and the exit is to delete the route.

• Updated dependencies [bb964c0, 48af3ae, 14f4ecc]:

  • @​lifi/sdk@​4.11.0

4.0.16

Patch Changes

• #505 56f9913 Thanks @​chybisov! - Pick the first pipeline task by class reference instead of by class name. In builds that mangle class names, a step could start or resume at the wrong task — for example, an unneeded approve() before a native-token swap.

4.0.15

Patch Changes

• Updated dependencies [dcbbdcc, 2d60ab4, 2d60ab4, 2d60ab4, 2d60ab4, 2d60ab4]:
  • @​lifi/sdk@​4.10.0

4.0.14

Patch Changes

• Updated dependencies [a65b003, 9e815bd, 145f2b4]:
  • @​lifi/sdk@​4.9.0

4.0.13

Patch Changes

• Updated dependencies [1a7c966, b17e93e]:
  • @​lifi/sdk@​4.8.2

... (truncated)

Commits

• 05ddf90 chore: version packages (#515)
• e120c8e chore: version packages (#508)
• 14f4ecc fix: resume a signed transaction instead of signing it again (JUMEMB-79) (#507)
• bb964c0 chore: bump packages and pinned GitHub Actions (#510)
• 48af3ae feat(sdk): validate an address against its destination chain, starting with Z...
• 4ee4265 chore: version packages (#506)
• 56f9913 fix: select the first pipeline task by class reference, not by name (JUM-1621...
• 6ffd1be chore: bump packages (#500)
• 8065041 chore: version packages (#497)
• 2d60ab4 feat(sdk): add an abort signal to sleep and fix the unit, cache and timeout h...
• Additional commits viewable in compare view

Updates @lifi/sdk-provider-ethereum from 4.0.3 to 4.2.8

Release notes

Sourced from @​lifi/sdk-provider-ethereum's releases.

@​lifi/sdk-provider-ethereum@​4.2.8

Patch Changes

• #514 5dc9cc5 Thanks @​chybisov! - After a user rejected a single-call EIP-5792 bundle in MetaMask, every "Try again" failed with "This bundle id is unknown". The wallet showed no new prompt. MetaMask returns the bundle id before the user approves the bundle. When the user rejects the bundle, MetaMask removes it.

  Now the SDK uses a new rule for a bundle with one call. If the wallet reports the bundle and then has no record of it in the same wait, the SDK treats the bundle as never sent. The step fails with a final SignatureRejected. The action keeps the bundle id with txFinal: true, so the action is closed, and "Try again" signs a new bundle. The SDK uses this rule only for 10 minutes after signing. Some wallets get the bundle status from a remote service, and that service can forget an old bundle.

  This rule applies only to a bundle with one call. MetaMask returns the id of a bundle with two or more calls only after it sent the bundle. The action stores the number of calls in callCount, so the rule also works after a page reload. A bundle that the SDK stored before this release has no callCount, and the rule does not apply to it.

  One limit stays for a bundle with one call. If the wallet sends it and then loses its record of it within 10 minutes of signing, "Try again" can sign a second bundle. Examples are "Delete activity and nonce data" or "Reset account" in MetaMask, or a remote status service that forgets the bundle.

  When the wallet has no record of the bundle at its first answer, the step fails with the new code LiFiErrorCode.CallBundleNotFound. A page reload after the reject is an example. The step also fails with this code when the rule does not apply. An example is a wallet that loses the bundle 10 minutes or more after signing. The SDK cannot know if the wallet sent this bundle. Thus the action keeps the bundle id, and "Try again" waits for the bundle again and does not sign. A route that is stuck after a reject on @lifi/sdk 4.11.0 fails with CallBundleNotFound on its next "Try again".

  If an "unknown bundle id" error (5730) reaches the error parser from another call, the step also fails with CallBundleNotFound, not with SignatureRejected.

• Updated dependencies [5dc9cc5]:

  • @​lifi/sdk@​4.12.0

@​lifi/sdk-provider-ethereum@​4.2.7

Patch Changes

• #510 bb964c0 Thanks @​chybisov! - Bump runtime dependencies: viem to 2.57.3, @​stellar/stellar-sdk to 17.2.1, @​mysten/sui to 2.35.0, @​lifi/types to 18.13.0 and @​bigmi/core to 0.9.3.

• #509 34ecf9c Thanks @​chybisov! - Concurrent first calls for a chain now share one public client instead of each building one. With fallbackTransportConfig.rank set, each extra client also ran its own transport ranking loop that never stopped.

• #503 c7f1d3b Thanks @​chybisov! - Send the token approval when a step only turns out to be relayed at /stepTransaction. With an EIP-5792 wallet, a step that carries no typed data and no executionType: 'message' at routes time looks batchable, so the allowance tasks prepared the approval for a batch. When /stepTransaction then answered with typed data only, the relayer path ran: a queued approve was dropped without an error while SET_ALLOWANCE read DONE, and an allowance already found sufficient for the batch spender could be the wrong one for the relayed lane, which pulls through Permit2. Prepare now checks whether the work done for the batch still holds in the strategy the re-quote establishes, against the spender the allowance check recorded. If it does not, the step replays once in that strategy, before anything reaches the wallet, and the allowance tasks derive the spender again and send the approve as its own transaction. If the replay's re-quote changes the strategy again, the step fails with TransactionUnprepared, and a wallet that declines the EIP-7702 upgrade during a replay fails the step instead of asking for a second retry.

• #507

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
good-wallet-v2	Ignored	Preview	Aug 4, 2026 10:47am