Pinned Tweet
Yonatan Sompolinsky – The Mind Behind Scalable Decentralization and Kaspa🧠
—With 4,223 citations on Google Scholar, Yonatan Sompolinsky has cemented his role as a foundational thinker in blockchain scalability and distributed systems. “The minds behind Kaspa aren’t just anybody. These are the architects who saw the limits of traditional blockchains and dared to reimagine them. They didn’t follow trends — they set new standards. Backed by peer-reviewed research and real academic firepower, they built Kaspa not for hype, but for history. This isn’t just another crypto project — it’s what happens when the brightest minds in distributed systems decide decentralization deserves better.”
Study Kaspa.
Think Kaspa💡
$Kas #Kaspa $Btc
Kaspa Visuals retweeted
i’ll do everything in my power on the technical side to help this initiative move forward and navigate any protocol-level obstacles along the way.
on a personal note, Alex has a rare mix of technical depth, bizdev talent and deep Kaspa knowledge. i honestly can’t think of anyone better suited to lead it, and i really appreciate him taking this on
Today we are introducing KaspaDollar, an initiative led by core developer @asaefstroem to build the first decentralized stablecoin on the $KAS network.
The developments around @kccforum and the Toccata hardfork have considerably widened what Kaspa is capable of. Capability alone, however, does not make an ecosystem. Decentralized finance requires a unit of account that holds its value, and until Kaspa has a stablecoin of its own, every application built on it will remain dependent on assets issued elsewhere.
The design we intend to follow is the decentralized, overcollateralized stablecoin: a pattern whose security properties have been examined and tested across the industry for the better part of a decade. With the support of the core team, we consider the conditions right to bring it to Kaspa.
Realizing this requires development, an independent audit, further research, and the operational work of taking a protocol from specification to production. To fund it, we are opening a fundraiser with a target of 5,000,000 KAS.
Contributions are made directly to the fundraising address published on the website. Should the target not be reached by 1 January 2027, every contribution will be returned to the address from which it was sent.
Up until that point, this account will share the plans, details and progress of the work as it develops.
Kaspa Visuals retweeted
Replying to @aKaspamaxi
i believe we can get to a stable (and secure) testnet this year
Kaspa Visuals retweeted
I spoke with @hashdag about $KAS wallet number one, he says being anonymous is not uncommon, but having zero (anonymous) coordination with the team is . . like the main investor giving up an observer seat on the Board and not protecting their investment.
So his guess is EntityX may be a first timer that started crypto in 2020s for sure . . . What an interesting angle from our Favorite Br!lli@nt Mind !!
Kaspa Visuals retweeted
TradFi may not want to call it crypto.
But at Sibos 2026, roughly one in six substantive conference sessions focused on blockchain, tokenization, stablecoins or digital money.
Not a single session title used the word “crypto.”
What happened at one of global finance’s most important gatherings tells us something about where the industry is heading. 🗺️
Kaspa Visuals retweeted
I want to share something I’ve been working on that I'm calling OpenMiner.
My goal is to understand the chips that power our miners, share what we learn, and use that knowledge to build open software and hardware.
Today, I’m making the OpenMiner Reference repo public. This is the research and documentation repo, starting with my work on the BM2382 chip inside the Bitmain KS5. It covers communicating with the chip, initializing it, sending mining work, and reading its responses, including what I’ve tested and what I still don’t know.
I hope it grows to cover more chips, manufacturers, and miner models. My focus is Kaspa, but I want OpenMiner to be useful for all miners. Other people have different hardware and interests, and I’d love for their research to become part of it too.
I see three stages to this work:
1. Understand the chips. Learn how they work and document that knowledge so others can use it.
2. Take control of our miners. Build open software for existing hardware. I’d like to explore detailed logging and diagnostics, remote monitoring, custom fan and temp controls, and automatic power management based on schedules, electricity prices, solar availability, or other triggers. Over time, I’d also like to work towards power limits, efficiency tuning, undervolting, and overclocking, so we can choose how our miners run.
3. Build new hardware. Explore taking chips from existing miners and putting them into new form factors. Maybe, over time, that leads to miners of our own.
A lot of my inspiration comes from Bitaxe and the people who have contributed to open mining hardware in the Bitcoin community. I have huge respect for that work and would love to see more people able to experiment with mining hardware themselves.
Later, I’ll share the OpenMiner platform repo, where I’ve been turning this research into an open source, modular mining platform. I want it to support different miners, with compatibility growing as we learn about and test more hardware.
I’m going to keep working on this. I’m sharing the reference now because others might want to join in, whether that’s investigating another chip, improving the docs, writing software, or designing hardware.
I’ll be focusing on Kaspa. If your interest is elsewhere but still would love to contribute, I’d love to hear from you too.
github.com/elldeeone/openmin…
Kaspa Visuals retweeted
you can build a kaspa vault that only lets you spend once a price condition is met.
silverscript’s HodlVault example checks your signature and a signed price message from an oracle, an outside source of data.
kaspa checks that the message meets the contract’s conditions. you’re still trusting the oracle to report the price accurately.
the example code is in the comments for devs to build from.
Kaspa Visuals retweeted
Crypto was built to replace the financial system. Instead, it may be rebuilding the infrastructure underneath it.
Recent moves by the Fed, SEC, and CFTC point in the same direction: stablecoins are becoming banking infrastructure, traditional assets and records are moving onchain, and blockchain is increasingly serving TradFi—not replacing it.
New analysis by @NicholasSismil:
kasmedia.com/article/crypto-…
Replying to @Radical_Ed_Bad
Time has come to interact with all programmable chains. #Kaspa kaspa:native is ready to get the eyes on it by devs and investors.
The $BTC litecoin:native zcash:native etc crowds are still important audiences, but there are more use cases now for kaspa:native and by getting the projects, payments will follow.
Replying to @DecodeMarkets
You a can take a look at #Kaspa ticker kaspa:native to see what Vitalik is aiming for. Btw, its a fair launched hard capped POW coin with an OG founder called Sompolinsky. And Vitalik already used his research before in #Ethereum.
xitter.cf/captaindwork/status/19…
Kaspa Visuals retweeted
hello again. the devs made things this week and i made a list.
1 / Rusty Kaspa v2.1.0
nodes now download sync data in smaller chunks to avoid bottlenecks and timeouts while catching up with the network. v2.1.0 also includes Stratum bridge fixes and moves the existing zero-knowledge proof tools into their own package.
github.com/kaspanet/rusty-ka…
2 / vProgs
@Max143672 announced the first vProg running on testnet. it’s a playable tic-tac-toe game with real execution and settlement. still a working proof of concept, with public code for devs to build from.
xitter.cf/Max143672/status/21034…
3 / Python SDK
@smartgoo_ released Python SDK v2.1.0. devs can now compile SilverScript contracts in Python and debug them without running a node. it also adds tools for using zero-knowledge proofs, examples and bug fixes. SilverScript support is still experimental.
github.com/kaspanet/kaspa-py…
4 / SilverScript Studio
@KasperoLabs announced SilverScript Studio is live on mainnet. build, compile and deploy covenants from your browser. write them yourself, describe what you want to its AI, or use the wizards for things like vaults, escrow, recurring payments and payroll.
xitter.cf/KasperoLabs/status/210…
5 / KCC23
@manyfest_ explained a proposal for linking details like token names, symbols and images to a covenant, without copying them into every holder’s coins. KCC23 is still a draft and open for review.
xitter.cf/manyfest_/status/21030…
6 / KCC standards
@asaefstroem’s proposal to finalize KCC0 was merged. it sets out how shared ecosystem conventions are proposed and reviewed. he also proposed moving KCC20 into last call review. that hasn’t merged, so KCC20 is still a draft.
github.com/kaspanet/kccs/pul… github.com/kaspanet/kccs/pul…
7 / DNS seeder
@supertypo_kas released DNS seeder v0.9.6, fixing a bug that counted some offline nodes as online.
github.com/supertypo/simply-…
thanks to everyone building. see you next week.
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…
Kaspa Visuals retweeted
Decent move from $KAS so far, up 84% since August 26.
In your opinion, it will keep pushing or pull back here?
Kaspa Visuals retweeted
Vitalik’s new “cryptographic world computer” thesis makes an important point that extends far beyond Ethereum: the future of blockchain probably isn’t putting more computation directly on-chain. It is separating ordering, execution and verification so each can happen where it makes the most sense.
That is where Kaspa starts becoming extremely interesting.
Kaspa does not need to become a giant replicated computer where every node executes every application instruction. Its more natural role may be providing the decentralized ordering and settlement substrate underneath an enormous amount of computation happening elsewhere.
Toccata already pushes Kaspa in this direction. Covenants allow UTXOs to become persistent state machines. Covenant IDs preserve application lineage. Silverscript makes those transitions programmable. Argent is exploring how independently stateful actors can interact atomically. And vProgs takes the architecture further: applications can submit operations into Kaspa’s ordered environment, execute computation outside consensus, generate cryptographic proofs, and ultimately settle verified state transitions back to L1.
The distinction matters.
Instead of forcing the entire world computer into consensus, Kaspa can make consensus responsible for the things decentralized consensus is uniquely valuable for: ordering, timestamping, ownership, state commitments and final settlement.
Computation can then become massively parallel.
Different applications can maintain different state domains. Independent UTXOs can progress simultaneously. Expensive execution can happen off-chain. Proofs compress that computation into something L1 can verify.
The emerging architecture looks less like “Kaspa with smart contracts” and more like a cryptographic coordination fabric.
Ethereum appears to be moving away from the original idea of the blockchain executing everything toward a system that orders, verifies and settles increasingly external computation.
Kaspa may be approaching the same destination from the opposite direction: starting with an extremely fast decentralized PoW clock, then progressively attaching programmable state and verifiable computation around it.
The world computer may ultimately be less of a computer than a world-scale system for proving who did what, in what order, and whether the resulting state is valid.




























