The first three Kaspa Calls for Conventions (KCCs) have been published as DRAFT. together they propose a common base for Kaspa covenants, from low-level representation to a concrete token standard. kcc-01 formalizes the basic covenant concepts. they were already implicitly used in different forms by SilverScript, Argent and by some applications. the direct outcome is interoperability. wallets, indexers and applications can agree on how covenant state, entrypoints and templates are represented. it also makes higher-level discussions and reasoning easier. while working on kcc-02 and kcc-20, and with community participation, we had to return several times to kcc-01 and make its terms more precise. this is also a good reason to keep it DRAFT and open for discussion for some time. kcc-02 defines authority schemes. the need came directly from kcc-20: before defining token transfers, we need a shared way to describe who or what can authorize them. this is not limited to a public key owner. an authority can be a public key, a key commitment, a script or another covenant lineage (a covenant can be owner / governor of a token UTXO). the list of schemes is extensible, so more can be added later. for wallets, the goal is to recognize these authorities uniformly, only from the program ABI instead of learning a different format for every application. kcc-20 is the first "concrete composer". it defines common state and transfer conventions for fungible-token covenants. an application should be able to recognize a KCC-20 token, read it and construct transfers for it. the actual program can still be written in Argent, SilverScript or directly with opcodes. kcc-20 leaves room for token-specific extended state. an application can add its own data and behavior while keeping the base token state and transfer interface recognizable. the intent is not to make every token identical, but to keep a common interaction surface between different deployments. kcc-20 also introduces borrowed receive and its authorization schemes. token assets are separate from KAS, but every new token UTXO must still be funded with enough KAS under Kaspa's storage-mass rules. borrowed receive allows an existing recipient token UTXO to be reused instead. this feels natural for fungible tokens because its token amount can increase while its KAS value, owner and extended state stay unchanged. the owner must first opt in and select the authorization scheme controlling when this is allowed. the three drafts did not really happen one after another. kcc-20 showed that kcc-02 was needed, and kcc-02 required some missing definitions from kcc-01. publishing them together now allows each layer to be discussed and reviewed against a real use case. all 3 are drafts and community participation is needed.