Announcing the first public, open source release of the #kaspa@dotk_name indexer (&api). 🥳 Any integrator can now run their own instead of relying on the dotk api for name "hints". Details and how it works below 👇
First version of kaspa was written as a btcd fork (now it's rewritten from scratch in Rust). This is why Kaspa inherited the transaction, script structure and the UTXO model from Bitcoin (on the last hardfork some adaptations were made to make covenants and zk first-class citizens)
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.
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.
🚨 NEW Episode w @OriNewman "How Kaspa Wins Over FIAT"
00:00 Why kaspa:native needed covenants
06:34 Why SilverScript
13:47 sCrypt, CashScript and OP_CAT
16:00 #Bitcoin's accidental covenant
22:16 KIP-17: state inside a UTXO
30:54 KCC20, CAT20 and the lineage attack
37:37 CovenantID, and If Toccata affects your wallet
46:03 Thousands of lines to 60 with @IzioDev
53:39 Posts by @hashdag and @michaelsuttonil
59:28 Competing with bitcoin:native
--------
DISCLAIMER This video is for educational and informational purposes only and is NOT financial or investment advice. We do not recommend you to buy or sell any assets. Opinions of guests are their own and do not constitute endorsements. Cryptocurrency and blockchain investments are highly risky and can result in total loss of capital. Do your own research and consult licensed professionals. The channel and its hosts are not liable for any investment decisions or losses.
On Saturday I’ll stream a live technical session around Argent and KCC20.
My intention is to share the process we’ve through designing the spec, while also making it real using Argent.
See you here on X or in Discord!
Seven months since the first commit, and after an extensive review and standardization process (thanks to @manyfest_,@iziodev,@michaelsuttonil and @asaefstroem), I'm publishing a release candidate for Silverscript v1.
The last merged PR was written by @michaelsuttonil and numbered #235, which is a nice reminder to the fact that Silverscript started as my (someone235) project and is now becoming a project involving the entire Kaspa community.
You can find a link to the release candidate in the reply, and I'd love to hear the community's feedback. If we don't receive any substantial feedback, we'll release Silverscript v1 for mainnet use one week from now.
In which case specifically? Anyway, I'm not saying there can't be manual interventions to the automatic mining protocol, but the mining protocol is automatic by default, and the analysis (security, confirmation time, etc) relies on that.
The same applies for BSV reorgs: they do not reveal human intervention in the protocol, but merely an automatic process of following the longest chain according to the miner POV.
@kurtwuckertjr@BTCTKVR@Vladcostea And btw, you don't get to 99% so fast. e.g. when attacker size is 0.1, you'll need 6 blocks for that, even when chain growth is healthy.
@kurtwuckertjr@BTCTKVR@Vladcostea It does prevent it probabilistically, with attack success probability exponentially diminishing with the chain growth, but of course this property is harmed when the chain growth is harmed.