ASI Alliance Breach: Compromised Mint Authority Drained Fetch.ai, NuNet, and SingularityNET for $2.25M Across Three Linked Projects

On September 19 and 20, 2026, a linked attacker targeted three projects within the Artificial Superintelligence Alliance ecosystem: Fetch.ai, NuNet, and SingularityNET. Across a sequence of on-chain operations traced by Bitquery's investigation, the attacker removed approximately 8,721,530 FET from Fetch.ai's token-conversion contract and used privileged minting authority to create large quantities of NTX, AGIX, WMTX, and CGV without any corresponding backing or authorization.

The minted token quantities were substantial in nominal terms: approximately 408.5 million NTX, 896 million AGIX, 500.5 million WMTX, and 492.4 million CGV. However, as Protos reported, these figures should not be mistaken for realized losses. Most of the minted tokens could not be sold at their pre-incident market prices; the actual proceeds from liquidating the positions were far lower than any figure derived by multiplying quantities by spot prices. Bitquery estimated approximately $2.25 million in realized proceeds: around 523 ETH from selling the FET, and roughly 184 ETH plus $52,395 in stablecoins from selling the four minted tokens.

Bitquery's on-chain tracing also identified a sweep of 16 wallets, four of which it had associated with SingularityNET or NuNet infrastructure. The means by which the attacker gained access to those wallets was not established with certainty. A subsequent operation drained $289,575 USDC from what Bitquery described as a payroll or payout contract. As ForkLog noted, analysts linked the wallet activity across all three incidents to a single actor, based on address relationships and the sequencing of operations.

Bitquery's assessment is that the attack abused privileged signing and minting authority rather than exploiting a flaw in the token contracts themselves. The contracts behaved as designed; the problem was that whoever issued the minting and transfer calls had obtained the keys required to do so.

The root cause, to the extent it can be established from available reporting, was a compromise of privileged key material rather than a vulnerability in the token contracts' logic. This is a categorically different attack surface from a smart contract exploit. The token contracts provided mint functions gated by an access control check: only addresses holding the mint authority role can call them. The contracts correctly enforced this check. The attacker satisfied it because they held, or had obtained access to, the keys associated with that role.

How minting authority works and where it fails

Standard token contracts on Ethereum and EVM-compatible networks implement minting as a privileged operation restricted to one or more designated addresses. The most common pattern uses OpenZeppelin's AccessControl or Ownable modules: a role constant is defined, the mint function checks that the caller holds that role, and role grants are controlled by an admin address. The security of this model depends entirely on the security of the private keys that hold the privileged roles. If those keys are compromised, the access control functions as intended: it authenticates the attacker as an authorised caller and allows the mint to proceed.

// Standard access-controlled mint function.
// The contract logic is correct: only MINTER_ROLE can mint.
// The vulnerability is not in the contract — it is in key management.

bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

function mint(address to, uint256 amount) external {
    require(hasRole(MINTER_ROLE, msg.sender), "caller is not a minter");
    _mint(to, amount);
}

// Attacker obtains the private key for an address holding MINTER_ROLE.
// From that point, the contract cannot distinguish the attacker from
// a legitimate minter. Every call passes the access control check.

// Resulting calls (illustrative quantities):
mint(attacker_address, 408_500_000e18)  // NTX
mint(attacker_address, 896_000_000e18)  // AGIX
mint(attacker_address, 500_500_000e18)  // WMTX
mint(attacker_address, 492_400_000e18)  // CGV
// All pass. No contract-level defense remains once the key is compromised.

The conversion contract drain and wallet sweep

The FET component followed a different path. Fetch.ai's token-conversion contract held FET for users converting between token versions or formats. Draining it required a call that either held the owner or admin key for that contract, or exploited a withdrawal or transfer function that accepted a privileged caller. The result, 8.72 million FET transferred to the attacker and then sold for approximately 523 ETH, reflects the same underlying condition: the attacker had access to key material that authorised the operation.

The 16-wallet sweep and the subsequent payroll-contract drain point to the breadth of the access the attacker had obtained. A sweep of 16 wallets, four of which Bitquery associated with SingularityNET or NuNet infrastructure, suggests that the compromised key material was not limited to a single minting key but extended to operational addresses used by the projects. The payroll-contract drain reinforces this: payroll or payout contracts are typically operated by addresses distinct from token mint authorities. Reaching both suggests either a broad key management failure or access to a higher-level administrative credential that could derive or authorize multiple downstream keys.

// What was taken vs. what was actually realized

// FET drained from conversion contract:
fet_removed       = 8,721,530 FET
fet_sold_for      = ~523 ETH

// Tokens minted without authorization and sold:
ntx_minted        = 408,500,000  NTX
agix_minted       = 896,000,000  AGIX
wmtx_minted       = 500,500,000  WMTX
cgv_minted        = 492,400,000  CGV
minted_sold_for   = ~184 ETH + $52,395 USDC
// (most of the minted supply could not be sold without collapsing price)

// Additional cash taken:
payroll_contract  = $289,575 USDC

// Total estimated realized proceeds: ~$2.25 million
// (not the much larger nominal value of all minted tokens at pre-incident prices)

The precise access vector remains uncertain

Bitquery's investigation establishes what the attacker did on-chain but does not confirm how they obtained the privileged keys. The candidate scenarios include a targeted phishing or social engineering attack on a keyholder, a compromise of key storage infrastructure, a software supply chain attack affecting a tool or dependency used in key management, or insider access. The 16-wallet sweep encompassing addresses associated with two different projects within the same alliance suggests either that a shared key management system was compromised, or that the attacker had obtained access to credentials with cross-project reach. Without a confirmed technical post-mortem from the affected projects, the precise vector remains a reconstruction.

• Require multi-signature authorization for any mint operation. A single key holding MINTER_ROLE is a single point of failure. Replacing it with a multi-sig threshold, requiring M of N independent keyholders to authorize each mint call, means that compromising one key is not sufficient to execute an unauthorized mint. For token supply operations of this magnitude, a 3-of-5 or similar threshold across geographically and organizationally separated keyholders is the appropriate control. Protocols that retain single-key mint authority for operational convenience are accepting a risk whose downside is proportional to the entire circulating value of the token.
• Impose a timelock on large mint operations. Any mint above a defined threshold should be subject to a mandatory delay before execution, announced on-chain at submission. A 24 or 48-hour timelock on mints above, for example, 1% of circulating supply would have created a visible, on-chain signal of the pending unauthorized operations and a window for the teams to cancel them before any tokens were issued. Timelocks do not prevent the attacker from submitting the transaction, but they prevent instantaneous execution and give defenders time to respond.
• Use hardware security modules or MPC for privileged role keys. Private keys that control mint authority, contract ownership, or treasury access should not reside on general-purpose computers accessible via internet-connected sessions. Hardware security modules enforce signing in isolated, tamper-resistant hardware. Multi-party computation distributes key material such that no single device or operator holds a usable key fragment. Either approach dramatically raises the cost and complexity of extracting the key material needed to impersonate a privileged role.
• Segregate mint keys, operational keys, and payroll keys by principle and practice. The breadth of this incident, spanning mint authority across four tokens, a conversion contract drain, a 16-wallet sweep, and a payroll contract, suggests that keys with different functions were either stored together or derivable from a shared credential. Each category of privileged key should have its own isolated lifecycle: separate generation, separate storage, separate access logging, and separate revocation procedures. A compromise of a mint key should have no path to a payroll key, and vice versa.
• Monitor for anomalous mint events and large token movements in real time. A mint of 896 million AGIX is not a routine operation. An on-chain monitoring system watching for mint function calls above a defined threshold would have produced an alert within seconds of the first unauthorized transaction. At that point, emergency revocation of the compromised role or a contract pause could have stopped subsequent mints even if the first had already executed. Real-time monitoring does not prevent the first transaction, but it can limit the total damage by reducing the window for subsequent operations.
• Conduct cross-project key management audits within shared ecosystems. Projects within an alliance or ecosystem that share infrastructure, tooling, or operational practices inherit each other's key management risks. An audit that reviews key storage, access controls, and role assignments across all linked projects as a single exercise, rather than reviewing each project in isolation, is more likely to identify shared vulnerabilities before they are exploited. A compromise that can reach three projects in one operation is evidence that their security perimeters overlap more than each project's individual audit may have reflected.