AI × Crypto · Developing
408.5 Million NTX Came Out of NuNet's Own Minting Key
Four token contracts across the Artificial Superintelligence Alliance were drained or inflated inside a day. Fetch.ai says signing keys were stolen. It has not said how — and the converter that paid out first checks a signature and almost nothing else.
Over roughly twenty-four hours this weekend, a single attacker emptied a Fetch.ai token converter, then used stolen minting keys to conjure new supply for three more tokens belonging to the same corporate family. The projects — Fetch.ai, NuNet and SingularityNET — are the constituent members of the Artificial Superintelligence Alliance, the 2024 merger that pooled three AI-and-crypto teams under one token. Whatever was breached, it was upstream of all of them.
Fetch.ai has published what it calls a preliminary on-chain analysis, which PANews reports traces the path from a compromised signing key to the attacker's cash-out wallet. TechFlow's account of the same statement says attackers "gained access through stolen signing keys," and that Fetch.ai has worked with SingularityNET to disable the affected wallets and contracts. Neither statement says how the keys were obtained. That gap is the whole story, and it is still open.
One function, one signature, the whole balance
The first loss is the one we can read for ourselves. According to Blockaid, the attacker used a valid conversion-authorizer signature to call conversionIn on Fetch.ai's TokenConversionManagerV3 contract, releasing the converter's FET inventory in a single transaction. Coinpedia and Fetch.ai's own figure put the amount at 8,721,530 FET, worth roughly $1.55 million.
The source for that contract is public, in SingularityNET's converter-token-manager-v3 repository, and it is worth reading rather than summarising. The contract has two mirror-image functions. conversionOut — the one where a user hands tokens to the converter — carries a checkLimits(amount) modifier that reverts anything below a minimum or above a maximum per-transaction size. conversionIn — the one that sends tokens out to an address the caller names — does not carry it. Its only guards are that the destination is not the zero address, that the signature recovers to the stored authorizer, that the signature has not been used before, and that the converter holds enough tokens to cover the request.
Read plainly: the direction that takes money in has a ceiling, and the direction that pays money out does not. With a valid authorizer signature, the maximum withdrawal is whatever the converter happens to be holding.
There is a second structural detail in the same few lines. The authorization check is a raw ecrecover against a single stored address, _conversionAuthorizer. That construction can only ever validate a signature from a plain externally-owned account — one private key, one signer. It cannot accept a multisig or a smart-contract wallet signature, because those are not ECDSA recoveries. The owner can rotate the authorizer to a different address, but it will always be another single key.
None of that is a bug in the ordinary sense, and it is worth resisting the reflex to call it one. Capping an inbound conversion is genuinely awkward: the amount is fixed by what a user already locked on another chain, and a ceiling would strand anyone whose legitimate transfer exceeded it. Plenty of bridges are built this way. The point is narrower and harder to argue with — the design concentrates the entire converter balance behind one key, and the contract has no second opinion to offer when that key signs something.
Then the minting keys
The wallet that received the FET went on to mint. Per Coinpedia and Blockaid, 408.5 million NTX were created directly through NuNet's deployer account. NTX carries a stated maximum supply of one billion tokens, per CoinGecko — so a quantity equal to about 41% of the token's entire cap was issued in one action, by the project's own key, to someone who did not own the project.
Then SingularityNET. PeckShield reported that the same attacker minted 260 million AGIX and 53.838 million WMTx on Ethereum. PeckShield also counted the attacker's holdings at roughly $16.77 million at the time — including 198.3 million AGIX valued near $14.42 million, 649 ETH, and 33.538 million WMTx.
Four contracts, one actor, one weekend
| Token | Amount | Mechanism |
|---|---|---|
| FET (Fetch.ai) | 8,721,530 drained | Authorizer signature on conversionIn |
| NTX (NuNet) | 408,500,000 minted | NuNet deployer / minting key |
| AGIX (SingularityNET) | 260,000,000 minted | Not yet specified |
| WMTx | 53,838,000 minted | Not yet specified |
The numbers do not agree yet
They rarely do this early, and it is worth naming rather than smoothing over. Coinpedia dates the attack to September 19; The Cryptonomist and PeckShield's alerts place it on September 20. The FET loss is given as roughly $1.53 million by Coinpedia and roughly $1.56 million by BeInCrypto, against the same 8.7 million tokens — a price-timing difference, not a dispute about the transfer. The NTX mint is valued at about $452,000 by BeInCrypto and about $463,000 by Coinpedia. The reported fall in NTX ranges from 65% to more than 90% depending on the outlet and the hour.
Only one of those disagreements matters, and it is the date. Everything else is a valuation snapshot of a token whose supply had just been inflated by two-fifths, which is not a number that means very much. What the spread really records is that no full postmortem exists. Fetch.ai has said its analysis is preliminary and the investigation is open.
What a mint is actually worth
The $16.77 million PeckShield attributes to the attacker deserves an asterisk. Most of it — 198.3 million AGIX, marked near $14.42 million — is the minted supply itself, still sitting in the wallet. A token you printed is worth the quoted price only until you try to sell it, and a book deep enough to absorb 198 million unbacked units at the quoted price is precisely the book that does not exist. The portion the attacker did convert is the portion that was real: PeckShield tracked roughly 546.36 ETH, about $1.44 million, swapped out of the stolen FET.
That asymmetry is the recurring shape of the unbacked-mint incident. Draining a converter yields liquid assets someone else deposited. Minting yields a large number on a screen and a narrow, closing window in which to trade any of it. It is also why the deactivation work Fetch.ai describes — disabling affected wallets and contracts alongside SingularityNET — is the meaningful response even after the tokens exist. The mint cannot be undone. Its convertibility can be attacked.
The part that has not been answered
Four contracts across three projects, reachable within a day, through keys held by different teams. That pattern points somewhere upstream — shared operational infrastructure, a shared secrets store, a shared administrator — but Fetch.ai has not said where, and this desk will not guess on its behalf. The alliance structure that makes the coincidence suggestive is also a perfectly ordinary explanation for why three merged teams might share a deployment pipeline.
What can be said now is what the published record shows: a converter that pays out on one signature with no ceiling, minting keys for at least two tokens in an attacker's hands, and a preliminary analysis that stops at the cash-out wallet. The remaining question is not what the contracts did. They did what they were configured to do. It is how one actor came to hold the credentials of three separate projects on the same weekend.
The Take
The industry spent a decade auditing contract logic and has spent 2026 losing money to key custody instead. This incident is a clean specimen: nothing here required finding a flaw in anyone's Solidity. It required holding the right key and calling a function exactly as written. The one design choice worth arguing with is the asymmetry in the converter — a per-transaction limit on the inbound leg and none on the payout leg means the blast radius of a leaked authorizer key is the whole balance, every time. A ceiling on conversionIn would not have stopped the theft. It would have capped it, and it would have forced the attacker into repeated transactions that monitoring has a chance of catching. That is the whole argument for limits: not prevention, but turning a single fatal event into a sequence somebody can interrupt.