[questions] transfer module

[junbeomlee]

I have a question.
In the case of transferring tokens through ibc (A chain -> B chain), won't there be a problem if the token is not burned after locking the token in the A chain and after confirming that the B token has been minted?

[junbeomlee]

And where is the code verifying the proof that the token was locked?

[crodriguezvega]

The tokens on the source chain (chain A in your example) are sent to an escrow address. The packet commitment is stored here and upon submitting the receive message on the destination chain (chain B in your example), then the packet commitment is verified here.

When the tokens reach the chain B, then vouchers are minted on the destination chain. If the tokens are later on transferred back to chain A, then those vouchers are burnt.

I hope this answers your questions. I will close the issue for now. Feel free to reopen it if something is not clear.

[junbeomlee]

Thank you for answer. I have an additional question, is it not possible to confirm that the A chain sent to the escrow address because it only checks the commitment to the packet, but not the contents of the packet or state of escrow address?
And even if chain A have actually made a commitment, when chain A receive an ack from the B chain, what happens if chain A return the token without burning it?

Since all packets are stored in state, will someone claim and post-process if something goes wrong?

[junbeomlee]

@crodriguezvega

[junbeomlee]

i cannot reopen this issue

[crodriguezvega]

is it not possible to confirm that the A chain sent to the escrow address because it only checks the commitment to the packet, but not the contents of the packet or state of escrow address?

The security model assumes that both chains are running trusted IBC code. One chain, when verifying the packet commitment, trust that the counterparty runs a non-malicious IBC implementation and it trusts that if has escrowed the tokens on its side. Otherwise, actually verifying that the tokens has been escrowed, etc would make the protocol way too complicated.

when chain A receive an ack from the B chain, what happens if chain A return the token without burning it?

This is again related to the security model: we assume that chains are using a compliant implementation of the IBC protocol that is not following malicious behavior. In Cosmos, when chains add new modules, the validators has to approve a proposal, so it's unlikely that validators would vote for a module that is malicious. There can be software bugs, of course, but it's very unlikely that malicious module would get deployed on a chain.

Since all packets are stored in state, will someone claim and post-process if something goes wrong?

The hash of the packet commitment contains the packet data (amount and denom of the tokens that are being transferred) and the relayer needs to send the packet data to the destination. The destination chain will reconstruct the packet commitment and verify that the source chain stored the same packet commitment at a certain block height.

Feel free to ask if you have any more questions.

[junbeomlee]

Thank you for answer!