Security Incident Report — Updated

[Duka]

Security Incident Report — Updated

Klever Blockchain — NFT Marketplace Royalty Inflation Exploit

Status: Mitigated — Investigation Ongoing

Summary

Klever was alerted by the KleverPulse community builder (kpulse.tech) to suspicious on-chain activity. Internal investigation confirmed a critical arithmetic flaw in the NFT Marketplace kApp settlement logic that allowed an attacker to mint KLV out of thin air through self-controlled NFT trades.

The fix was deployed to mainnet on June 5, 2026 at 19:00 UTC (fork 19.rc-2). Two epoch transitions have since completed with no anomalies reported.

Exploit Window

2026-06-04T10:38:24Z → 2026-06-05T11:30:32Z (~25 hours)

Root Cause

The settlement layer of the NFT Marketplace kApp failed to validate that the sum of referralPercentage and royalties.marketPercentage could not exceed 100% at the time of the Buy transaction. These values were validated independently and at different points in time, allowing the attacker to manipulate one of them after the sell order was already snapshotted.

At settlement, both the referral payout and the royalty payout were credited in full against the buyer’s bid, but the seller’s debit was computed as:

bid − referral − royalty

When both percentages were 100%, this resulted in a negative debit that was silently skipped, effectively minting the difference. Since the attacker controlled the buyer, seller, royalty receiver, and referral address simultaneously, the entire surplus flowed to a single beneficiary.

On-Chain Footprint

The attacker operated across 2 addresses and 283 total transactions, spanning 4 NFT collections (POCDJ08X0X, POCDJ090G7, POCDJ0GG, NFLATION) and 2 marketplaces (both named “Inflation Market”).

• Execution: The buy cycle was executed 60 times, with bid values escalating in a doubling ladder peaking at 25,600,000 KLV per self-buy.

• Total Minted: A total of 486,357,300.26 KLV was artificially generated by the exploit.

• Reconciliation: The attacker’s estimated total position (transfers out + DEX swaps + remaining balance) was ~486,527,149 KLV — a delta of ~169,849 KLV, which is consistent with the attacker’s pre-existing legitimate balance and fees consumed during setup operations.

Fund Flow & Exchange Exposure

Post-mint, the attacker dispersed funds through 9 intermediate wallets and routed KLV to multiple destinations. Current taint graph analysis (6 depth levels, 28 tainted edges, 27 chains enumerated) has confirmed deposits to KuCoin. Other listed exchanges have been flagged as suspected destinations based on initial traces and are currently under active investigation:

Exchange	Estimated KLV Deposited	Status
KuCoin	~69,707,673 + ~55,285,585	Confirmed
Gate	~777,472 + ~627,135	Suspected / Under Analysis
MEXC	~792,881 + ~358,471	Suspected / Under Analysis
VoxSwap	~5,000	Suspected / Under Analysis
Bitget	Multiple traceable deposits	Suspected / Under Analysis

• KLV Residue: Remaining KLV was traced to 10 intermediate wallets still holding funds, flagged for blocking.

• Ethereum Bridge: On the Ethereum side, fabricated KLV was swapped on the DEX to wrapped assets (USDC, USDT, WBTC, WETH) and bridged out via the ETH–KLV bridge.

Known Attacker Addresses

KLV (Primary):

Plaintext

klv12n4z3ef86sfk2z97j4fhfta9f2xztsv6frr8faqj7l8q9kc0fcdsfjfqez

ETH:

Plaintext

0x5B9c0b7545aC8a62bff83C73b8A0Ab0568f36E6c
0x163945Fd929c0d4FcE2EA2B6011a789c939cdD59

Note: KLV intermediate wallets flagged for blocking (10 addresses, residues ranging from ~3 KLV to ~55M KLV) — full list available on request.

Response & Mitigation

• Patch Deployed: June 5, 2026 ~19:00 UTC: Fork 19.rc-2 deployed to mainnet. This is the final fix for this vulnerability.

• Network Stability: Two epoch transitions completed post-fork with no registered issues.

• Blacklisting: TRM Labs notified with ETH addresses for blacklisting.

• Exchange Coordination: Exchange contacts are currently being pursued for KLV deposit freezes.

Next Steps

1. Service Restoration: Gradually restore all affected services, including the ETH–KLV bridge, bitcoin.me, and swap.

2. Monitoring: Upgrade network monitoring infrastructure with AI-assisted anomaly detection to proactively identify abnormal on-chain behavior across all kApps.

3. Legal Action: Initiate formal criminal proceedings, including police reports and applicable legal procedures across relevant jurisdictions.

4. Buyback Program: Execute a KLV buyback, conducted gradually and at the team’s discretion, to counteract the price pressure resulting from the attacker’s liquidations.

5. Token Burn: Plan and execute a burn of the full 486,357,300.26 KLV artificially minted during the exploit, restoring the circulating supply to its pre-attack state.

6. Post-Mortem: Complete root cause analysis and publish the full post-mortem.

7. Account Freezes: Continue engaging exchanges for account freezes on all confirmed deposit addresses.

Disclaimer: This is an updated preliminary report. Information is subject to revision as new findings emerge.

[Burak_Kulaksizoglu]

Question about the exploit, circulating supply accounting, and supply-level monitoring

I’ve been tracing the incident on-chain and I’d like the team to clarify something about how the supply numbers reflect (or don’t reflect) the attack.

KleverScan computes circulating supply as mintedValue − burnedValue. When I compare the figures across the exploit window, the circulating supply doesn’t show the attack at all:

• Epoch 5717 (before the exploit): 9,621,913,408 KLV
• Now: 9,625,355,293 KLV
• Net change: ~3.4M KLV, which matches the normal staking-reward growth (~132k/epoch over 28 epochs).

There is no ~486M jump anywhere in the supply trajectory.

Looking at the exploit transactions, the reason seems clear. Each fraudulent Buy settled against the marketplace’s built-in settlement address (the klv1qqqq… address, nonce 0). In a single buy, the attacker sent in 25.6M KLV, and the settlement address paid back 25.6M as “referral” + 25.6M as “royalty” (both manipulated to 100%), while the seller debit that should have offset this went negative and was silently skipped. The surplus landed in the attacker’s real, spendable balance — but it was never recorded as a mint. The transactions contain Transfer receipts only: no Mint and no Burn receipt. So mintedValue was never incremented, and the supply counter never moved, even though hundreds of millions of real, transferable KLV were created and later sent to exchanges.

In short, this behaved like an “off-the-books” issuance: economically real and spendable KLV that’s invisible to the protocol’s supply accounting.

Question 1 — the burn: When you burn the 486M KLV from the attack, the circulating supply will still show ~9.62B — basically unchanged — correct? Since the exploited KLV was never added to mintedValue in the first place, the burn would either have to be booked as a burnedValue increase (which would actually push the displayed circulating below its pre-attack level), or it won’t move the headline 9.62B figure at all. Can you clarify how the burn will be reflected in the supply numbers, given that the mint never registered in them?

Question 2 — the structural risk: I understand this specific bug (the missing validation on referral% + royalty% exceeding 100%) was closed in fork 19.rc-2, and that’s reassuring. But the underlying mechanism — that a flaw in settlement accounting can produce real, spendable value without leaving any trace in the supply figures — seems like a structural risk worth addressing beyond this one patch. If the total supply metric can’t catch this class of issue, what transaction-level invariants or monitoring are being put in place to ensure that settlement payouts can never exceed settlement inputs again across all kApps (not just the NFT marketplace)?

[Duka]

Hi Burak,

First, thank you for the thorough on-chain analysis. You’ve outlined the exact mechanics of how this exploit bypassed the standard supply accounting, and your technical assessment is spot on.

Here is how we are addressing the two critical points you raised:

1. The Burn and Circulating Supply Accounting

You are entirely correct that a standard burn transaction would simply increment the burnedValue without a corresponding mintedValue. As you pointed out, this would artificially push the displayed circulating supply below its true, pre-attack level.

To resolve this, we will not just fire off a standard burn. As established in our mitigation plan, we are coordinating a specialized burn process specifically designed to adjust the on-chain supply metrics. The goal is to ensure that once the 486M KLV is destroyed, the on-chain accounting is accurately reconciled to match what the circulating supply should be, without breaking the KleverScan math. We will share the technical mechanics of this state adjustment before it is executed.

2. Structural Risk and Protocol-Level Safeguards

You hit the core issue: patching a specific arithmetic bug in one kApp isn’t enough if the underlying settlement logic can still silently inflate value without triggering supply alerts.

We are not just stopping at the patch. We are already engineering a more robust, systemic solution to address this exact structural risk. Our team is working to expand the network’s monitoring capabilities by implementing a protocol-level “second check.” This invariant check will strictly evaluate the inputs versus outputs of any transaction before finalizing the state. If an anomaly is detected—such as settlement payouts exceeding the settlement inputs—the transaction will automatically revert.

This fail-safe is being designed to operate across all kApps, ensuring that local settlement logic can never bypass global supply constraints again.

We highly appreciate this level of scrutiny from the community. It’s exactly this kind of oversight that helps us build a more resilient network.

Best,

DK

[Burak_Kulaksizoglu]

Thanks Duka, that’s a clear and reassuring response on both points. I’d like to drill into the burn mechanics a bit, since this is where the accounting gets subtle.

On the “specialized burn” / state reconciliation:

You mentioned you’ll adjust the on-chain supply metrics so the burn doesn’t push circulating below its true pre-attack level. To make this verifiable for the community, could you clarify exactly which fields will change and how?

1. Will the reconciliation work by lowering mintedValue (effectively reversing the off-the-books issuance as if the mint never happened), or by increasing burnedValue while also adjusting initialSupply/mintedValue to keep circulating = mintedValue − burnedValue at the correct pre-attack figure? The two approaches leave very different audit trails.
2. Will this state adjustment be a single on-chain transaction (or set of transactions) anyone can inspect on KleverScan, or an off-chain/state-level edit applied at a fork? If on-chain, could you share the transaction hash(es) once executed so we can verify the before/after supply ourselves?
3. Is there a target epoch or date for the burn + reconciliation? A concrete reference point would let us watch the numbers move in real time.

On the protocol-level invariant check:

4. Once the input-vs-output “second check” is live across all kApps, how will the community be able to confirm it’s actually enforced — e.g. a fork version, a config flag, or a demonstrable test transaction where an over-payout reverts? Just so we know the fail-safe is active and not only deployed in name.

One suggestion (not a demand):

5. The reconciliation effectively neutralizes the accounting impact, but the ~486M tokens are economically real and already out in the market. Since a buyback program is already planned, would the team also consider pairing it with a genuine, voluntary burn of an equivalent amount from team/treasury reserves? That would actually reduce the real circulating supply rather than just correcting the ledger — and it would send a strong signal that the cost of the incident is being absorbed by the project rather than diluted across holders. Totally understand if the reserve situation makes this difficult, but I think the community would really appreciate even a partial gesture in this direction.
6. On a related note — there was talk a while back about burning the KLV that had been accumulating from the genesis validators, but as far as I can tell that was never actually carried out. Could you give an update on the status of that? It feels like a natural complement to the current cleanup, and following through on it now would build a lot of goodwill.

Appreciate the transparency so far — just want to make sure the fix, the burn, and the broader supply commitments are all independently verifiable once they land.

Thanks ,

Burak.

---

[Duka]

Hi Burak,

Thanks for following up. These are exactly the right questions to ask, and I appreciate the depth of your analysis. Let’s break down each point directly.

1. The Burn Mechanics & State Reconciliation

Since the exploit took advantage of a flaw to artificially mint KLV without affecting how the network calculates the official supply, the burn will follow the exact same logic. The goal is to remove those artificially minted KLVs from circulation without altering the official supply counters. This approach will effectively reverse the “off-the-books” issuance, restoring the coherence between the calculated supply and the actual amount of KLV in circulation.

The exact technical strategy to execute this is still under active discussion by our core engineers to ensure we use the safest approach with the lowest risk of unintended chain impact. However, we have already established that the burn will occur through the approval of a formal on-chain proposal via the network’s governance structure.

We don’t have a hard target date yet, as we want to execute this as fast as possible but prioritize the absolute security and transparency this movement requires. Once the technical path is finalized, the entire procedure will be public, verifiable on KleverScan, and officially announced before execution.

2. The Protocol-Level Invariant Check

The “second check” safeguard will be deployed as part of an upcoming network fork.

To ensure the community can independently verify that this fail-safe is active and strictly enforced, our integration tests will specifically cover and confirm this over-payout reversion scenario. Since Klever’s codebase is fully open-source, all of these tests and the underlying code will be pushed to our public repositories. Any community member or developer will be able to review the logic, inspect the invariant checks, and run the tests themselves at any time.

3. Mitigated Impact, Genuine Burns, and Genesis Rewards

I want to thank you for the suggestions regarding the treasury burn and the genesis rewards.

First, I have some good news on the impact front: of the ~486M KLV artificially minted by the hacker, we successfully tracked down and froze 136,018,157.493492 KLV in the addresses directly involved in the attack before they could be liquidated. This significantly reduced the actual market impact and the total amount circulating in the wild.

Regarding your suggestions: yes, we agree completely. We intend to execute a genuine, voluntary burn from our own reserves to help absorb the impact of the exploit as well. Furthermore, the KLV accumulated from the genesis validators’ rewards will also be utilized in this exact cleanup process. We believe this is the right move to align with the community and correct the ledger.

We really appreciate the trust, the constructive scrutiny, and the open dialogue. We will be sharing all the technical details, transaction hashes, and further next steps in our upcoming Action Plan update reports.

Best,

DK

[Burak_Kulaksizoglu]

Thanks Duka, this is a great response — the commitment to doing the burn through an on-chain governance proposal that’s verifiable on KleverScan, and pushing the invariant check + its integration tests to the open-source repos, is exactly the kind of transparency that builds confidence. And it’s great to hear the voluntary treasury burn and the genesis-validator rewards will both be folded into the cleanup.

Two small things I’ll be looking forward to in the Action Plan update:

1. The exact reconciliation method. Whenever the engineers finalize it, it’d be really helpful to spell out which supply field actually changes (e.g. reducing mintedValue to reverse the issuance vs. adjusting burnedValue/initialSupply), since that determines what we’ll see on KleverScan before/after. Even a one-line “here’s the field that moves and why” would make the burn fully auditable.
2. The transaction hashes. Once the governance proposal passes and the burn + treasury/genesis burns execute, sharing the hashes would let the community independently confirm the before/after supply in real time.

No rush on timing — I’d much rather you take the safe, well-tested path than move fast. Really appreciate the open dialogue and the level of engagement here; this is how trust gets built. Looking forward to the Action Plan report.

Best, Burak