# CosmWasm // IBC ## Problem CosmWasm IBC + permisionless smart contract chains present new usecases and possibilities but also new attack vectors. 2 issues noted - CosmWasm contracts can infinite loop over IBC, gets ACK for a previous send packet and then dispatches another msg from that ACK - Out of gas issues that can fail processes which leaves pending msgs Not clear if relayer software currently accounts for these issues and if safeguards should be built in at the relayer layer, the IBC layer and/or the smart contract layer. CosmWasm IBC deviates away from simple ics20 transfers due to this infinite loop + out of gas issue. ## Thoughts/Possible Solutions Possibly allowlist of contracts to relay for to safeguard against malicious contracts. Is approach to solve issues in the relayer software or in contracts? Maybe focus on a relaying single packet vs. clearing a channel. Are these issues present in only malicious contracts? No, even trusted contracts could cause this issue because it's impossible to account for every possible input and someone could execute a contract with an arbitrary input that causes out of gas issue. Limited on bytes that can be sent in/out of a contract. Contracts cannot introspect things i.e. how much gas have I consumed so far Zeke solution: - move towards self relaying so applications can safeguard against unexpected inputs and only attempt to relay packets that a user is generating vs. trying to clear an entire channel of packets. Relayer software does not expose an API to commit a tx, relay only this packet, and stop i.e. dont touch other packets. Due to relaying being permisionless, there is nothing stopping users from relaying on a specific set of channels so not possible to completely put the relaying burden on the maintainers of some specific app or channels. Since relayers pay the tx fees there is no cost to a user who may attempt to maliciously send a packet that triggers the infinite loop or out of gas issue. If a setup could be implemented to put the burden of paying the relayer fees on the user it would solve this issue because the attack is no longer free and costs are not on the relayer operators. Possibly detect a packet that will cause the out of gas issue at simulation, give up immediately, cache the packet information and then timeout the packet on the sending side once the timeout period has ellapsed.