feat: add Stellar (STL) wallet support - #827
Conversation
Introduce @lifi/widget-provider-stellar (Stellar Wallets Kit v2.5.0), the base StellarContext + useSDKProviders wiring, wallet-management integration (useAccount, useCombinedWallets, StellarListItemButton, connect-menu switch), and enable the Stellar ecosystem in the widget wallet providers. Stellar is gated out of the route selector until execution lands. Install-gated wallets (shown only when installed): Freighter, Rabet, Hana, Lobstr, Klever, OneKey, Bitget, and xBull (gated to window.xBullSDK); WalletConnect offered when a project id is configured. Albedo and HOT are excluded (always-on / no install state). Depends on @lifi/sdk-provider-stellar being published; lockfile update follows once it lands on npm.
🦋 Changeset detectedLatest commit: 851052f The changes in this PR will be included in the next version bump. This PR includes changesets to release 28 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 |
|
✅ E2E Dev Smoke — passing
4 passed · 0 failed · 0 skipped · 32s |
E2E Examples — all passedAll examples passed in the latest run. |
Temporarily pin the widget packages' @lifi/sdk and @lifi/sdk-provider-* deps to the sdk#427 preview build (0.0.0-preview-5e098f3) so CI can install and build against the unreleased @lifi/sdk-provider-stellar (its first npm publish). Replace with the real release versions before merge. examples/ + e2e are untouched (they consume the published @lifi/widget). This is the first successful install on the branch, so the lockfile is regenerated (the Stellar subtree was never locked) and 5 native build-script deps pnpm flagged (@stellar/stellar-sdk, secp256k1, tiny-secp256k1, blake-hash, usb) are set to allowBuilds: false, matching the existing browser-bundle convention. Verified: pnpm install --frozen-lockfile, pnpm check:types, and pnpm build all pass.
E2E Playground results
Details
📥 Download full HTML report (open the run → Artifacts → |
Add ChainType.STL to supportedChainTypes in useAvailableChains so the widget requests Stellar chains from getChains and they become available in the route selector. Removes the Phase-1 gate that omitted STL.
Add ChainType.STL to the verified and search token chainTypes in useTokens so getTokens returns Stellar tokens, matching the getChains change.
Stellar wallets are connectable, so the ecosystem switches must cover STL: - useChainTypeFromAddress: detect Stellar addresses via the Stellar provider's isAddress, returning ChainType.STL. - useAccountDisconnect: add the ChainType.STL case so disconnecting a Stellar wallet actually calls the Stellar provider's disconnect instead of silently no-opping.
Add the Stellar entry (ChainType.STL, ChainId.XLM, stellar.svg) to chainTypeIcons so Stellar chains group under the ecosystem avatar instead of falling back to individual chain logos.
The Phase-1 gate was removed earlier in this branch, so the changeset's claim that Stellar is not yet selectable no longer matches the code.
Resolves the merge by taking main's newer pnpm-workspace.yaml (its trimmed
minimumReleaseAgeExclude and overrides) and re-adding only the Stellar-specific
allowBuilds entries: @stellar/stellar-sdk plus the native hardware-wallet deps
the Stellar Wallets Kit's Trezor tree pulls in.
Repins every @lifi/sdk* package to 0.0.0-preview-207d898, which is the first
preview carrying StellarStepExecutor — the previous pin (5e098f3) shipped a
getStepExecutor that throws. All @lifi/sdk* pins must move together: the
provider tarballs hard-pin @lifi/sdk to their own preview version, and a second
copy of @lifi/sdk breaks route execution because executionState is a
module-level singleton. Example pins are deliberately left on published
versions.
Also pins @reown/appkit to an exact 1.8.23 instead of >=1.8.20: the Stellar
Wallets Kit tree otherwise drags in a second appkit minor, and two appkit copies
mean two AppKitNetwork type identities.
Known gap: widget-playground{,-vite} check:types still reports 2 errors in
ReownWalletProvider.tsx. appkit resolves viem under [email protected] while the
widget resolves it under 7.0.2, so AppKitNetwork and the widget's chain objects
are different type identities. Both are private packages and neither ships. A
blanket typescript override fixes it but breaks madge, whose
@typescript-eslint/typescript-estree peer-caps at typescript <6.1.0.
![aikido-pr-checks[bot]](https://avatars.githubusercontent.com/in/898896?s=60&v=4){kind=small}
There was a problem hiding this comment.
CVE-2026-41242 in protobufjs - critical severity
protobufjs compiles protobuf definitions into JavaScript (JS) functions. In versions prior to 8.0.1 and 7.5.5, attackers can inject arbitrary code in the "type" fields of protobuf definitions, which will then execute during object decoding using that definition. Versions 8.0.1 and 7.5.5 patch the issue.
Details
Remediation Aikido suggests bumping this package to version 7.5.5 to resolve this issue
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
| // Module-level singleton — the kit + connection state are shared across the app, | ||
| // mirroring the Solana wallet-standard store. The config from the first mount | ||
| // wins (it is stable for the lifetime of the app). | ||
| let store: StellarWalletsKitStore | undefined |
There was a problem hiding this comment.
Module-level variable 'store' caches mutable store state across imports; avoid request-scoped data in globals or make intentional shared cache explicit.
Details
✨ AI Reasoning
A module-level mutable variable is declared to hold the store singleton and is used to cache the store instance for reuse. This means state (selected wallet, address, connected flag, etc.) can persist across uses of the module. In long-running server processes (Node.js) such globals persist between requests and users, potentially leaking user-specific data or causing race conditions. The pattern creates a shared in-memory singleton rather than request-scoped state.
🔧 How do I fix it?
Avoid storing request-specific data in module-level variables. Use request-scoped variables or explicitly mark shared caches as intentional.
Reply @AikidoSec feedback: [FEEDBACK] to get better review comments in the future.
Reply @AikidoSec ignore: [REASON] to ignore this issue.
More info
…orkspace widget-provider-stellar was the only package declaring typescript ^6.0.3; every sibling declares ^7.0.2. That second typescript in the workspace made pnpm resolve viem twice — once per typescript peer — so @reown/appkit and the widget held different viem type identities and AppKitNetwork stopped accepting the widget's chain objects. check:types failed in widget-playground and widget-playground-vite as a result. viem now resolves to a single snapshot and all 17 packages type-check. This also removes the need for the @reown/appkit exact pin added earlier as a workaround, so pnpm-workspace.yaml overrides are identical to main again — the only remaining diff there is the Stellar allowBuilds entries.
Matches the SDK branch head. The previous pin (207d898) predated the @stellar/stellar-sdk ^16.1.0 range bump, so the published sdk-provider-stellar tarball declared a range the branch no longer used. All seven @lifi/sdk* pins move together, as they must: the provider tarballs hard-pin @lifi/sdk to their own preview version, and a second copy of @lifi/sdk breaks route execution because executionState is a module-level singleton. Verified one copy resolves across widget, widget-provider-stellar and wallet-management. Example pins stay on published versions.
Matches the SDK branch head (lifinance/sdk#427, c3280231), which refines the Stellar approval handling. The previous pin (3a18dab) predated that commit. All seven @lifi/sdk* pins move together, as they must: the provider tarballs hard-pin @lifi/sdk to their own preview version, and a second copy of @lifi/sdk breaks route execution because executionState is a module-level singleton. Verified one copy resolves across widget, widget-provider, widget-provider-stellar and wallet-management. Example pins stay on published versions.
2 participants
🔗 Linear: EMB-463 · Stellar: Add support on widget/SDK
Part of EMB-463 — client-side Stellar support for the widget. Blocked by lifinance/sdk#427 (publish
@lifi/sdk-provider-stellar).What
@lifi/widget-provider-stellarusing Stellar Wallets Kit v2.5.0, baseStellarContext+useSDKProviderswiring, wallet-management integration (useAccount,useCombinedWallets,StellarListItemButton, connect-menu), widget provider enablement, and playground wiring.window.xBullSDK); WalletConnect offered when a project id is configured. Albedo + HOT excluded (always-on / no install state).Verified locally
✅ type-checks across packages; dev playground renders and the connect menu lists the installed Stellar wallets without runtime errors.
Blocked by / notes
@lifi/sdk-provider-stellarfirst — until thenpnpm install/ CI 404s, and the lockfile update follows.