# flashProof is not flash-proof

Vader's flashProof modifier checked tx.origin, so a miner bundling transactions from fresh EOAs via a proxy contract could still execute same-block flash-loan-style attacks.

- 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/218
- Library page: https://bugbountylibrary.com/r/c4%3A2021-04-vader%3AM-04
- Tags: area:web3 domain:web3 impact:funds-loss kind:contest platform:code4rena sev:medium tech:evm tech:solidity vuln:access-control vuln:flash-loan

**Target:** flashProof modifier on sensitive protocol functions
**Root cause:** The flashProof modifier enforces its same-block restriction on tx.origin rather than per-user address, so distinct EOAs (or a relaying proxy called from fresh EOAs) in one miner-controlled block bypass the check.
**Steps:**
1. Identify sensitive functions guarded by the `flashProof` modifier, which blocks repeat calls in the same block keyed on `tx.origin`.
2. Deploy a proxy contract that relays calls to the protocol.
3. Have a miner include several transactions in one block, each originating from a different EOA calling the proxy, so `tx.origin` differs each time.
4. The same-block restriction never triggers, allowing the multi-call sequence the modifier was meant to prevent.
**How found:** Read the flashProof modifier and noticed it keys on tx.origin, then reasoned that flash loans are bounded by block, not transaction, and that miners control block ordering and can use fresh EOAs.
**Exploitation:** A miner controls block composition and can bundle back-to-back transactions (like flashbot bundles) from different EOAs through a relaying proxy, executing the sensitive multi-step sequence within one block despite flashProof.
**Insight:** Same-block reentrancy/flash guards keyed on tx.origin are bypassable: miners bundle transactions and any caller can rotate EOAs or relay through a proxy. Check whether the guard should key on msg.sender or per-address state instead.