Skip to content

feat: adjust dApp configuration for Solana as supported chain id #7525

Open
limitofzero wants to merge 22 commits into
developfrom
feat/use-evm-chains-enum
Open

feat: adjust dApp configuration for Solana as supported chain id #7525
limitofzero wants to merge 22 commits into
developfrom
feat/use-evm-chains-enum

Conversation

@limitofzero
Copy link
Copy Markdown
Contributor

@limitofzero limitofzero commented May 18, 2026

Summary

I've linked cowprotocol/cow-sdk#873 to this pr, so added some additional checks and solana fields in records/maps. Also I removed additional token list updater because all token lists moved in common.

P.S. Please don't pay attention on broken cow.fi, it's affected by invalidated npm token and I can't update it due to restricted permissions. It should work when we publish new cow-sdk version and I link it here

To Test

  1. Check that current functionality not broken
  • Solana tokens should be visible when we select sol as dst network
  • Switching chains is working as expected, balances are loading
  • Solana bridge is working as expected

Summary by CodeRabbit

  • New Features

    • Solana promoted to a supported destination across the app (UI, explorer links, price lookups, token lists, LP/AMM mappings).
  • Bug Fixes

    • Prevented EVM-only balance/multicall queries from running on non-EVM chains.
  • Refactor

    • Unified token-list handling for EVM and Solana; removed legacy additional-chain token-list updater and simplified chain/config mappings.
  • Tests

    • Updated unit tests to align with Solana chain migration.
  • Chores

    • Bumped SDK packages to preview/prerelease versions.

Review Change Stack

@vercel
Copy link
Copy Markdown

vercel Bot commented May 18, 2026

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

Project Deployment Actions Updated (UTC)
cowfi Error Error May 22, 2026 5:48pm
explorer-dev Ready Ready Preview May 22, 2026 5:48pm
storybook Error Error May 22, 2026 5:48pm
swap-dev Ready Ready Preview May 22, 2026 5:48pm
widget-configurator Ready Ready Preview May 22, 2026 5:48pm
2 Skipped Deployments
Project Deployment Actions Updated (UTC)
cosmos Ignored Ignored May 22, 2026 5:48pm
sdk-tools Ignored Ignored Preview May 22, 2026 5:48pm

Request Review

@coderabbitai
Copy link
Copy Markdown
Contributor

coderabbitai Bot commented May 18, 2026

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

  • @coderabbitai resume to resume automatic reviews.
  • @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

  • ▶️ Resume reviews
  • 🔍 Trigger review

Walkthrough

Consolidates Solana support by migrating SOLANA to SupportedChainId, updates many @cowprotocol SDK deps to a prerelease tag, consolidates token-list handling (removes additional-chain updater/state and fetch path), and adds EVM-only gating for EVM-specific flows.

Changes

Solana mainnet support migration

Layer / File(s) Summary
Dependency bumps to prerelease SDKs
apps/*, libs/*
Multiple package.json files updated to *-pr-873-eb1555e3.0 prerelease SDK versions.
Solana chain-id migration, tests, and constants
apps/*, libs/*
Replaced AdditionalTargetChainId.SOLANA usages with SupportedChainId.SOLANA, updated tests and mocks, and added Solana entries to constants (DEFILLAMA, CHAIN_INFO, START_DATE, CHAIN_SPECIFIC_BENEFITS, token maps).
Token-list sanitization and additional-chain removal
libs/tokens/*
Consolidated sanitizer to handle EVM+Solana, removed fetchAdditionalChainTokenList, DEFAULT_ADDITIONAL_CHAIN_TOKENS_LISTS, additional-chain atoms, and the AdditionalChainTokensListsUpdater component and re-exports. Added NearSolana token-list entry to tokensList.json.
EVM gating and utilities
libs/balances-and-allowances/*, libs/common-utils/*, libs/core/*, apps/explorer/*, apps/cowswap-frontend/*
Added isEvmChain gating for multicall/read flows, filtered EVM-only contract address maps, added Solana explorer base path, updated LP page link slugs to include SOLANA keys (empty), and adjusted trust-logo mapping.
Workflow env
.github/workflows/i18n-extract.yml
Adds PACKAGE_READ_AUTH_TOKEN env secret for SDK preview installation.

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

Suggested reviewers

  • elena-zh
  • shoom3301

🐰 I hopped through code with a curious grin,
Swapped chain ids so Solana could join in,
Token lists made tidy, no extra updater dance,
EVM gates closed — non-EVM chains get their chance,
A tiny carrot for tests passing with a spin.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 41.18% which is insufficient. The required threshold is 80.00%. Write docstrings for the functions missing them to satisfy the coverage threshold.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly summarizes the main change: adjusting dApp configuration to treat Solana as a supported chain ID, which aligns with the extensive updates throughout the codebase.
Description check ✅ Passed The description covers the key objectives (linking to cow-sdk PR #873, adding Solana-specific fields, removing token list updater), provides context about cow.fi issues, and includes concrete test items for verification.
Linked Issues check ✅ Passed Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check ✅ Passed Check skipped because no linked issues were found for this pull request.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
📝 Generate docstrings
  • Create stacked PR
  • Commit on current branch
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Commit unit tests in branch feat/use-evm-chains-enum
⚔️ Resolve merge conflicts
  • Resolve merge conflict in branch feat/use-evm-chains-enum

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@cloudflare-workers-and-pages
Copy link
Copy Markdown

cloudflare-workers-and-pages Bot commented May 18, 2026

Deploying swap-dev with  Cloudflare Pages  Cloudflare Pages

Latest commit: 04c1a71
Status:🚫  Build failed.

View logs

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (1)
apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts (1)

16-16: 💤 Low value

Consider adding explanatory comments for consistency.

Lines 33 and 50 include comments noting that Solana isn't supported by those providers, but lines 16 (COW_AMM_CHAINS) and 67 (PANCAKE_CHAINS) have no such comments. Adding comments would improve consistency and make the intent clearer to future maintainers.

💡 Suggested additions
-  [SupportedChainId.SOLANA]: '',
+  [SupportedChainId.SOLANA]: '', // Doesn't support

Also applies to: 67-67

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts` at line 16, Add a
short explanatory comment next to the SupportedChainId.SOLANA entries in the
COW_AMM_CHAINS and PANCAKE_CHAINS maps to match the style used elsewhere; locate
the SupportedChainId.SOLANA key in the COW_AMM_CHAINS constant and the
PANCAKE_CHAINS constant and add a one-line note (e.g., "Solana not supported by
COW AMM" / "Solana not supported by Pancake") explaining why the value is an
empty string for consistency with the comments at lines 33 and 50.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts`:
- Line 50: Fix the typo in the inline comment for SupportedChainId.SOLANA in
lpPageLinks.ts: change "Doesnt'" to the correct "Doesn't" so the comment reads
"Doesn't support" (locate the entry keyed by SupportedChainId.SOLANA in the
lpPageLinks mapping and update the comment only).

---

Nitpick comments:
In `@apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts`:
- Line 16: Add a short explanatory comment next to the SupportedChainId.SOLANA
entries in the COW_AMM_CHAINS and PANCAKE_CHAINS maps to match the style used
elsewhere; locate the SupportedChainId.SOLANA key in the COW_AMM_CHAINS constant
and the PANCAKE_CHAINS constant and add a one-line note (e.g., "Solana not
supported by COW AMM" / "Solana not supported by Pancake") explaining why the
value is an empty string for consistency with the comments at lines 33 and 50.
🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

  • Push a commit to this branch (recommended)
  • Create a new PR with the fixes

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 2dd93acc-f041-451a-b67b-a68f2bcc9397

📥 Commits

Reviewing files that changed from the base of the PR and between 36a3f2d and 04c1a71.

⛔ Files ignored due to path filters (1)
  • pnpm-lock.yaml is excluded by !**/pnpm-lock.yaml
📒 Files selected for processing (6)
  • apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts
  • libs/balances-and-allowances/src/hooks/usePersistBalancesViaWebCalls.ts
  • libs/common-const/src/tokens.ts
  • libs/core/src/gnosisSafe/index.ts
  • libs/tokens/src/hooks/tokens/useTokensByAddressMapForChain.ts
  • libs/tokens/src/state/tokenLists/tokenListsStateAtom.ts
💤 Files with no reviewable changes (4)
  • libs/tokens/src/state/tokenLists/tokenListsStateAtom.ts
  • libs/core/src/gnosisSafe/index.ts
  • libs/tokens/src/hooks/tokens/useTokensByAddressMapForChain.ts
  • libs/common-const/src/tokens.ts

[SupportedChainId.LINEA]: '', // TODO: confirm. This one is actually supported.
[SupportedChainId.PLASMA]: '', // TODO: confirm
[SupportedChainId.INK]: '',
[SupportedChainId.SOLANA]: '', // Doesnt' support
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Fix typo in comment.

The comment has a misplaced apostrophe: "Doesnt'" should be "Doesn't".

📝 Proposed fix
-  [SupportedChainId.SOLANA]: '', // Doesnt' support
+  [SupportedChainId.SOLANA]: '', // Doesn't support
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
[SupportedChainId.SOLANA]: '', // Doesnt' support
[SupportedChainId.SOLANA]: '', // Doesn't support
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts` at line 50, Fix the
typo in the inline comment for SupportedChainId.SOLANA in lpPageLinks.ts: change
"Doesnt'" to the correct "Doesn't" so the comment reads "Doesn't support"
(locate the entry keyed by SupportedChainId.SOLANA in the lpPageLinks mapping
and update the comment only).

Copy link
Copy Markdown
Contributor

@elena-zh elena-zh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @limitofzero , works great!
The only thing that solana tokens images are broken on Explorer:

Image

Could you please take a look at it?

Copy link
Copy Markdown
Contributor

@fairlighteth fairlighteth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AI findings:

  1. High: apps/cowswap-frontend/src/modules/application/containers/App/Updaters.tsx:110 now only fetches token lists for sourceChainId, while apps/cowswap-frontend/src/entities/bridgeProvider/useBridgeSupportedTokens.ts:22 expects destination-chain token lists via useTokensByAddressMapForChain(params?.buyChainId). Since the removed AdditionalChainTokensListsUpdater was the only target-chain fetch path, Solana destination lists/logos will stay empty unless the app is actually on Solana as the source chain. Likely related to Elena’s Explorer comment about broken Solana token images.
  2. Medium: apps/explorer/src/components/common/TokenImg/index.tsx:32 cannot load the new sol native image key from apps/explorer/src/utils/miscellaneous.ts:74: the filename regex does not include sol, and there is no apps/explorer/src/assets/img/tokens/sol.png. Native Solana image fallback resolves to nothing. This is the likely cause of Elena’s screenshot.
  3. Medium: libs/tokens/src/state/tokenLists/tokenListsStateAtom.ts:35 still has CodeRabbit’s valid issue: UNISWAP_TOKEN_LIST_URL[SupportedChainId.SOLANA] is '', but curatedListSourceAtom always returns a list source from it. In curated/widget mode that can propagate { source: '' }, causing fetch('') and a bogus enabled-list key.
  4. Low: libs/core/src/gnosisSafe/index.ts:20 maps Solana to '', so createSafeApiKitInstance(SOLANA) passes the “supported” check and builds https://api.safe.global/tx-service//api/. Prefer omitting Solana or guarding on a truthy Safe network id.

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🧹 Nitpick comments (1)
.github/workflows/i18n-extract.yml (1)

14-18: ⚡ Quick win

Scope PACKAGE_READ_AUTH_TOKEN to the install step instead of workflow-wide env.

This token is only needed for dependency install; narrowing scope reduces accidental exposure across unrelated steps.

Patch suggestion
 env:
   NODE_VERSION: lts/jod
-  # needed by tools/scripts/install-sdk-preview.js when package.json pins a `pr-NNN`
-  # SDK preview build — install:ci writes an .npmrc that auths to GitHub Packages.
-  PACKAGE_READ_AUTH_TOKEN: ${{ secrets.PACKAGE_READ_AUTH_TOKEN }}
+  # needed by tools/scripts/install-sdk-preview.js when package.json pins a `pr-NNN`
+  # SDK preview build — install:ci writes an .npmrc that auths to GitHub Packages.
@@
       - name: Install dependencies
+        env:
+          PACKAGE_READ_AUTH_TOKEN: ${{ secrets.PACKAGE_READ_AUTH_TOKEN }}
         run: pnpm run install:ci --frozen-lockfile
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.github/workflows/i18n-extract.yml around lines 14 - 18, The
PACKAGE_READ_AUTH_TOKEN environment variable is declared at workflow-level under
env: but is only needed during the dependency install step; remove
PACKAGE_READ_AUTH_TOKEN from the top-level env block and add it to the install
step's env instead (the step that runs npm install / yarn install or the script
that invokes tools/scripts/install-sdk-preview.js) so only that step receives
PACKAGE_READ_AUTH_TOKEN; use the same secret reference (${ {
secrets.PACKAGE_READ_AUTH_TOKEN } }) when adding it to that step's env to
preserve functionality.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In @.github/workflows/i18n-extract.yml:
- Around line 14-18: The PACKAGE_READ_AUTH_TOKEN environment variable is
declared at workflow-level under env: but is only needed during the dependency
install step; remove PACKAGE_READ_AUTH_TOKEN from the top-level env block and
add it to the install step's env instead (the step that runs npm install / yarn
install or the script that invokes tools/scripts/install-sdk-preview.js) so only
that step receives PACKAGE_READ_AUTH_TOKEN; use the same secret reference (${ {
secrets.PACKAGE_READ_AUTH_TOKEN } }) when adding it to that step's env to
preserve functionality.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 5fa08b0b-05d6-48c7-a27e-9b841bc3fe4a

📥 Commits

Reviewing files that changed from the base of the PR and between 04c1a71 and 848c6ee.

📒 Files selected for processing (2)
  • .github/workflows/i18n-extract.yml
  • apps/explorer/src/modules/bridge/hooks/useBridgeProviderBuyTokens.ts

@limitofzero
Copy link
Copy Markdown
Contributor Author

@fairlighteth

  1. no, we support loading token lists for dst chain in bridge mode, I configured it and it works, issue in explorer has another cause
  2. fixed
  3. fixed

@limitofzero
Copy link
Copy Markdown
Contributor Author

@elena-zh thank you, nice catch! fixed

Copy link
Copy Markdown
Contributor

@coderabbitai coderabbitai Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)
libs/core/src/gnosisSafe/index.ts (2)

90-94: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Add guard for non-EVM chains.

getSafeWebUrl has the same issue as getSafeAccountUrl: it accepts any SupportedChainId (including non-EVM chains like Solana) but constructs a Gnosis Safe transaction URL. This produces semantically incorrect URLs for non-EVM chains where Safe doesn't exist.

🛡️ Proposed fix
 export function getSafeWebUrl(chainId: SupportedChainId, safeAddress: string, safeTxHash: string): string {
+  if (!(chainId in SAFE_API_NETWORK_ID)) {
+    throw new Error(`Gnosis Safe is not supported for chain ${chainId}`)
+  }
   const chainShortName = CHAIN_INFO[chainId].addressPrefix

   return `${SAFE_BASE_URL}/${chainShortName}:${safeAddress}/transactions/tx?id=multisig_${safeAddress}_${safeTxHash}`
 }
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/src/gnosisSafe/index.ts` around lines 90 - 94, getSafeWebUrl
currently builds a Gnosis Safe tx URL for any SupportedChainId (using CHAIN_INFO
and SAFE_BASE_URL) which yields invalid URLs for non‑EVM chains; update
getSafeWebUrl to first guard that the provided chainId supports EVM/Gnosis Safe
(e.g. check a boolean like CHAIN_INFO[chainId].isEvm or ensure
CHAIN_INFO[chainId].addressPrefix corresponds to an EVM chain) and if not,
either throw a clear error or return an empty/undefined value consistent with
getSafeAccountUrl behavior; reference the function name getSafeWebUrl, the
CHAIN_INFO lookup, SupportedChainId type and SAFE_BASE_URL when making the
change.

63-67: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Avoid generating Gnosis Safe app URLs for non-EVM chains in getSafeAccountUrl.

getSafeAccountUrl (libs/core/src/gnosisSafe/index.ts, lines 63-67) accepts SupportedChainId and always builds a Safe URL from CHAIN_INFO[chainId].addressPrefix. SAFE_API_NETWORK_ID is already used to gate Safe API instantiation for EVM chains, but getSafeAccountUrl has no equivalent guard—so for non-EVM chains like SupportedChainId.SOLANA (which exists in CHAIN_INFO), it can generate an invalid/broken “safe app” link.

Align getSafeAccountUrl (and the same pattern in getSafeWebUrl) with the SAFE_API_NETWORK_ID EVM-only guard and avoid rendering a Safe link for unsupported chains (e.g., return ''/undefined or narrow the input type), rather than constructing a URL unconditionally.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@libs/core/src/gnosisSafe/index.ts` around lines 63 - 67, getSafeAccountUrl
currently builds a Safe app URL for any chain using
CHAIN_INFO[chainId].addressPrefix; update it (and the analogous getSafeWebUrl)
to first check that the chain is an EVM-supported network (use
SAFE_API_NETWORK_ID or a helper that verifies EVM-only support) and return an
empty string (or undefined) for unsupported/non-EVM chains instead of
constructing `${SAFE_BASE_URL}/${chainShortName}:${safeAddress}`; reference
getSafeAccountUrl, getSafeWebUrl, CHAIN_INFO, SAFE_BASE_URL and
SAFE_API_NETWORK_ID when making this guard.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@libs/core/src/gnosisSafe/index.ts`:
- Around line 90-94: getSafeWebUrl currently builds a Gnosis Safe tx URL for any
SupportedChainId (using CHAIN_INFO and SAFE_BASE_URL) which yields invalid URLs
for non‑EVM chains; update getSafeWebUrl to first guard that the provided
chainId supports EVM/Gnosis Safe (e.g. check a boolean like
CHAIN_INFO[chainId].isEvm or ensure CHAIN_INFO[chainId].addressPrefix
corresponds to an EVM chain) and if not, either throw a clear error or return an
empty/undefined value consistent with getSafeAccountUrl behavior; reference the
function name getSafeWebUrl, the CHAIN_INFO lookup, SupportedChainId type and
SAFE_BASE_URL when making the change.
- Around line 63-67: getSafeAccountUrl currently builds a Safe app URL for any
chain using CHAIN_INFO[chainId].addressPrefix; update it (and the analogous
getSafeWebUrl) to first check that the chain is an EVM-supported network (use
SAFE_API_NETWORK_ID or a helper that verifies EVM-only support) and return an
empty string (or undefined) for unsupported/non-EVM chains instead of
constructing `${SAFE_BASE_URL}/${chainShortName}:${safeAddress}`; reference
getSafeAccountUrl, getSafeWebUrl, CHAIN_INFO, SAFE_BASE_URL and
SAFE_API_NETWORK_ID when making this guard.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: a4a086c1-b3ba-4420-a403-43941df525c9

📥 Commits

Reviewing files that changed from the base of the PR and between 8816d05 and a6d58b3.

📒 Files selected for processing (1)
  • libs/core/src/gnosisSafe/index.ts

Copy link
Copy Markdown
Contributor

@fairlighteth fairlighteth left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still some AI review findings that show up:

  • Medium: Safe URL builders still accept SupportedChainId.SOLANA and generate invalid Safe links. createSafeApiKitInstance() was fixed, but libs/core/src/gnosisSafe/index.ts:63 and libs/core/src/gnosisSafe/index.ts:90 still build app.safe.global/solana:.... This leaves CodeRabbit’s final Safe-link comment unaddressed.
  • Medium: The Solana destination token-list hydration path was removed without an equivalent replacement. apps/cowswap-frontend/src/modules/application/containers/App/Updaters.tsx:110 only runs
    TokensListsUpdater for sourceChainId, while libs/tokens/src/hooks/tokens/useTokensByAddressMapForChain.ts:29 reads destination-chain list state. The new NearSolana list at libs/tokens/src/const/
    tokensList.json:212 will not be fetched for normal EVM-to-Solana bridge flows. This means fairlighteth’s “target-chain token lists/logos stay empty” comment is not fully addressed.
  • Medium: Explorer’s native Solana local-image fallback is still broken. apps/explorer/src/utils/miscellaneous.ts:74 maps native Solana to sol, but apps/explorer/src/components/common/TokenImg/index.tsx:32
    does not recognize sol, and there is no apps/explorer/src/assets/img/tokens/sol.png. The bridge-provider logoURI fallback may cover Elena’s reported screen, but the local fallback path still fails.
  • Low: PACKAGE_READ_AUTH_TOKEN is still workflow-wide in .github/workflows/i18n-extract.yml:14. CodeRabbit asked to scope it to the install step; that was not done.
  • Low: The unresolved GitHub inline thread is still valid in apps/cowswap-frontend/src/modules/yield/lpPageLinks.ts:50: Doesnt' remains, and the requested explanatory comments at lines 16 and 67 are also still absent.

Also there are some merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants