feat(tokens): custom token activation for evm #2141
Conversation
| pub struct TendermintTokenProtocolInfo { | ||
| pub platform: String, | ||
| // Todo: can decimals be gotten from rpc call for custom tokens? |
There was a problem hiding this comment.
There is denoms_metadata endpoint available on tendermint, but I am not sure if it works with the custom tokens.
There was a problem hiding this comment.
Thanks for the hint, will give it a look.
… `token_conf` parameter instead
…functions * `get_custom_token_info` RPC now returns `config_ticker` when token exists in config. This allows GUI to detect tokens in config and use them for activation instead of the token being wallet-only. * Move new ERC20 functions to erc20.rs for better organization
shamardy
force-pushed
the
feat-custom-evm-token
branch
from
5879540
to
5fb0bdd
Compare
Also split lp_commands.rs file to multiple files
…add test coverage for `get_custom_token_info` RPC in it
…duplicate contract in the coins config
…t is in coins config
…s another ticker enabled
|
@mariocynicys all the nits are fixed and Qs answered. I will merge this PR once CI passes and docs issue is open. |
There was a problem hiding this comment.
Q: Did you think about populating coins file for custom/unsupported coins? For example, we could provide an RPC interface where people can add any custom coin to our coins file and that eventually would allow them to enable and use that coin in KDF. Wouldn't that be much simpler to handle and maintain in KDF? And that would work fine for any of our supported protocols (e.g., cosmos, evm, etc.).
mm2src/coins/eth/erc20.rs
Outdated
| pub(crate) async fn get_token_decimals(web3: &Web3<Web3Transport>, token_addr: Address) -> Result<u8, String> { | ||
| let tokens = call_erc20_function(web3, token_addr, "decimals").await?; | ||
| match tokens[0] { | ||
| Token::Uint(dec) => Ok(dec.as_u64() as u8), | ||
| _ => ERR!("Invalid decimals type {:?}", tokens), | ||
| } | ||
| } | ||
|
|
||
| async fn get_token_symbol(coin: &EthCoin, token_addr: Address) -> Result<String, String> { | ||
| let web3 = try_s!(coin.web3().await); | ||
| let tokens = call_erc20_function(&web3, token_addr, "symbol").await?; | ||
| match &tokens[0] { | ||
| Token::String(symbol) => Ok(symbol.clone()), | ||
| _ => ERR!("Invalid symbol type {:?}", tokens), | ||
| } | ||
| } |
There was a problem hiding this comment.
I wouldn't try to access index 0 directly as it would panic when tokens is empty.
There was a problem hiding this comment.
unfortunately, we seem to have these all over the eth code (e.g. \[\d\] in eth_taker_swap_v2.rs), and we consider this safe for some reason :/.
i verified how such vecs come and their sizes in a previous PR, but i would still be on the safe side and not have them addressed like that. also reducing tragic effects from dev errors.
There was a problem hiding this comment.
I wouldn't try to access index 0 directly as it would panic when tokens is empty.
Missed this when copying the code. Will fix only the instances in this PR and fix all others in another PR.
There was a problem hiding this comment.
Fixed here f38fc3f
I did consider this and can be part of the next PR mentioned here #2141 (comment)
But I think separating them is better so that updating the coins file is simple since it will remain static. |
…and `get_token_symbol`
I would have consider this seriously before making further progress I guess. For example, this PR is EVM only and already adds ~1k diff on the codebase and it will increase even more once we start supporting other protocols and adding a support for custom coin. All that would be dead simple with adding an RPC function for populating the coins file. If we don't want to make modifications on the coins file, I guess that's fine; we could save them in-memory (the value where we search/find coins from) without modifying the actual file on FS. Is there any big advantage that current approach brings compare to what I just suggested? |
If we didn't count refactors and tests, it's only ~500 diff, the token info RPC code will be reusable across protocols as well and it's absolutely needed for GUI ref. #2141 (comment), same for
The custom config need to be persisted across restarts, which leaves us with two options: modifying the coins file or creating dedicated storage/DB for custom tokens. The process requires more than just adding an RPC function for coins file population - we need comprehensive validation for duplicate tickers, contracts, and other potential conflicts. Most of the validation logic will be necessary regardless of approach. We will also need to make coins config a struct and not just json to deserialize it probably, I reused the I am not against changing the whole approach if it's clear how it will be implemented, but I can't be sure that using the coins file will not bring more complications of it's own that we didn't anticipate. |
I am suggesting that because in the PR it says "for EVM", and in one of the notes there is a comment says something like "we support tokens only for now, not coins". Because of that, I am suggesting that we can handle every coin, token and protocol in a same way we do with coins file, so we don't need to worry about type of the protocol/coin/token. If it needs to be persistent, we could create another file next to coins file called |
At the current stage, adding custom coins should never be supported as it can be dangerous and shouldn't be allowed to be added by the normal user. @cipig does a lot of checks and tests before adding a coin to coins config repo. It's also the reason why custom tokens will be added as wallet only since there are a lot of non standard tokens that will not work right with swaps.
I am not against that ref. #2141 (comment)
This will be done in the next PR maybe with the refactors for coin config structs. Should we use a file or db, we have to use db for wasm though.
Agreed and I actually thought of this :) As I said, adding custom coins is dangerous but we should add some validations such as (for utxo): 1 - Transactions/blocks deserializations This is to make sure the coin will work fine for all wallet functionalities, it will also require adding the RPC urls by the user. For swaps, it's a different thing and will require more thinking about. Can I do this in a later PR? right now EVM custom tokens are needed to be released with 1inch integration so that users can swap any token, wallet only means not working for our cross chain swaps only but will be allowed to work with same chain dexes. |
I think it's better to store customs tokens in a separate file/db (and retain the original coins file intact). |
* dev: chore(release): update v2.2.0-beta date (#2277) chore(release): add changelog entries for v2.2.0-beta (#2240) fix(watchers): align taker fee validation retries with makers (#2263) feat(tokens): custom token activation for evm (#2141) use safer subtraction on healthcheck expiration check (#2272) fix(hd-wallet): correctly display evm addr in `get_new_address` response (#2264)
Adds support for enabling custom EVM (ERC20, PLG20, etc..) tokens without requiring them to be in the coins config. This allows users to interact with any ERC20 token by providing the contract address.
Todo:
Can also add a balance API before token is activated to show balance in GUI, it can be a separate API or the same ticker/symbol RPC.Token should be activated to get the balances of all addresses and scan for addresses to show accurate balance. If it's not imported, it can be disabled again. This way we also call balances only one on import instead of twice.Token logo can be returned as well, but we need to check the url for phishing and sanitize it.Will be handled from GUI.lp_commandswallet_onlyas true if coin is not in config.Next PR:
Custom token config storage and deletion. Deletion should be when token is deactivated.Will be handled from GUI.An RPC to get previously enabled custom tokensWill be handled from GUI.To Test (WIP):
required_confirmationsshould equal to platform's if not set in activation request.