Kaspa Eco Foundation (KEF)

SUPPORTING KASPA ECOSYSTEM BUILDING - work with the community to foster the development, adoption, and sustainability of the Kaspa ECO.

[Kaspa Eco Foundation (KEF) @Kaspa_KEF]

The full video of @OxfordUnion address by #Kaspa Originator @hashdag is now live — including a 40-min address and a Q&A.

Dr. Yonatan Sompolinsky explained why the Internet is an unfinished democracy, why the problem isn't caused by bad actors but broken systems, and what crypto should actually be building. #staghunt #coordinationgames #whyCMatters

https://t.co/Ms3WyXSg1a

[coderofstuff @coderofstuff_]

@michaelsuttonil @FoxH04 @KASperiencexyz @moshikrl @BSCNews *now* is the time to build on kas. I prefer to hold the mindset that assuming no further updates were to happen ever (not saying this is the case, just the mindset), what can be built now with what we have?

[Michael Sutton @michaelsuttonil]

I’m finishing my argent compiler sprint (proof attached) and then I’ll do my best to communicate. Thing is, I think you are not my target audience despite indeed being a very informed investor. Talk is cheap, I want you to be INFORMED through the first serious app launching natively on Kaspa L1 and making you ask yourself “wait, how the hell is this even possible on KAS L1??”

[Michael Sutton @michaelsuttonil]

In programming, the actor model is a concurrency model that avoids lock-based synchronization. Instead of controlling access to a data element through a mutex or a read-write lock, you define a single owning actor for that element, and only that actor can mutate its state.

The actor can receive msgs in a message queue from other actors. Think of it as a single thread waiting for msgs in a loop, processing them through actions, and sending msgs to others as part of those actions. It can also initiate communication with other actors. Synchronization primitives may still appear in the implementation of msg queues, but contention is minimal by design.

To illustrate, if several parts of a program want to update the same state, they do not race to acquire its lock. They send msgs to the owning actor, which alone decides how to update its private state and what actions or msgs follow.

(By the way, rusty-kaspa’s consensus-processing pipeline was inspired by a similar design: actors/processors communicate through msg queues to provide pipeline concurrency, while each uses a worker pool for inner-task parallelism.)

---

UTXO detour

In the UTXO model, each UTXO is a one-time data storage point, consumed by the spending tx, which in turn produces new UTXOs. These storage cells carry kas value and an spk (script public key). The spk holds the rules for spending the UTXO.

With kaspa covenants, we focused on one type of spk called p2sh (pay to script hash), which is basically a simple 32-byte hash committing to a locking script. The locking script (aka the redeem script) can also hold state fields within it (think of them as constants embedded in this specific script and fed to the script’s “main function” as args upon execution).

Recent kaspa Toccata additions allow this script to enforce complex conditions, including inspecting the output spks of the tx and verifying complex rules over them. This means an input can verify that an output follows exactly the same contract/script, and that only the embedded state constants are mutated according to the script rules and embedded in the output. Alternatively, it can verify that control has passed to some other known contract template, with the same or a different state object.

eg:

Counter { count: 5 } → Counter { count: 8 }

or:

League { players: n, ... } -- register_new_player → League { players: n+1, ... } + Player { games: 0, ... }

---

To get to my point, imo this makes it natural to name such a stateful covenant UTXO an “actor.” It is not an actor with a long-lived process and a msg-queue processing loop, but it is an actor in the sense of state ownership. Only my fixed logic can consume my own state and produce the actor(s) I become next, with updated state. No one else can consume or mutate that state without going through the rules the covenant itself enforces.

The tx is the interaction/msg that triggers the actor’s next state transition.

A logical actor can therefore continue as a chain of UTXOs:

Actor₀ → Actor₁ → Actor₂ → ...

Each arrow is a valid tx that respects the actor’s transition rules. A covenant id can also give this evolving UTXO lineage a stable identity across state transitions.

---

I argue that this is the right mental model and terminology to establish when discussing covenant state-controlling entities: a piece of code owning a state and exclusively authorizing its mutation/consumption. I think many more details now emerging from eg Argent will be easier to discuss once we establish such jargon.

[CoinDesk @CoinDesk]

Crypto gave individuals sovereignty. Staghunt is betting the next frontier is the group version: coordination markets.

Read more at our latest thought leadership in partnership with @hashdag

https://t.co/VJQ15N0ka0

[Michael Sutton @michaelsuttonil]

@ibuypow @skibumtrading @KaspaKii “a self replicating contract that can copy it’s code to the output” = the whole idea of covenants

cf here https://t.co/ZLUMBvQHor

[Michael Sutton @michaelsuttonil]

pub rnd discussion started here: https://t.co/ewTnfxOzFJ
---
some initial discussion points that come to mind, in short:
- ownership scheme (should we start by speccing the idea of nested ownership more broadly, i.e., pk | p2sh | cov | <hash of something more complex that all asset contracts understand, e.g., borrow min incremental threshold or secondary borrow pk>)
- borrow paths (how to send asset funds to someone by updating their utxo “in-place”)
- minter role: multi-contract vs. a boolean indicator field
- controller pattern via icc
- etc

[Michael Sutton @michaelsuttonil]

Mission accomplished

[Michael Sutton @michaelsuttonil]

Now that we have programmability paths on Kaspa, the need to converge on ecosystem standards in the right way becomes paramount.

It appears we lack a fitting forum for such discussions.

A primary and timely example would be a standard specification for native assets. We need a place for technical discussions where wallet devs, explorer devs, community thinkers, and core devs can brainstorm and rapidly converge on ideas without communication gaps, and without important ideas and messages getting lost to oblivion.

As a start, here is a call for community discussion on native assets.

An initial discussion on kas pub rnd is linked below, but again, to me this feels like an echo chamber, with probably the most important voices missing.

>>

[Kaspa Ecosystem Growth (KEG) 𐤊 @kaspagrowth]

Want to build AI on Kaspa? 💚

Join our two live workshops at the Imperial College London AI Agent Hackathon - in person or fully remote, live stream will be provided.

All devs are welcome to join.
Register here:
July 1: https://t.co/tBv0L38Sb6
July 2: https://t.co/gRnNl6kvKh

[EMCD @emcd_io]

⚡ $KAS miners — time’s almost up.

You still have a chance to win up to $𝟯𝟬𝟬 𝘁𝗼𝘄𝗮𝗿𝗱 𝘆𝗼𝘂𝗿 𝗲𝗹𝗲𝗰𝘁𝗿𝗶𝗰𝗶𝘁𝘆 𝗯𝗶𝗹𝗹 with EMCD × Kaspa.

How to join:

1️⃣ Create an EMCD account

2️⃣ Activate promo code 𝗘𝗠𝗖𝗗𝗞𝗔𝗦:
New users: enter it during registration
Existing users: go to 𝗣𝗿𝗼𝗳𝗶𝗹𝗲 → 𝗣𝗿𝗼𝗺𝗼 𝗰𝗼𝗱𝗲𝘀
👉 https://t.co/t8Qh0sjPYz

3️⃣ Connect your miner and submit at least 1 valid $KAS share

4️⃣ Link your KAS wallet

[KasMap @KasMaporg]

#Kaspa $KAS at Imperial College London, with the table full of merch, 2 great looking banners, and 2 great guys!

[Chris Hutchinson 𐤊 @Chris_Hutch7]

Kaspa is always a big hit wherever it goes.

@IzioDev done Kaspa proud.

Still a few more days to keep impressing the academics and start ups 🔥

Massive thanks to @KasMaporg once again for organising this and huge shout out to the community for helping fund it.

Kaspa is where it needs to be 💚

$KAS #Kaspa

[Michael Sutton @michaelsuttonil]

@KasMaporg fingers crossed @IzioDev &amp; @asaefstroem 🤞 i think you are the best ppl in existence to bridge between the consensus-level efforts and ecosystem builders wishing to use Kaspa’s newly combined superiorities

[Michael Sutton @michaelsuttonil]

my timeline organically filled with 4 different kas core dev updates is something I’ve dreamed of for a while

[kasperia_wallet @KasperiaWallet]

🚀 Great news! Kasperia Wallet is now officially available on Google Play for Android! Securely manage your Kaspa assets with a fast, intuitive, and user-friendly wallet designed for the Kaspa ecosystem.
#Kaspa #KAS #CryptoWallet #Android #Blockchain

[Kaspa Eco Foundation (KEF) @Kaspa_KEF]

Now available: @oneforonehaha’s talk from @UnchainedSummit Vietnam. 🇻🇳

Good to see #Kaspa represented in rooms where infrastructure, policy, and real-world adoption are being discussed! Every one of these conversations helps bring #Kaspa to broader audiences. 💚

https://t.co/wVExzmSkrh

[Michael Sutton @michaelsuttonil]

epilogue

Agents are helping create layers of programming languages that will help them, in turn, build end-to-end applications. Both silverscript and argent were and are being built with massive help from llms. The experience shows that they/codex are particularly good at developing compilers. (Both because there are many references of compiler code in the world, and also -- in my opinion -- because syntactic formality is natural to them).

If we were to let an agent build a complex application directly in Kaspa’s script language (=the eqv of assembly), it would wander off and stumble over countless hurdles.

But, like humans, the gradual creation of abstraction layers, here in the form of programming languages translating to each other in a formal way, allows us to formalize the transition from business logic to final code. The abstraction layers become the braces. Humans and agents forge them together, and then both can use them to move more safely from business logic toward raw executable code.

[Michael Sutton @michaelsuttonil]

prologue

Taking my dr.’s (Sompolinsky) advice to rest a bit and have fun after Toccata’s release, I started experimenting with argent: a small high-level DSL for multi-contract covenant apps that produces silverscript code.

Please don’t laugh at this definition of “rest” ;) Releasing heavy core consensus upgrades carries a massive burden of mainnet responsibility. Playing with language compilers and application structure is exploratory work. So yes, for some ppl, it might genuinely feel like resting.

---

About three months ago, during the development of Toccata and silverscript, Ori (@someone235) threw a quick sentence at me: “You can implement a mechanism similar to MAST using ICC.”

(Stay with us if you want to understand what MAST is and why Ori was only partially right.)

Around that time, I started playing with complex scripts over silverscript and mostly tried to understand what a complex contract system over the new Kaspa script engine/silverscript could look like (or if one could be built at all). One thing led to another and I started trying to develop a chess game over silverscript. “okay codex, let’s start developing chess, let’s start with a chess game with basic movement rules, no complications. An array of 64 cells representing the board, public keys for black/white, turn, movement. The bare minimum that is still sufficiently complex.”

Of course, the first attempt didn’t go so well. As is fitting for a compiler in its early days, I quickly reached a state where I was the first one walking through certain code paths. This triggered a burst of contributions to silverscript itself and/or finding temporary workarounds.

The second attempt got stuck on the boundaries of the script itself. It turns out that implementing all the game rules for every possible piece plus scan loops statically unrolled to 64 iterations is, how should I put it, not really workable and tends to blow up. I came to the conclusion that the logic needed to be shattered into different contracts, meaning different scripts.

But how do you do that within the boundaries of a game? And what if I want to implement a decentralized chess league with players and scores that persist and update over time?

(By the way, chess is a complex and interesting test case for development, but don’t mistakenly think for a second that this discussion is limited to or aimed at games.)

>>

[Kaspa Eco Foundation (KEF) @Kaspa_KEF]

A small thank-you to the miners helping secure #Kaspa. ⚒️

Glad to support this campaign together with @emcd_global: one $KAS miner will receive up to $300 toward electricity costs! 💚

Make sure to review the rules and eligibility before participating! 🔥

[EMCD @emcd_io]

That moment when the electricity bill drops…
and it’s not on you 😌

EMCD × Kaspa are covering up to $300 in electricity costs for one $KAS miner ⚡

How to participate:

- Follow @emcd_global and @Kaspa_KEF
- Create an EMCD account using the promo code 𝗘𝗠𝗖𝗗𝗞𝗔𝗦: https://t.co/t8Qh0sjPYz
- Connect your hardware and mine $KAS (≥1 valid share)
- Link your KAS wallet for payout
- Upload your electricity bill: https://t.co/kKPoNvcxZq

🗓️ June 17 – July 1

The winner will be selected randomly.

Keep your setup running — we’ll help with the cost 🤝

Rules: https://t.co/1g8aNt0hCE

[Michael Sutton @michaelsuttonil]

(newer release: https://t.co/oU2tKHtrVC)