chore: Change blockExplorerLink function to support Tron#1379
chore: Change blockExplorerLink function to support Tron#1379dijanin-brat wants to merge 11 commits intopxrl/tronfrom
Conversation
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
Signed-off-by: bennett <bennett@umaproject.org>
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3d7923743c
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| export function chainIsEvm(chainId: number): boolean { | ||
| // TODO: Update when additional execution layers beyond EVM and SVM are supported. | ||
| return PUBLIC_NETWORKS[chainId]?.family !== ChainFamily.SVM; | ||
| return PUBLIC_NETWORKS[chainId]?.family !== ChainFamily.SVM && PUBLIC_NETWORKS[chainId]?.family !== ChainFamily.TVM; |
There was a problem hiding this comment.
Keep TVM out of global unsupported-chain paths
Changing chainIsEvm to return false for TVM chains introduces runtime failures in existing call sites that only branch on EVM vs SVM; for example, getWidestPossibleExpectedBlockRange in src/clients/BundleDataClient/utils/PoolRebalanceUtils.ts only handles chainIsEvm and chainIsSvm then assert(false) for anything else. After this change, passing a TRON chain ID now hits that assert and aborts bundle-range computation, whereas it previously followed the EVM path. If TVM isn’t fully supported across those paths yet, this helper change should be scoped or paired with TVM branches in those callers.
Useful? React with 👍 / 👎.
| if (txHexNoPrefix.length === 64 && ethers.utils.isHexString(`0x${txHexNoPrefix}`)) { | ||
| const txIdForUrl = txHexNoPrefix.toLowerCase(); | ||
| return `<${constructURL(explorerDomain, ["#", "transaction", txIdForUrl])} | ${shortURLString}>`; | ||
| } |
There was a problem hiding this comment.
I'm surprised that this function mixes both /txn and /address in here. For future, we probably want to split that apart - i.e. the top-level function might want to discriminate between txn and address and then farm that out to the right underlying translation based on chainId / chain family.
No description provided.