chore: version packages

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and publish to npm yourself or setup this action to publish automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to main, this PR will be updated.

Releases

@lifi/widget@4.9.0

Minor Changes

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• #884 97e59c5 Thanks @chybisov! - New package @lifi/widget-provider-zcash. Add ZcashProvider() to providers to offer ZEC as a destination; without it the widget shows no ZEC, because no ZEC receiver could be validated. With external wallet management the widget ignores providers, so render the component that ZcashProvider() returns around the widget, next to the other ecosystem providers. @lifi/widget-provider exports ZcashContext and useZcashContext, asks the provider that serves a chain for receiver checks, and recognises a Zcash address without a chain, so a Zcash bookmark keeps the Zcash icon.

Patch Changes

• #884 97e59c5 Thanks @chybisov! - A token pick that moves the destination chain, for example from "All networks", now resets a receiver the new chain cannot take, as the chain select already does.

• #896 10d954a Thanks @chybisov! - Update react-i18next to 17.0.16.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update motion to 14.0.0.

• #896 10d954a Thanks @chybisov! - Update @tanstack/react-router to 1.170.41.

• Updated dependencies [10d954a, 10d954a, 97e59c5, 97e59c5]:

  • @lifi/wallet-management@4.3.2
  • @lifi/widget-provider@4.6.0

@lifi/widget-provider@4.6.0

Minor Changes

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• #884 97e59c5 Thanks @chybisov! - New package @lifi/widget-provider-zcash. Add ZcashProvider() to providers to offer ZEC as a destination; without it the widget shows no ZEC, because no ZEC receiver could be validated. With external wallet management the widget ignores providers, so render the component that ZcashProvider() returns around the widget, next to the other ecosystem providers. @lifi/widget-provider exports ZcashContext and useZcashContext, asks the provider that serves a chain for receiver checks, and recognises a Zcash address without a chain, so a Zcash bookmark keeps the Zcash icon.

Patch Changes

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

@lifi/widget-provider-zcash@4.0.0

Minor Changes

• #884 97e59c5 Thanks @chybisov! - New package @lifi/widget-provider-zcash. Add ZcashProvider() to providers to offer ZEC as a destination; without it the widget shows no ZEC, because no ZEC receiver could be validated. With external wallet management the widget ignores providers, so render the component that ZcashProvider() returns around the widget, next to the other ecosystem providers. @lifi/widget-provider exports ZcashContext and useZcashContext, asks the provider that serves a chain for receiver checks, and recognises a Zcash address without a chain, so a Zcash bookmark keeps the Zcash icon.

Patch Changes

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:
  • @lifi/widget-provider@4.6.0

@lifi/wallet-management@4.3.2

Patch Changes

• #896 10d954a Thanks @chybisov! - Update react-i18next to 17.0.16.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-light@4.5.1

Patch Changes

• #896 10d954a Thanks @chybisov! - Raise the optional peer floors to the latest releases: wagmi 3.7.7, @wagmi/core 3.6.5, @bigmi/client 0.10.5, @bigmi/react 0.9.5, @mysten/dapp-kit-react 2.1.39 and @wallet-standard/base 1.1.1.

@lifi/widget-provider-bitcoin@4.3.2

Patch Changes

• #896 10d954a Thanks @chybisov! - Update @bigmi/client to 0.10.5 and @bigmi/core to 0.9.3, and raise the @bigmi/react peer floor to 0.9.5.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-ethereum@4.1.7

Patch Changes

• #896 10d954a Thanks @chybisov! - Raise the wagmi peer floor to 3.7.7 and the @wagmi/core peer floor to 3.6.5.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-solana@4.1.7

Patch Changes

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-stellar@4.2.3

Patch Changes

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #896 10d954a Thanks @chybisov! - Update @creit.tech/stellar-wallets-kit to 2.7.0.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-sui@4.1.7

Patch Changes

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #896 10d954a Thanks @chybisov! - Update @mysten/sui to 2.35.0 and raise the @mysten/dapp-kit-react peer floor to 2.1.39.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-tron@4.1.7

Patch Changes

• #896 10d954a Thanks @chybisov! - Raise the @tronweb3/tronwallet-adapter-react-hooks peer floor to 1.1.14.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update the LI.FI SDK providers to latest: @lifi/sdk-provider-bitcoin 4.1.0, @lifi/sdk-provider-ethereum 4.2.7, @lifi/sdk-provider-solana 4.3.4, @lifi/sdk-provider-stellar 4.3.8, @lifi/sdk-provider-sui 4.2.8 and @lifi/sdk-provider-tron 4.1.7.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget-provider@4.6.0

@lifi/widget-checkout@4.0.6

Patch Changes

• #896 10d954a Thanks @chybisov! - Update react-i18next to 17.0.16.

• #896 10d954a Thanks @chybisov! - Update @lifi/sdk to 4.11.0. A resumed route no longer signs a second transaction while the first one may still land.

• #896 10d954a Thanks @chybisov! - Update motion to 14.0.0.

• #896 10d954a Thanks @chybisov! - Update @tanstack/react-router to 1.170.41.

• #884 97e59c5 Thanks @chybisov! - ZEC is a destination-only chain. It never appears as a source chain or source token, and a fromChain of ZEC from the widget config or the URL is ignored. A ZEC receiver must be a transparent Zcash address (t1… or t3…) or a unified address (u1…) with an Orchard receiver; Sapling, TEX and other unified addresses get a message that names the accepted formats. The address inputs take up to 512 characters, so a unified address fits.

  Receivers are now checked against the destination chain, not only its chain type, so a Bitcoin address no longer passes as a ZEC receiver. A connected Bitcoin wallet is never filled in, offered, seeded or priced as a ZEC receiver, and a BTC → ZEC route asks for a receiver. Bookmarks of other ecosystems still save as before, and a Zcash bookmark shows the Zcash icon. The reverse and swap controls stay hidden while the destination chain is not allowed as a source by chains.from, so they never select a source chain the config excludes.

  @lifi/widget-provider exports useAddressForChain, which returns isAddressForChain(address, chain), and the ChainRef and IsAddressForChain types. Every package that depends on the SDK requires the release whose isAddress accepts a chain ID, so a consumer keeps a single @lifi/sdk. The widget now passes the chain ID to each provider's isAddress, so upgrade the @lifi/widget-provider-* packages together with @lifi/widget: an older @lifi/widget-provider-bitcoin refuses every Bitcoin receiver and hides Bitcoin balances. name and version exported from @lifi/widget stay the widget's own now that @lifi/sdk exports the same names.

• Updated dependencies [97e59c5, 10d954a, 10d954a, 10d954a, 10d954a, 97e59c5, 97e59c5]:

  • @lifi/widget@4.9.0
  • @lifi/wallet-management@4.3.2
  • @lifi/widget-provider@4.6.0
  • @lifi/widget-provider-mesh@4.0.5

@lifi/widget-provider-mesh@4.0.5

Patch Changes

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:
  • @lifi/widget-provider@4.6.0

@lifi/widget-provider-transak@4.0.5

Patch Changes

• Updated dependencies [10d954a, 97e59c5, 97e59c5]:
  • @lifi/widget-provider@4.6.0