# Taiko L1 - Proposer can maliciously cause loss of funds by forcing someone else to pay prover's fee

Taiko proposer sets params.coinbase to a victim's address, making AssignmentHook pull the victim's approved ERC20 allowance to pay the assigned prover's fee.

- Payout: Contest reward
- Severity: high
- Program: Taiko
- Credited: zzebra83
- Disclosed: 2024-04-26
- Write-up quality: 7/10
- Original: https://github.com/code-423n4/2024-03-taiko-findings/issues/163
- Library page: https://bugbountylibrary.com/r/c4%3A2024-03-taiko%3AH-04
- Tags: domain:web3 impact:funds-loss kind:contest platform:code4rena sev:high tech:evm tech:solidity technique:source-review vuln:access-control vuln:business-logic

**Target:** L1 AssignmentHook / LibProposing proposeBlock
**Root cause:** proposeBlock only defaults params.coinbase to msg.sender when it is address(0), so a proposer can set coinbase to any address; AssignmentHook then pulls the prover fee via safeTransferFrom(_meta.coinbase, ...).
**Steps:**
1. Victim proposer A approves AssignmentHook for ERC20 feeToken with allowance exceeding actual fee.
2. A proposes a block; fee is pulled, residual allowance remains.
3. Attacker B calls proposeBlock with params.coinbase = A and an AssignmentHook feeToken = that ERC20.
4. AssignmentHook.onBlockProposed executes `IERC20(feeToken).safeTransferFrom(_meta.coinbase, assignedProver, proverFee)`, pulling A's tokens.
**How found:** Code reading of LibProposing's coinbase defaulting logic combined with AssignmentHook's safeTransferFrom using _meta.coinbase as payer; noticed coinbase is caller-controlled and only defaulted when zero.
**Exploitation:** Attacker proposes blocks with coinbase set to a victim who has a standing ERC20 allowance to AssignmentHook; the hook transfers the prover fee from the victim's balance to the assigned prover, so the attacker pays nothing while the victim loses funds.
**Insight:** When a contract pulls fees via transferFrom on a user-supplied 'payer' field, check whether that field is validated against msg.sender; residual ERC20 allowances to shared hook/escrow contracts are a reusable griefing surface.