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.

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

Are shielded IBC transfers via memo broken? #2749

Closed
zenodeapp opened this issue Feb 27, 2024 · 4 comments
Closed

Are shielded IBC transfers via memo broken? #2749

zenodeapp opened this issue Feb 27, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@zenodeapp
Copy link
Contributor

zenodeapp commented Feb 27, 2024

Hi,

I haven't seen anyone speak on this, so I'm not sure if it's actually a bug or I'm doing something wrong.

Though I think I've tried every possible combination for trying to get external assets from another chain to a shielded address in our chain. I even attempted to use a namada <=> namada IBC, but this failed as well. Is there maybe something up with the hex value generated via the ibc-gen-shielded command? Or are maybe these generated values always outdated (because of the now used shielded-sync method)? If it's the latter and time dictates whether a hex value is valid or not, then this would be a flaw in the MASP's proofing design.

I've tested:

  • Sending foreign assets shielded from chain B to chain A (namada is A).
  • Sending foreign assets shielded from Namada to Namada using the memo-path.
  • Sending the native naan token back, for this I generated a memo using the tokens tnam address but also tried to use the IBC/channel-etc denominator.
  • the tnam- and ibc/channel-formatted denoms I also tried with foreign assets.
  • I've tried playing around with the channel ID I placed in the ibc-gen-shielded command. Either using the source or target chain's channel ID.
  • I tried sending it to shielded payment addresses, to shielded view addresses, even to MASP 😅. At some point I thought it worked like an exchange, which I think this logic is coming from?
  • I thought perhaps the memo file's hex should be encapsulated by "" (like tx-dumps are) , so I also tried doing that, but alas to no avail.

I'm not sure if I covered everything above that I've attempted. But I really couldn't get it to work. Shielded IBC transfers do work from Namada to chain B though.

@zenodeapp zenodeapp added the bug Something isn't working label Feb 27, 2024
@zenodeapp
Copy link
Contributor Author

As a reference to what I thought to be the standard method (from which I later on started to deviate due to it not working):
#2308 (comment)

(For Namada <=> Namada I used the memo-path field instead to get it from B to A.)

@zenodeapp
Copy link
Contributor Author

Oh, oh! I see it being fixed in latest release 0.31.7.

Thank you @yito88 => #2634

@cpp-phoenix
Copy link
Contributor

cpp-phoenix commented Mar 2, 2024

I guess this issue should be closed then

@zenodeapp
Copy link
Contributor Author

I guess this issue should be closed then

Ah yes, I guess so!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants