-
Notifications
You must be signed in to change notification settings - Fork 59
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.
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
Refactor addresses.json
to account for ZRC-20 of ERC-20s
#89
Comments
adresses.json
to account for ERC-20sadresses.json
to account for ZRC-20 for ERC-20s
adresses.json
to account for ZRC-20 for ERC-20sadresses.json
to account for ZRC-20 of ERC-20s
We also probably need a convention to label tokens from different chains. For example, when using the swap example you want swap USDC for gETH on Goerli:
If there is no denom ( |
If we ever need to specify both a chain and a token, we can do something like |
Should we do something like: "zevm": {
"goerli_testnet": {
"zrc20": [
{
"symbol": "gETH",
"zrc20_contract_address": "0x13A0c5930C028511Dc02665E7285134B6d11A5f4"
},
{
"symbol": "USDC",
"zrc20_contract_address": "0x0cbe0dF132a6c6B4a2974Fa1b7Fb953CF0Cc798a"
}
]
},
} Using the structure from the foreign coins API for consistency. |
@andresaiello @lucas-janon I really think we should start thinking about a new structure for |
How about simplifying the structure: [
{
"chain": "goerli_testnet",
"type": "zetaToken",
"address": "0x5b1869D9A4C187F2EAa108f3062412ecf0526b24",
"category": "messaging"
},
{
"chain": "goerli_testnet",
"type": "tss",
"address": "0x5b1869D9A4C187F2EAa108f3062412ecf0526b24",
"category": "omnichain"
},
{
"chain": "zeta_testnet",
"type": "zrc20",
"symbol": "USDC",
"address": "0x5b1869D9A4C187F2EAa108f3062412ecf0526b24",
"category": "omnichain"
},
{
"chain": "zeta_testnet",
"type": "zrc20",
"symbol": "gETH",
"address": "0x5b1869D9A4C187F2EAa108f3062412ecf0526b24",
"category": "omnichain"
}
] A flat array structure will let us add more metadata to addresses if needed.
Symbol is optional, this way the function is backwards compatible.
The following will throw an error and we can make the error very discriptive by listing all valid options calculated automatically from the JSON:
We can also run a script to validate the JSON and generate the types from it as well. |
@lucas-janon @andresaiello please, provide feedback on this! We still don't have USDC in our JSON |
I think we can have two models, tokens and non tokens. For tokens I like
|
@andresaiello but they will still be in a single array like so, right? {
"chain": "goerli_testnet",
"type": "tss",
"address": "0x5b1869D9A4C187F2EAa108f3062412ecf0526b24",
"category": "omnichain"
},
{
"zrc20_contract_address": "0x91d4F0D54090Df2D81e834c3c8CE71C6c865e79F",
"asset": "0x9999f7fea5938fd3b1e26a12c3f2fb024e194f97",
"foreign_chain_id": "80001",
"decimals": 6,
"name": "USDC-mumbai_testnet",
"symbol": "USDC",
"coin_type": "ERC20",
"gas_limit": "100000",
"paused": false
}, |
adresses.json
to account for ZRC-20 of ERC-20saddresses.json
to account for ZRC-20 of ERC-20s
I've updated the script and now it generates addresses in the updated format: |
Currently we have only 1 ZRC-20 per chain:
protocol-contracts/data/addresses.json
Lines 121 to 137 in 6005f22
On chain "foreign coins":
Source: https://zetachain-athens.blockpi.network/lcd/v1/public/zeta-chain/zetacore/fungible/foreign_coins
cc @lucas-janon @andresaiello
The text was updated successfully, but these errors were encountered: