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 found that in ICS-20, when the acknowledgement is not successful, the tokens will be refunded.
functiononAcknowledgePacket(packet: Packet,acknowledgement: bytes){// if the transfer failed, refund the tokensif(!acknowledgement.success)refundTokens(packet)}
But in implementation, when the acknowledgement error, the tokens will be refunded.
func(kKeeper)OnAcknowledgementPacket(ctxsdk.Context,packetchanneltypes.Packet,datatypes.FungibleTokenPacketData,ackchanneltypes.Acknowledgement)error{switchack.Response.(type){case*channeltypes.Acknowledgement_Error:
returnk.refundPacketToken(ctx,packet,data)
default:
// the acknowledgement succeeded on the receiving chain so nothing// needs to be executed and no error needs to be returnedreturnnil}}
I think there are some differences between the two.
As ICS-02, there may be a non-empty sentinel ABSENCE value used to provide absence proofs.
Since the verification method is designed to give complete control to client implementations, clients can support chains that do not provide absence proofs by verifying the existence of a non-empty sentinel ABSENCE value. Thus in these special cases, the proof provided will be an ICS-23 Existence proof, and the client will verify that the ABSENCE value is stored under the given path for the given height.
This means that before the receiver receives the packet and writes a success acknowledgement , there may be an ABSENCE value on the path where the acknowledgement will be stored. I think the relayer may be able to claim the existence of an ABSENCE value and provide corresponding proof. And this ABSENCE value is not a success acknowledgement, so it will trigger a refund.
This process may not be feasible in practical implementation. But I think at the protocol level, it should be clear that refunds will only be made when the acknowledgement fails. In addition to success and error receipts, there may be also a default ABSENCE value.
The text was updated successfully, but these errors were encountered:
I found that in ICS-20, when the acknowledgement is not successful, the tokens will be refunded.
But in implementation, when the acknowledgement error, the tokens will be refunded.
I think there are some differences between the two.
As ICS-02, there may be a non-empty sentinel
ABSENCE
value used to provide absence proofs.This means that before the receiver receives the packet and writes a success acknowledgement , there may be an
ABSENCE
value on the path where the acknowledgement will be stored. I think the relayer may be able to claim the existence of anABSENCE
value and provide corresponding proof. And thisABSENCE
value is not a success acknowledgement, so it will trigger a refund.This process may not be feasible in practical implementation. But I think at the protocol level, it should be clear that refunds will only be made when the acknowledgement fails. In addition to success and error receipts, there may be also a default
ABSENCE
value.The text was updated successfully, but these errors were encountered: