Fri. Sep 11th, 2026

Osmosis Community Warning on Nomic Came Weeks Before nBTC Exploit Was Disclosed

ByShane Neagle

September 10, 2026 #nBTC
Crypto Hack

An Osmosis community member questioned the security risk of increasing exposure to Nomic’s nBTC in late July, pointing specifically to the bridge’s apparent lack of recent public development activity weeks before Osmosis discovered that unbacked nBTC had created a major hole in its Alloyed BTC reserves.

The warning appeared in an Osmosis governance discussion opened on July 22 to increase nBTC’s maximum share of Alloyed BTC, or allBTC, from 35% to 60%.

Alloyed BTC combines several forms of bridged Bitcoin into a single fungible asset on Osmosis. At the time, the basket included native WBTC, Axelar-routed WBTC and cbBTC, Cosmos Hub-routed WBTC and Nomic’s nBTC. Static composition limits are intended to stop any one bridge from becoming an unlimited source of risk to the combined asset.

The proposal itself explicitly described those limits as a mechanism for bounding Osmosis’s exposure if an underlying bridge was compromised.

But nBTC had grown to roughly 33% of allBTC, putting it close to its existing 35% ceiling. The proposal argued that this was preventing additional Nomic deposits and creating friction for users. It proposed raising the ceiling to 60%, citing Nomic’s previous reliability and growing demand.

That prompted a pointed response on July 27 from Osmosis forum participant giansalex.

The community member asked whether Nomic was still active, noting that its latest visible tweet and GitHub release appeared to date from 2024. The post then invoked Gravity Bridge, another Cosmos-linked bridge that had been drained earlier in 2026, and questioned whether an apparently inactive Nomic could face a similar risk.

Gravity Bridge had suffered a roughly $5.4 million drain on May 30, adding fresh context to the concern about relying on lightly maintained cross-chain infrastructure.

An Osmosis contributor, JohnnyWyles, responded the following day that Nomic remained available behind the scenes and responded when Osmosis raised issues involving delayed transfers from its Bitcoin checkpointing system.

He also pushed back on using release frequency alone as evidence of abandonment, arguing that functional released software does not necessarily need regular code updates.

Governance ultimately approved Proposal 1031, increasing nBTC’s static limit from 35% to 60%. Governance trackers list the proposal as passed. Previous votes had already progressively raised nBTC’s ceiling from 5% to 10%, then 20% and 35% as its usage expanded.

The subsequent incident gives the July discussion a striking retrospective significance.

On Sept. 9, Osmosis disclosed that a vulnerability in Nomic’s custom forwarding mechanism had allowed an attacker to double-spend nBTC and send false vouchers to Osmosis. The Osmosis blockchain and the IBC protocol themselves were not compromised.

Osmosis said 39.84 nBTC associated with the incident sat inside Alloyed BTC, representing approximately 36% of its backing. Nomic and allBTC flows were frozen, while an emergency upgrade allowed validators to immobilize 22.65 BTC linked to the attacker. Osmosis said governance would be asked to seize those assets and use community-pool Bitcoin to cover the remaining shortfall.

There is an important wrinkle in the timeline: the July warning did not actually precede the exploit activity itself.

On-chain analysis published after the incident traced the main creation of unbacked nBTC to June 25, when approximately 40.65 nBTC was allegedly generated and transferred through 25 cross-chain transactions. Part of the proceeds was exchanged and moved toward Ethereum, while another 22.65 nBTC was converted into allBTC on July 17. The problem was not publicly identified until September.

That means giansalex was raising concerns about Nomic on July 27 while the vulnerability had apparently already been exploited — without the Osmosis community knowing it.

The forum discussion was updated again on Sept. 9. Pointing to the newly discovered compromise, giansalex returned to the thread and argued that old, unmaintained code remained a security risk.

Nomic’s public GitHub organization also shows limited recent activity across several repositories, while its release page lists Stakenet v9 as the latest tagged Nomic release from the earlier development cycle.

There is no evidence, however, that the lack of recent public releases caused the vulnerability, or that maintaining the original 35% limit would have prevented the attack.

What the governance history does show is that concerns over Nomic’s operational and maintenance profile were raised publicly at the same time Osmosis was considering substantially increasing how much of its unified Bitcoin asset could depend on the bridge.

The Bigger Problem Is How DeFi Governance Measures Bridge Risk

This story would be easy to reduce to “someone warned them and they ignored him.” The reality is more uncomfortable than that.

The commenter did not identify the double-spend vulnerability. There was no technical proof presented in July that Nomic had been compromised, and infrequent GitHub releases are not, by themselves, evidence that software is unsafe.

The Osmosis response was therefore not irrational. Mature infrastructure can remain stable for long periods without visible releases, and the contributor provided another relevant data point: Nomic was apparently still communicating with Osmosis when operational problems arose.

But that does not make the governance decision uninteresting.

The purpose of a static cap is precisely to protect against things the community does not know.

If everyone already knew a bridge was compromised, the correct exposure would be zero. A 35% or 60% limit matters because governance is operating under uncertainty. Raising that limit is therefore fundamentally a decision that the underlying bridge deserves more trust.

And that is where the July discussion looks different in hindsight.

The rationale for Proposal 1031 leaned heavily on historical reliability and growing demand. nBTC had reached its cap, users wanted to deposit more and raising the limit removed that bottleneck. Those are strong arguments for capital efficiency.

They are not security evidence.

The forum participant raised a different category of question: What evidence existed that the infrastructure deserved a larger risk budget?

That question now looks especially relevant because the attack apparently occurred on June 25, weeks before the governance debate. By the time Osmosis was discussing raising Nomic’s maximum exposure, counterfeit nBTC may already have been circulating through the system.

In other words, historical reliability was being used to justify additional exposure at exactly the moment when historical reliability had silently stopped being true.

That is not something governance participants could reasonably have known from the available information. But it highlights the weakness of using an absence of incidents as a substitute for active security monitoring.

The numbers also demonstrate why composition limits matter.

The compromised 39.84 nBTC eventually represented about 36% of allBTC’s backing. That is not a peripheral component failing. It is large enough to turn the solvency of the unified asset into a governance and treasury problem, requiring freezes, an emergency chain upgrade, potential seizure of attacker funds and community assets to restore backing.

The 60% ceiling did not cause that loss, and the affected amount remained well below 60%. But approving a higher ceiling created the possibility that a future Nomic failure could expose an even larger proportion of the basket.

That should probably change how such votes are evaluated.

For bridge exposure, governance may need more than evidence of user demand. Code maintenance, active development, security reviews, reserve monitoring, checkpoint health, incident-response availability and automated backing verification are all relevant before increasing concentration limits.

The lesson from Nomic is therefore not that dormant code is automatically dangerous.

It is that when a protocol deliberately limits exposure to outside infrastructure because that infrastructure might fail, removing part of that limit should require evidence that the risk has fallen — not merely evidence that demand has risen.

Financial Markets Analyst and Digital Assets Journalist at  |  More Posts

Shane Neagle is a financial markets analyst and digital assets journalist specializing in cryptocurrencies, memecoins, prediction markets, and blockchain-based financial systems. His work focuses on market structure, incentive design, liquidity dynamics, and how speculative behavior emerges across decentralized platforms.

He closely covers emerging crypto narratives, including memecoin ecosystems, on-chain activity, and the role of prediction markets in pricing political, economic, and technological outcomes. His analysis examines how capital flows, trader psychology, and platform design interact to create rapid market cycles across Web3 environments.

Alongside digital assets, Shane follows broader fintech and online trading developments, particularly where traditional financial infrastructure intersects with blockchain technology. His research-driven approach emphasizes understanding why markets behave the way they do, rather than short-term price movements, helping readers navigate fast-evolving crypto and speculative markets with clearer context.

Leave a Reply

Your email address will not be published. Required fields are marked *