The $20,000 problem: when a protocol's input is cheaper than what it controls

A price tag on the input

In September 2026, three unrelated incidents had the same shape. Someone, or something, produced an input cheaply. A protocol treated it as truth. A lot of money moved.

On Neutron, an attacker spent about 20,199 USDC on roughly 31.6 million NTRN, staked it minutes before a vote closed, and passed a proposal that handed over eleven contracts. Neutron's post-mortem counts about $6.24 million taken. Our write-up of the Neutron governance takeover has the details.

On Starknet, Nostra's lending market accepted an inflated price for its own thin token, NSTR. About $3.5 million was borrowed. See our Nostra article.

Also on Starknet, a wrong conversion factor inside Pragma's publishing software made major assets look halved, and Vesu liquidated 47 positions. We cover it in the Pragma and Vesu article.

The useful question for any such design is blunt: what does it cost to move this input, and what does the input control?

Three cases, three inputs

A vote. Neutron's governance could change the admin of any contract. The input was a tally, and the tally depended on how much NTRN someone could get hold of. The cost was about $20,000. Per the post-mortem, without that last-minute stake the proposal would not have reached quorum. The output was admin control over ten contracts' worth of other people's liquidity.

A pool price. Nostra valued NSTR by a price Pragma gathered from several sources. Pragma says one of them read a manipulated on-chain pool, and that only two sources contributed to the answer, below the three it recommends. The attacker needed a pool anyone could create, and enough thinness to set a price. The output was collateral value 8,000 times too high, according to BlockSec and Credora.

A conversion. Pragma's own post-mortem says a registry mapped USDC to an old bridged token, which produced a bad USDT price, and the software used that price to convert other prices. Nobody paid to attack this one. An error did the job a manipulator would have done, and the result looked identical to a manipulation.

Why it keeps happening

Because the check that would catch it is usually missing at the point where money moves.

• Independence is assumed, not verified. Pragma's lesson is explicit: "Publisher redundancy is not software independence." Two publishers running the same code, and many exchange prices passing through one conversion, are not many opinions.
• Counts hide dependencies. Vesu checks a minimum number of sources, and it did reject the thin two-source USDT feed. It still accepted BTC and ETH feeds that showed many sources but shared a weak input. The number was accurate. It was not informative.
• Votes are weighted by what you can buy. Governance that can touch contracts it does not own turns a token's market cap into a security budget, and a thin market means a small budget.
• Time is the defender's scarcest resource. Expedited tracks, freshness windows and auto-liquidation all compress the time in which a human can notice.

What good looks like

None of this is exotic. Teams have shipped each of these.

1. Price the attack. For each input, estimate what it costs to move and compare it with what it controls. If the second number is bigger, add a control until it isn't.
2. Limit what a single input can move. Caps on how fast a price can change, or how much can be borrowed against a thin asset, bound the damage. Pragma now recommends at least three sources, and a four-source default for USDT and USDC.
3. Do not list thin assets as collateral. Pragma says a listing in an oracle does not mean an asset is fit for lending.
4. Make governance slow where it matters. A delay after a vote passes, a veto window, or a ban on touching contracts governance does not own would each have changed Neutron's day. Neutron's recovery release restricted governance to software upgrades and text proposals for now, according to its post-mortem.
5. Add circuit breakers. A price that moves by half in seconds should pause borrowing, not liquidate.
6. Test the monitors. Pragma found in its own follow-up that a chain reorganisation could freeze its deviation checks while indexing kept running.

Where we stand

Neutron's recovery proposal and Vesu's curator refunds are still in progress. Nostra's final loss and any recovery were not public at the time of writing. We will update this piece if the projects' accounts change.

Sources: Pragma's post-mortem, Neutron's post-mortem and the Cosmos Hub forum update, and the reporting of BlockSec and Credora on Nostra, none of which are linked beyond the official pages above. We have not verified the on-chain figures.