"Programmable high-frequency proof of work" is how Michael Sutton described Kaspa on 8 October, replying to a post that called it programmable proof of work. High frequency, he added, is "all the rage so to speak". It makes Kaspa "a continuous composition of highly responsive mini programs" (X post).
Mini programs can only work together if they follow the same rules. On 7 October the rulebook for tokens, KCC-20, moved into Last Call, the last chance to raise problems before it becomes final (GitHub). A day later, developers were invited to try to break the code that comes with it.
Manyfest announced the move and thanked Sutton for being there "from the start to finish". "Software aims to solve a specific problem," the post says. "A standard aims to define a general foundation for a wide class of solutions."
Any token standard has to deal with copies, because anyone can copy a token's code. The same day, Sutton summed up the copy problem in three words, and Supertypo released a tool that uses the same idea to prove the whole .k name list is real.
The week had more. KaChat is testing names that you rent rather than own. A simple question about public keys turned into a lesson in why hardware wallets change slowly. And Luke Dunshea is opening up Kaspa mining machines, one chip at a time.
The rules behind the tokens
KCC stands for Kaspa Call for a Convention, and each one sets a shared standard (KCC-0). KCC-20 is built on two others. KCC-1 is the common language for covenants. It sets how a covenant's data is laid out and how wallets and apps call its actions, whatever programming language the covenant was written in (KCC-1).
KCC-2 sets out whose approval an action can need. That can be a public key, a key hidden behind a hash, a script or another covenant (KCC-2). KCC-20 then puts both to work for tokens. It sets how a token's balances are stored and how they move, so a wallet that supports one KCC-20 token can handle them all, whoever made them.
For users, the bigger change is who keeps track of balances. KRC-20, the older token format, relies on indexers outside the network to work out who owns what (our report). A KCC-20 token lives inside a covenant, and the network itself refuses any transfer that breaks its rules.
KCC-20 lists four authors, Sivan Helfer, Michael Sutton, Ori Newman and Romain Billot. Manyfest first posted it on the Kas-Smiths forum in July, where the discussion is still open (Kas-Smiths), and it became a formal KCC draft in August (our article).
The KCC-20 document itself is "relatively simple", Billot wrote in September, but it "brought a whole new area of discussions", which is why KCC-1, KCC-2 and now KCC-23 were moved forward (X post).
KCC-23 is still a draft (GitHub). While prototyping KCC-20, Manyfest was asked where a token's symbol, description and image should be defined, and KCC-23 is the answer. It ties that information to the covenant ID itself, so a wallet can check it rather than trust a list (X post, our article).
Sending tokens without the extra KAS
One part of KCC-20, called borrowed receive, deals with a small cost that adds up. Every token balance sits in a coin of its own, and that coin has to hold a little KAS. Normally, each payment creates a new coin for the receiver, and that coin needs KAS too, even if the receiver already holds the token.
With borrowed receive, the sender adds the tokens to a coin the receiver already has. The sender can only add tokens. They cannot change the owner or take any KAS out (KCC-20).
There is a catch, and the standard says so. Every time someone adds to your coin, it gets a new ID, so a payment you were about to send from it can fail. That is why each token coin has its own borrowing setting. The owner can switch borrowing off or allow it under conditions, such as a minimum amount per payment or approval from a chosen key (KCC-20).
Borrowed receive needs a coin to add to, and a newcomer has none. On 8 October Sutton explained how the reference code for KCC-20 solves this. A token built with it starts with a few special coins called seeds, and anyone can use one to open an empty token coin with a little of their own KAS (GitHub).
From then on, others can send them tokens without putting up any KAS. "This lets anyone enter the token covenant without already holding any token value," Sutton wrote.
The same code shows a simple way to launch a token. Anyone can mint it, a limited amount at a time, until the planned supply runs out. Since a coin can be spent only once, a single minting coin would make everyone wait their turn, so it can split into several when demand grows and merge again when it falls (GitHub).
Try to break it
Manyfest wrote this reference version of KCC-20 in the Argent covenant language and added it to GitHub on 7 October (GitHub). The repository also holds the SilverScript code it turns into, so reviewers can check exactly what would run.
Sutton, one of the authors of KCC-20, went through the code first, by hand and with AI tools, checking whether it follows the standard, whether it works correctly and how it handles unusual cases (X post).
Now it is everyone else's turn. The KCC Coordination Forum has opened the code for what it calls final public battle testing. "We encourage developers and security-minded reviewers to try to break it, probe edge cases, and report any implementation bugs or discrepancies with the spec," it wrote.
This is code to test, not a token to buy. Its examples and tests run offline, and the project says plainly that the tests are "not an independent security audit" (GitHub).
Sutton called the repository "the first step towards a general standardized Kaspa Token Lib (KTL)", and sees it growing beyond tokens, into libraries for other kinds of contracts.
Last Call itself is not the finish line. To become final, KCC-20 also needs public test cases, at least one public version of the code that passes them all, and everything it builds on to be finished first (KCC-0).
KCC-1 and KCC-2 have themselves been in Last Call since 1 October (KCC-1, KCC-2). KCC-20 also relies on KIP-20, a network rule that is already active. It gave every covenant its own ID, and that ID is what lets a wallet tell a real token from a copy (KIP-20).
Forgery, lineage and provenance
Copies were already on Sutton's mind. Two days before KCC-20 reached Last Call, he asked Kaspa users for one word for the difference between two kinds of covenants, those that are about the KAS they protect and those that are about the information they carry (X post). Our article the next day went with forgery (our article).
Sutton's own answer came on 7 October, and it matched what many people had already suggested. The idea that separates the two kinds, he wrote, is forgery, lineage or provenance. He had asked for one word and gave three.
The three words come at the same idea from different sides. Forgery is the risk. Lineage and provenance are the defence, a record that traces something back to where it began, much as art experts trace a painting's history to tell a real one from a fake.
The post also came with a one-sentence definition. "Covenant lineage is required when covenant state represents a scarce resource other than the native KAS it controls." A name is that kind of resource, and so is a token balance.
Not every covenant that stores information needs a lineage. A vault that remembers how much you have taken out this month can be copied by anyone for their own coins, and nobody is fooled, because each copy only guards its own KAS. Lineage starts to matter, Sutton wrote, "when the state itself represents something scarce or uniquely identifiable" (X post).
Sutton called lineage "an identity anchor around which social consensus can gather" (X post). On Kaspa, that anchor is the covenant ID, which arrived with the Toccata upgrade (reply). A covenant is born once, by spending one particular coin that can never be spent again, and every later version must prove it descends from that birth. The information inside can change while the identity stays the same (X post).
Mind the gap
Names are the clearest case of something scarce that is not KAS. A .k name such as alice.k stands in for a long Kaspa address, and there can only ever be one alice.k. The names launched in September, but the covenant code behind them was not public (our article). On 7 October, the same day as Sutton's answer, Supertypo published it as open source (GitHub).
Supertypo calls it a gap and deed design. Every name is turned into a fingerprint, and all possible fingerprints sit in order along one long line. The stretches between registered names are the gaps, and each gap is a coin on Kaspa.
To register a name, you spend the gap that holds its fingerprint. The gap splits in two around your name, and the name gets a coin of its own, called a deed, which records the name and its owner. Anyone else who wants the same name would have to spend that same gap, and since a coin can be spent only once, the network rejects the second try as a double spend (code).
That keeps every .k name unique, first come, first served, with nobody in charge of a waiting list. The design has been explained on the dotk website since launch (dotk.name).
What is new is a way to check all of it yourself. The release includes a verifier that runs on your own computer. It reads the name list that dotk publishes and checks every entry against a Kaspa node, one step at a time, explaining each check and waiting for a key press before moving on (GitHub).
First it proves that the published contracts turn into exactly the code running on the network, and that the real registry's covenant ID, which is built into the verifier, belongs to that code. Anyone reviewing the code on GitHub is reviewing what runs on mainnet. Then it proves that every name has the owner the website shows, and that the list is complete, with nothing left out and nothing made up.
Completeness is the hard part. You can call every number in a phone book, find each one correct, and still not know whether someone tore out a page.
The gaps solve that. Together, gaps and names must cover the whole line. A missing name would leave a hole, and a made-up name would sit inside a gap, so the verifier catches both. That is why Supertypo says it proves the registry is "correct and complete".
Nor would a copy fool it. Anyone can take the dotk contracts and start their own registry, but it would be born from a different coin and get a different covenant ID. The verifier checks for the real one, which is exactly the lineage Sutton was talking about.
The verifier does not remove all trust. It still relies on the SilverScript compiler, the Kaspa libraries it is built with and the node it talks to, which can be your own. The project's tests feed it wrong or tampered answers from the website or the node, and every one of them fails the proof (GitHub).
Most people will never run it, since it needs Rust and a terminal. It is really a tool for developers, wallets and explorers, but anyone can run it, any time, without asking permission. Sutton called the release "amazing" and said he would take a deeper look as soon as he can (X post).
The rest of the dotk project is public too, including the kits that wallets and apps use to look up and register names, the core library and the indexer behind the website's list. The Kaspire and Kurncy wallets already support .k names (GitHub).
A name for rent
Kaspa Silver, who builds the KaChat messaging app, wants names to work differently. A .kachat name is rented, not owned, and every fee goes to miners.
Rentals run for one or two years and can be renewed in the last 30 days. Miss that window and you get 90 more days to claim the name back (X post), but it stops pointing to your address in the meantime (X post). After that, it goes back on the market. Kaspa Silver shared the planned prices on X.
A name with five or more characters would cost 35 KAS, and renewing it 8.75 KAS. Shorter names cost more, up to 4,000 KAS for a single character. The KaChat code leaves that money in the transaction as a fee for the miner who includes it. You also pay deposits, which come back when you give the name up (code).
Kaspa Silver says the fees earn the developer nothing. The same post calls .k "the best design we have", but points to two weak spots. Its fees go to the developer, and a name owned forever has no way back if the owner loses their seed phrase or passes away. "Those domains are gone forever," Kaspa Silver wrote. Renting also stops people from buying up names just to sit on them (X post).
The .k design makes the opposite choice. A .k name never expires and has no yearly bill. For a name of five or more characters, 38 KAS of the 40 KAS price is a one-time fee that funds development, and the other 2 KAS stays with the name and comes back if you give it up (our article).
The .kachat prices are fixed in the contract (code). Kaspa Silver once planned a key that could adjust them, but dropped the idea, because anyone who got hold of a lost or stolen key could change every price. If KAS rises sharply, the plan is an emergency migration that moves every name into a new contract (X post). Practising that migration without losing any names is the last thing that really needs testing (X post).
None of this works with real KAS yet. The names run only on testnet-10, and the move to mainnet will wait for an audit (code). Kaspa Silver has asked people to test them in the KaChat 5.2 beta for Android (X post) or in the new KaChat browser extension, also in beta and not yet in browser stores, after switching to testnet in the settings (X post).
A key question about safer addresses
A Kaspa user asked Sutton whether there is a way to move KAS to a "safer" address, because a normal Kaspa address shows the public key (X post).
That part is true. A normal Kaspa address contains the public key itself (code), while a hashed address shows only a fingerprint of it, and the key appears only when you spend. A visible public key is safe against today's computers. The worry is a future quantum computer powerful enough to work out the private key from it.
Sutton replied that this is "very easy to implement in kaspa with p2sh addresses", short for pay to script hash. The real challenge, he wrote, is getting wide wallet support. He added that KCC-20 tokens support hashed addresses from the start, through KCC-2.
He then asked coderofstuff whether it could be added to KasVault, calling it "a 2-line silverscript contract" (X post). coderofstuff wrote most of the Kaspa app for Ledger hardware wallets (GitHub) and built KasVault, a web app that works with Ledger devices (GitHub). The reply explains why even a small feature takes time on a hardware wallet.
KasVault is only a web app, like Ledger Live. The real work would happen in the Kaspa app on the Ledger device itself, and as far as coderofstuff remembers, that means development, ongoing maintenance and a security audit, which policy requires. All of it costs money. A later reply adds that the feature would have to go through the same full process as any new feature (X post).
Sutton thinks the work "should be relatively easy" and offered to put together a handoff for the task (X post). He also said the wallet section on kaspa.org should list support for hashed addresses as one of its criteria (X post). For now, it is still just an idea.
Lifting the lid on mining machines
"If you can't open it, you don't own it." That old maker slogan sits at the top of OpenMiner, a project by Luke Dunshea (GitHub).
Kaspa ASIC miners run software from the companies that make them. Dunshea wants owners to be able to run their own.
On 1 October he made OpenMiner Reference public, a set of documents on how to talk to the chips inside these machines, starting with the BM2382 chip in the Bitmain KS5 Pro (X post). On 7 October he added a second machine, the Goldshell KA Box. Thanks to the tools he had built for the KS5 Pro, he says, that took only about two days.
His goal is to collect enough knowledge that anyone can use the documents to "create their own software that can safely take over control of the miner", send valid shares to a pool and keep the machine at a safe temperature.
On the KA Box, his own software mined Kaspa for about two minutes and had 121 shares accepted, while controlling both fans itself. In a separate test, he handed control back to the stock software. There are limits. The stock software still has to prepare the board first, a cold start without it has not been tested, and the chip's electrical wiring has not been mapped yet (GitHub).
The repository holds documents, not a finished program. Dunshea's own mining software stays in a private research repository for now, and he plans to release an open source OpenMiner platform later. Every claim in the documents states its evidence and test conditions, unknowns are clearly marked, and the project calls itself community research, not manufacturer documentation.
He describes three stages. First, understand the chips. Second, run existing miners on open software, with detailed logs, remote monitoring, custom fan settings and power managed by schedule, electricity price or solar output. Third, build new hardware, perhaps by moving chips from existing miners into new designs.
Much of his inspiration comes from Bitaxe, an open source Bitcoin miner, and the people who build open mining hardware for Bitcoin. His focus is Kaspa, but he wants OpenMiner to be useful for all miners. Next on his list is the KS0, a small low-power Kaspa miner.
Igra and Kaskad on the move
Igra Labs updated its attester dashboard on 7 October. Attesters can now move all or part of their IGRA allocation to another wallet in one transaction, including tokens that have not unlocked yet, so they can switch wallets or replace a key that is lost or no longer safe.
Igra adds three warnings. Each address can receive an allocation only once, a move cannot be undone, and IGRA that is ready to withdraw moves too, so withdraw it first if you want to keep it (X post).
Kaskad, a lending app on Igra, has also launched on Robinhood Chain, a network built on Ethereum by the trading app Robinhood (X post), and now runs on both (DefiLlama). Hours later, the team warned that there is no Kaskad token on Robinhood Chain yet. The only KSKD token is the one on Igra, any new token will be announced by the team itself, and anyone who says otherwise should be treated as a liar, the post added (X post).
Order, order
Ross plans to hand the order matching on KOB, short for Kaspa Order Book, to miners over time. KOB is an open-source exchange for KCC-20 tokens, which Ross rebuilt as an Argent app at the end of September (X post).
Anyone can run an executor, the program that matches buy and sell orders, and keep the price gap plus any tips. The order contracts have no protocol fee, no operator key and no admin function (GitHub).
In the plan Ross shared on 8 October, executors would run on a Kaspa full node with modest extra specs, and all rewards would go to miners as extra income (X post). For now KOB runs only on testnet-10 and has not been independently audited (GitHub).
