# Calculating tax amount does not include taxes in `WasmMsg::Execute` messages

get_tax_amount() only sums BankMsg::Send transfers, ignoring WasmMsg::Execute taxes, so payments fail or payers skip taxes.

- Payout: Contest reward
- Severity: medium
- Program: Andromeda Ado
- Credited: g
- Disclosed: 2024-05-14
- Write-up quality: 6/10
- Original: https://github.com/sherlock-audit/2024-05-andromeda-ado-judging/issues/37
- Library page: https://bugbountylibrary.com/r/sherlock%3A2024-05-andromeda-ado%3AM-4
- Tags: domain:web3 impact:funds-loss kind:contest platform:sherlock sev:medium tech:solidity technique:source-review vuln:business-logic vuln:fee-bypass

**Target:** CosmWasm tax calculation in std rates module
**Root cause:** get_tax_amount() maps over on_funds_transfer messages but only extracts amounts from CosmosMsg::Bank(BankMsg::Send), returning zero for WasmMsg::Execute messages generated when a fee recipient has a msg set.
**Steps:**
1. Configure a fee/tax recipient with a `msg` field set, so generate_direct_msg() emits `WasmMsg::Execute` instead of `BankMsg::Send`.
2. Trigger a funds transfer on a non-fungible ADO contract that calls `get_tax_amount()`.
3. Observe the WasmMsg::Execute tax amount is counted as zero, causing either transfer failure (with royalties) or unpaid taxes (without royalties).
**How found:** Code review of get_tax_amount()'s message mapping versus generate_direct_msg()'s branching on recipient.msg, spotting the mismatch in message types.
**Exploitation:** A payer configures or benefits from a tax recipient with a msg set; the WasmMsg::Execute tax is not counted, so the payer underpays taxes or the payment transaction reverts.
**Insight:** When auditing fee/tax accounting, verify the summation logic covers every message variant the transfer hook can emit, not just the common BankMsg::Send path.