The Attacker’s Favorite Functions in DeFi Protocols (And Why They Keep Paying Off)

Attackers don’t audit your protocol the way a developer does—they hunt for callable surfaces that can move value, change pricing, or alter permissions. Flash loans make this hunting even more effective, because they let an attacker borrow large sums with no collateral and combine multiple actions in a single atomic transaction.

In practice, this creates a “top list” of functions that repeatedly show up in exploit chains: anything that transfers assets, updates accounting, consumes oracle prices, or can be invoked at the wrong time. Below is the auditor’s map of attacker priorities and how to defend each category.

1) Deposit / Mint / Share-Issuance

Deposits and mints are high-value because they define who owns what—attackers target rounding, share accounting, and price-per-share logic to mint more claims than they paid for. If a protocol uses an external price to compute shares, the share function becomes an oracle attack target as well.

Defend with strict invariant tests on share issuance (no “free” value), conservative rounding policies, and oracle hardening (TWAP / decentralized feeds with staleness + deviation checks).

2) Withdraw / Redeem / Claim

Withdrawals and redemptions are where paper value becomes real tokens, which is why these functions are frequent end-points of exploit chains. Attackers look for paths where they can inflate balances earlier, then “cash out” here—often within the same flash-loan transaction.

Defend by ensuring accounting updates happen before external transfers, using reentrancy guards where appropriate, and validating end-of-function solvency/invariants rather than assuming intermediate checks were sufficient.

3) Borrow / Repay / Interest Accrual

Borrow and repay functions mix economics with state, so tiny mistakes can become massive when scaled. Flash loans amplify these mistakes by giving attackers the leverage to repeatedly interact, move prices, and re-enter the protocol’s accounting at scale.

Defend with post-action solvency validation, caps on per-transaction parameter changes, and careful handling of precision/decimals in interest and share math—these are common roots of logic exploits.

4) Liquidation

Liquidation functions are “authorized theft” under strict rules: if health factors cross a threshold, liquidators can seize collateral at a discount. Attackers target liquidation because it moves large amounts of value, and because it depends heavily on oracle correctness.

If liquidation eligibility relies on a manipulable price, attackers can push a healthy position into liquidation (or prevent liquidation when it should happen) and extract value from the price mismatch. Defend with hardened oracles, anti-manipulation windows, and circuit breakers that halt liquidations during extreme deviations.

5) Price / Oracle-Consumer Functions

Any function that consumes a price feed is a prime target: swaps, collateral valuation, share pricing, liquidation checks, and even some governance/risk parameter calculations. Oracle manipulation attacks happen when the oracle’s price feed is artificially altered, changing protocol behavior in ways that create extractable profit.

A common blueprint is manipulating AMM spot price with flash-loaned capital, then using the distorted price to borrow or redeem at favorable terms, then repaying the flash loan. Defend with robust oracle design (TWAP, decentralized feeds, staleness checks, deviation thresholds) and avoid trusting low-liquidity spot prices for critical logic.

6) Admin / Upgrade / Pause

Privilege is an attacker’s shortcut: if an attacker can influence upgrades, risk parameters, or pausing controls, they can turn a “secure” system into a drain. Even when smart contracts are correct, centralized operational weaknesses can undermine everything.

Defend with strict access control, timelocks for sensitive changes, multi-sig requirements, and clear emergency procedures that can pause safely without creating hostage scenarios.

Auditor’s Checklist: What To Review First

If you want to prioritize review like an attacker, start with the functions that can move value or change eligibility conditions, then work outward to their dependencies. OWASP SC07 explicitly notes that flash loans often combine with oracle manipulation, reentrancy, or faulty logic—so treat these as connected risks, not separate checklist items.

A practical first pass is: (1) withdrawals/redemptions, (2) liquidation eligibility + oracle sources, (3) share accounting on deposit/mint, (4) any external call surface, (5) admin/upgrade controls. That ordering mirrors how many real exploit chains are assembled.

At 0xTeam, we audit these “favorite functions” as a connected system: we map value paths, identify where prices or permissions can be influenced, and test whether a flash-loan-funded attacker can traverse a chain from harmless edge case to real extraction. When you defend the chain, not just the bug, your protocol becomes significantly harder to exploit.