FE: add polygon native USDC and FRAX #1627
Conversation
ChiTimesChi
requested review from
bigboydiamonds,
abtestingalpha,
nautsimon and
aureliusbtc
as code owners
WalkthroughThe updates across various files in the Synapse Interface codebase reflect a significant enhancement of the bridge mapping logic, including the addition of new token addresses and chain IDs, as well as updates to contract addresses. These changes suggest an expansion of supported networks and tokens, and an update to the routing infrastructure within the platform. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on X ? TipsChat with CodeRabbit Bot (
|
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #1627 +/- ##
=============================================
Coverage 51.34971% 51.34971%
=============================================
Files 362 362
Lines 24746 24746
Branches 284 284
=============================================
Hits 12707 12707
Misses 10802 10802
Partials 1237 1237
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 0
Configuration used: CodeRabbit UI
Files selected for processing (4)
- packages/synapse-interface/constants/bridgeMap.ts (3 hunks)
- packages/synapse-interface/constants/tokens/bridgeable.ts (1 hunks)
- packages/synapse-interface/scripts/generateMaps.js (2 hunks)
- packages/synapse-interface/utils/actions/fetchPortfolioBalances.tsx (1 hunks)
Additional comments: 13
packages/synapse-interface/constants/bridgeMap.ts (6)
521-531: The addition of
USDC.ewith the specifiedoriginanddestinationarrays, as well as theswappableaddresses, aligns with the PR's objective to support more routes for swapping USDC.e and DAI on the Polygon network.541-552: The addition of a new entry for
USDCon the Polygon network with theorigin,destination, andswappableaddresses specified is consistent with the PR's goal to add support for Polygon native USDC.554-565: The addition of
FRAXwith theoriginanddestinationarrays, as well as theswappableaddresses, is in line with the PR's objective to add support for FRAX. However, it's important to note that the PR mentions the on-chain liquidity for FRAX is currently smaller compared to other coins, which may affect its usability and should be communicated to users.570-577: The changes to the
DAIentry, including the updatedoriginanddestinationarrays and the addition of newswappableaddresses, support the PR's objective to introduce more routes for swapping on the Polygon network.583-590: The addition of
nUSDwith the updatedoriginanddestinationarrays, as well as the newswappableaddresses, aligns with the PR's objective to enhance the swapping functionality on the Polygon network.603-611: The changes to the
USDTentry, including the updatedoriginanddestinationarrays and the addition of newswappableaddresses, support the PR's objective to introduce more routes for swapping on the Polygon network.packages/synapse-interface/constants/tokens/bridgeable.ts (1)
- 634-640: The addition of the Polygon chain token address for the FRAX token is consistent with the PR objectives and follows the established pattern for token definitions in the file. The priority rank is set correctly according to the file's comments on priority ranks.
packages/synapse-interface/scripts/generateMaps.js (3)
29-34: The contract addresses for
SynapseCCTPRouterAddressandSynapseCCTPAddresshave been updated, and a new chain ID137has been added to theallowedChainIdsForSynapseCCTPRouterarray. Ensure that these changes are consistent with the new contract deployments and that the new chain ID is correctly integrated into the application's routing logic.60-66: The instantiation of
SynapseCCTPshas been modified to use the newSynapseCCTPAddressfor all chain IDs. Confirm that this change is intended and that it does not negatively impact any functionality that previously depended on different addresses for different chains.27-37: > Note: This review was outside the patches, so it was mapped to the patch with the greatest overlap. Original lines [27-66]
Review the entire
generateMaps.jsfile to ensure that the updated contract addresses and the addition of the new chain ID are correctly used in all relevant parts of the script, and that they align with the PR's objective of enhancing functionality for the Polygon network.packages/synapse-interface/utils/actions/fetchPortfolioBalances.tsx (3)
- 8-8: <!--Monologue:
Thought 1: The search forROUTER_ADDRESSreturned multiple results, including some that reference a different address (0x7E7A0e201FD38d3ADAA9523Da6C109a07118C96a).
Reflect 1: This suggests that there are multiple router addresses being used in the codebase, which could be for different purposes or networks. It's important to note that theCCTP_ROUTER_ADDRESSis distinct from theROUTER_ADDRESS.Thought 2: The
CCTP_ROUTER_ADDRESSis consistently used in the files where it's expected to be used, based on the search results.
Reflect 2: This is a good sign that the update has been made correctly for theCCTP_ROUTER_ADDRESS.Thought 3: The broader context search for the new
CCTP_ROUTER_ADDRESSshows it's being used in the expected manner, with no unexpected occurrences.
Reflect 3: This indicates that the update to the new router address has been done correctly and is not used in any incorrect context.Thought 4: The presence of both
ROUTER_ADDRESSandCCTP_ROUTER_ADDRESSin the same files suggests that they are used for different purposes or contracts within the application.
Reflect 4: This is a common pattern in applications that interact with multiple smart contracts or services, where each service might have its own address.Thought 5: The
ROUTER_ADDRESS_MAPandCCTP_ROUTER_ADDRESS_MAPin thesdk-routerpackage indicate that there are mappings for these addresses, which are likely used to handle different chains or contexts.
Reflect 5: This is a standard approach to handle different environments or networks in blockchain applications.Thought 6: There are no indications that the old
CCTP_ROUTER_ADDRESSis still being used, and the new one is correctly implemented in the places it's referenced.
Reflect 6: This suggests that the update has been done correctly and there are no issues with the router address update.Conclusion: The verification process has not revealed any issues with the update of the
CCTP_ROUTER_ADDRESS. The new address is used consistently across the codebase, and there are no remnants of the old address. The presence of different router addresses for different purposes is acknowledged and does not indicate an issue.
-->The
CCTP_ROUTER_ADDRESShas been successfully updated across the codebase, and the new address is being used consistently in the expected files. There are no instances of the old address remaining, and the presence of different router addresses for distinct purposes is correctly handled. The verification process has not revealed any issues with the update of theCCTP_ROUTER_ADDRESS.Analysis chain
The
CCTP_ROUTER_ADDRESSconstant has been updated. Verify that this new address is correctly used wherever theROUTER_ADDRESSis referenced, and ensure that any functionality relying on the router's address is tested to confirm that it interacts correctly with the updated address.* 7-7:Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for the old router address to ensure it's no longer used. rg '0xd359bc471554504f683fbd4f6e36848612349ddf' # Search for the new router address to ensure it's being used consistently. rg '0xd5a597d6e7ddf373a92C8f477DAAA673b0902F48'Length of output: 492
Script:
#!/bin/bash # Search for any other potential router address constants or variables that might not have been updated. rg 'ROUTER_ADDRESS' --ignore-case # Search for the new router address in a broader context to ensure it's not used incorrectly. rg '0xd5a597d6e7ddf373a92C8f477DAAA673b0902F48' -C 3Length of output: 7969
The presence of both
ROUTER_ADDRESSandCCTP_ROUTER_ADDRESSin the codebase is intentional, and their usage is distinct and correct. They are used in different contexts and serve different purposes, as evidenced by their usage in various parts of the codebase, including conditional logic that determines which address to use based on certain conditions. There is no indication thatCCTP_ROUTER_ADDRESSis meant to replaceROUTER_ADDRESS.Analysis chain
Confirm that the presence of both
ROUTER_ADDRESSandCCTP_ROUTER_ADDRESSis intentional and that their usage is correct and distinct within the codebase. IfCCTP_ROUTER_ADDRESSis meant to replaceROUTER_ADDRESS, then all instances ofROUTER_ADDRESSshould be updated accordingly.* 5-9: The changes to `CCTP_ROUTER_ADDRESS` are clear, but the PR objectives mention adding support for new cryptocurrencies and routes. Ensure that the necessary updates to token addresses and routing logic are also included in the PR and are consistent with the updated router address.Scripts Executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for usage of `ROUTER_ADDRESS` to ensure it's being used correctly. rg 'ROUTER_ADDRESS' # Search for usage of `CCTP_ROUTER_ADDRESS` to ensure it's being used correctly. rg 'CCTP_ROUTER_ADDRESS'Length of output: 8162
Deploying with
|
| Latest commit: |
205d7ce
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://41f5b876.sanguine.pages.dev |
| Branch Preview URL: | https://fe-polygon-native-usdc.sanguine.pages.dev |
* update for new tokens (#1623) * feat: Add Polygon support to New CCTP Router Contracts (#1617) * feat: Add Polygon support to SDK Router - Clear CCTP_ROUTER_ADDRESS for future update - Add Polygon to CCTP_SUPPORTED_CHAIN_IDS - Define median time for Polygon in MEDIAN_TIME_CCTP * Add new SynapseCCTpRouter address * Adjust median time for Polygon: 8 minutes * Chore: remove extra line --------- Co-authored-by: ChiTimesChi <[email protected]> * Publish - @synapsecns/[email protected] - @synapsecns/[email protected] - @synapsecns/[email protected] - @synapsecns/[email protected] * Regenerate agents (#1575) * adding cctp contracts to the explorer UI (#1626) * adding cctp contracts * Add Ethereum CCTP contract --------- Co-authored-by: ChiTimesChi <[email protected]> * Publish - @synapsecns/[email protected] * FE: add polygon native USDC and FRAX (#1627) * Update values in generation script * Update CCTP Router Address * Regenerate bridge map * Add FRAX address on Polygon --------- Co-authored-by: bigboydiamonds <[email protected]> * Publish - @synapsecns/[email protected] * adding frax support on polygon (#1631) * Publish - @synapsecns/[email protected] --------- Co-authored-by: Moses <[email protected]> Co-authored-by: aureliusbtc <[email protected]> Co-authored-by: ChiTimesChi <[email protected]> Co-authored-by: bigboydiamonds <[email protected]>
Description
Adds support for Polygon native USDC, more routes for USDC.e/DAI on Polygon. Also adds support for FRAX, although the on-chain liquidity is smaller than for the other coins.
Summary by CodeRabbit
New Features
Enhancements
Bug Fixes
Refactor
620192cb945f9f46798bf4334b80810a010ee1f7: synapse-interface preview link