Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

chore: update Base & Polygon ERC-20 custody addresses #430

Merged
merged 3 commits into from
Nov 26, 2024
Merged

chore: update Base & Polygon ERC-20 custody addresses #430

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
6783942
chore: update erc20 custody addresses
fadeev Nov 22, 2024
3c3c527
yarn generate with updated foundry
fadeev Nov 22, 2024
74e19ba
BNB, Ethereum, sBTC
fadeev Nov 26, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 4 additions & 6 deletions v2/data/addresses.mainnet.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,3 @@


[
{
"address": "0x000007Cf399229b2f5A4D043F20E90C9C98B7C6a",
Expand All @@ -9,7 +7,7 @@
"type": "connector"
},
{
"address": "0x0000030Ec64DF25301d8414eE5a29588C4B0dE10",
"address": "0x0Bad40D9e9C369f2223c835E108f43a45fd223B5",
"category": "omnichain",
"chain_id": 1,
"chain_name": "eth_mainnet",
Expand Down Expand Up @@ -72,7 +70,7 @@
"type": "connector"
},
{
"address": "0x00000fF8fA992424957F97688015814e707A0115",
"address": "0x0Bad40D9e9C369f2223c835E108f43a45fd223B5",
"category": "omnichain",
"chain_id": 56,
"chain_name": "bsc_mainnet",
Expand Down Expand Up @@ -100,7 +98,7 @@
"type": "connector"
},
{
"address": "0x69727Ef241ebD6e42Fc3A798092077069B415B2D",
"address": "0x0Bad40D9e9C369f2223c835E108f43a45fd223B5",
"category": "omnichain",
"chain_id": 137,
"chain_name": "polygon_mainnet",
Expand Down Expand Up @@ -398,7 +396,7 @@
"type": "connector"
},
{
"address": "0x53b0705194e686Ba745eF8A80cB1Ef355dE645D0",
"address": "0x0Bad40D9e9C369f2223c835E108f43a45fd223B5",
"category": "omnichain",
"chain_id": 8453,
"chain_name": "base_mainnet",
Expand Down
22 changes: 20 additions & 2 deletions v2/data/addresses.testnet.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,5 +1,3 @@


[
{
"address": "0x0000ecb8cdd25a18f12daa23f6422e07fbf8b9e1",
Expand Down Expand Up @@ -203,13 +201,33 @@
"symbol": "tBNB",
"type": "zrc20"
},
{
"address": "0xdbfF6471a79E5374d771922F2194eccc42210B9F",
"asset": "",
"category": "omnichain",
"chain_id": 7001,
"chain_name": "zeta_testnet",
"coin_type": "gas",
"decimals": 8,
"description": "sBTC.sBTC",
"foreign_chain_id": "18333",
"symbol": "sBTC",
"type": "zrc20"
},
{
"address": "tb1qy9pqmk2pd9sv63g27jt8r657wy0d9ueeh0nqur",
"category": "omnichain",
"chain_id": 18332,
"chain_name": "btc_testnet",
"type": "tss"
},
{
"address": "tb1qy9pqmk2pd9sv63g27jt8r657wy0d9ueeh0nqur",
"category": "omnichain",
"chain_id": 18333,
"chain_name": "empty",
"type": "tss"
},
{
"address": "0x60E6b70bC2761f878Ff992276612F67FbABC1761",
"category": "messaging",
Expand Down
4 changes: 2 additions & 2 deletions v2/lib/types.ts
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
export type ParamSymbol = "USDC.BSC" | "USDC.ETH" | "BTC.BTC" | "ETH.BASE" | "PEPE.ETH" | "BNB.BSC" | "SHIB.ETH" | "USDT.ETH" | "USDT.BSC" | "USDC.BASE" | "POL.POLYGON" | "DAI.ETH" | "ULTI.BSC" | "ETH.ETH" | "USDT.POL" | "ULTI.ETH" | "USDC.POL" | "sETH.SEPOLIA" | "ETH.BASESEPOLIA" | "tBTC" | "MATIC.AMOY" | "USDC" | "SOL.SOLANA" | "USDC.SEPOLIA" | "tBNB";
export type ParamChainName = "eth_mainnet" | "bsc_mainnet" | "polygon_mainnet" | "zeta_mainnet" | "btc_mainnet" | "base_mainnet" | "bsc_testnet" | "solana_devnet" | "zeta_testnet" | "btc_testnet" | "amoy_testnet" | "base_sepolia" | "sepolia_testnet";
export type ParamSymbol = "USDC.BSC" | "USDC.ETH" | "BTC.BTC" | "ETH.BASE" | "PEPE.ETH" | "BNB.BSC" | "SHIB.ETH" | "USDT.ETH" | "USDT.BSC" | "USDC.BASE" | "POL.POLYGON" | "DAI.ETH" | "ULTI.BSC" | "ETH.ETH" | "USDT.POL" | "ULTI.ETH" | "USDC.POL" | "sETH.SEPOLIA" | "ETH.BASESEPOLIA" | "tBTC" | "MATIC.AMOY" | "USDC" | "SOL.SOLANA" | "USDC.SEPOLIA" | "tBNB" | "sBTC";
export type ParamChainName = "eth_mainnet" | "bsc_mainnet" | "polygon_mainnet" | "zeta_mainnet" | "btc_mainnet" | "base_mainnet" | "bsc_testnet" | "solana_devnet" | "zeta_testnet" | "btc_testnet" | "empty" | "amoy_testnet" | "base_sepolia" | "sepolia_testnet";
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Codebase verification

Add network suffix to "sBTC" for consistency

The codebase follows a consistent pattern where test tokens (prefixed with 's' or 't') include their network suffix (e.g., "sETH.SEPOLIA"). The newly added "sBTC" lacks this network designation, breaking this established pattern. This inconsistency could lead to confusion or potential issues in network-specific handling.

  • Consider updating "sBTC" to include its network, e.g., "sBTC.SEPOLIA" if it's meant for the Sepolia network
  • Other test tokens in the codebase: "sETH.SEPOLIA", "tBTC", "tBNB", "tMATIC" all maintain consistent naming
🔗 Analysis chain

Verify the naming pattern for "sBTC"

The newly added "sBTC" symbol deviates from the established pattern where tokens include their network (e.g., "USDC.BSC", "sETH.SEPOLIA"). While this might be intentional, we should verify its usage.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check how "sBTC" is used in the codebase and verify if this naming is consistent

# Search for any references to sBTC in the codebase
echo "Searching for sBTC usage:"
rg "sBTC" --type ts

# Search for similar test token patterns to compare
echo -e "\nSearching for similar test token patterns:"
rg "s[A-Z]+\.[A-Z]+" --type ts

Length of output: 1628

export type ParamType = "connector" | "erc20Custody" | "tss" | "uniswapV2Factory" | "uniswapV2Router02" | "uniswapV3Factory" | "uniswapV3Router" | "weth9" | "zetaToken" | "fungibleModule" | "systemContract" | "zrc20" | "custody" | "gateway";
Copy link
Contributor

Choose a reason for hiding this comment

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

💡 Codebase verification

Based on the implementation of getAddress and its usage, I can now provide a final response:

The "empty" chain type could lead to runtime errors

The getAddress function directly uses the network parameter to query addresses from a network list by matching chain_name. Using "empty" as a chain name will always result in undefined address since there's no corresponding network configuration with chain_name === "empty". This could lead to runtime errors when the function is called.

  • The getAddress implementation in v2/lib/addresses.ts uses chain_name === network for lookups
  • No special handling exists for the "empty" case
  • This will cause address to be undefined, leading to potential runtime errors

Consider these alternatives:

  1. Use undefined | null for uninitialized states instead of "empty"
  2. Add proper handling in getAddress if "empty" is a valid special case
  3. Use a discriminated union if this represents a distinct state: type ParamChainName = NetworkChain | { type: "uninitialized" }
🔗 Analysis chain

Consider a more type-safe alternative to "empty"

The addition of "empty" to ParamChainName deviates from the established network naming pattern and might introduce potential type-safety issues. Consider these alternatives:

  1. Use a separate type union with undefined/null if this represents an uninitialized state
  2. Create a discriminated union if this represents a special case

Example:

type NetworkChainName = "eth_mainnet" | "bsc_mainnet" | /* ... */;
type ParamChainName = NetworkChainName | { type: "empty" };

Let me gather more context about how this type is used in the codebase.

Let me search for the actual usage of this type in function calls to understand how "empty" is being used.

Let me check one more thing - looking at how this type is used in the codebase, particularly in the getAddress function implementation.

🏁 Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Check how "empty" chain name is used to understand its purpose

# Search for usage of empty chain name
echo "Searching for empty chain usage:"
rg '"empty"' --type ts -C 3

# Look for similar patterns that might indicate uninitialized states
echo -e "\nSearching for similar initialization patterns:"
ast-grep --pattern 'type $_ = $_ | "empty" | $_'

Length of output: 1198

Script:

#!/bin/bash
# Search for ParamChainName usage to understand the context
echo "Searching for ParamChainName usage:"
rg "ParamChainName" --type ts -C 4

# Search for any function or variable that handles chain initialization
echo -e "\nSearching for chain initialization patterns:"
rg "chain.*(?:init|empty)" --type ts -C 4

Length of output: 5068

Script:

#!/bin/bash
# Search for getAddress function calls to see how the network parameter is used
echo "Searching for getAddress function calls:"
ast-grep --pattern 'getAddress($_, $network, $_)'

# Search for any string literals containing "empty" in typescript files
echo -e "\nSearching for 'empty' string literals in ts files:"
rg '"empty"' --type ts -A 2 -B 2

# Look for test files that might explain the usage
echo -e "\nSearching for test files containing 'empty':"
fd -e test.ts -e spec.ts -x rg -l "empty" {}

Length of output: 1392

Script:

#!/bin/bash
# Look at the implementation of getAddress to see how it handles the network parameter
echo "Searching for getAddress implementation:"
rg -A 15 "export const getAddress = \(.*\)" --type ts

# Check if there are any other files that might use "empty" chain
echo -e "\nSearching for files importing ParamChainName:"
rg "import.*ParamChainName" --type ts

Length of output: 3542


Loading