KCC20 Borrower Path Pushes Tokens Toward A Common Interface

The strongest post-activation design debate in the R&D channel is not about hype around native assets. It is about how covenant tokens should actually be recognized, transferred, and received without creating bad UTXO incentives.

Manyfestation reset the topic on June 25 with a draft proposal for a minimal interaction interface for fungible tokens on Kaspa. The proposal centered on a TokenDescriptor that lets tooling recognize, index, and transfer covenant tokens while leaving each token free to extend its own state, logic, and policy. He separated the surface into reader/indexer, writer/wallet, and later SDK/SilverScript/composability layers, with the first focus on tracking tokens and creating valid transfers. ^[1]

The debate quickly narrowed to the borrower path. Sutton introduced the core motivation as KIP-9 and storage mass: KAS is the scarce resource backing UTXO storage, so creating new UTXOs with tiny KAS values is intentionally expensive. For normal KAS transfers, the output itself carries KAS. For asset transfers, the recipient still needs a KAS-backed asset UTXO, but the sender should not have to donate fresh KAS storage mass every time they send a token. ^[2]

The proposed repeat-receive answer is a borrower path. If the recipient already has an asset UTXO, the sender can borrow that UTXO without the recipient normal owner signature, but only under additive receive rules: same asset identity, same owner identifier, token amount increases by the received amount, KAS amount stays the same or increases, and optional spam controls through minimum deltas or receive authorization. ^[2]

That design turns a recipient asset UTXO into something the sender can update in a narrow, owner-preserving way. It reduces the need to create a fresh recipient UTXO for every transfer. It also makes wallet and indexer agreement more important, because the system needs a shared way to know which UTXO can be borrowed, under what policy, and how the resulting state should be interpreted.

Arthur argued that a descriptor could expose a borrow or receive policy, saying whether an existing recipient UTXO can be borrowed and under what rules. ^[3] IzioDev pushed on the interface boundary, saying the dilemma is whether reducing owner UTXO count is a base requirement or something that should live above the base interface. He said he still favored a universal built-in mechanism personally. ^[4]

The first-receive case stayed harder. If the recipient does not yet have a borrowable token UTXO, someone still has to fund storage. Arthur suggested a split: sender-provision for first receive, borrower path for repeat receive. In that model, the sender wallet can surface the extra KAS cost when no suitable recipient UTXO exists, while later transfers reuse the existing asset UTXO. ^[5]

Spam protection also became concrete. Sutton said a descriptor could add fields describing if and how to borrow inputs, with canonical mechanisms such as minimum increase, secondary secrets or private keys used only for receive authorization. ^{[6] [7]} Maxim Biryukov warned that preimage or hash knowledge is weak in a mempool because everyone sees it; keypair and signature checks work better. ^[8]

The cleanest security constraint came later from Sutton: there has to be a one-to-one mapping between borrowed inputs and outputs, so witnesses alone are not safe if the same output can satisfy multiple borrowed inputs. ^[9] He suggested requiring the output covenant index to match the input covenant index, or an equivalent mapping from borrowed inputs to outputs. ^{[10] [11]}

This is why the thread is article-worthy. It is not just "tokens are coming." It is the less glamorous design work that decides whether token transfers become wallet-friendly without abusing UTXO storage. The emerging shape is a minimal common descriptor, a reader/writer split, sender-funded first receive, borrower-path repeat receive, and explicit policy fields so wallets and indexers can converge on the same state transitions.