# Transfer fee avoidance

Vether4 fee-exclusion applied to both sender and recipient, so one 128 VETH exclusion contract let all users route transfers fee-free.

- Payout: Audit contest
- Severity: medium
- Program: Vader Protocol
- Disclosed: 2021-06-14
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-04-vader-findings/issues/33
- Library page: https://bugbountylibrary.com/r/c4%3A2021-04-vader%3AM-12
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:business-logic vuln:fee-bypass

**Target:** Vether4 token contract (0x4Ba6dDd7b89ed838FEd25d208D4f644106E34279) _transfer fee logic
**Root cause:** _transfer() waives the transfer fee when either sender or recipient is excluded, so an excluded contract acting as a forwarder makes every routed transfer fee-free.
**Steps:**
1. Pay 128 VETH to call Vether4.addExcluded() on an attacker-controlled contract address.
2. Have users send transfers through that excluded contract as an intermediary forwarder.
3. Because the recipient (or sender) is excluded, _transfer() skips the fee for all routed transfers.
**How found:** Observed that addExcluded() is permissionless for a fixed 128 VETH cost and that fee waiver triggers on either party being excluded, enabling a shared forwarder.
**Exploitation:** Attacker pays a one-off 128 VETH to exclude a forwarder contract, then any user routes transfers through it to avoid fees, denying the contract an estimated $140k of accumulated fees and future fees.
**Insight:** When a fee/whitelist check ORs sender and recipient, a single whitelisted intermediary contract becomes a universal fee bypass; check whether exclusion should apply only to the payer side.