Pinned Tweet
I was scrolling down a Bitcoin forum when I noticed a post about this new coin claiming to solve blockchain. After it popped up two more times, I had to see what the deal was.
The claims were so big, they forced me to DoMyOwnResearch, one that started two years ago and continues to this day with growing momentum.
I started with (finally) understanding Bitcoin, why it must be slow to be secure, step by step I learned about GHOSTDAG all the way to understanding the basic ideas of DAGKNIGHT - The thing is complex and my understanding is partial, but man… what a beautiful moment that was!
Some solutions are... solutions. But some rare ones are THE solution. Not an incremental improvement, not a patch - DAGKNIGHT is of this rare kind, more of a fundamental truth than a new invention.
During my software dev career, I got paid to build products for companies. Open source projects always excited me but I stood from afar. Until today =]
Kaspa was just too mind blowing, over the last month I decided to step in and work on something I deeply believe in. After a lot of help from the developer community, and @michaelsuttonil in particular, I made my first contribution to an open source project!
Kaspa is intriguing. It's research, math, cryptography, and hardcore software engineering. But it's also community. I mostly stay away from social media, but this time it's different. Contributing great, but contributing to the community in Kaspa's case matters just as much.
In the near future I aim to translate some of the concepts behind the tech, share thoughts & ideas, and hopefully inspire others to jump in as well.
Well prophesied
My prophecy: Kaspa core will keep researching, budling and delivering. Yonatan will continue to lead it in terms of vision, far-reaching long-term research and short-term endless day-to-day brainstorming. Core R&D will continue to scale and expand to wider and wider circles. Builders and developers will keep joining L2 testnets and build dapps which utilize Kaspa’s inherent superiorities. Kaspa’s marketing will decentralize more and more. There will be no central voice. As part of the many voices, core members will find ways to communicate their vision and nuanced discussions to the broader crypto community. Truthfulness will prevail. Kaspa core will identify with people who actively contribute, build, research and think about Kaspa from the moment they wake up until the moment they fall asleep. Educators, pedagogues and evangelizers will do what they do best and communicate at different levels based on their knowledge and expertise. I will keep researching, thinking, developing and posting about Kaspa and speak as directly, accurately and truthfully as I can. I love you all (not a prophecy). We just started.
Onwards!
KCC-20 lets us create tokens that work together through a shared interface. Native KAS is a fungible token as well, but it isn’t a KCC-20 token.
Imagine a DEX, for example. KCC-20 lets us write a generic pool covenant that supports any pair of KCC-20 tokens. But if one side of the pair is KAS, we’d need special logic to handle it.
Representing KAS as a KCC-20 token would let covenants handle KAS the same way they handle other KCC-20 tokens. There could be different implementations and deployments of a KAS-backed KCC-20 token, but it would be beneficial to agree on a single one to avoid fragmentation.
I'm proposing a simple implementation, KAS20. Join the discussion on Kas-Smiths:
kas-smiths.org/t/a-kas-backe…
Greetings $KAS. KCC-1, KCC-2 and KCC-20 are now Final, meaning they are ready for full adoption across the ecosystem.
We invite Kaspa builders to join the public KCC channel to ask questions, get support, discuss implementations and share what you build.
Come build with us.
Manyfest retweeted
Greetings $KAS. KCC-1, KCC-2 and KCC-20 are now Final, meaning they are ready for full adoption across the ecosystem.
We invite Kaspa builders to join the public KCC channel to ask questions, get support, discuss implementations and share what you build.
Come build with us.
4 months ago Toccata enabled native L1 programmability.
Last month, SilverScript brought a high-level language for covenants.
Today KCC-20 finalization gives the ecosystem a shared convention for defining, deploying, interacting with, and composing fungible token assets.
There is still more work to do on indexers, tooling, and KRC-20 migration, but the pieces are coming together.
I made some interactive walkthroughs so curious interns can explore these conventions visually. They cover the Argent reference implementation, hash-chain borrowing, and KCC-23 metadata declaration.
KCC-20 spec:
github.com/kaspanet/kccs/blo…
Reference implementation:
github.com/argent-lang/kcc20…
KCC-20 walkthrough:
kcc20.manyfest.dev/
Hash-chain demo:
kcc20.manyfest.dev/hash-chai…
KCC-23 walkthrough:
kcc23.manyfest.dev/
Manyfest retweeted
KCC-20 has advanced to Last Call:
github.com/kaspanet/kccs/blo…
A companion reference implementation by @manyfest_, written in Argent together with its pinned generated Silverscript, underwent an extensive manual review and AI-assisted audit by Michael Sutton, covering KCC-20 conformance, implementation correctness, and edge cases.
It is now open for 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.
Argent contracts:
github.com/argent-lang/kcc20…
Generated Silverscript:
github.com/argent-lang/kcc20…
KCC-20 has officially moved to Last Call status.
Developing software and developing standards are very different.
Software aims to solve a specific problem. A standard aims to define a general foundation for a wide class of solutions.
A special thanks to @michaelsuttonil , who was there from the start to finish , guided me in how to approach this complex craft.
Manyfest retweeted
i’ve written about it in the past but i feel like now it would hit more ears so to speak.
there are basically two categories of covenants, those that are all about the Kaspa they protect (eg vaults, timelocks, escrow etc) and those that are about the state they carry which essentially forms another mini social consensus (eg name services, native kcc20 tokens, and whatnot). one might typically call these stateful covenants but that’s not the full story
instead of diving straight in, i’d like to hear from you. how do you understand the difference between the two categories, conceptually as well as what are the technical implications resulting from the differences
Manyfest retweeted
argent now has a first implementation of covenant genesis proofs:
github.com/argent-lang/argen…
idk how to emphasize this enough, but i expect *every stateful covenant* deployed on kaspa to eventually provide such a proof.
the goal is a verifiable link from a covenant id back to the source code, deployment parameters, and genesis state that produced it.
we should strive for an ecosystem where explorers expose this proof data for every covenant id they discover onchain, assuming its deployers want public trust.
think of it as the analogue of contract verification on etherscan, extended to stateful covenants: you should be able to inspect what a covenant is, audit the code behind it, and verify how it was instantiated.
kudos to @supertypo_kas for being an early-bird example of such a proper deployment process:
github.com/supertypo/dotk-in… (not sure if the sil contracts themselves are public yet)
KCC-20 is progressing together with KCC-1 and KCC-2, since it builds on top of them.
In addition, KCC-20 requires a published reference implementation before it can be finalized.
The Argent reference implementation is being audited and tested, and we are pushing to get it ready for Last Call as well.
The KCC Coordination Forum has reached an important milestone in the standardization process. The foundational KCC-1 and KCC-2 standards have now entered Last Call.
This opens a final 14-day review period. If no major issues are identified, both standards will be finalized and considered ready for ecosystem adoption.
We encourage anyone working with these standards to review them carefully and raise any remaining concerns during this period.
Manyfest retweeted
The KCC Coordination Forum has reached an important milestone in the standardization process. The foundational KCC-1 and KCC-2 standards have now entered Last Call.
This opens a final 14-day review period. If no major issues are identified, both standards will be finalized and considered ready for ecosystem adoption.
We encourage anyone working with these standards to review them carefully and raise any remaining concerns during this period.
Manyfest retweeted
i used to think real-time execution was the one thing that couldn’t be faked on bitcoin L1.
i stand corrected.
While prototyping KCC-20 I got asked how should token symbols, descriptions, images, and other kind of metadata be defined.
On EVM systems, there is a single SC which represents a token, and holds both its balance state and global state.
On the UTXO model there is no global state, the token is split and held across holders, each one holds his specific token (UTXO/covenant).
This means that adding state fields for metadata would duplicate them across each UTXO, which is wasteful. Things such as representation, name, symbol or image are also not part of the SC logic, and should not be part of it.
A naive approach is to declare such metadata in the payload field of a tx, which is an "empty space" that can be used to write whatever information.
The issue is that Kaspa is prunable. Eventually, the block containing this tx would no longer be available for verification, so at some point the data would need to be trusted by off chain entity.
After drafting a few solutions, we came up with KCC-23, a convention for binding the metadata to the covenant ID itself.
Read more on Kas-Smiths:
kas-smiths.org/t/kcc-23-conv…
Or read the KCC draft:
github.com/kaspanet/kccs/pul…
Manyfest retweeted
A version worth upgrading to:)
Kaspa v2.1.0 is out [Link in the reply]
All node, mining, and infrastructure operators across mainnet and testnets are strongly encouraged to upgrade.
This release introduces P2P Protocol Version 11, extracts a standalone ZK SDK, and reflects an ongoing focus on proactive defense-in-depth across the node architecture.
Key Highlights:
• P2P Protocol Version 11 & Chunked IBD: Large Initial Block Download (IBD) payloads (including Pruning Point Proofs, headers, and trusted data) are now streamed in 20 MiB chunks. This eliminates message-
framing bottlenecks and timeouts during node sync, backed by overall safety limits and transfer timeouts, while maintaining full backwards compatibility with Protocol 10 peers.
• Standalone ZK SDK: Zero-Knowledge proof and script-generation tooling has been extracted into a dedicated crate (kaspa-txscript-zk-sdk). It adds support for RISC Zero Groth16 and STARK verifier generation
with dynamic or static image IDs, bounds control proofs against oversized inputs, and resolves cross-platform build issues.
• General Hardening: Comprehensive defense-in-depth upgrades across the node, including stricter P2P message and block limits to guard against DoS vectors, a workspace-wide arithmetic safety audit to
eliminate overflow risks, enhanced stratum bridge stability, and tighter consensus validation.
These structural safeguards significantly strengthen node resilience and provide higher confidence in overall network security.
Manyfest retweeted
“...always-on rails built for high-frequency, low-value payments.”
i think ai’s need more than that. they need an ai-native programming language for dynamically expressing and composing logic on demand, so they can form cheap enforceable “covenants” with each other. they need fast rails where multiple parties can enter those agreements atomically.
eg an agent could assemble several agents it neither knows nor trusts for a one-off job, generate custom rules for contribution, success and payment, and have everyone enter the agreement atomically. once settled, the agreement can simply disappear
Manyfest retweeted
adding some context in case you never heard about KCC-20.
in essence, a KCC-20 compatible program is a program whose state roughly contains: a owner (your address) and an amount (the balance of this token).
for each program, a developer define a list of callable entries (short for entrypoints), in KCC-20 case, a "transfer" entry is mandatory, so you can transfer your tokens to another owner.
the challenge described by Manyfest is that token deployers may want to attach some extra data (metadata) to this created token, possibly: ticker, number of decimals, or others. where to/how to?
next read: kas-smiths.org/t/fungible-to…
KCC20 is nearing finalization, and I’m now working on the final reference implementation.
There is still discussion about token metadata declarations (such as name, symbol, and decimals).
This is not an integral part of KCC20 token interaction or functionality, but there is still value in standardizing how this information is declared, so the ecosystem can discover it directly from the chain.
One optional direction is inscribing token metadata into the covenant ID at covenant genesis, making it a verifiable commitment (in opposition to using the tx payload field), without adding this data to every token UTXO.
For more details, see the KCC20 thread on Kas-Smiths.
Shana Tova!
kcc-20 is mostly figured out, what's missing is it being kcc-0 compliant (formal document needs to be revisited), and at least one reference implementation.
i think @manyfest_ is the best person to give a rough estimate to measure the missing effort.
more generally, anyone can (and is encourage to) contribute to this kind of effort. at the end of the day, the community is the owner of it
Manyfest retweeted
@OriNewman and @IzioDev’s first token mechanism took thousands of lines of raw opcodes. They can now write the same thing in 60 readable lines of Silverscript.
Silverscript v1 is out. Congrats sir, and thanks to everyone who helped get it here.
Finally, Silverscript v1 is out [Link in the reply]. This completes the journey we started eight months ago with Toccata — it's finally possible to write human- (and AI-) readable smart contracts on Kaspa.
This language started simply as "CashScript with loops", but eventually grew into a full-fledged smart contract language capable of expressing complex, stateful contracts. It's always fun to look back at the first token mechanism @IzioDev and I worked on using raw opcodes, which took thousands of lines of code, and see the same thing implemented in just 60 easy-to-read lines of Silverscript.
I'm excited to explore the possibilities of UTXO programmability together with the Kaspa community, and this is only the beginning - Silverscript will evolve, Argent will add higher layers of abstractions, and I'm sure more people will find their own way of extending this new ecosystem.
Manyfest retweeted
From UTXOs and covenants to KCC20 token borrowing in Argent.
Part 1 -
YT: youtube.com/watch?v=vZUS45fY…
X: xitter.cf/i/broadcasts/1AKEmvDBA…
Part 2 -
xitter.cf/i/broadcasts/1Oxwbngwj…
GitHub: github.com/Manyfestation/kcc…
xitter.cf/i/broadcasts/1AKEmvDBA…
Argent & KCC20 dev session is starting, join in!
