Cosmos Total Supply Manipulation via IBC Burning about building-secure-contracts HOT 1 OPEN

The "burns transferred coins in the source chain" statement is misleading, but one may argue that it is somehow valid, as per the cosmos comment:

The coins (vouchers) are burned on the sender chain and then transferred to the receiving chain though IBC

What you wrote is much more clear and precise, and we should clarify the "IBC" exploit scenario. To be more precise we should consider four cases: when the chain with AMM

1. is sending coins to other chain - coins are escrowed
2. is receiving coins from other chain - coins are minted
3. is sending coins back to original chain - coins are burned
4. is receiving coins back - coins are taken from escrowed address

1 and 4 shouldn't impact total supply (uTokensInCirculation) - no issue here (as you noticed). Spendable coins amount (tokensHeld) may be impacted though, because escrowing is locking coins - but from the code it seems like there is no real "lock" like it is in with delegating coins (?)

2 and 3 change total supply. However, I don't remember how coin's prefixes influence these computations. At the best case the AMM is not buggy, because burning and minting is of other coins (with a prefix, different denomination). Not sure.

We should rewrite the "IBC" exploit scenario to be more generic and less specific (e.g., "be aware of IBC transfers that may influence balances"). Ideally, we research this topic more and provide accurate and tested "IBC" exploit scenario. It was some time ago when I wrote the issue, and now don't have testing code around anymore. Also the IBC code may have changed.

If you are willing to research the topic, we would gladly accept a PR.

from building-secure-contracts.