# Inability to reliably verify inbound transactions may result in missed inbound transactions

InTxTracker verification checks tx.To against connector/custody/TSS addresses, so valid deposits routed via intermediary contracts fail verification and are dropped.

- Payout: Contest reward
- Severity: medium
- Program: ZetaChain
- Credited: berndartmueller
- Disclosed: 2024-09-06
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2023-11-zetachain-findings/issues/394
- Library page: https://bugbountylibrary.com/r/c4%3A2023-11-zetachain%3AM-21
- Tags: domain:web3 impact:dos kind:contest platform:code4rena sev:medium tech:evm technique:source-review vuln:business-logic

**Target:** Cosmos SDK msg server AddToInTxTracker / VerifyEVMInTxBody
**Root cause:** VerifyEVMInTxBody validates inbound EVM txs by comparing tx.To to the connector, ERC20Custody, or TSS address, but a deposit made by an intermediary contract has tx.To set to that contract, not the custody/connector address.
**Steps:**
1. Call ERC20Custody.deposit (or connector) from a wrapper contract so the outer tx.To is the wrapper, not the custody contract.
2. Observers miss the tx; user submits MsgAddToInTxTracker with a valid block-inclusion proof.
3. VerifyProof succeeds, but VerifyEVMInTxBody compares txx.To().Hex() to Erc20CustodyContractAddress and returns 'receiver is not erc20Custory contract'.
4. Tx is rejected and never added to the inbound tracker, so it is not processed.
**How found:** Code reading of AddToInTxTracker/VerifyEVMInTxBody: noticed validity is inferred solely from tx.To, which does not capture deposits routed through intermediary contracts.
**Insight:** When a verifier infers intent from a single top-level field like tx.To, check whether the same logical action can be performed via an intermediary (wrapper contract, multicall, proxy) that changes that field while remaining legitimate.