On September 17, 2026, Starknet's Nostra Finance paused all lending and borrowing after an attacker borrowed $3.5 million by artificially inflating the price of NSTR, the protocol's governance token, from roughly $0.006 to $49.50 in minutes. The exploit was not a hidden code bug or a contract flaw that auditors missed. Instead, it exposed a structural weakness in how lending protocols choose which assets to accept as collateral and how they price those assets in real time.

What Exactly Happened in Those 27 Minutes?

The attack unfolded with surgical precision. According to security firm GoPlus Security's reconstruction, the attacker began by creating a fake NSTR/SolvBTC liquidity pool with almost no real depth, then used wash trades (buying and selling to themselves) to artificially pump the price through that thin pool. Once the price aggregator GeckoTerminal selected this fake pool as the reference source, the attacker had their opening.

Here is the timeline of the exploit:

• 05:23 UTC: Attacker created a fake NSTR/SolvBTC pool with only about 1.5 SolvBTC of one-sided liquidity.
• 05:27 to 05:47 UTC: Wash trades ran through the thin pool, pulling liquidity from the market-making range to create the illusion of activity.
• 05:47 to 05:48 UTC: Repeated swaps through the pool printed NSTR at a price near $49.50.
• 05:48 to 05:50 UTC: The inflated NSTR was posted as collateral, and the account borrowed ETH, STRK, USDC, USDT, WBTC, and DAI.
• 05:51 to 07:08 UTC: Proceeds were dumped across multiple decentralized exchanges (DEXs) including AVNU, Ekubo, and JediSwap, with about 2.2 million STRK bridged off-chain through the NEAR Intents bridge.

By the time Nostra's team detected the attack, approximately $1.92 million had already been bridged to Ethereum, including 234.57 ETH and 1.3 million DAI. The remaining $1.5 million sat in the borrow account.

Why Did the Price Aggregator Pick a Fake Pool?

The core issue was not that Nostra's smart contract was broken. The issue was that the protocol relied on a price feed that ranked pools by superficial signals like recent trading volume or displayed liquidity depth, rather than actual market depth or cross-venue consensus. An attacker who understood those ranking rules could manufacture a reference market cheaper than manipulating a deep, legitimate pool.

NSTR's market cap at the time was only about $546,751. The attacker borrowed $3.5 million against it, meaning the borrowed amount was roughly six times the token's entire circulating value. This is not a subtle edge case; it is a fundamental mismatch between collateral value and borrowing capacity.

The Hidden Cost: Honest Users Frozen Alongside the Attacker

Nostra's response was the most severe option available. The protocol paused all supply, borrowing, withdrawals, and liquidations to protect remaining reserves. According to DeFi Llama data cited by BeInCrypto, total value locked (TVL) collapsed from about $4 million on September 16 to roughly $710,000 after the pause.

The catch: users who never borrowed a dollar were still frozen with everyone else. An oracle failure that harms one account becomes a liquidity freeze for all accounts. That is the hidden cost of an oracle incident.

Why Protocol Tokens Keep Becoming Collateral Disasters?

This pattern is not unique to Nostra or Starknet. In late August, Moonwell on Base suffered a similar attack when its own governance token's price was manipulated. The names and chains change, but the structure repeats.

Protocol teams are drawn to accepting their own tokens as collateral because it bootstraps utility for the native token, raises apparent TVL, and makes governance look productive. However, these tokens are dangerous collateral for everyone else because the float is small, the deepest pool is often the project's own trading pair, market makers can withdraw in one transaction, and the token's "price" is frequently a dashboard artifact rather than a real liquidation-grade oracle.

As one security analyst summarized the core problem: "If a token's market cap is smaller than the assets that can be borrowed against it, the token is not collateral. It is a call option on the lending pool".

How to Protect a Lending Protocol From Oracle Manipulation?

• Use a time-weighted price across multiple independent venues: Instead of relying on a single pool's spot price, aggregate prices from multiple DEXs over a time window to smooth out short-term manipulation.
• Enforce a maximum one-block or one-minute deviation: If a price moves more than a set threshold in a single block or minute, reject it as an outlier and use the previous trusted price instead.
• Set a borrow cap below the token's free-float market cap: Never allow borrowing against a token to exceed the token's actual circulating supply or market value, preventing the "call option" scenario.
• Implement isolation mode for governance tokens: Prevent a single collateral asset from draining reserves of other assets by capping how much of the pool's blue-chip assets can be borrowed against a single risky token.

Code audits alone do not catch this class of failure unless the audit scope includes economic invariants, not only smart contract function correctness. A contract can be technically "correct" while consuming a price that is a lie.

The Patient Attacker: Why Months of Preparation Mattered?

One of the most overlooked details in the GoPlus reconstruction is the lead time. The borrow account interacted with NSTR contracts in March and August 2026, months before the September 17 attack. This was not cinematic villainy; it was ordinary operational hygiene for a patient attacker who accumulated the cheap token without moving the spot price, waited until the lending market still treated that token as collateral, then spent a few minutes creating a fake reference pool.

For on-chain monitoring systems, this is a better signal than waiting for the 05:48 borrow burst. By the time six borrows fire in two minutes, the damage is already in the mempool or the sequencer. A continuous watcher would have flagged a new pool with one-sided liquidity, a sudden ranking change on a public price aggregator, and a wallet that accumulated collateral for months without behaving like a normal liquidity provider or borrower.

Where Did the Stolen Funds Go?

After borrowing, the attacker did not hold the assets on Starknet. They converted into ETH, STRK, stablecoins, and WBTC, sold through Starknet DEXs, then used the NEAR Intents bridge to move 2.2 million STRK off-chain. PeckShield's Ethereum bridge figure of approximately $1.92 million marked the investigator's first hard waypoint.

The exit path followed a predictable pattern: corrupt an application-layer price, borrow blue-chip inventory from a shared pool, dump on local AMMs before the pause, leave the originating chain through an intents or bridge path faster than governance, and consolidate on Ethereum where liquidity and privacy tools are thicker. Recovery odds drop at each hop. A paused money market can freeze remaining Starknet balances, but it cannot un-bridge ETH that already landed on mainnet.

Nostra publicly warned that it will never direct message users or ask them to connect a wallet during recovery. That warning is now standard because every protocol pause is followed by phishing attempts.

What This Means for Other Lending Protocols?

The Nostra case compresses into a short control list for any team maintaining a money market. Do not list a token as collateral if its market cap is smaller than the assets that can be borrowed against it. Require a time-weighted price across multiple independent venues, enforce a maximum one-block or one-minute deviation, set a borrow cap below the token's free-float market cap, and implement isolation mode so a single risky token cannot drain reserves of other assets.

The same week on Starknet, Pragma's oracle failed in a different way, triggering 47 liquidations with Pragma later reporting about 95% recovery. Nostra was different: the price was not accidentally wrong. It was deliberately constructed. Same chain, same week, two different oracle failure modes. That pattern should worry any team that treats "we use an oracle" as a completed security control.

" }