You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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:
memo-path
.ibc-gen-shielded
command. Either using the source or target chain's channel ID.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.
The text was updated successfully, but these errors were encountered: