SoBu 𐤊

[Kaspa Kii @KaspaKii]

Kii is giving a keynote at the ETIM Forum 2026 in Torremolinos, Spain on 28 October.

We will show KiiWORKS: digital product passports for industry, built from the ETIM data manufacturers already publish and verifiable by anyone on Kaspa.

#Kaspa

[Ori Newman @OriNewman]

Published KIP 22 to help Kaspa users better protect their funds from future quantum attackers by keeping public keys hidden until spending

https://t.co/SOslUfDwKB

[Michael Sutton @michaelsuttonil]

two years ago, when we were designing based rollups/apps over kaspa with canonical bridging etc, did we have this privacy use case in mind? at least for me, no.

(see posts here:
https://t.co/QXbfQiGHWr
https://t.co/EWw6y6ygz1 brainstormed with @dimdumon, @hashdag and @VolokhIlia)

seeing these ideas now being explored for privacy is a reminder of why infrastructure work needs to be sound, diligent and forward thinking. you can’t anticipate every application, but thinking carefully about the foundations can make room for things you hadn’t specifically imagined.

eg with the canonical bridge, the core idea is a pool of resources whose internal distribution is managed by the L2 app state and opaque to L1. this seems to map cleanly to the proposed privacy architecture, with an additional layer where each user’s private state is hidden from everyone else and the app itself verifies user proofs as part of its execution/proving (worth mentioning that these user proofs need not be directly compatible with L1 zk opcodes, only the outer app proof needs to be)

same goes for kip21 and proving work proportional to app activity, which seems rather useful and important here as well.

one more thing i wanted to add here (and we discussed), @WellerOlaf: the based component not only provides censorship resistance but also gives in-app confirmation times driven by L1 frequency and not proof frequency. once an operation is ordered and its execution locally validated, every possible prover is bound to that outcome. no valid proof can advance past it while skipping or changing it

[Olaf Weller @WellerOlaf]

Had a really interesting conversation with Kaspa core developer @michaelsuttonil about the Kaspa Privacy Initiative today.

We discussed our candidate architecture for a scalable shielded native KAS protocol, using covenants, ZK proofs, permissionless relayers and batchers.

One of the biggest takeaways was how much of the infrastructure we're looking for may already be available through Kaspa's Based Apps and KIP-21.

In our original design, one of the challenges was ensuring that batchers couldn't selectively omit user operations while claiming to have processed a complete batch.

With Based Apps, user operations can be ordered directly on Kaspa L1 in an application-specific lane. KIP-21 provides cryptographic sequencing commitments, allowing a properly designed settlement proof to demonstrate that the relevant operations were processed correctly.

That could remove a substantial amount of custom infrastructure we'd otherwise have to build ourselves.

We also discussed canonical bridges, recursive proving and why sharding may introduce unnecessary complexity at this stage.

Our next step is a small Based App feasibility PoC on TN10.

We'll test lane ordering, execution, proof-based settlement, deliberate transaction omission and independent reconstruction before adding the actual shielded privacy logic.

No architecture has been finalized. The goal remains to find the safest, most scalable and most decentralized solution, not to defend an earlier design.

Really appreciate Michael taking the time to share his insights. Conversations like these are incredibly valuable.

Technical feedback, criticism and contributions are very welcome!

https://t.co/h4gdcS1dfn

[Kaspa Silver @KaspaSilver]

My dream is that KaChat becomes the playground for $KAS core devs to have an app to test any new features they want to bring to Kaspa.

To make this happens KaChat needed full support for testnet. In 5.2 anyone will be able to use KaChat in testnet and test things to their hearts content.

[Olaf Weller @WellerOlaf]

I’ve now launched the Kaspa Privacy Initiative.

It’s an independent, community-led effort to explore optional privacy for native KAS. And judging by the response to my previous post, there’s clearly a lot of interest in making this happen.

I’m not a cryptographer or Kaspa core developer. My role is initiator / project steward: to get the ball moving, organize the research, bring the right people together and keep pushing toward something concrete.

I also use AI extensively for research, documentation and prototyping. I think that can dramatically accelerate the work, but security-critical architecture and code will still need review from people with deep Kaspa, ZK and privacy expertise.

What I felt was missing was an open place where the community could work together toward a privacy protocol for native KAS that is not built around a new token, a company or personal gain.

No new token. No custodian. No predetermined architecture.

We’re starting by figuring out what can already be built with Toccata, what may require vProgs, and what architecture can eventually give native KAS strong optional privacy with permissionless exits.

Everything is open from day one. If you understand Kaspa, ZK, privacy systems, wallets, security or simply see flaws in our assumptions, I want you involved.
GitHub 👇
https://t.co/h4gdcS0FpP

[Michael Sutton @michaelsuttonil]

argent now has a first implementation of covenant genesis proofs:
https://t.co/u4G36X0lkE

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:
https://t.co/B6g9H0C9x1 (not sure if the sil contracts themselves are public yet)

[Michael Sutton @michaelsuttonil]

don’t let this fly under the radar

refer to my pinned post → dual programibility landscape → second pillar: based zk apps

this is becoming real now

[Kaspa Silver @KaspaSilver]

I think the problem with crypto gaming is that each game always required another token specific to that game. Ended up just being used to extract from players.

If you want crypto gaming to be a success with a coin use the native L1 like $KAS for everything.

$KAS has the power to BE THE MoE. Stop making new tokens for everything when we have one of the most efficient programmable L1 PoW digital currency in the world.

Tokens should be an exception not a starting point.
Treat $KAS as holding a share of a stock. What you build using $KAS as the foundation supports the project as a whole!

Builders who keep value inside $KAS are aligning their product with the base layer instead of siphoning it into a side token that dies when the marketing cycle ends.

$KAS is never dependent on your single product to stay alive and in demand. If it gets used by tons of different players then you never have to worry about hype fading from $KAS like you do when you build a token for only 1 specific purpose.

[Ori Newman @OriNewman]

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.

[KasBTC | HUB21 @kasbtc_krc20]

Argent (.ag) → SilverScript (.sil) → Bytecode → Local VM Testing

Inspired by @manyfest_’s video and the examples provided by @michaelsuttonil, I built an editor for Argent and SilverScript.

The idea: make code and its relationships visible and easier to understand.

• Synchronized code and structure views
• Visualization of actors, states, and dependencies
• Autocompletion and integrated compilation
• Local VM tests with targeted correction hints

Thank you for the insights and foundations this project builds on.

Argent source code and examples:
https://t.co/7B5b8CStK5

kaspa:native

[vertex @KaspaScopio]

This one seems to have gone almost unnoticed.

Kii Foundation has just made the source for Portrait public.

It’s a high-level language for Kaspa covenants that compiles down to SilverScript, with a library of reusable patterns already covering things like vaults, escrow, auctions and registries.

There are 35 covenant sources in the repo. 10 are cross-layer/vProg patterns, and Kii documents 5 of those as already settled on TN10.

What caught my attention is the tooling around it.

Portrait includes Lens, which uses Z3 to check properties of the covenant model, and Composer, designed to catch problems when multiple covenants interact.

Basically, Toccata gave Kaspa the primitives. SilverScript gave developers a way to express them. Portrait is now trying to make them easier to build, check and reuse.

Still very early though.

It’s pre-production, unaudited and testnet-only. Nothing here is deployed on mainnet.

But this is another interesting piece of the post-Toccata stack quietly taking shape.

Source:
https://t.co/3HfWFCxSQy

https://t.co/Th2qIcq6HZ

[Kaspa Silver @KaspaSilver]

Do you see this? The @KaChat_ app just managed to quickly onboard a new Kaspian. ChangeNow swap got him his first bit of Kaspa. The swap feature has a toggle to auto add to your portfolio for tracking.

kaspa:native has been missing a juicy app that does it all doesn't require any questions asked. I intend to keep building!

Enough explaining about Kaspa lets get people experiencing it!

[Gemini @Gemini]

GEMINI × KASPA SILVER

Join us live with @KaspaSilver for a conversation about Kaspa, the technology behind the project, and the community around it.

Tomorrow @ 9am ET

Be there or be square🟧

[Ori Newman @OriNewman]

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.

[Kas Finder @KasFinderCom]

KasFinder is live on Kaspa mainnet. 🎉

A real-world treasure hunt. Someone hides a physical marker with a secret code on it, and locks real KAS to that code.

Find the marker, enter the code, the Kaspa is yours.

#KASPA #KAS

[KaspaMama 🇳🇴 @Kaspamama]

🚨 Kaspa has a marketing problem.

Yonatan has made it clear that he doesn’t want the main Kaspa account to become a centralized, polished corporate marketing machine.

And honestly, I agree with that. 🫡

Kaspa’s decentralization ethos matters. The protocol should not feel like it’s controlled by one company, one spokesperson, or one official marketing department.

But here’s the trade-off:

Decentralization should NOT mean weak communication. 📣

Right now, some of the most important developments around Kaspa are barely understood outside the existing community:

⚡ DAGKnight
🧠 vProgs
🏗️ KII
🎼 Toccata
💻 Developer progress
🏛️ Institutional infrastructure
🌍 Real-world adoption use cases

The technology can be world-class, but if people outside the bubble don’t understand what is being built, Kaspa loses attention, developers, institutions, and mindshare to projects that are simply better at telling their story.

That’s why I think the community should seriously consider supporting Kaspa Commons / Chad Ballantyne as an independent communications and marketing arm for the ecosystem. 🤝

Not official Kaspa marketing.
Not controlled by Core.
Not corporate hype.

But professional, community-funded storytelling:

🎥 videos
🧵 threads
🎙️ interviews
📰 ecosystem updates
📚 explainers
🚀 adoption stories
👨‍💻 developer content
📢 outreach beyond the current Kaspa audience

Chad has already shown that he knows how to communicate Kaspa and grow an audience organically.

This could give us the best of both worlds:

Kaspa main account stays decentralized and cypherpunk.
Kaspa Commons tells the story professionally.
The community funds it transparently.

✅ Clear deliverables
✅ Transparent budget
✅ Measurable goals
✅ No control over the protocol

Because the problem is not that nothing is happening.

The problem is that too few people know what is happening.

Kaspa doesn’t need centralized marketing.

But it absolutely needs stronger communication. ⚡

Would you support a community-funded push to grow Kaspa Commons and tell the Kaspa story properly?

@ChadBallantyne @hashdag @michaelsuttonil @Kaspa_HypeMan @travladd @realvijayk @KaspaKii @Kaspa_KEF

$KAS

[Michael Sutton @michaelsuttonil]

As far as I understand this post, I strongly disagree with it (but maybe I’m reading it wrong)
Kaspa covenants can support onchain composability in ways which are conceptually eqv to eth/vm style interfaces. Ie two completely different bytecode contracts can share the same onchain verification api such that eg a dex can interact with two types of asset contracts in the same manner.

I currently know of 2 ways to do this (but I can imagine there are more).

Composability method #1:

Define/ spec/ conventionize the state layout of a contract. By making sure that all contracts following a specific spec/ convention share the same state layout, you allow an independent third program to inspect and observe their state transition without being tied to a specific bytecode implementation. That is, the observer can look at all inputs and outputs involved in the observed contract state transition and deduce from that the logical operation that occurred.
All the observer needs is 2 things:
(i) A stable hash of the non-state parts of each such covenant
(ii) A covenant id

Composability method #2:

This one is a bit more involved but also more efficient.

The specification not only defines an agreed state layout but it also defines an additional component: the state of each output must have a designated field which must describe the operation that just happened in concise terms. I.e., descriptors of the form: <note: x tokens were transferred from A to B>. This designated note / receipt field can be plaintext or a hash of several statements, and its exact format must be part of the said standard. Think of this as the verification eqv of an interface call. Instead of calling an opaque interface entry and relying on the specific runtime contract to execute the logical meaning of that op (as in classic vms), you have that specific contract declare the statement of what it did, and as an observer, you only need to inspect and read that note and make sure it matches the operation you expected.

---

I wrote about method #1 here https://t.co/xf2hjgfb4S and full support for it is already implemented in argent. Method #2 is somewhat more powerful/minimal but requires more effort from each contract following the std.

I appreciate you taking the time to analyze and write about this topic and raise awareness of the std challenges.
I’d be happy to explain more, brainstorm initial ideas etc etc

cc @DailyKaspa

[Luke Dunshea @elldeeone]

still looking for more people to assist with this

tldr, a private node today is like a phone that can make calls but cannot receive them - this should change that by allowing them to call each other without needing to make any changes to local network/internet

this will = an even stronger kaspa p2p network fabric

if you can spare some time:

1. Build this branch from source:
https://t.co/tkgiLku3nw

2. Use this command to start the node:
cargo run --release --bin kaspad -- --loglevel=info,kaspa_p2p_libp2p=debug,kaspad_lib::libp2p=debug,kaspa_p2p_lib::core::connection_handler=debug

3. DM or reply to this post to let me know.

If you don't understand how to do these steps but still want to help, give your AI this post and ask it to assist.

appreciate you all

[Travladd 𐤊 @travladd]

Not going to beat around the bush, $KAS price action has sucked.

But if anything really deserves to be a top tier crypto it’s Kaspa and I’ll die on that hill.