Fix ibc-gen-shielded to receive a non-Namada token #2311
Conversation
sdk/src/rpc.rs
Outdated
| None => { | ||
| return context | ||
| .wallet() | ||
| .await | ||
| .find_address(token.as_ref()) | ||
| .map(|addr| addr.to_string()) | ||
| .unwrap_or(token.as_ref().to_string()); | ||
| } |
There was a problem hiding this comment.
is this the correct behavior? users could have populated their wallet with an alias that might coincide with some other chain's address format. it's odd, but certainly possible. perhaps we should document in the cli the order of parsing/look-ups
There was a problem hiding this comment.
Good point. We shouldn't look up the token address with the wallet of the destination chain.
When ibc-gen-shielded is requested, a user is trying to send the token of another chain. A user should be able to get the raw address of the token on the source chain.
And, if the token address is invalid, though the proof will be generated, the following ibc-transfer will fail.
(When query_ibc_denom is called from ibc-transfer, the token should be parsed and this Err branch shouldn't be reached.)
| @@ -0,0 +1,2 @@ | |||
| - Non-Namada token can be given to ibc-gen-shielded | |||
There was a problem hiding this comment.
I think we also need another changelog for the sdk updates
* origin/yuji/fix-ibc-gen-shielded: add SDK changelog fix parsing token address add changelog non-namada token to ibc-gen-shielded
* origin/yuji/fix-ibc-gen-shielded: fix e2e test add SDK changelog fix parsing token address add changelog non-namada token to ibc-gen-shielded
* origin/yuji/fix-ibc-gen-shielded: fix e2e test add SDK changelog fix parsing token address add changelog non-namada token to ibc-gen-shielded
Describe your changes
closes #2308
closes #2309
ibc-gen-shieldedshould get not only a Namada token but also a non-Namada token to transfer it from non-Namada chainsIndicate on which release or other PRs this topic is based on
v0.28.1Checklist before merging to
draft