Flash loan attack prevention starts with the state the loan can change

Same-transaction state reads: follow the lasting claim

A flash loan attack uses temporary financing to reach a state that a vulnerable application treats as authoritative. The borrowed assets must be accounted for at the end of the financing transaction, but a different protocol may already have issued a lasting claim against a distorted price, share balance or vote. Investigating the loan alone leaves that decisive transition unexplained.

Begin at the output.

Identify what the attacker retained, what debt remained and which authorization allowed the value to leave. Work backward to the state that satisfied that authorization. A large temporary balance is evidence of financing; the missing constraint is the explanation for the loss.

The ERC-3156 specification describes a loan and callback that complete within a transaction, including repayment of principal and any fee. The atomic boundary prevents the lender from accepting an unpaid ordinary flash loan. It does not promise that every application the borrower touches will maintain its own accounting. These are separate contracts with separate acceptance rules.

Aave's documented interfaces also distinguish a simple flash loan from a multi-asset path that can, when its conditions permit, open a debt position. An investigation should name the actual method and repayment mode rather than treating every call containing flash as the same financing primitive. Current fee values must come from the relevant deployment; a documented initialization value is not a permanent price.

In a prevention review, trace each same-transaction input that can influence issuance, borrowing or execution.

Ask whether temporary capital can control that input, whether the application reads it immediately and whether reversing the temporary position leaves a benefit behind. That chain of conditions is more useful than trying to blacklist a list of known lenders.

ERC-3156 repayment and callback requirements and Aave flash-loan execution modes establish the financing boundary. They do not certify a downstream borrower.

Spot-price collateral valuation: a price can be real and unsuitable

A pool can report its actual reserves while still supplying an unsafe collateral valuation.

If the same actor can move those reserves and immediately borrow against the resulting quote, the value can be mechanically correct for that instant and economically unsuitable for the lending decision. An oracle review therefore needs the consumer's purpose, not just the provider's interface.

Consider a hypothetical lending market that accepts a pool's current swap quote as the value of deposited collateral. Temporary capital changes the reserve ratio, collateral appears more valuable and the market issues a larger loan. Restoring the pool before repaying the financing does not undo the debt already created in the lending market. The weak point is the consumer's acceptance rule.

The defense has to constrain that rule.

Possible designs use an independent price source, an observation window, liquidity requirements or explicit limits on how far a valuation can move. Each has assumptions. A time average can still be manipulated across its window; an independent feed can become stale; a liquidity threshold can measure the wrong side of the market.

Test those assumptions separately.

An audit that replaces every oracle with a constant cannot establish how the application behaves during a distorted or unavailable observation. Include the path used when the primary feed fails. A fallback that silently switches to a manipulable spot quote may remove the protection exactly when the system needs it.

Price manipulation and stale-state exploitation also differ.

A fresh timestamp does not establish a manipulation-resistant source, while a delayed value is not automatically wrong for every use case. The acceptance condition should specify units, freshness, deviation handling and the economic action permitted by the value. Write those constraints into the scope before deciding which monitor or feed to buy.

The oracle manipulation review connects feed checks to the consuming contract. Apply the same reasoning to a price returned by a vault or strategy.

Share-price inflation: donations change the denominator relationship

A share price is another valuation surface.

A vault may derive it from assets held divided by shares issued. A direct asset transfer can change that relationship without following the ordinary deposit route. Whether the change is intended yield, harmless surplus or an exploitable input depends on the vault and every application consuming its shares.

OpenZeppelin's ERC-4626 discussion shows how rounding and direct donations interact in an empty vault.

A small initial depositor can move the conversion rate so a later deposit receives very few shares or rounds to none. Its documented defense combines virtual assets and shares with increased share precision. The explanation concerns a specific conversion design; applying the interface name alone does not establish that a deployed vault uses the defense.

Separate the victim's deposit from a collateral consumer's valuation. A first-depositor inflation attack can harm someone entering the vault. A donation-driven price increase can also matter to a lending market holding the vault share as collateral. The paths may share arithmetic while requiring different tests and mitigations. Do not collapse them into one generic donation finding.

For a review, identify all asset changes that bypass the share-minting function: direct transfers, strategy gains, losses and exceptional recovery paths. Specify whether each should affect redeemable value. Then test conversion rounding in the direction required by the operation, including the first deposit and the nearly empty state.

The donation amount is not the attacker's profit. A coherent analysis tracks recoverable shares, financing costs, the victim's contribution and any residual value left in the vault. A transaction that visibly moves a large balance may be unprofitable under the actual share ownership. Keep the accounting proof with the finding rather than inferring economic impact from a price chart.

OpenZeppelin ERC-4626 inflation analysis supplies the conversion mechanism. The token integration checklist adds the asset behavior that can change the accounting assumptions.

Governance snapshots: when temporary capital becomes authority

Governance creates a different lasting effect: a decision can move a treasury or change the implementation that controls it. If current voting weight can be acquired and used within the financing transaction, a valid vote count may authorize an outcome that the governance design never intended temporary holders to control.

Past voting checkpoints address a specific part of that problem. OpenZeppelin's governance guidance retrieves voting power from a past snapshot instead of a current balance. A reviewer still needs to inspect the clock, snapshot selection, delegation updates and execution path in the actual deployment. A function named snapshot is insufficient evidence of those properties.

A past snapshot also does not eliminate the possibility of acquiring voting power before the snapshot and retaining it across the relevant window. Such financing has a different cost and duration from an atomic flash loan. The governance threat model should distinguish temporary transaction-local power from a longer-lived concentration of authority.

Proposal execution is another boundary. A delay in a normal voting path provides little protection if an emergency method, privileged executor or upgrade key can reach the same target without that delay. Trace the authority graph through the final treasury call, including module-enabled wallet routes. The paper governance process and executable permissions can diverge.

Use a test that varies when power arrives and when the proposal becomes executable. Verify the intended weight at the chosen clock point, then inspect what the successful proposal can actually call. A counterexample that merely buys tokens is incomplete. The meaningful result is whether those tokens authorize an operation outside the intended governance constraints.

Temporary power

Acquire voting weight.

Decision boundary

Snapshot and execution.

Lasting change

Treasury or permissions.

OpenZeppelin governance checkpoints is a reference for the voting model. The DAO security review traces its execution and treasury dependencies.

Audit checks per pattern

Organize the audit around the state that the attacker can influence. The financing source belongs in the reproduction record, but it should not dictate the entire checklist. Equivalent capital supplied from another source can expose the same missing constraint.

Receiver authentication deserves its own row. ERC-3156 passes both lender context and initiator information into the callback. A receiver should not assume that a callback is authorized merely because its parameters look familiar. An unexpected caller can supply plausible token and amount values; the receiver must enforce the intended relationship.

Record the complete balance sheet in a local reproduction. Identify starting assets, borrowed principal, fees, debt created and assets retained. Use the deployment's actual token units and fee configuration. This avoids a common reporting error in which gross movement is called profit or an unrepaid position is mistaken for a successful atomic loan.

The proposed checks here are review requirements, not claims that we executed a live exploit. A team should implement them in an isolated test environment and preserve both successful and rejected paths. Where a production dependency is mocked, disclose the behavior the mock cannot establish.

1. Freeze the release, chain configuration and relevant observation block.
2. Identify the persistent claim or authority being protected, then map every temporary input it consumes.
3. Construct an isolated state sequence and preserve its financing assumptions. Test the same property with alternate capital sources when applicable.
4. Check the complete final accounting and the reason any intermediate operation rejects.
5. Review the fix against the original path and its fallback variants. Keep the regression evidence with the final report.

Use the audit scope builder to request the same evidence from prospective reviewers. A provider comparison such as the Halborn analysis is background; the commissioned scope must name your own valuation and authority paths.

Our catalog check: the flash-loan label misses the mechanism

A literal search of an incident catalog is a poor way to define prevention scope. In the retrieved DeFiLlama response, only 4 of 1,253 rows contain flash-loan wording in the technique field. Every one of those rows carries a governance classification. Other rows use mechanism labels such as spot-price manipulation or donation attack without stating how the attacker financed the operation.

Method

Source

DeFiLlama public hacks endpoint

Retrieved

September 5, 2026

Population

All 1,253 returned rows, without deduplication or content-based exclusions.

Selection

A case-insensitive whole-word pattern for flash loan, flash-loan or flashloan in the technique field.

Interpretation

Publisher labels are measured as labels. Individual incidents and financing traces were not independently verified by this catalog census.

Results

The last row provides a contrast in classification granularity. It does not establish that those oracle incidents used flash loans. Financing and root cause are different fields of inquiry, and the retrieved schema does not give a complete financing history.

Limits

• A missing label is not evidence that a flash loan was absent.
• All returned source fields were empty. This is a limitation of the retrieved endpoint, not a claim that supporting publications do not exist elsewhere.
• Rows are catalog entries rather than proven unique events. No total loss or trend is calculated from this response.

Reproduction uses seo/research/incident-evidence-fields-survey.py; its dated output is seo/research/incident-evidence-fields-survey-2026-09-05.json. These files remain in the repository and are not published as downloads. The output preserves source responses, retrieval outcomes and the selection rules for later verification.

Named incidents: what the primary accounts actually establish

Beanstalk's account of the April 17, 2022 attack identifies a flash loan used against governance. Its stated loss is approximately $77 million in non-Beanstalk user assets. That definition matters: it should not be silently replaced by a larger headline using a different asset or valuation basis.

Euler's retrospective describes the March 13, 2023 Euler V1 exploit through a missing health check in the path involving donateToReserves. It reports roughly $197 million extracted at the time. The same account explains that the function had been introduced in an audited upgrade. Calling it an unaudited addition would reverse the source's account.

These cases support different audit questions. Beanstalk directs attention to the conversion of voting weight into execution authority. Euler directs attention to whether an accounting transition can leave an account eligible for a profitable liquidation path without the required health constraint. The fact that capital amplifies a sequence does not make the sequences interchangeable.

A recovery figure belongs in another column or another dated record. Asset prices can change between extraction and return, so the dollar value recovered can exceed the earlier dollar estimate without proving that more units came back. This article does not combine those values into a recovery rate.

The prevention decision follows the verified path. State what an attacker controls, which observation becomes authoritative and which claim survives afterward. Then request evidence that the reviewed release rejects that sequence under its actual dependencies. The lender's repayment check is useful protection for the lender; your protocol still needs its own acceptance conditions.

Before accepting a proposed mitigation, repeat the accounting with the protection enabled and with its data source unavailable. A rule that works only while every dependency responds normally leaves an operational boundary untested. Preserve that boundary in the finding and identify which team owns the remaining response.