When a wallet shows a token, its name and symbol make it easier to recognise. But the wallet also needs a way to check where those details came from. Manyfest has proposed a way to connect that information to a token's identity on Kaspa, so applications can verify it rather than rely only on the website supplying it.
The proposal is called KCC-23. It is still a draft, but it addresses a practical question raised while Manyfest was working on KCC-20, a design for tokens built with Kaspa covenants. Where should a token's description live, and how can a wallet check that it belongs to the token being displayed? (Manyfest's explanation)
Why the label matters
A name, a symbol and a logo help people recognise an asset. Software also needs details that are less visible, such as the number of decimal places used to display its balance. Developers call this descriptive information metadata.
The draft gives an example of a token named Example Token, with the symbol EXT and eight decimal places. A wallet following that convention would display a raw balance of 100,000,000 units as 1 EXT. If it used nine decimal places instead, the same balance would appear as 0.1 EXT. The underlying amount has not changed, but the number shown to the holder has. (Token example)
That makes the description more than decoration. A wallet needs the right information to present the asset clearly. It also needs to know which asset the information describes. Names and symbols alone are not enough, because different tokens can use the same ones.
For a covenant token, the more precise reference is its covenant ID. This is a calculated identifier, separate from its human-readable name. KCC-23 would connect a declaration of metadata to that identifier, giving software something it can check.
Why the description should not follow every transfer
Kaspa covenants place rules on how transaction outputs can be spent. Developers can use them to build applications such as tokens. Those tokens can be held across many separate outputs, called UTXOs, which transfers spend and replace.
The balance in each holding matters to the token's rules. Its name and description usually apply to the token as a whole. Copying those details into every holding would repeat the same information and carry it through later transfers. Manyfest wanted to avoid that duplication. (Announcement)
KCC-23 separates the two jobs. The covenant controls what spending is allowed. A declaration made when the covenant is created describes the application. The proposal adds no spending permission and does not change the rules that protect the funds. After deployment, transfers need no extra input or output just to carry this description. (Design rationale)
Two transactions connect the description to the token
The proposed process begins before the covenant is created. The creator puts the metadata into a preparation transaction, using JSON, a common text format for named fields and their values. That transaction also creates an output that can be spent.
The next transaction spends that particular output to create the covenant. This connects the two records. The first transaction's ID depends on the metadata it contains. The covenant ID, in turn, depends on the output used to create it and the relevant creation outputs. Changing the description changes the first link in that calculation. (Deployment and verification)
A wallet could receive copies of both transactions and repeat the calculations. It would check that the second transaction uses the expected output from the first, then check that the resulting covenant ID matches the token it is examining. Someone supplying a changed description could not simply keep the original IDs and expect that check to pass.
For example, the draft includes a check where the declared decimal setting changes from eight to nine while the expected covenant ID stays the same. The modified description must fail verification. These are constructed examples for checking implementations, not evidence of a token already launched with the proposal.
The application must still start with the correct covenant ID. Checking a declaration against that ID is separate from establishing that a token exists on the network or is the asset the user intended to select.
Keeping a checkable copy without keeping every old block
Kaspa nodes do not all have to retain the full transaction history forever. Pruning lets ordinary nodes discard old historical data while retaining what they need to validate the current network state. This helps keep the storage burden of running a node manageable.
A description stored only in an old transaction would therefore be a poor long-term plan if applications expected every ordinary node to keep providing it. The transaction might remain available from an archive, but a regular node is not a permanent archive.
KCC-23 allows the two deployment transactions to be preserved and shared outside the network as a launch proof. A project could supply a copy, and another service or user could keep the same records. A wallet could check that copy against the expected covenant ID even when its node no longer stores the original historical transaction data. (Forum explanation)
The source of the copy would not have to be trusted to describe the token correctly. The calculations provide that check. However, somebody still needs to preserve and provide the records. The proposal makes an available copy verifiable. It does not recover a copy that nobody kept.
What a verified name would and would not tell you
The check answers which metadata is bound to a particular covenant ID. It does not decide whether the token is a good investment, whether its creator is honest or whether its name copies another project. A familiar name would still need to be checked against the intended asset.
The exact declaration is fixed for that covenant ID. The same protection does not automatically extend to everything the declaration points to. If it contains a website address for an image, the address is committed, but the website could later serve a different image. Keeping that image independently checkable would require an additional convention.
KCC-23 also leaves the meaning of fields to application conventions. Its name, symbol and decimal example illustrates one possible use, rather than imposing a complete token profile on every application. Wallets and other tools would need to agree on how to interpret the information as well as how to verify its connection to the ID. (Declaration rules)
The proposal remains open for review, and applications are not required to perform the verification. For holders to benefit, wallet and explorer developers would need to implement the check and arrange access to the supporting records. A wallet could then distinguish information checked against the token's ID from a label it had merely received from a service. (Current proposal)
