Separate token names can share an authorization problem
The SingularityNET bridge incident affected several tokens because parts of their infrastructure could authorize issuance or release assets through connected routes. A token’s name and blockchain do not tell you whether its security dependencies are independent of another token’s.
This explanation covers the information available in the companion video as of September 22, 2026. It separates transaction reporting, project responses, and preliminary reconstruction. Later investigation may refine the scope or root cause; the figures below should not be read as a final loss calculation.
The first distinction is between creating new tokens and removing existing assets. Both can cause harm, but they are different accounting events. Mixing them produces a large number without a clear explanation of what that number measures.
What the early reports described
OrangeX’s transaction account described about 8.72 million FET leaving a converter on Ethereum on September 19, followed by roughly 408.53 million newly minted NuNet tokens, NTX, sent to the same recipient. The first action moved existing tokens; the second created supply.
Reporting on the expanded incident described a PeckShield snapshot including unauthorized issuance of 260 million AGIX and about 53.8 million WMTx. Tracked holdings were valued at approximately $16.77 million. That was a valuation of assets held at a particular moment, not confirmed cash received by the attacker.
World Mobile reported unauthorized WMTx minting through the SingularityNET bridge. Fetch.ai announced pauses to AGIX-to-FET conversion and, as a precaution, its Ethereum-side bridge. It also said FET continued operating normally and its contracts were not under threat. These are reported project statements, not an independent final postmortem.
A bridge needs evidence from another ledger
Separate blockchains maintain separate records. A deposit recorded on one chain does not automatically update another. A bridge coordinates the relationship between those records using a particular verification design.
In a simplified lock-and-mint example, a user locks 100 tokens on the source chain, and a corresponding representation is issued on the destination. A burn-and-mint design instead destroys source tokens before issuing replacements elsewhere. The intended relationship is movement of value, not unlimited additional supply.
Ethereum’s bridge documentation explains the range of bridge designs and their risks. Not every bridge uses the same signers, proofs, or contracts. The example here explains a dependency, not every transaction in the SingularityNET incident.
The user signs a source transaction, potentially after approving the bridge to transfer tokens. The destination system then needs acceptable evidence that the required source event occurred. In a system using external signers, their authorization can be part of that evidence.
There are two authorization questions: did the user approve the intended source transaction, and did the bridge receive legitimate authority to issue or release assets on the destination? A correctly protected wallet answers only the first. The bridge’s signers, proofs, and contracts remain a separate dependency.
A valid signature can authorize an illegitimate action
Imagine a warehouse issuing collection tickets only after goods arrive. If somebody gains control of ticket issuance, they may produce tickets that pass the local checks without delivering goods. The checking process works as coded, but the authority behind the ticket has been abused.
That analogy illustrates unauthorized issuance. It does not establish the incident’s exact root cause. Preliminary analysis shared by Fetch.ai pointed toward compromised signing credentials; it did not settle how access was obtained or establish an identical route for every affected asset.
Bitquery’s investigation describes multiple authorizing addresses and contract paths, including direct use of an NTX mint function and activity involving converters. “One stolen key opened everything” is therefore a tidier story than the available reconstruction supports.
On-chain execution records can show issuance, transfers, and contract calls. The security failure that made an authorization possible may involve off-chain systems. Correct signature verification and legitimate authorization are different claims.
A converter can carry the problem into another asset
A bridge connects blockchain environments. A converter can exchange one token for another under specified rules. AGIX-to-FET conversion is therefore a separate function from moving a token between chains, even when the services belong to an interconnected ecosystem.
Consider a hypothetical converter accepting Token A and releasing existing Token B:
- An issuance failure creates unauthorized A.
- The converter accepts that A under its exchange rules.
- Existing B leaves the converter’s reserves.
The first step expands supply; the third drains an existing balance. The converter can follow its local rules while accepting an input whose authority failed elsewhere. This explains a possible propagation route, not a claim that every affected token followed that sequence.
That explains why a conversion pause can be useful without proving that the converter has its own code vulnerability. It also explains why different token names in a wallet are not sufficient evidence of independent exposure.
Containment measures act at different boundaries
Pausing a conversion can stop a route while restricting legitimate users too. It does not necessarily halt all token transfers. Disabling a website is also different from disabling an on-chain contract that other interfaces can call.
World Mobile reported work with exchanges on affected deposits and efforts to revoke minting authorities. Deposit restrictions and permission revocation address different operations. Neither automatically reverses earlier transactions.
Containment needs to identify the actual authority: who can mint, who can release reserves, which routes remain usable, and which permissions have been removed. A general statement that a service is “paused” does not answer every one of those questions.
Three numbers that should never be combined casually
The incident’s numbers describe different things:
| Measure | What it counts | What it does not establish |
|---|---|---|
| Unauthorized token units | Supply created through the reported calls | A dollar loss or cash received |
| Market value of tracked holdings | A balance valued at prices at one moment | The price available for selling the entire balance |
| Realized attacker proceeds | Value actually obtained through disposal | The amount originally minted |
A million newly issued tokens quoted at a dollar do not guarantee a million dollars of buyers. Converting units into a headline valuation is not the same as tracing realized proceeds.
The $16.77 million snapshot should not be described as confirmed losses or proceeds. It also should not simply be added to earlier estimates covering related activity: the measurements may overlap.
Bitquery described a broader issuance total of roughly 2.3 billion units across several tokens, including CGV. Its counts differ from the earlier snapshot. Before combining them, an investigation must reconcile token scope, timing, and transactions.
A final account should distinguish which calls created supply, which released existing balances, which permissions failed, and what supports reopening each service. The wider lesson is concrete: follow the authority that enables the next operation. The blockchain recording an action is only one part of the system that allowed it.
