-
Notifications
You must be signed in to change notification settings - Fork 460
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
Stride to Osmosis IBC Bug for DYM #1093
Comments
Should note on this that ideally I can get a way in Keplr to move these funds out of that dym wallet I clearly have sign rights but how do I access it. Maybe some sort of lost in space sweep Keplr can do. |
Hey, sorry for getting back to you issue so late. The issue has been solved in the most recent version. |
That doesn't make sense for what I'm trying to get to. I need a way to access the Dym address Keplr created from my Cosmos app not the Eth app off the Ledger. Keplr is apparently using that as some sort of transfer address. See above what @bpiv400 stated on twitter. |
Also would like to note that my Keplr version has updated to 0.12.82 |
Understood. However, this is due to a bug, so it's difficult to resolve in the production version. Download keplr-extension-manifest-v2-v0.12.81-dym-temp.1.zip and install it manually as described above. Then, you will be able to create an account with a different dym address. Transfer DYM from there to your main account. |
Im sorry I know your one of the devs that works on it but I have a hard time installing beta or temp builds to work with my Ledger. Why not have a sweet built into keplr to empty out EVM wallets that are used with Ledger. It clearly has sign rights and just gets stuck during an IBC send. |
�It is structurally difficult to support both ethereum app and cosmos app on one chain at the same time. I sent 30DYM to osmosis account "osmo13nhlg7cqspec5e0yv0n6nts3zcmfnc6humte4y", please check. |
I understand and you didnt have to send the DYM. |
Describe the bug
There appears to be an issue where sometimes doing an IBC Send on the Keplr wallet via a Ledger. Keplr appears to be using the Coin type 118. this is Per @bpiv400 on Twitter.
To Reproduce
Steps to reproduce the behavior:
I can produce this everytime using Leap and Ledger.
Both of these have the Ethereum\Dym Address setup and both of them have the same DYM address which is the one not being used.
Expected behavior
Id expect the IBC transfer to transfer as normal
Screenshots
TX: E7DCD4C389215D40EE7B7CD2262F7EC93E1E31B4EEAB61088093F1B0B17E1F65
See how the DYM shows in Keplr but not on Stride this is what made me go duh just buy stDym and transfer it to Stride so here is where I went to Keplr cause no matter what Leap wont send this.
This won’t even populate the tx to sign it just does nothing. Leap prevents the IBC
Leap Errors
So now we go to Keplr and Search Dym and hit Send
Here is the Send Data
`Keplr Tx:
Data: {
"account_number": "15283",
"chain_id": "stride-1",
"fee": {
"gas": "165488",
"amount": [
{
"amount": "828",
"denom": "ustrd"
}
]
},
"memo": "Stride to Osmosis via Keplr Extension. DYM Transfer",
"msgs": [
{
"type": "cosmos-sdk/MsgTransfer",
"value": {
"memo": "{"forward":{"receiver":"dym13nhlg7cqspec5e0yv0n6nts3zcmfnc6hxa50xc","port":"transfer","channel":"channel-19774","forward":{"receiver":"osmo13nhlg7cqspec5e0yv0n6nts3zcmfnc6humte4y","port":"transfer","channel":"channel-2"}}}",
"receiver": "osmo13nhlg7cqspec5e0yv0n6nts3zcmfnc6humte4y",
"sender": "stride13nhlg7cqspec5e0yv0n6nts3zcmfnc6hhtc4h6",
"source_channel": "channel-5",
"source_port": "transfer",
"timeout_height": {
"revision_height": "14807943",
"revision_number": "1"
},
"token": {
"amount": "500000000000000000",
"denom": "ibc/3E039E6F6B10D2062BB1C248E1C8D14FC0D380D809D4BAD216C835323C2AF839"
}
}
}
],
"sequence": "62"
}
`
TX: B7F68EBB595C662676A04EE2E003DDDFC37859A8B8E2B62476948767F23140AF
And now the DYM is stuck in this dym wallet during the IBC transfer (dym13nhlg7cqspec5e0yv0n6nts3zcmfnc6hxa50xc)
my ETH Dym address that is in both Leap and Keplr is dym1sj8zr5qa35de76wu7f2zanmmccu3ad2lt2slfz
Device details (please complete the following information):
Additional context
If you look at that DYM address its using during the transfers some of them go through fine its only randomly that a TX will get stuck.
The text was updated successfully, but these errors were encountered: