KCC-20 ist ein Standard, um Token auf Kaspa zu erzeugen und zu übertragen.
Der Zustand des Tokens wird mit UTXOs dargestellt.
Die Regeln, wie diese UTXOs genutzt werden dürfen, werden über Covenants festgelegt.
Kurz gesagt:
Der Token und die Regeln für seine Nutzung leben auf Kaspa selbst.
Wenn jemand eine KCC-20-Transaktion erstellt, können die Computer, die Kaspa prüfen, als Teil dieser Prüfung sehen, ob sie den Regeln des Tokens folgt.
Ein externer Indexer muss die Aktionen nicht danach lesen und entscheiden, welcher Token-Zustand gültig sein soll.
Wie sieht das aus?
Sagen wir, Emma hat:
100 TOKEN
Dieser Token-Zustand wird mit einem UTXO dargestellt.
Emma sendet Liam:
30 TOKEN
Die Transaktion erzeugt den neuen Zustand:
70 TOKEN -> Emma30 TOKEN -> Liam
Die Covenants legen fest, welche Änderungen erlaubt sind.
Die prüfenden Computer von Kaspa kontrollieren, dass die Transaktion diesen Regeln folgt.
Wo ist der Token also?
Auf Kaspa.
Die Transaktionen, UTXOs und Regeln, die man braucht, um den Token-Zustand zu prüfen, liegen im Netzwerk selbst.
Es braucht kein getrenntes System, das die maßgeblichen Token-Guthaben führt und entscheidet, ob eine Übertragung gültig ist.
Ein Indexer kann Dinge trotzdem leichter machen: suchen, die Historie ansehen oder eine freundliche Oberfläche bauen.
Aber er ist nicht die Instanz, die entscheidet, ob der Token-Zustand gültig ist.
Wie unterscheidet sich das von KRC-20?
KRC-20
Kaspa hält die Aktionen fest.Ein Indexer deutet sie und berechnet den Zustand des Tokens.
KCC-20
Kaspa hält den Token-Zustand und prüft die Regeln, die diesen Zustand ändern dürfen.
Die Hauptidee
KCC-20 arbeitet durch Kaspa selbst.
Der Token-Zustand wird durch UTXOs dargestellt, und seine Regeln werden durch Covenants durchgesetzt - ohne einen externen Indexer, der den gültigen Token-Zustand bestimmt.