An attacker took ZEAL and NACHO tokens from a bridge on 20 September without stealing its private keys. According to the ZealousSwap incident report, the failure was in the Kasplex indexer, the software that reads KRC-20 instructions and keeps track of token balances. The bridge later trusted those incorrect balances and issued tokens that the attacker could sell.
The incident exposed a difference that is easy to miss. KRC-20 data is recorded on Kaspa, but separate software applies the token rules. Storing an instruction on the network does not make that instruction an authorised token transfer.
What Kaspa records and what Kasplex decides
Kaspa L1, the base network, has no KRC-20-specific program that checks token ownership or calculates KRC-20 balances. Token instructions are stored inside Kaspa transactions. The Kasplex indexer reads those instructions, decides which ones count and updates its token records.
Kaspa nodes still check the surrounding transaction. They check that the KAS being spent is available, that the amounts follow network rules and that the conditions for spending those coins are met. Those are checks on the KAS transaction, not on the meaning of the KRC-20 data it carries (transaction validation code).
That is why a transaction can be accepted by Kaspa while the token instruction inside it should be rejected by Kasplex. The two systems have different jobs. A confirmed transaction alone is not proof that the KRC-20 token owner approved a transfer.
Where the token check failed
The attack used the bridge's public key. Unlike a private key, a public key is visible information and does not give someone control of a wallet.
The attacker placed that public key inside a script, a set of instructions attached to a Kaspa transaction. There was no signature from the bridge. The script's signature check returned false, but the attacker added another instruction that changed that result to true.
Kaspa nodes ran these spending instructions to check the KAS transaction. They did not run the KRC-20 token instruction, which was stored as data in a skipped section. Kasplex read that data separately. The attacker had created the spending script. They had not changed the rules protecting the bridge's KAS (reported transaction, signature-check code).
The crucial mistake came next. The indexer took the public key from the script and treated the token instruction as coming from that key's owner. It recognised the expected pieces without requiring the complete script structure that would prove the owner had signed. A public identifier was treated as permission (Kasplex parser).
The report, written by Louis Saad, identifies five successful forged transfers involving about 186.4 million ZEAL and 54.4 billion NACHO. Those are the amounts moved through the forgeries, not a final figure for money stolen. The reported flaw concerned KRC-20 transfer checks generally, rather than a rule unique to either token.
How the false balance reached the bridge
A bridge holds tokens on one network and issues matching tokens on another. The tokens it holds are supposed to back the ones it issues.
After the forged transfers, the attacker sent tokens back to the bridge as ordinary deposits, signed with the attacker's own key. The bridge saw deposits from an address that the indexer said owned those tokens. It then issued matching tokens on Igra and Kasplex L2, where they could be traded.
But the original bridge holdings had already backed tokens circulating on those networks. Moving tokens out without permission and depositing them again did not remove those existing tokens. Issuing more created a shortfall between the tokens in circulation and the backing held by the bridge.
KAT says its bridge issued tokens only after the Kasplex indexer reported a successful deposit. It also says its signing and administrator keys were not compromised. The bridge relied on the indexer to establish ownership, and that dependency carried the error into another system.
The attacker sold the newly issued tokens into trading pools, which hold assets supplied by other users for swaps. The report measured about 2.01 million KAS worth of reserves removed from four pools. It explicitly says some of that came from other holders selling and people withdrawing their liquidity. It is not the same as the attacker's proceeds (report).
Blocked withdrawals are not recovered funds
An independent reconstruction by CatDog, published on 21 September, supports the reported cause and adds detail about where the funds went. This is an individual researcher's work, separate from the projects' investigations.
CatDog found a sixth transaction with the same attack pattern, but reported that its KRC-20 transfer failed because the sender's recorded token balance was slightly too low. That stopped this particular transfer. It did not show that the missing permission check had been fixed (analysis).
The reconstruction traces about 141,594 KAS paid out through five Kasplex L2 bridge withdrawals. On Igra, CatDog reports four requests to exchange a total of one million iKAS for KAS on the base network. The iKAS was removed from circulation, but the corresponding KAS payments had not arrived (Kasplex payouts, Igra withdrawal requests).
Pausing those payments may stop the attacker from receiving more KAS. It does not establish that the funds have been returned to affected users. CatDog asks how the outstanding withdrawal requests will be cancelled, reassigned or otherwise secured. That remains a separate question from whether the bridge is paused (follow-up).
What still needs to be repaired
On 21 September, Kasplex said it was investigating, temporarily disabling its public API and asking users to stop KRC-20 operations. KAT said bridge routes were paused. Neither statement established that a corrected indexer and repaired token history were already running (Kasplex, KAT).
Fixing the indexer means both rejecting unauthorised instructions and recalculating balances from valid history. This changes the token records kept by the indexer. It does not require rewriting the transactions already stored on Kaspa.
It also does not automatically undo what happened on other networks. Newly issued tokens were sold to buyers. The incident report says the four affected token contracts have no administrator function to freeze or burn those tokens. Restoring the backing and resolving withdrawals therefore need more than a corrected balance display.
Igra's notice warned against bridging KRC-20, buying the affected tokens on other networks or adding funds to their trading pools. For holders, the next meaningful update needs to explain which balances have been corrected, how bridged tokens will be backed and what will happen to pending withdrawals.
