# Swivel: implementation for initiateZcTokenFillingZcTokenExit is incorrect

Swivel's initiateZcTokenFillingZcTokenExit transfers premium+fee to the maker instead of splitting premium to maker and fee to Swivel, misrouting funds.

- Payout: Audit contest
- Severity: medium
- Program: Swivel
- Found by: itsmeSTYJ
- Disclosed: 2021-11-05
- Write-up quality: 6/10
- Original: https://github.com/code-423n4/2021-09-swivel-findings/issues/38
- Library page: https://bugbountylibrary.com/r/c4%3A2021-09-swivel%3AM-05
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:solidity technique:source-review vuln:accounting-error vuln:fee-bypass

**Target:** Swivel Solidity vault contract, initiateZcTokenFillingZcTokenExit
**Root cause:** The function transfers the full premium+fee amount in underlying to the maker (o.maker) rather than sending premium to maker and the separate fee to Swivel, so the fee is never collected by the protocol.
**Steps:**
1. Call `initiateZcTokenFillingZcTokenExit(o, a, c)` as taker filling `a` principal of a ZcTokenExit order
2. Observe `Erc20(o.underlying).transferFrom(msg.sender, o.maker, a - premiumFilled)` sends premium to maker
3. Observe fee is computed but not transferred separately to `swivel`
4. Net result: maker receives premium+fee; Swivel receives no fee
**How found:** Code reading of the transfer comment versus actual transferFrom target: comment says premium+fee to swivel, but code sends to o.maker, revealing the fee is misrouted.
**Exploitation:** A taker filling a ZcTokenExit order causes the protocol fee to be paid to the maker instead of Swivel, so Swivel loses fee revenue on every such fill; no attacker capital needed beyond normal order filling.
**Insight:** When a comment describes a transfer destination, diff it against the actual transferFrom recipient and amount split; fee-vs-premium splits are a common place where a refactor drops one leg of the transfer.