Kasplex Deploys KRC-20 Indexer Fix After Signature Bypass—Recovery Is Still Unfinished

Kasplex released KRC-20 indexer version 3.01.260930 on 3 October 2026 after a September signature-validation bypass created unauthorized token balances. The code correction is material, but it does not by itself restore affected liquidity, reopen every bridge route or complete compensation.

The repaired indexer changes how KRC-20 transfers are accepted. According to specialist reporting by Kaspa News dated 3 October, a transfer is now counted only when it uses the standard form in which Kaspa validates the owner’s signature. Non-standard forms that previously created the authorization gap are ignored. The public Kasplex service was rolled back, rechecked and returned using the corrected rules.

Kasplex also told self-hosted indexer operators to stop their service, remove the existing data and rebuild the token history under the updated rules. That is an important operational detail: the fix is not simply a front-end patch. Independent operators must resynchronize before their KRC-20 state can reflect the stricter interpretation.

What happened—and what did not

The September incident affected the off-chain indexer that interprets KRC-20 instructions carried in Kaspa transactions. Reporting and ecosystem incident statements describe an attacker creating unauthorized ZEAL and NACHO balances and moving them through bridges into liquidity pools. The distinction matters: this was not presented as a compromise of Kaspa’s layer-one consensus, a theft of users’ seed phrases or a forged Kaspa signature accepted by the base network.

KRC-20 state is interpreted outside Kaspa’s core consensus. That architecture allowed a faulty authorization rule in the indexer to recognize balances that the underlying signature conditions should not have supported. The new version is designed to reject those malformed transfer paths. Kasplex’s public GitHub package registry provides the project’s distributed indexer packages, while the detailed change and recovery status were documented by Kaspa News from project releases, code changes and ecosystem statements.

The correction therefore addresses the accounting path that enabled the incident. It does not erase the economic consequences already created when unauthorized balances reached bridges and markets.

Recovery and bridge risk remain

As of 3 October, the recovery plan for affected ZEAL and NACHO holders was still being worked out. Kaspa News reported that the relevant KRC-20 bridge routes remained closed and that the bridge operator continued to advise against treating the code fix as a completed recovery. ZealousSwap had reopened some trading after isolating affected routes, but said trades made during and after the incident would remain valid and that a final recovery plan should not be rushed.

Those conditions create two separate tests. The technical test is whether independently rebuilt indexers converge on the corrected token history without new discrepancies. The economic test is whether bridge operators, liquidity venues and affected communities agree on a transparent treatment of recovered, escrowed and missing assets.

A pass on the first test does not automatically pass the second. Traders should distinguish “the exploit path is closed” from “all users are made whole.” They should also distinguish KRC-20 token balances from native KAS held under Kaspa’s base-layer rules.

Why this matters for KAS

The direct incident exposure sits in the KRC-20 and bridging layer rather than Kaspa consensus. That limits the strongest bearish interpretation. Even so, ecosystem applications depend on users trusting indexing, bridge and settlement infrastructure. Rebuilding that trust requires reproducible state, public incident accounting and conservative reopening criteria.

For KAS, the development is best viewed as an infrastructure-risk test rather than evidence of a base-chain failure. A successful resynchronization across operators would reduce uncertainty around KRC-20 accounting. A fragmented rebuild, unexplained supply differences or premature bridge reopening would widen the risk premium around applications built above the base network.

NetNapz assessment

Fact: a corrected indexer version has been released, the public service has reprocessed token history under stricter rules, and the previously forged transfer no longer appears in the corrected records reported by Kaspa News. Inference: this is constructive for containment but insufficient for a bullish conclusion because recovery, bridge hardening and compensation remain incomplete.

Bull case: independently operated indexers reproduce the same corrected balances, affected routes reopen only after audits and bridge hardening, and a documented recovery plan reconciles returned, escrowed and missing funds. That sequence would show that the ecosystem can isolate an application-layer failure without impairing Kaspa consensus.

Bear case: operators produce inconsistent rebuilt states, new malformed transfers appear, recovery disputes persist or bridges reopen before verification is complete. In that scenario, the code patch would not have resolved the wider confidence problem.

Confirmation: reproducible indexer state, published bridge-reopening criteria and verifiable settlement of affected balances. Invalidation: a renewed authorization bypass, materially inconsistent KRC-20 histories or evidence that the incident scope extends beyond the currently identified tokens and routes.

What to watch

Over the next several days and weeks, watch for a formal recovery proposal, the status of ZEAL and NACHO liabilities, bridge-audit results, a clear reopening timetable and confirmation from independent indexer operators that full resynchronization produces matching state. The broader technical question is whether KRC-20 validation rules and release procedures now make similar authorization assumptions harder to reintroduce.

No price target or execution level is provided. The important decision points are operational and verifiable: state convergence, bridge controls, recovery completion and the absence of another bypass.

Sources: Kaspa News technical and recovery report, 3 October 2026 · Kasplex GitHub package registry · ZealousSwap incident and recovery updates.