feat: integrate Ethereal (5064014) as second-class Relay chain#11940
Merged
gomesalexandre merged 29 commits intodevelopfrom Feb 25, 2026
Merged
feat: integrate Ethereal (5064014) as second-class Relay chain#11940gomesalexandre merged 29 commits intodevelopfrom
gomesalexandre merged 29 commits intodevelopfrom
Conversation
Contributor
|
Note Reviews pausedIt 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 Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Ethereal (chainId 5064014, USDe native asset) as a new second-class EVM chain alongside renaming Flow EVM environment variables (VITE_FLOWEVM → VITE_FLOW_EVM). Introduces chain-specific infrastructure including adapters, viem clients, CSP headers, asset definitions, wallet support flags across all HDWallet implementations, and feature-flagged plugin registration. Updates environment and configuration files, type definitions, and related utility functions across the codebase. Additionally rewrites the SwapWidget component for multi-chain swap execution with cross-chain wallet switching support. Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes The scope is substantial with heterogeneous changes: new EtherealChainAdapter implementation, comprehensive type/constant updates across CAIP and contract packages, repeated capability flag additions across 12 HDWallet implementations (moderate homogeneity reduces per-file review), environment variable consolidation, and a major SwapWidget rewrite. The integration pattern is applied consistently but the variety of file types (adapters, types, configs, plugins, hooks, state) and the density of the swap widget logic necessitate careful review. Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
1 task
This was referenced Feb 20, 2026
…ereal-relay # Conflicts: # .claude/contracts/second-class-evm-chain.md # .env # .env.development # headers/csps/chains/flowEvm.ts # headers/csps/index.ts # packages/caip/src/adapters/coincap/generated/eip155_1/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_10/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_137/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_42161/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_43114/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_56/adapter.json # packages/caip/src/adapters/coincap/generated/eip155_8453/adapter.json # packages/caip/src/adapters/coincap/generated/solana_5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_1/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_130/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_137/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_146/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_1514/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_1868/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_25/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_324/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_34443/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_42161/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_42220/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_43111/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_43114/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_480/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_5000/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_56/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_59144/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_60808/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_747/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_80094/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_81457/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_8453/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_98866/adapter.json # packages/caip/src/adapters/coingecko/generated/eip155_999/adapter.json # packages/caip/src/adapters/coingecko/generated/index.ts # packages/caip/src/adapters/coingecko/generated/solana_5eykt4UsFv8P8NJdTREpY1vzqKqZKvdp/adapter.json # packages/caip/src/adapters/coingecko/generated/sui_35834a8a/adapter.json # packages/caip/src/adapters/coingecko/index.test.ts # packages/caip/src/adapters/coingecko/index.ts # packages/caip/src/adapters/coingecko/utils.test.ts # packages/caip/src/adapters/coingecko/utils.ts # packages/caip/src/constants.ts # packages/chain-adapters/src/evm/EvmBaseAdapter.ts # packages/chain-adapters/src/evm/SecondClassEvmAdapter.ts # packages/chain-adapters/src/evm/index.ts # packages/chain-adapters/src/evm/mantle/MantleChainAdapter.ts # packages/chain-adapters/src/types.ts # packages/contracts/src/ethersProviderSingleton.ts # packages/contracts/src/viemClient.ts # packages/hdwallet-coinbase/src/coinbase.ts # packages/hdwallet-core/src/ethereum.ts # packages/hdwallet-core/src/wallet.ts # packages/hdwallet-gridplus/src/gridplus.ts # packages/hdwallet-keepkey/src/keepkey.ts # packages/hdwallet-ledger/src/ledger.ts # packages/hdwallet-metamask-multichain/src/shapeshift-multichain.ts # packages/hdwallet-native/src/ethereum.ts # packages/hdwallet-phantom/src/phantom.ts # packages/hdwallet-trezor/src/trezor.ts # packages/hdwallet-vultisig/src/vultisig.ts # packages/hdwallet-walletconnectv2/src/walletconnectV2.ts # packages/swap-widget/src/components/SwapWidget.tsx # packages/swapper/src/swappers/AcrossSwapper/constant.ts # packages/swapper/src/swappers/RelaySwapper/constant.ts # packages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.ts # packages/types/src/base.ts # packages/types/src/zerion.ts # packages/utils/src/assetData/baseAssets.ts # packages/utils/src/assetData/getBaseAsset.ts # packages/utils/src/chainIdToFeeAssetId.ts # packages/utils/src/getAssetNamespaceFromChainId.ts # packages/utils/src/getChainShortName.ts # packages/utils/src/getNativeFeeAssetReference.ts # public/generated/asset-manifest.json # public/generated/asset-manifest.json.br # public/generated/asset-manifest.json.gz # public/generated/generatedAssetData.json # public/generated/generatedAssetData.json.br # public/generated/generatedAssetData.json.gz # public/generated/relatedAssetIndex.json # public/generated/relatedAssetIndex.json.br # public/generated/relatedAssetIndex.json.gz # scripts/generateAssetData/coingecko.ts # scripts/generateAssetData/generateAssetData.ts # scripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.ts # scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts # src/components/TradeAssetSearch/hooks/useGetPopularAssetsQuery.tsx # src/config.ts # src/constants/chains.ts # src/context/PluginProvider/PluginProvider.tsx # src/context/WalletProvider/WalletConnectV2/config.ts # src/hooks/useActionCenterSubscribers/useSendActionSubscriber.tsx # src/hooks/useWalletSupportsChain/useWalletSupportsChain.ts # src/lib/account/evm.ts # src/lib/asset-service/service/AssetService.ts # src/lib/coingecko/utils.ts # src/lib/market-service/coingecko/coingecko.test.ts # src/pages/Markets/components/MarketsRow.tsx # src/plugins/activePlugins.ts # src/plugins/flowEvm/index.tsx # src/state/migrations/index.ts # src/state/slices/opportunitiesSlice/mappings.ts # src/state/slices/portfolioSlice/utils/index.ts # src/state/slices/preferencesSlice/preferencesSlice.ts # src/test/mocks/store.ts # src/vite-env.d.ts
…tion - reset generated files to develop then regen ethereal - fix broken try/catch blocks in coingecko utils.ts (7 chains) - fix broken Object.freeze closings in baseAssets.ts - fix broken switch cases in coingecko.ts - fix broken toAssetId closings in index.test.ts - add etherealChainId export to generate:chain module - add ethereal export to baseAssets.ts Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Actionable comments posted: 9
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (4)
scripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.ts (1)
53-84:⚠️ Potential issue | 🔴 CriticalData inconsistency:
manualRelatedAssetIndexdiffers between full and per-chain generation functions — per-chain updates will not include manual links for blast, bob, cronos, hemi, mode, soneium, sonic, unichain, worldchain, zkSyncEra.The
manualRelatedAssetIndexingenerateChainRelatedAssetIndex.tscontains only 8 assets, while the same index ingenerateRelatedAssetIndex/generateRelatedAssetIndex.tscontains 20 assets (includes zkSyncEraAssetId, blastAssetId, worldChainAssetId, hemiAssetId, unichainAssetId, bobAssetId, modeAssetId, soneiumAssetId). SincegenerateChainRelatedAssetIndex()is called during per-chain updates viayarn generate:chain, incremental regeneration of ETH or other chains will not include manual related asset links for the missing chains, even if the full generation includes them. Either synchronize both files or verify this is intentional and document the split strategy.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.ts` around lines 53 - 84, The manualRelatedAssetIndex defined in generateChainRelatedAssetIndex.ts is missing many entries present in the full generateRelatedAssetIndex (causing per-chain runs to omit manual links); update manualRelatedAssetIndex in generateChainRelatedAssetIndex (or refactor to import/share the single source) to include the same asset keys (e.g., zkSyncEraAssetId, blastAssetId, worldChainAssetId, hemiAssetId, unichainAssetId, bobAssetId, modeAssetId, soneiumAssetId and any others present in generateRelatedAssetIndex/generateRelatedAssetIndex.ts) so per-chain generation via generateChainRelatedAssetIndex() matches the full generation, or alternatively add a comment documenting the intentional split and which keys are omitted.packages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.ts (1)
164-195:⚠️ Potential issue | 🔴 CriticalCritical: Nine switch cases have incomplete return objects — missing
assetNamespaceand closing braces.Lines 164–190 contain nine consecutive
caseblocks where eachreturn {is never closed andassetNamespace: ASSET_NAMESPACE.slip44is missing. This is a syntax error that will fail TypeScript compilation.Affected cases:
EtherealMainnet,CeloMainnet,FlowEvmMainnet,PlumeMainnet,StoryMainnet,ZkSyncEraMainnet,BlastMainnet,WorldChainMainnet,HemiMainnet.🐛 Proposed fix — restore closing braces and assetNamespace for all affected cases
case CHAIN_REFERENCE.EtherealMainnet: return { assetReference: ASSET_REFERENCE.Ethereal, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.CeloMainnet: return { assetReference: ASSET_REFERENCE.Celo, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.FlowEvmMainnet: return { assetReference: ASSET_REFERENCE.FlowEvm, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.PlumeMainnet: return { assetReference: ASSET_REFERENCE.Plume, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.StoryMainnet: return { assetReference: ASSET_REFERENCE.Story, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.ZkSyncEraMainnet: return { assetReference: ASSET_REFERENCE.ZkSyncEra, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.BlastMainnet: return { assetReference: ASSET_REFERENCE.Blast, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.WorldChainMainnet: return { assetReference: ASSET_REFERENCE.WorldChain, + assetNamespace: ASSET_NAMESPACE.slip44, + } case CHAIN_REFERENCE.HemiMainnet: return { assetReference: ASSET_REFERENCE.Hemi, + assetNamespace: ASSET_NAMESPACE.slip44, + }🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.ts` around lines 164 - 195, The switch cases inside relayTokenToAssetId that handle CHAIN_REFERENCE.EtherealMainnet, CeloMainnet, FlowEvmMainnet, PlumeMainnet, StoryMainnet, ZkSyncEraMainnet, BlastMainnet, WorldChainMainnet, and HemiMainnet return unterminated objects and omit assetNamespace; fix each of those case blocks in relayTokenToAssetId by closing the returned object and adding assetNamespace: ASSET_NAMESPACE.slip44 (e.g., return { assetReference: ASSET_REFERENCE.Ethereal, assetNamespace: ASSET_NAMESPACE.slip44 };), ensuring each case has the proper closing brace and semicolon so TypeScript compiles.scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts (1)
60-82:⚠️ Potential issue | 🟡 MinorDuplicate entries in
manualRelatedAssetIndexforethAssetId— likely a merge artifact.
katanaAssetIdappears at lines 65, 72, and 76 (3×), andmegaethAssetIdappears at lines 67, 74, and 77 (3×). These duplicates look like remnants from resolving merge conflicts across the sequential PR series. While they won't crash at runtime (the array is consumed via.includes()andSetdedup in other paths), they're incorrect data.Proposed fix: remove duplicate entries
[ethAssetId]: [ optimismAssetId, arbitrumAssetId, baseAssetId, katanaAssetId, megaethAssetId, zkSyncEraChainId, blastAssetId, worldChainAssetId, hemiAssetId, inkAssetId, - katanaAssetId, lineaAssetId, - megaethAssetId, scrollAssetId, - katanaAssetId, - megaethAssetId, unichainAssetId, bobAssetId, modeAssetId, soneiumAssetId, ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts` around lines 60 - 82, The manualRelatedAssetIndex entry for ethAssetId contains duplicate asset ids (katanaAssetId and megaethAssetId repeated multiple times); edit the manualRelatedAssetIndex object to remove repeated values from the ethAssetId array so each related asset id appears only once (e.g., ensure katanaAssetId and megaethAssetId are present a single time), preserving the original order otherwise; update the ethAssetId array in generateRelatedAssetIndex.ts where manualRelatedAssetIndex is defined.packages/caip/src/constants.ts (1)
348-393:⚠️ Potential issue | 🟠 MajorAdd
flowEvmAssetId(andbobAssetId,modeAssetId) toFEE_ASSET_IDSarray.The
flowEvmAssetIdis declared at line 30 and actively used inchainIdToFeeAssetId.tsto mapKnownChainIds.FlowEvmMainnetto its native fee asset, but is missing from theFEE_ASSET_IDSarray. This inconsistency should be resolved by adding it (andbobAssetId,modeAssetIdwhich have the same issue) to the array to keep the fee asset definitions in sync.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/caip/src/constants.ts` around lines 348 - 393, The FEE_ASSET_IDS array is missing flowEvmAssetId, bobAssetId, and modeAssetId which causes inconsistency with mappings (e.g., chainIdToFeeAssetId.ts mapping KnownChainIds.FlowEvmMainnet to flowEvmAssetId); update the FEE_ASSET_IDS constant by adding flowEvmAssetId, bobAssetId, and modeAssetId into the exported array so the declared asset IDs are listed alongside the other fee asset constants.
🧹 Nitpick comments (6)
packages/utils/src/getChainShortName.ts (1)
63-64:'ETH_E'is the only short name containing an underscore — consider a pure-letter alternative.Every other entry in this switch returns an all-letter string (
ETH,KAT,CELO, etc.).ETH_Eis the sole exception. Beyond the visual inconsistency, downstream consumers that treat short names as opaque identifiers (URL slugs, composite keys, regex patterns) may behave unexpectedly with an embedded underscore.An all-letter alternative like
ETRLorETHRLwould stay consistent and avoid any separator ambiguity.♻️ Suggested rename
case KnownChainIds.EtherealMainnet: - return 'ETH_E' + return 'ETRL'🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/utils/src/getChainShortName.ts` around lines 63 - 64, The short name for KnownChainIds.EtherealMainnet in getChainShortName currently returns 'ETH_E' with an underscore; change it to a pure-letter identifier (e.g., 'ETHRL' or 'ETRL') in the KnownChainIds.EtherealMainnet case of the getChainShortName switch so it matches the all-letter convention used elsewhere, and update any tests or downstream references that expect 'ETH_E' to use the new value.packages/hdwallet-core/src/wallet.ts (1)
586-589:supportsEtherealis placed after theHDWalletinterface, unlike all othersupports*guards.All other chain support type guards (lines 116–266) are grouped together before the
HDWalletInfoandHDWalletinterfaces. This function is appended at the very end of the file. Consider moving it to sit alongside its peers for discoverability.Suggested placement
Move
supportsEtherealto the block of EVM chain support guards (e.g., aftersupportsSoneiumat line 266):export function supportsSoneium(wallet: HDWallet): wallet is ETHWallet { return isObject(wallet) && (wallet as any)._supportsSoneium } + +export function supportsEthereal(wallet: HDWallet): wallet is ETHWallet { + return isObject(wallet) && (wallet as any)._supportsEthereal +} export function infoCosmos(info: HDWalletInfo): info is CosmosWalletInfo {And remove the duplicate at the end of the file (lines 586–589).
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/hdwallet-core/src/wallet.ts` around lines 586 - 589, The supportsEthereal type-guard is misplaced after the HDWallet interface and duplicated; move the supportsEthereal function into the existing block of chain support guards (e.g., immediately after supportsSoneium in the EVM guards group) so it sits with the other supports* functions, and delete the duplicate definition currently appended at the end of the file; ensure the moved function still exports the same signature (supportsEthereal(wallet: HDWallet): wallet is ETHWallet) and retains the original implementation.packages/swap-widget/src/components/SwapWidget.tsx (4)
612-644: ERC-20 approval doesn't check existing allowance — users may pay for unnecessary approval transactions.The code always sends an
approvetransaction whenquoteResponse.approval?.isRequiredis truthy, without first reading the current allowance. If the user already has sufficient allowance (e.g., from a previous swap), this wastes gas on a redundant on-chain approval. AreadContractcall forallowance(owner, spender)before sending the approval would avoid this.Also, the
approveamount is set to exactlysellAmountBaseUnit(line 628). This means every subsequent swap of the same token to the same spender requires a new approval. Consider usingmaxUint256if the UX preference is "approve once", or keep exact amounts if security-conscious — but document the intent.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swap-widget/src/components/SwapWidget.tsx` around lines 612 - 644, In SwapWidget.tsx, before sending the approve transaction inside the block that checks quoteResponse.approval?.isRequired, first read the current ERC‑20 allowance by calling readContract/allowance(owner: walletAddress, spender: quoteResponse.approval.spender) for the token at sellAssetAddress; only call client.sendTransaction for approve if the current allowance is < sellAmountBaseUnit. Also decide and document whether to approve exactly sellAmountBaseUnit (current behavior) or use maxUint256 for a one‑time approve—implement the chosen amount when building approvalData passed to client.sendTransaction and keep the existing waitForTransactionReceipt flow (createPublicClient / waitForTransactionReceipt) unchanged.
178-186: Redundant aliases:canExecuteDirectly≡isSellAssetEvm,canExecuteUtxo≡isSellAssetUtxo,canExecuteSolana≡isSellAssetSolana.These aliases add no semantic distinction and are used interchangeably with the originals (e.g.,
handleExecuteSwapchecks bothisSellAssetUtxoandcanExecuteUtxo). Collapsing to one set of names would reduce cognitive overhead.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swap-widget/src/components/SwapWidget.tsx` around lines 178 - 186, The three boolean aliases canExecuteDirectly, canExecuteUtxo, and canExecuteSolana are redundant with isSellAssetEvm, isSellAssetUtxo, and isSellAssetSolana; remove the canExecute* declarations and update all usages (e.g., inside handleExecuteSwap and any conditional rendering) to reference isSellAssetEvm / isSellAssetUtxo / isSellAssetSolana directly (ensure imports/props unaffected), then run tests/type checks to confirm no remaining references to canExecuteDirectly/canExecuteUtxo/canExecuteSolana.
371-374: MultiplesetTimeoutcalls without cleanup — potential stale updates after unmount or re-execution.
executeUtxoSwap,executeSolanaSwap, andexecuteEvmSwapall schedulesetTimeoutfor balance refetching without storing timer IDs or cleaning them up. If the user navigates away or triggers another swap before the timers fire,refetchSellBalance/refetchBuyBalancewill execute against stale context. While React 18+ won't throw on unmounted setState, the refetches are still wasteful network calls.Consider storing timeout IDs in a ref and clearing them on unmount via a cleanup
useEffect, or using the query client'sinvalidateQuerieswith a proper polling interval.Also applies to: 520-523, 682-698
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swap-widget/src/components/SwapWidget.tsx` around lines 371 - 374, The three swap executor functions (executeUtxoSwap, executeSolanaSwap, executeEvmSwap) schedule setTimeouts that call refetchSellBalance/refetchBuyBalance without capturing or clearing timer IDs; store each timeout ID in a React ref (e.g., balanceRefetchTimersRef) when you call setTimeout and add a cleanup useEffect that clears all timers on unmount (clearTimeout), or replace the timeouts with a single queryClient.invalidateQueries or a debounced refetch to avoid redundant network calls; update all occurrences (the setTimeout calls around refetchSellBalance/refetchBuyBalance) to push timer IDs into the ref and ensure the cleanup effect clears them.
135-1283:SwapWidgetCoreis ~1,150 lines — consider extracting execution logic into custom hooks.The three
execute*Swapcallbacks alone account for ~400 lines. Extracting them into hooks likeuseEvmSwapExecution,useUtxoSwapExecution, anduseSolanaSwapExecutionwould improve readability and testability without changing behavior. ThebuttonTextandisButtonDisabledmemos are also good extraction candidates.As per coding guidelines: "KEEP component files under 200 lines when possible; BREAK DOWN large components into smaller, reusable pieces" and "EXTRACT complex logic into custom hooks."
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/swap-widget/src/components/SwapWidget.tsx` around lines 135 - 1283, The SwapWidgetCore is too large; extract the large execution and UI logic into hooks to reduce file size and improve testability: move the executeEvmSwap, executeSolanaSwap, and executeUtxoSwap callbacks into separate hooks (e.g., useEvmSwapExecution, useSolanaSwapExecution, useUtxoSwapExecution) that accept the necessary inputs (apiClient, walletClient, walletAddress, sellAsset, buyAsset, sellAmountBaseUnit, sellAssetBalance, signPsbt/sendBitcoinTransfer/sendSolanaTransaction, slippage, effectiveReceiveAddress, refetchSellBalance/refetchBuyBalance, onSwapSuccess/onSwapError, resetBitcoinState/resetSolanaState, etc.) and return an execute function plus any state (isExecuting, txStatus setters, reset hooks); also extract the buttonText and isButtonDisabled logic into a small hook (e.g., useSwapButtonState) that consumes sell/buy asset metadata, connection states, rates, and execution flags and returns text/disabled; replace the inline callbacks and memos with these hooks, keep prop and behavior identical, and ensure all dependencies are forwarded so unit tests can target the hooks directly.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/chain-adapters/src/evm/EvmBaseAdapter.ts`:
- Around line 392-407: The targetNetwork object literal has missing closing
braces for multiple entries (e.g., KnownChainIds.EtherealMainnet,
KnownChainIds.CeloMainnet, KnownChainIds.FlowEvmMainnet,
KnownChainIds.PlumeMainnet, etc.), causing a syntax error; fix by adding the
missing closing "}," after each chain entry inside the targetNetwork definition
(ensure each property object like the one for KnownChainIds.EtherealMainnet ends
with "},") so every entry is a properly terminated object before the next
KnownChainIds key.
In `@packages/chain-adapters/src/evm/index.ts`:
- Line 3: Restore the removed type guard or update consumers: either re-export
the isSecondClassEvmAdapter function from the evm index (so current import sites
keep working) or change consumers to use an instanceof check against
SecondClassEvmAdapter (replace calls like isSecondClassEvmAdapter(adapter) with
adapter instanceof SecondClassEvmAdapter and adjust imports to import
SecondClassEvmAdapter). Ensure the symbol names match exactly:
isSecondClassEvmAdapter and SecondClassEvmAdapter, and update/imports in the
consumer modules that currently call isSecondClassEvmAdapter so they compile
without breaking.
In `@packages/contracts/src/viemClient.ts`:
- Around line 185-196: Several createPublicClient declarations
(viemEtherealClient, viemCeloClient, viemFlowEvmClient, viemPlumeClient,
viemStoryClient, viemZkSyncEraClient, viemBlastClient, viemWorldChainClient,
viemHemiClient) are left unclosed and cause a TypeScript syntax error; for each
of those exported constants, close the object call and cast to the PublicClient
type by appending the missing closing sequence "}) as PublicClient" immediately
after the transport(...) configuration so each declaration matches the pattern
used by viemLineaClient.
In `@packages/swap-widget/src/components/SwapWidget.tsx`:
- Around line 359-365: The txStatus update that sets status:'pending' with
txHash in executeUtxoSwap and executeSolanaSwap is immediately overwritten by
the following status:'success' call (so the pending state is never shown);
either insert an actual await-based confirmation step between the two
setTxStatus calls (confirm the transaction via the chain-specific confirmation
method and only set success after confirmation) or remove the initial
setTxStatus({...status:'pending'...}) in both executeUtxoSwap and
executeSolanaSwap if the intent is to treat "submitted" as final; update the
code paths in those functions (executeUtxoSwap, executeSolanaSwap) accordingly
so txStatus reflects the real lifecycle.
- Around line 974-983: The onChange handler for the sell amount input allows
multiple decimal points because it only strips non-digit/dot chars; update the
handler used with setSellAmount to normalize the value so only the first decimal
point is kept (remove any subsequent dots) before calling setSellAmount, then
still call setSelectedRate(null) and setTxStatus(null); target the inline
onChange for the input that currently uses
setSellAmount(e.target.value.replace(/[^0-9.]/g, '')) and replace its
normalization logic to collapse extra dots (e.g., split on '.', keep the first
dot and join remaining parts) so downstream parsing (parseAmount/parseFloat)
never receives values like "1.2.3".
- Around line 604-610: The fallback chain created when
VIEM_CHAINS_BY_ID[requiredChainId] is missing sets rpcUrls: { default: { http:
[] } }, which will break createPublicClient/publicClient; update the logic
around viemChain/chain so that when viemChain is undefined you derive a usable
RPC URL (e.g., extract an RPC endpoint from baseAsset.metadata or
baseAsset.explorer, or use a sensible default RPC for the network) and populate
rpcUrls.default.http with that URL, and additionally guard the code that
constructs/uses the publicClient (the createPublicClient call and any
wait-for-approval flow) to skip or fail gracefully if no valid RPC is available;
references: VIEM_CHAINS_BY_ID, viemChain, chain, requiredChainId, baseAsset,
publicClient/createPublicClient.
- Around line 1194-1205: The transaction explorer URL construction in SwapWidget
(the inline href using isSellAssetUtxo/isSellAssetSolana and
sellAsset.explorerTxLink with txStatus.txHash) can produce malformed URLs when
sellAsset.explorerTxLink lacks a trailing slash; update the href logic to
normalize the base link before concatenation (e.g., ensure
sellAsset.explorerTxLink ends with a '/' or otherwise join with a '/' if
missing) so the final URL is always base + separator + txStatus.txHash, while
keeping the special-cases for mempool.space and solscan intact.
- Around line 41-55: The current VIEM_CHAINS_BY_ID map is incomplete and the
fallback chain construction creates rpcUrls: { default: { http: [] } }, which
causes createPublicClient + waitForTransactionReceipt to throw UrlRequiredError
for unsupported chains; update the code so that either (A) you add the missing
chain entries to VIEM_CHAINS_BY_ID (referencing VIEM_CHAINS_BY_ID) with valid
rpcUrls, or (B) change the fallback logic that builds the chain object to use a
configurable fallback RPC provider (read from env/config) and populate
rpcUrls.default.http with that URL before calling createPublicClient and
waitForTransactionReceipt, and if no fallback is configured, throw a clear error
instead of supplying an empty http array.
In `@packages/types/src/zerion.ts`:
- Around line 56-57: Remove the unsupported 'ethereal' entry from the
ZERION_CHAINS array in packages/types/src/zerion.ts so API calls to Zerion use
only valid chain identifiers (e.g., keep 'celo' but delete 'ethereal'); update
the ZERION_CHAINS constant (and any related exports or tests referencing
ZERION_CHAINS) to reflect the removal and run tests/typechecks to ensure no
remaining references to 'ethereal' cause errors.
---
Outside diff comments:
In `@packages/caip/src/constants.ts`:
- Around line 348-393: The FEE_ASSET_IDS array is missing flowEvmAssetId,
bobAssetId, and modeAssetId which causes inconsistency with mappings (e.g.,
chainIdToFeeAssetId.ts mapping KnownChainIds.FlowEvmMainnet to flowEvmAssetId);
update the FEE_ASSET_IDS constant by adding flowEvmAssetId, bobAssetId, and
modeAssetId into the exported array so the declared asset IDs are listed
alongside the other fee asset constants.
In `@packages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.ts`:
- Around line 164-195: The switch cases inside relayTokenToAssetId that handle
CHAIN_REFERENCE.EtherealMainnet, CeloMainnet, FlowEvmMainnet, PlumeMainnet,
StoryMainnet, ZkSyncEraMainnet, BlastMainnet, WorldChainMainnet, and HemiMainnet
return unterminated objects and omit assetNamespace; fix each of those case
blocks in relayTokenToAssetId by closing the returned object and adding
assetNamespace: ASSET_NAMESPACE.slip44 (e.g., return { assetReference:
ASSET_REFERENCE.Ethereal, assetNamespace: ASSET_NAMESPACE.slip44 };), ensuring
each case has the proper closing brace and semicolon so TypeScript compiles.
In
`@scripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.ts`:
- Around line 53-84: The manualRelatedAssetIndex defined in
generateChainRelatedAssetIndex.ts is missing many entries present in the full
generateRelatedAssetIndex (causing per-chain runs to omit manual links); update
manualRelatedAssetIndex in generateChainRelatedAssetIndex (or refactor to
import/share the single source) to include the same asset keys (e.g.,
zkSyncEraAssetId, blastAssetId, worldChainAssetId, hemiAssetId, unichainAssetId,
bobAssetId, modeAssetId, soneiumAssetId and any others present in
generateRelatedAssetIndex/generateRelatedAssetIndex.ts) so per-chain generation
via generateChainRelatedAssetIndex() matches the full generation, or
alternatively add a comment documenting the intentional split and which keys are
omitted.
In
`@scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts`:
- Around line 60-82: The manualRelatedAssetIndex entry for ethAssetId contains
duplicate asset ids (katanaAssetId and megaethAssetId repeated multiple times);
edit the manualRelatedAssetIndex object to remove repeated values from the
ethAssetId array so each related asset id appears only once (e.g., ensure
katanaAssetId and megaethAssetId are present a single time), preserving the
original order otherwise; update the ethAssetId array in
generateRelatedAssetIndex.ts where manualRelatedAssetIndex is defined.
---
Nitpick comments:
In `@packages/hdwallet-core/src/wallet.ts`:
- Around line 586-589: The supportsEthereal type-guard is misplaced after the
HDWallet interface and duplicated; move the supportsEthereal function into the
existing block of chain support guards (e.g., immediately after supportsSoneium
in the EVM guards group) so it sits with the other supports* functions, and
delete the duplicate definition currently appended at the end of the file;
ensure the moved function still exports the same signature
(supportsEthereal(wallet: HDWallet): wallet is ETHWallet) and retains the
original implementation.
In `@packages/swap-widget/src/components/SwapWidget.tsx`:
- Around line 612-644: In SwapWidget.tsx, before sending the approve transaction
inside the block that checks quoteResponse.approval?.isRequired, first read the
current ERC‑20 allowance by calling readContract/allowance(owner: walletAddress,
spender: quoteResponse.approval.spender) for the token at sellAssetAddress; only
call client.sendTransaction for approve if the current allowance is <
sellAmountBaseUnit. Also decide and document whether to approve exactly
sellAmountBaseUnit (current behavior) or use maxUint256 for a one‑time
approve—implement the chosen amount when building approvalData passed to
client.sendTransaction and keep the existing waitForTransactionReceipt flow
(createPublicClient / waitForTransactionReceipt) unchanged.
- Around line 178-186: The three boolean aliases canExecuteDirectly,
canExecuteUtxo, and canExecuteSolana are redundant with isSellAssetEvm,
isSellAssetUtxo, and isSellAssetSolana; remove the canExecute* declarations and
update all usages (e.g., inside handleExecuteSwap and any conditional rendering)
to reference isSellAssetEvm / isSellAssetUtxo / isSellAssetSolana directly
(ensure imports/props unaffected), then run tests/type checks to confirm no
remaining references to canExecuteDirectly/canExecuteUtxo/canExecuteSolana.
- Around line 371-374: The three swap executor functions (executeUtxoSwap,
executeSolanaSwap, executeEvmSwap) schedule setTimeouts that call
refetchSellBalance/refetchBuyBalance without capturing or clearing timer IDs;
store each timeout ID in a React ref (e.g., balanceRefetchTimersRef) when you
call setTimeout and add a cleanup useEffect that clears all timers on unmount
(clearTimeout), or replace the timeouts with a single
queryClient.invalidateQueries or a debounced refetch to avoid redundant network
calls; update all occurrences (the setTimeout calls around
refetchSellBalance/refetchBuyBalance) to push timer IDs into the ref and ensure
the cleanup effect clears them.
- Around line 135-1283: The SwapWidgetCore is too large; extract the large
execution and UI logic into hooks to reduce file size and improve testability:
move the executeEvmSwap, executeSolanaSwap, and executeUtxoSwap callbacks into
separate hooks (e.g., useEvmSwapExecution, useSolanaSwapExecution,
useUtxoSwapExecution) that accept the necessary inputs (apiClient, walletClient,
walletAddress, sellAsset, buyAsset, sellAmountBaseUnit, sellAssetBalance,
signPsbt/sendBitcoinTransfer/sendSolanaTransaction, slippage,
effectiveReceiveAddress, refetchSellBalance/refetchBuyBalance,
onSwapSuccess/onSwapError, resetBitcoinState/resetSolanaState, etc.) and return
an execute function plus any state (isExecuting, txStatus setters, reset hooks);
also extract the buttonText and isButtonDisabled logic into a small hook (e.g.,
useSwapButtonState) that consumes sell/buy asset metadata, connection states,
rates, and execution flags and returns text/disabled; replace the inline
callbacks and memos with these hooks, keep prop and behavior identical, and
ensure all dependencies are forwarded so unit tests can target the hooks
directly.
In `@packages/utils/src/getChainShortName.ts`:
- Around line 63-64: The short name for KnownChainIds.EtherealMainnet in
getChainShortName currently returns 'ETH_E' with an underscore; change it to a
pure-letter identifier (e.g., 'ETHRL' or 'ETRL') in the
KnownChainIds.EtherealMainnet case of the getChainShortName switch so it matches
the all-letter convention used elsewhere, and update any tests or downstream
references that expect 'ETH_E' to use the new value.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (6)
public/generated/asset-manifest.jsonis excluded by!**/generated/**public/generated/asset-manifest.json.bris excluded by!**/generated/**public/generated/asset-manifest.json.gzis excluded by!**/*.gz,!**/generated/**public/generated/generatedAssetData.jsonis excluded by!**/generated/**public/generated/generatedAssetData.json.bris excluded by!**/generated/**public/generated/generatedAssetData.json.gzis excluded by!**/*.gz,!**/generated/**
📒 Files selected for processing (71)
.beads/ss-dx5.12.json.beads/ss-dx5.15.json.beads/ss-dx5.17.json.claude/contracts/second-class-evm-chain.md.env.env.developmentheaders/csps/chains/ethereal.tsheaders/csps/chains/flowEvm.tsheaders/csps/index.tspackages/caip/src/adapters/coingecko/index.tspackages/caip/src/constants.tspackages/chain-adapters/src/evm/EvmBaseAdapter.tspackages/chain-adapters/src/evm/SecondClassEvmAdapter.tspackages/chain-adapters/src/evm/ethereal/EtherealChainAdapter.tspackages/chain-adapters/src/evm/ethereal/index.tspackages/chain-adapters/src/evm/index.tspackages/chain-adapters/src/evm/mantle/MantleChainAdapter.tspackages/chain-adapters/src/types.tspackages/contracts/src/ethersProviderSingleton.tspackages/contracts/src/viemClient.tspackages/hdwallet-coinbase/src/coinbase.tspackages/hdwallet-core/src/ethereum.tspackages/hdwallet-core/src/wallet.tspackages/hdwallet-gridplus/src/gridplus.tspackages/hdwallet-keepkey/src/keepkey.tspackages/hdwallet-ledger/src/ledger.tspackages/hdwallet-metamask-multichain/src/shapeshift-multichain.tspackages/hdwallet-native/src/ethereum.tspackages/hdwallet-phantom/src/phantom.tspackages/hdwallet-trezor/src/trezor.tspackages/hdwallet-vultisig/src/vultisig.tspackages/hdwallet-walletconnectv2/src/walletconnectV2.tspackages/swap-widget/src/components/SwapWidget.tsxpackages/swapper/src/swappers/AcrossSwapper/constant.tspackages/swapper/src/swappers/RelaySwapper/constant.tspackages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.tspackages/types/src/base.tspackages/types/src/zerion.tspackages/utils/src/assetData/baseAssets.tspackages/utils/src/assetData/getBaseAsset.tspackages/utils/src/chainIdToFeeAssetId.tspackages/utils/src/getAssetNamespaceFromChainId.tspackages/utils/src/getChainShortName.tspackages/utils/src/getNativeFeeAssetReference.tsscripts/generateAssetData/ethereal/index.tsscripts/generateAssetData/generateAssetData.tsscripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.tsscripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.tssrc/components/TradeAssetSearch/hooks/useGetPopularAssetsQuery.tsxsrc/config.tssrc/constants/chains.tssrc/context/PluginProvider/PluginProvider.tsxsrc/context/WalletProvider/WalletConnectV2/config.tssrc/hooks/useWalletSupportsChain/useWalletSupportsChain.tssrc/lib/account/evm.tssrc/lib/asset-service/service/AssetService.tssrc/lib/coingecko/utils.tssrc/lib/utils/celo.tssrc/lib/utils/ethereal.tssrc/lib/utils/flowEvm.tssrc/lib/utils/story.tssrc/pages/Markets/components/MarketsRow.tsxsrc/plugins/activePlugins.tssrc/plugins/ethereal/index.tsxsrc/plugins/flowEvm/index.tsxsrc/state/migrations/index.tssrc/state/slices/opportunitiesSlice/mappings.tssrc/state/slices/portfolioSlice/utils/index.tssrc/state/slices/preferencesSlice/preferencesSlice.tssrc/test/mocks/store.tssrc/vite-env.d.ts
💤 Files with no reviewable changes (4)
- packages/chain-adapters/src/evm/mantle/MantleChainAdapter.ts
- src/state/migrations/index.ts
- src/context/WalletProvider/WalletConnectV2/config.ts
- src/vite-env.d.ts
- fix sonic coingecko platform: sonic-3 (native coin id) -> sonic (asset platform id) - restore viemClient.ts to develop base + add ethereal chain/client - restore WalletConnectV2/config.ts: re-add flowEvmChain + all new second-class chains (mantle, cronos, sonic, unichain, bob, mode, soneium, hemi, worldchain, blast, zksync, story, plume, celo) - restore vite-env.d.ts: re-add removed chain env var declarations + ethereal - restore migrations/index.ts: re-add clearAssets 296-304, add 305 for ethereal - fix portfolioSlice/utils: add missing plumeChainId to accountIdToLabel - delete dead code util files: celo.ts, ethereal.ts, flowEvm.ts, story.ts in src/lib/utils/ Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- restore SecondClassEvmAdapter.ts to develop base (re-adds isSecondClassEvmAdapter, getTransactionStatus, all wrapped native contracts for blast/zksyncEra/hemi/worldChain/celo/flowEvm/story) - add plumeChainId to WRAPPED_NATIVE_CONTRACT_BY_CHAIN_ID (0xea237441...) - restore isSecondClassEvmAdapter export in chain-adapters evm/index.ts - add EtherealMainnet to ETHSignTx signing map in types.ts - fix PlumeMainnet missing from coingecko chainIdToCoingeckoAssetPlatform switch - update generated asset data (plume: 54 assets, celo: 39 assets w/ WCELO, ethereal: precision 18 fixed) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
… ethereal removal - add missing closing }, for 9 entries in targetNetwork object (EtherealMainnet through HemiMainnet) - remove 'ethereal' from ZERION_CHAINS and zerionChainIdToChainId map (zerion doesn't support ethereal) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
adds cronos, unichain, sonic, zksync, worldchain, flowMainnet, story, soneium, mantle, celo, hemi, ink, linea, bob, blast, plumeMainnet, scroll - prevents UrlRequiredError during approval tx polling for these chains Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Merge artifact - EtherealMainnet through HemiMainnet cases were all missing assetNamespace and closing } in the slip44 return objects. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
@coderabbitai gm mr robot did you capture an issue for cross-chain Relay swaps to CELO missing second-class Tx history/execution price> |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 23 🏁 Script executed: Length of output: 69759
No, I did not find or capture an existing issue for cross-chain Relay swaps to CELO missing second-class transaction history/execution price. My search across the repository returned no issues matching that specific problem (CELO + Relay swaps + tx history/execution price). I did find issue Would you like me to create a new issue to track this as a follow-up for the second-class chain integration work? If so, I can open it with the relevant context about CELO being a second-class Relay chain and the missing transaction history/execution price data. 🧠 Learnings used |
Contributor
@coderabbitai do it |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 46
I've created issue The issue includes:
🧠 Learnings used |
Contributor
There was a problem hiding this comment.
Actionable comments posted: 4
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
packages/caip/src/constants.ts (2)
299-316:⚠️ Potential issue | 🔴 CriticalBug:
CHAIN_REFERENCE.CeloMainnetis duplicated inVALID_CHAIN_IDS.
CeloMainnetappears at both line 300 and line 316 in the EVM chain references array. Remove the duplicate entry at line 316.🐛 Proposed fix
CHAIN_REFERENCE.SoneiumMainnet, CHAIN_REFERENCE.SeiMainnet, - CHAIN_REFERENCE.CeloMainnet, ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/caip/src/constants.ts` around lines 299 - 316, The VALID_CHAIN_IDS (EVM chain references array) contains a duplicate entry CHAIN_REFERENCE.CeloMainnet; remove the second occurrence (the later CHAIN_REFERENCE.CeloMainnet in the array) so each CHAIN_REFERENCE value appears only once, leaving the first CeloMainnet entry intact in the CHAIN_REFERENCE list in packages/caip/src/constants.ts.
354-400:⚠️ Potential issue | 🔴 CriticalAdd
flowEvmAssetIdtoFEE_ASSET_IDSarray.
flowEvmAssetIdwas removed fromFEE_ASSET_IDSduring reordering. It was previously included when Flow EVM was integrated in commit 6999bfa but is missing from the current array, causing fee estimation failures for Flow EVM transactions.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/caip/src/constants.ts` around lines 354 - 400, FEE_ASSET_IDS is missing flowEvmAssetId which breaks Flow EVM fee estimation; update the FEE_ASSET_IDS array to include flowEvmAssetId (add the symbol flowEvmAssetId into the exported array alongside the other asset ids) so Flow EVM is recognized for fee calculations—locate the FEE_ASSET_IDS constant and insert flowEvmAssetId in the list in a logical grouping with other EVM assets.
🧹 Nitpick comments (3)
scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts (1)
72-77: Remove duplicatedkatanaAssetId/megaethAssetIdentries in the ETH related-assets list.Line 72/74/76/77 re-add values already listed at Line 65/66. Even though later logic dedupes, this manual index should stay canonical and unambiguous.
Suggested cleanup
[ethAssetId]: [ optimismAssetId, arbitrumAssetId, baseAssetId, katanaAssetId, megaethAssetId, zkSyncEraAssetId, blastAssetId, worldChainAssetId, hemiAssetId, inkAssetId, - katanaAssetId, lineaAssetId, - megaethAssetId, scrollAssetId, - katanaAssetId, - megaethAssetId, unichainAssetId, bobAssetId, modeAssetId, soneiumAssetId, ],🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts` around lines 72 - 77, The ETH related-assets array in generateRelatedAssetIndex.ts contains duplicate entries for katanaAssetId and megaethAssetId (they appear twice); remove the repeated occurrences so each of katanaAssetId and megaethAssetId appears only once in the literal list (leave the existing single entries at their original positions), ensuring the manual index is canonical even though later dedup logic exists.packages/hdwallet-core/src/wallet.ts (1)
591-593: Minor:supportsEtherealis placed after theHDWalletinterface, unlike all other chain type guards.All other EVM chain guards (
supportsFlowEvm,supportsCelo,supportsBerachain, etc.) are declared in the 116–415 range, before theHDWalletInfoandHDWalletinterface definitions. Consider movingsupportsEtherealinto that block alongsidesupportsKatanaand the other recently added chain guards for consistency.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/hdwallet-core/src/wallet.ts` around lines 591 - 593, Move the supportsEthereal type-guard function so it sits with the other EVM chain guards (e.g., alongside supportsKatana) before the HDWalletInfo/HDWallet interface declarations; locate the existing supportsEthereal export (function supportsEthereal(wallet: HDWallet): wallet is ETHWallet) and cut/paste it into the EVM guards block (the area containing supportsFlowEvm, supportsCelo, supportsBerachain, supportsKatana) to maintain consistent ordering and grouping of chain-specific type guards.packages/chain-adapters/src/types.ts (1)
250-250: Nit:EtherealMainnetordering inconsistent inChainSignTxvs other type maps.In
ChainSpecificAccount,ChainSpecificFeeData,ChainSpecificBuildTxData, andChainSpecificGetFeeDataInput,EtherealMainnetis placed afterKatanaMainnet(consistent with the rest of the PR). But inChainSignTx, it's placed betweenSoneiumMainnetandSeiMainnet(line 250). Not a functional issue since TypeScript type key ordering is irrelevant, but inconsistent placement makes future maintenance harder.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@packages/chain-adapters/src/types.ts` at line 250, Reorder the KnownChainIds.EtherealMainnet entry in the ChainSignTx type so it appears in the same position as in the other maps (after KatanaMainnet) to keep ordering consistent; update the mapping in the ChainSignTx type (where KnownChainIds.EtherealMainnet currently sits between SoneiumMainnet and SeiMainnet) to be placed after KatanaMainnet.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.env:
- Line 165: Update the VITE_ETHEREAL_NODE_URL value in the base .env to the
browser-compatible RPC endpoint used in development; replace the current
VITE_ETHEREAL_NODE_URL=https://rpc.ethereal.global with
VITE_ETHEREAL_NODE_URL=https://rpc.ethereal.trade so production builds inherit
the correct .trade endpoint (the same value present in .env.development).
In `@packages/chain-adapters/src/evm/SecondClassEvmAdapter.ts`:
- Around line 552-572: The fallback that treats ERC20 Transfer logs as native
receives in SecondClassEvmAdapter.ts must be limited to chains where the native
token is also an ERC20 (e.g., Celo); update the block that parses Transfer logs
(using parseEventLogs, erc20Abi, wrappedNativeContract, pubkey and pushing to
internalTxs) to run only when the adapter's chainId equals celoChainId (or other
explicitly dual-native chain ids added to the same guard), so non-Celo chains
(where wrapped native tokens like WETH are pure ERC20) do not produce mistaken
native internalTxs and duplicate tokenTransfers.
In `@src/config.ts`:
- Line 73: The env var was renamed in config to VITE_FLOW_EVM_NODE_URL but the
viem client still reads process.env.VITE_FLOWEVM_NODE_URL (old key), causing the
client to ignore the provided value; update the viem client to read the new key
name (VITE_FLOW_EVM_NODE_URL) wherever process.env.VITE_FLOWEVM_NODE_URL is
referenced (e.g., in the viem client initialization logic around the Flow EVM
endpoint), and ensure any fallback logic uses the validated config value from
the renamed variable rather than the old env key.
In `@src/context/WalletProvider/WalletConnectV2/config.ts`:
- Around line 9-30: Import and include the Ethereal chain (chain id 5064014) in
the WalletConnect V2 wiring: add the Ethereal symbol to the viem/chains import
list, append it to walletConnectV2OptionalChains, include its environment
variable extraction in getConfig() alongside other optional chains, and add an
entry for Ethereal in rpcMap so WalletConnect can advertise and switch to the
Ethereal RPC; update any related arrays/objects where other second-class chains
are handled (the same places as entries for sei, soneium, sonic, story, etc.) to
mirror their handling for Ethereal.
---
Outside diff comments:
In `@packages/caip/src/constants.ts`:
- Around line 299-316: The VALID_CHAIN_IDS (EVM chain references array) contains
a duplicate entry CHAIN_REFERENCE.CeloMainnet; remove the second occurrence (the
later CHAIN_REFERENCE.CeloMainnet in the array) so each CHAIN_REFERENCE value
appears only once, leaving the first CeloMainnet entry intact in the
CHAIN_REFERENCE list in packages/caip/src/constants.ts.
- Around line 354-400: FEE_ASSET_IDS is missing flowEvmAssetId which breaks Flow
EVM fee estimation; update the FEE_ASSET_IDS array to include flowEvmAssetId
(add the symbol flowEvmAssetId into the exported array alongside the other asset
ids) so Flow EVM is recognized for fee calculations—locate the FEE_ASSET_IDS
constant and insert flowEvmAssetId in the list in a logical grouping with other
EVM assets.
---
Nitpick comments:
In `@packages/chain-adapters/src/types.ts`:
- Line 250: Reorder the KnownChainIds.EtherealMainnet entry in the ChainSignTx
type so it appears in the same position as in the other maps (after
KatanaMainnet) to keep ordering consistent; update the mapping in the
ChainSignTx type (where KnownChainIds.EtherealMainnet currently sits between
SoneiumMainnet and SeiMainnet) to be placed after KatanaMainnet.
In `@packages/hdwallet-core/src/wallet.ts`:
- Around line 591-593: Move the supportsEthereal type-guard function so it sits
with the other EVM chain guards (e.g., alongside supportsKatana) before the
HDWalletInfo/HDWallet interface declarations; locate the existing
supportsEthereal export (function supportsEthereal(wallet: HDWallet): wallet is
ETHWallet) and cut/paste it into the EVM guards block (the area containing
supportsFlowEvm, supportsCelo, supportsBerachain, supportsKatana) to maintain
consistent ordering and grouping of chain-specific type guards.
In
`@scripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.ts`:
- Around line 72-77: The ETH related-assets array in
generateRelatedAssetIndex.ts contains duplicate entries for katanaAssetId and
megaethAssetId (they appear twice); remove the repeated occurrences so each of
katanaAssetId and megaethAssetId appears only once in the literal list (leave
the existing single entries at their original positions), ensuring the manual
index is canonical even though later dedup logic exists.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
⛔ Files ignored due to path filters (6)
public/generated/asset-manifest.jsonis excluded by!**/generated/**public/generated/asset-manifest.json.bris excluded by!**/generated/**public/generated/asset-manifest.json.gzis excluded by!**/*.gz,!**/generated/**public/generated/generatedAssetData.jsonis excluded by!**/generated/**public/generated/generatedAssetData.json.bris excluded by!**/generated/**public/generated/generatedAssetData.json.gzis excluded by!**/*.gz,!**/generated/**
📒 Files selected for processing (52)
.env.env.developmentheaders/csps/index.tspackages/caip/src/adapters/coingecko/index.tspackages/caip/src/constants.tspackages/chain-adapters/src/evm/EvmBaseAdapter.tspackages/chain-adapters/src/evm/SecondClassEvmAdapter.tspackages/chain-adapters/src/evm/index.tspackages/chain-adapters/src/types.tspackages/contracts/src/ethersProviderSingleton.tspackages/contracts/src/viemClient.tspackages/hdwallet-coinbase/src/coinbase.tspackages/hdwallet-core/src/ethereum.tspackages/hdwallet-core/src/wallet.tspackages/hdwallet-gridplus/src/gridplus.tspackages/hdwallet-keepkey/src/keepkey.tspackages/hdwallet-ledger/src/ledger.tspackages/hdwallet-metamask-multichain/src/shapeshift-multichain.tspackages/hdwallet-native/src/ethereum.tspackages/hdwallet-phantom/src/phantom.tspackages/hdwallet-trezor/src/trezor.tspackages/hdwallet-vultisig/src/vultisig.tspackages/hdwallet-walletconnectv2/src/walletconnectV2.tspackages/swapper/src/swappers/RelaySwapper/constant.tspackages/swapper/src/swappers/RelaySwapper/utils/relayTokenToAssetId.tspackages/types/src/base.tspackages/types/src/zerion.tspackages/utils/src/assetData/baseAssets.tspackages/utils/src/assetData/getBaseAsset.tspackages/utils/src/chainIdToFeeAssetId.tspackages/utils/src/getAssetNamespaceFromChainId.tspackages/utils/src/getChainShortName.tspackages/utils/src/getNativeFeeAssetReference.tsscripts/generateAssetData/generateAssetData.tsscripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.tsscripts/generateAssetData/generateRelatedAssetIndex/generateRelatedAssetIndex.tssrc/components/TradeAssetSearch/hooks/useGetPopularAssetsQuery.tsxsrc/config.tssrc/constants/chains.tssrc/context/PluginProvider/PluginProvider.tsxsrc/context/WalletProvider/WalletConnectV2/config.tssrc/hooks/useWalletSupportsChain/useWalletSupportsChain.tssrc/lib/account/evm.tssrc/lib/asset-service/service/AssetService.tssrc/lib/coingecko/utils.tssrc/pages/Markets/components/MarketsRow.tsxsrc/plugins/activePlugins.tssrc/state/slices/opportunitiesSlice/mappings.tssrc/state/slices/portfolioSlice/utils/index.tssrc/state/slices/preferencesSlice/preferencesSlice.tssrc/test/mocks/store.tssrc/vite-env.d.ts
💤 Files with no reviewable changes (1)
- scripts/generateAssetData/generateRelatedAssetIndex/generateChainRelatedAssetIndex.ts
🚧 Files skipped from review as they are similar to previous changes (9)
- src/context/PluginProvider/PluginProvider.tsx
- packages/utils/src/getAssetNamespaceFromChainId.ts
- packages/contracts/src/ethersProviderSingleton.ts
- src/state/slices/opportunitiesSlice/mappings.ts
- src/constants/chains.ts
- src/lib/account/evm.ts
- packages/hdwallet-trezor/src/trezor.ts
- packages/hdwallet-vultisig/src/vultisig.ts
- packages/hdwallet-gridplus/src/gridplus.ts
… rename - export `ethereal` chain from viemClient, add to walletConnectV2OptionalChains + rpcMap - scope direct ERC20 receive fallback in SecondClassEvmAdapter to celoChainId only - align VITE_FLOW_EVM_NODE_URL rename: viemClient, WalletConnectV2/config, vite-env.d.ts - fix .env base VITE_ETHEREAL_NODE_URL to use rpc.ethereal.trade (browser-compat endpoint) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Contributor
|
done @coderabbitai, f9beb59 |
Contributor
|
Tip For best results, initiate chat on the files or code changes. 🧩 Analysis chain🏁 Script executed: Length of output: 6762
I can see you've pushed fixes addressing several review items in
Issue 🧠 Learnings used |
Contributor
There was a problem hiding this comment.
🧹 Nitpick comments (1)
.env (1)
167-167:VITE_FLOW_EVM_NODE_URLmatches the hardcoded fallback — no transport redundancy.
viemFlowEvmClient(line 191 inviemClient.ts) declares:[process.env.VITE_FLOW_EVM_NODE_URL, 'https://mainnet.evm.nodes.onflow.org']Since both resolve to the same URL, the
fallbacktransport degrades to a single endpoint with no actual resilience benefit. Consider using a distinct secondary public RPC (e.g.https://flowmainnet.gateway.tenderly.coor an Ankr endpoint) as the hardcoded fallback, or dropping the duplicate entry.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In @.env at line 167, The environment variable VITE_FLOW_EVM_NODE_URL equals the hardcoded fallback URL, so the viemFlowEvmClient fallback transport (where [process.env.VITE_FLOW_EVM_NODE_URL, 'https://mainnet.evm.nodes.onflow.org'] is used) provides no redundancy; fix by updating either the env value or the fallback literal to a distinct public RPC endpoint (e.g., 'https://flowmainnet.gateway.tenderly.co' or another provider) or remove the duplicate fallback entry so viemFlowEvmClient actually has multiple unique endpoints for resilience.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In @.env:
- Line 167: The environment variable VITE_FLOW_EVM_NODE_URL equals the hardcoded
fallback URL, so the viemFlowEvmClient fallback transport (where
[process.env.VITE_FLOW_EVM_NODE_URL, 'https://mainnet.evm.nodes.onflow.org'] is
used) provides no redundancy; fix by updating either the env value or the
fallback literal to a distinct public RPC endpoint (e.g.,
'https://flowmainnet.gateway.tenderly.co' or another provider) or remove the
duplicate fallback entry so viemFlowEvmClient actually has multiple unique
endpoints for resilience.
ℹ️ Review info
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Disabled knowledge base sources:
- Linear integration is disabled
You can enable these sources in your CodeRabbit configuration.
📒 Files selected for processing (5)
.envpackages/chain-adapters/src/evm/SecondClassEvmAdapter.tspackages/contracts/src/viemClient.tssrc/context/WalletProvider/WalletConnectV2/config.tssrc/vite-env.d.ts
🚧 Files skipped from review as they are similar to previous changes (2)
- src/context/WalletProvider/WalletConnectV2/config.ts
- packages/chain-adapters/src/evm/SecondClassEvmAdapter.ts
- restore flowEvmAssetId to FEE_ASSET_IDS in constants.ts - restore blastAssetId, bobAssetId, cronosAssetId, hemiAssetId, modeAssetId, soneiumAssetId, sonicAssetId, unichainAssetId, worldChainAssetId, zkSyncEraAssetId imports and manualRelatedAssetIndex entries in generateChainRelatedAssetIndex - restore sonicAssetId, cronosAssetId imports and manualRelatedAssetIndex entries in generateRelatedAssetIndex; remove triplicate katanaAssetId/megaethAssetId entries Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
No await expression used - sync is correct here. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…nshots - yarn generate:chain story: Story IP native asset was missing (0 entries for eip155:1514) - yarn generate:chain plume: Plume PLUME native was missing (0 entries for eip155:98866), now 54 assets - yarn generate:chain celo: Celo had no ERC20s (0 entries for eip155:42220), now 39 assets - add e2e/screenshots/evm_chains_batch/ with one screenshot per chain (16 chains) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
gomesalexandre
approved these changes
Feb 25, 2026
Contributor
There was a problem hiding this comment.
agent-browser retested all (without retesting Tx execution) and confirmed happy, see screenshots:
All 16 second-class EVM chains verified in Trade page asset selector - chain icon, native asset, and popular tokens all loading correctly.
3 gaps found and fixed:
- Story: IP native asset was missing -
yarn generate:chain story(0 entries foreip155:1514) - Plume: PLUME native missing -
yarn generate:chain plume(0 entries foreip155:98866, now 54 assets) - Celo: only native CELO, no ERC20s -
yarn generate:chain celo(0 entries foreip155:42220, now 39 assets)
Ethereal USDe-as-native confirmed correct by design (Ethena-based chain, ethereal/index.ts intentionally returns native only).
Screenshots (one per chain):
| Chain | Screenshot |
|---|---|
| Mantle |  |
| Cronos |  |
| Sonic |  |
| Unichain |  |
| BOB |  |
| Mode |  |
| Soneium |  |
| Hemi |  |
| World Chain |  |
| Blast |  |
| zkSync Era |  |
| Story |  |
| Plume |  |
| Flow EVM |  |
| Celo |  |
| Ethereal |  |
… term) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…earch term) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
…this PR) Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- reset coingecko/index.ts to origin/develop (pure ordering artifact, no ethereal) - reset flowEvm/index.tsx, coingecko/utils.ts to origin/develop (FLOWEVM rename out of scope) - reset vite-env.d.ts, config.ts to origin/develop then add VITE_ETHEREAL_NODE_URL + VITE_FEATURE_ETHEREAL Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- rename VITE_FLOW_EVM_NODE_URL → VITE_FLOWEVM_NODE_URL across .env, .env.development, and headers/csps/chains/flowEvm.ts - rename VITE_FEATURE_FLOW_EVM → VITE_FEATURE_FLOWEVM to match what src/config.ts expects - VITE_FLOWEVM_NODE_URL was missing (no default in config.ts), causing config validation to silently fail and preventing VITE_FEATURE_ETHEREAL from loading Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Add support for Ethereal (EVM chain, chainId 5064014) as a second-class citizen. Ethereal is an Ethena-powered chain that uses USDe (a stablecoin) as its native gas token.
This is PR 16 of 17 in a sequential chain integration series. These PRs must be reviewed and merged in order, as each builds on the previous one (stacked branches).
PR merge order:
Note: Ethereal is not yet listed on CoinGecko, so price feeds are not available. It also requires a custom viem chain definition since it's not in the viem/chains package.
Implements: CAIP constants, chain adapter (SecondClassEvmAdapter), plugin, feature flag, Relay swapper mapping, HDWallet support flags, CSP headers, asset generation script, custom viem chain definition, ethers provider configuration, Zerion portfolio tracking, and all required shared-file entries.
Issue (if applicable)
Part of #11902
Risk
Low - All changes are behind the
Etherealfeature flag (VITE_FEATURE_ETHEREAL), disabled by default in production.No new on-chain transactions or contract interactions. Standard EVM chain support using existing SecondClassEvmAdapter pattern.
Testing
Engineering
VITE_FEATURE_ETHEREAL=truein.env.developmentyarn devyarn lint— passes with 0 errorsyarn type-check— verify no new type errorsOperations
Screenshots (if applicable)
N/A - Behind feature flag, no visual changes until enabled.
Summary by CodeRabbit
New Features
Bug Fixes
Lines changed: +9/-7