Inverse Finance TWAP (2022)

Independent research — not a commissioned audit. TierZero was not involved with Inverse Finance and had no access to non-public information; this analysis is based solely on public post-incident reporting.

What the protocol did

Inverse Finance ran Anchor, a Compound-style money market on Ethereum, alongside its DOLA stablecoin. Depositors could post supported assets — including Inverse's own governance token, INV — as collateral and borrow DOLA and other stablecoins against that collateral. To value INV for borrowing power, Anchor's price feed used a Keep3r V1-based time-weighted average price (TWAP) sourced from a Sushiswap INV/DOLA pool. That pool's liquidity was small relative to the position size an attacker could fund and relative to the borrowing capacity it unlocked once its price moved.

On April 2, 2022, an attacker used this mismatch to borrow on the order of $15.6 million in stablecoins against artificially inflated INV collateral — a figure widely reported by Inverse Finance itself and by firms including BlockSec in their post-incident analyses. Notably, this followed a separate incident roughly two months earlier in which Inverse's Frontier market lost funds to spot-price manipulation of a Curve-based feed. Both events trace to the same underlying category of mistake: pricing collateral off a feed that is cheap to move relative to what the protocol will lend against it.

The vulnerability

The bug class is oracle manipulation via low-liquidity price sourcing, compounded by a TWAP window that was short enough (and a reference pool thin enough) to be walked by a well-capitalized attacker over a handful of blocks rather than requiring the sustained, costly pressure a TWAP is supposed to demand. A TWAP is only as resistant to manipulation as the liquidity depth and time window behind it — a short window over a shallow pool approximates a spot price with extra steps.

The flawed pattern, simplified:

// Anchor-style collateral pricing (illustrative, simplified)
function getUnderlyingPrice(CToken cToken) external view returns (uint256) {
    // TWAP pulled from a single low-liquidity Sushiswap pair
    uint256 twap = keep3rOracle.current(INV, ONE_INV, DOLA);
    return twap; // no sanity bound, no cross-venue check, no depth requirement
}

Nothing here validates that the pool backing the TWAP has enough depth to make manipulation economically irrational, and nothing cross-checks the figure against an independent venue before it is used to size a loan.

How the exploit worked

1. The attacker accumulated capital and began trading against the thin INV/DOLA Sushiswap pool, pushing INV's price up over consecutive blocks rather than in one transaction, since a single-block spike averages out under a TWAP.
2. As the TWAP window rolled forward, the oracle's reported INV price rose toward the manipulated level because the underlying pool had too little depth to absorb the pressure without moving materially.
3. The attacker supplied INV as collateral into Anchor while the feed reflected the inflated price, which inflated their reported borrowing power far beyond the token's real market value.
4. Using that inflated borrowing power, the attacker drew down roughly $15.6 million in DOLA and other stablecoins from Anchor's lending pools.
5. The attacker withdrew the borrowed assets off-protocol; the manipulated INV price reverted once buying pressure stopped, leaving Anchor holding collateral worth a fraction of what had been lent against it — bad debt absorbed by the protocol and its treasury.

How an audit catches this

This is a standard finding in any collateral-pricing review, and it is exactly the kind of issue we look for in a full engagement — see our approach to /services/smart-contract-audit. The concrete checks:

• Liquidity-depth invariant: for every asset accepted as collateral, compute the capital required to move its reference price feed by X% and compare it against the maximum single-account borrowing power that price unlocks. If moving the feed costs less than the resulting loan, that is a finding, full stop.
• TWAP window sizing test: simulate sustained, multi-block price pressure against the exact pool and window the oracle uses, and confirm the window is long enough (and the pool deep enough) that manipulation cost exceeds extractable value with a safety margin, not just parity.
• Multi-source cross-check: require collateral pricing to reconcile against at least one independent venue or a Chainlink-style feed, and revert or clamp borrowing when sources diverge beyond a threshold.
• Circuit breakers on borrow velocity: flag or throttle large borrows that follow an abrupt change in a collateral asset's oracle price within a short window — a pattern absent from healthy usage but present in every TWAP-manipulation exploit we've reviewed.
• Governance-token-as-collateral review: treat a protocol's own low-float governance token as collateral with extra skepticism; its market is usually the thinnest, most correlated-to-the-protocol asset in the system, which is precisely the profile attackers target.

The same discipline applies whenever we do /services/code-review-audit work on lending or margin logic — pricing assumptions get tested against adversarial liquidity conditions, not just against normal-market backtests. Teams building new lending markets from scratch should have this baked in from day one through /services/smart-contract-development rather than retrofitted after a loss.

Remediation

The durable fix is to stop pricing collateral off any single low-liquidity venue. Use a decentralized oracle network (Chainlink or equivalent) as the primary feed for any asset used as collateral, and if a DEX-based TWAP must be used as a supplement, size the window against realistic attacker capital and require deep, multi-pool liquidity behind it. Cap loan-to-value ratios more conservatively for thinly traded or protocol-native tokens, add borrow-side circuit breakers that pause or rate-limit lending against an asset whose price moved sharply in the last N blocks, and require a second, independent price source to corroborate any valuation used to unlock large loans. None of this is exotic — it is the same rigor applied to oracle risk that shows up repeatedly in adjacent ecosystem writing, including our notes on /blog/cross-program-invocation-risk-solana-defi and the broader checklist in /blog/solana-program-security-audit-checklist-trading, both of which cover the general principle that any external data feeding a financial decision needs an adversarial cost model, not just a happy-path integration test.

If your protocol prices collateral, rewards, or liquidations off any on-chain feed, it is worth having that logic reviewed before it is tested in production — talk to us at /services/smart-contract-audit.

Thinking about a review like this for your own contracts? Get a smart contract audit from an independent team.