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
When users are allowed to construct their own ICS20 packets through MsgSendPacket, they are allowed to send (hashed) IBC denoms directly without unwrapping the trace path that would have happened if they were using the standard MsgTransfer route.
This allows users to construct two representations for the same escrowed token using the same channel. This might have broader impacts then I'm anticipating at the moment.
Expected Behaviour
Hashed IBC denoms should never be sent directly in an ICS20 packet. Because of the bug, the resolved denom in the final chain looks like:
srdtrk
changed the title
Users can send hashed IBC denoms using MsgSendPacket
Users can directly transfer hashed IBC denoms using MsgSendPacketJan 15, 2025
Hmm, can we just disable this by checking if the token is an IBC denom first before allowing it? Or we can convert it back to the full denom. Nice catch!
Summary of Bug
When users are allowed to construct their own ICS20 packets through
MsgSendPacket
, they are allowed to send (hashed) IBC denoms directly without unwrapping the trace path that would have happened if they were using the standardMsgTransfer
route.This allows users to construct two representations for the same escrowed token using the same channel. This might have broader impacts then I'm anticipating at the moment.
Expected Behaviour
Hashed IBC denoms should never be sent directly in an ICS20 packet. Because of the bug, the resolved denom in the final chain looks like:
instead, it should always look like:
Version
feat/ibc-eureka
Steps to Reproduce
I've ran into this issue while writing end to end tests for cosmos/solidity-ibc-eureka#59.
For Admin Use
The text was updated successfully, but these errors were encountered: