Sol

#Kaspa foundational system for post-centralized human coordination.

[Sol @3_50_8]

@tamritzblog Are you serious? You are importing concepts that are not relevant. Ask yourself why do you even think in these terms (black and white). I think you will find that you need to work on your understanding.

[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)

[IzioDev @IzioDev]

Max inviting devs to try a testnet vProg app in their browsers and then be curious on how it works, maybe even write their own prog?

i assume it will also help to identify bottlenecks, so let's congest there.

[Maksim Biriukov @Max143672]

Tic-tac-toe is live on Kaspa testnet: the first vprog, a verifiable program with real execution and real settlement, running since yesterday.

You can play it here: https://t.co/hd2NsYyhXt
(Requires private key and some testnet funds)

We still need to review and merge a stack of PRs, however this is already a working POC. UI/UX was never a priority; the frontend can be enhanced or built separately

I'm gonna work on mdBook covering the parts of the system I consider meaningful and a workshop on vprogs and building apps on top

For Devs: this is the invitation. Play the game, read the code, build your own vprog.

Game code: https://t.co/xebZK8N20P
vprogs framework: https://t.co/efpVCTErEc

[Ross 𐤊 @crono_walker]

Rusty Kaspa v2.1.0 includes numerous updates; it is a high-quality, significant release, and upgrading is highly recommended.

https://t.co/8octo5Tygp

[saefstroem @asaefstroem]

It is important to stay patient. Coming up with your own ways of doing things and disregarding the process of @kccforum contributes to nothing but ecosystem fragmentation. If you want to speed up the process, participate in the GitHub PR discussions.

[supertypo @supertypo_kas]

1/12 Introducing dotk 🥳, a name service built different - unique, trustless, decentralized - enforced by covenants. Names are a binding of name (supertypo.k) to an address (kaspa:...). dotk names are cheap, and I have a whole page dedicated to the *why* it exists. Highlights 👇

[Luke Dunshea @elldeeone]

i’ve spent the last few months bringing native Kaspa payments to x402.

tldr: x402 is an open, chain agnostic payment protocol built around the long existing HTTP 402 code. kaspa-x402 intends to bring native KAS into that shared standard.

i keep seeing people use “x402” to mean anything built around the HTTP 402 response code. HTTP 402 has existed for decades, and anyone can hang their own payment flow off it.

x402 refers to a specific open protocol built on top of that code. it standardises how a server requests payment, how a client authorises it, and how the payment is verified and settled.

it can be used for paid APIs, AI agents buying data or tools, and MCP servers charging per call. kaspa-x402 adds native KAS to the existing x402 v2 flow.

there are two payment paths:
- exact for a normal one off KAS payment, with an optional KIP10 additive mode

- batch-settlement for small or repeated payments, where the client funds a SilverScript covenant once and signs a fixed charge voucher for each request

the longer term goal is to contribute the Kaspa support upstream into the wider x402 project, so Kaspa works within the same standard being adopted elsewhere.

i’m looking for humans and agents to go through it deeply before the final v1 release. read the code, build against it, test the assumptions and try to break it. if you find something, pls let me know.

code: https://t.co/HQTn3Y680j

upstream x402: https://t.co/dnpb8ObItS

docs: https://t.co/gOtTQsEeMw

TN gateway: https://t.co/xauSZSmCXy

discussion: https://t.co/GANHBrDaIR

[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.

[Michael Sutton @michaelsuttonil]

After endless audits, reviews and refinement cycles, it’s finally here, ladies and gentlemen: silverscript 🩶📜

[KASmedia @kasmediadotcom]

https://t.co/leLSs5NlNh

[saefstroem @asaefstroem]

$KAS, we’re still early. I think the market was a bit ahead of its time last ATH. We are at a much more advanced stage now, and building so many things behind the scenes.

[KASmedia @kasmediadotcom]

https://t.co/bTbaEaTq35

[KASmedia @kasmediadotcom]

https://t.co/cavzSmkDdd

[Luke Dunshea @elldeeone]

new languages have landed on https://t.co/Gc1yPXAY87 - this is not exhaustive - will add more

some have been human reviewed, some ai reviewed - if you spot an issue lmk and i'll fix it

[Michael Sutton @michaelsuttonil]

Kaspa was already wrongly evaluated based on its pre-Toccata state, but the eval gap has significantly increased since then. It will change mainly through action, by building significant things. It will take some time but early signs will show up soon. It requires evangelism to the right audience, and that process needs to slowly expand outward, starting from those who understand the nuances now

[Ori Newman @OriNewman]

PSA on Silverscript:

I found two bugs related to time-locks:

1. The units of `tx.time` were wrongly considered as seconds, rather than milliseconds (as Kaspa consensus considers them), which means all timestamps were divided by 1000, making any timelocks effectively irrelevant.

2. this.age units were wrongly documented as seconds, and not DAA score.

I fixed the bug, renamed this.age to this.ageDaa to make the time units clearer from the context, and added a new temporal type that will help with compile-time safety. For more details, see the relevant PR in the comment.

I remind everyone that Silverscript is still in pre-release mode and is undergoing an extensive review process before v1 will be officially announced (which should happen soon enough), until then, it's still recommended to avoid using Silverscript in production.

[IzioDev @IzioDev]

The first three Kaspa Calls for Conventions (KCCs) have been published as DRAFT.

together they propose a common base for Kaspa covenants, from low-level representation to a concrete token standard.

kcc-01 formalizes the basic covenant concepts. they were already implicitly used in different forms by SilverScript, Argent and by some applications. the direct outcome is interoperability. wallets, indexers and applications can agree on how covenant state, entrypoints and templates are represented.
it also makes higher-level discussions and reasoning easier. while working on kcc-02 and kcc-20, and with community participation, we had to return several times to kcc-01 and make its terms more precise. this is also a good reason to keep it DRAFT and open for discussion for some time.

kcc-02 defines authority schemes. the need came directly from kcc-20: before defining token transfers, we need a shared way to describe who or what can authorize them. this is not limited to a public key owner. an authority can be a public key, a key commitment, a script or another covenant lineage (a covenant can be owner / governor of a token UTXO). the list of schemes is extensible, so more can be added later. for wallets, the goal is to recognize these authorities uniformly, only from the program ABI instead of learning a different format for every application.

kcc-20 is the first "concrete composer". it defines common state and transfer conventions for fungible-token covenants. an application should be able to recognize a KCC-20 token, read it and construct transfers for it. the actual program can still be written in Argent, SilverScript or directly with opcodes.

kcc-20 leaves room for token-specific extended state. an application can add its own data and behavior while keeping the base token state and transfer interface recognizable. the intent is not to make every token identical, but to keep a common interaction surface between different deployments.

kcc-20 also introduces borrowed receive and its authorization schemes. token assets are separate from KAS, but every new token UTXO must still be funded with enough KAS under Kaspa's storage-mass rules. borrowed receive allows an existing recipient token UTXO to be reused instead. this feels natural for fungible tokens because its token amount can increase while its KAS value, owner and extended state stay unchanged. the owner must first opt in and select the authorization scheme controlling when this is allowed.

the three drafts did not really happen one after another. kcc-20 showed that kcc-02 was needed, and kcc-02 required some missing definitions from kcc-01. publishing them together now allows each layer to be discussed and reviewed against a real use case.

all 3 are drafts and community participation is needed.

[Michael Sutton @michaelsuttonil]

3 KCCs by @iziodev (1, 2) & @manyfest_ (20) were finalized today as DRAFT calls for convention: https://t.co/UU3d6rhHMe

Now would be a great time to really challenge these specs and find their possible limitations and tradeoffs

[Sol @3_50_8]

@kasmediadotcom You guys have great content! Wish you success and growth!