12 Photos and videos
Pinned Tweet
5 Nov 2025
sovereignty as a service
2 Nov 2025
not gonna give you price targets on kas
can tell you the thesis is underpriced and if vprogs delivers the way hashdag thinks it will, you'll know when it happens
sovereignty narrative isn't fully understood yet
58
263
1,012
179,574
Jun 9
since many (~4) asked me about the zcash bug - - - earlier this year I had this convo with a zcash core dev:
zk: it's weird that kaspa is pruning past records
me: why does it need to keep 'em?
zk: the whole point of ledgers is to prove correctness of all state transitions
me: the whole point of ledgers is to provide focal points for the consensus state
zk: the whole point...
me: hmm then why did you come work in zcash? you know the Sprout->Sapling counterfeiting bug
zk: Turnstile guarantees that the counterfeit could have been very limited
me: true but you still cannot prove or even reason about correct state transitions besides the total supply cap
zk: that's actually a good point
----
the most hardcore cryptography coin is shifting away from correctness proofs to practical-enough proofs. I believe this is a step in the right practical direction, yet the paradigm shift should not go unnoticed - -cryptography is giving way to consensus.
if you came to zcash for cryptographic integrity, reconsider. there are many good reasons to root for zcash prospering. zcash is serving a more important role than bitcoin, whose utility for the original mission is by now blurry. cryptographic integrity is/should not be one of those reasons.
----
BTW the bug should definitely have been exploited. I don't know the personal values of Taylor Hornby, and I shouldn't be required to make the effort to learn them. I only know that if I found such an exploit, it wouldn't take me more than a few minutes to tempt myself into printing a longint amount of ZEC and deciding later what to do with it.
I wouldn't necessarily use it to exit the pool immediately and corrupt the supply, I'd wait to see if some portion of the broken pool does not seem to migrate on time (probably lost funds), in which case I would not think twice before claiming the funds myself.
you could argue that no harm done, and you might be right, but then again you are here -- in zcash / in crypto -- for its consensus dynamics, the ability to coordinate interests and convictions across different trust zones around some shared asset; not for some pristine mathematical integrity.
55
275
888
29,961
Yonatan Sompolinsky retweeted
The @festival_web3 2026 event is closing today! We want to highlight the #kaspa dev contributions as key parts of the ecosystem!
From core @michaelsuttonil
@OriNewman @coderofstuff_
@Max143672, @asaefstroem, d-stack, along with @kaspa_kef grantees @hus_qy @IzioDev @FreshAir08.
Working closely with exchanges and wallets @supertypo_kas
@lAmeR_1377
Thank you for your work!
Oh almost forgot @hashdag the goat (face not in the picture)
8
71
328
13,041
Yonatan Sompolinsky retweeted
wrote an outlook for the upcoming “Toccata” hard fork -- native L1 covenants, based zk apps, why the activation window moved, and what the road from feature freeze to mainnet looks like:
medium.com/@michaelsuttonil/…
47
287
845
118,541
Mar 26
fam: its been like 13 years, figured youd move on by now.
me:
Mar 26
41 yaşındaki LeBron James, blok sıralamasında 2'nci sırada bulunan Jay Huff'ın üstünden BİR DEĞİL İKİ DEFA SMAÇLADI 🤯
28
44
256
22,179
Mar 24
Highly recommended, Covenant SilverScript Chess (!!) webinar @michaelsuttonil & @OriNewman
In 30 minutes @ discord.gg/kaspa meeting-room
Mar 23
spontaneous live session tomorrow with @iziodev on silverscript and complex multi-contract L1 flows, with chess being the primary demo/ showcase. deal?
14
169
570
23,902
Mar 14
This isn't cypherpunk. This is just punk 🤷🏻♀️
12 Nov 2024
Devcon wouldn't be Devcon, without a song and dance with Vitalik 😉
50
57
386
22,848
Feb 28
Blessed be America my people, and Persia the work of my hands, and Israel my heritage.
Pax Persica Le'Chayim!
40
49
437
21,231
Yonatan Sompolinsky retweeted
Feb 27
counterpoint
x.com/nic_carter/status/2027…
Feb 27
If a top AI CEO in China told the CCP to go kick rocks when they asked for help, that CEO would be instantly sent to prison.
This is the correct approach
Letting AI CEOs play politics and dictate policy for the military and soon the entire country like their own personal fiefdoms is appalling and undemocratic
If Trump doesnt bring Dario to heel now, we will simply end up completely subjugated by him and his lunatic EA buddies
12
4
59
19,072
Feb 26
Kaspa is real-time bitcoin, solving scalability is great but not the core value prop.
Real-time bitcoin means achieving in a few seconds the same security guarantees that nakamoto consensus / bitcoin achieves after an hour; decentralizing each consensus round rather than chain quality achieved through a coarse aggregate of rounds.
A clean definition anchor for real-time decentralization (RTD): The ability to sample the honest majority in real-time.
(Note that even fast leaderless VRF-based proof-of-stake cant sample honestly bc the selected nodes get to choose the content of their blocks after they've been selected; pos=select then write, pow=write then select)
--
RTD affects: txn confirmation, censorship resistance, secure oracle finality, MEV resistance.
Eg censorship resistance, bitcoin is the most censorship resistant chain, but if 60% of the miners are censoring you (point in reference: OFAC abiding tornado censoring eth miners), your txn will pend for 30-40 minutes. For shady business payments that's not prohibitive, but for a real economy, for an asset aspiring to be at least a king of collateral even if not an MoE, this is unacceptable, esp under economic stress.
Beyond censorship, all things finance benefit tremendously from pow density, from sampling the majority in real-time in a secure and honest manner.
I wont get into MEV resistance now, but having a "conscious" stream of oracle attestations (not price oracles) finalized in real-time qualitatively upgrades the ability to encode informed risk, collateral, liquidity management, which is the lifeblood of defi.
In context of conf times, increasing from 1 to 10bps saturates the latency optimization. But for pow density we need dozens of blocks per second, with the endgame of 100 bps: Under 10bps a 37% attacker can fake the majority signal with probability 12%. With 100bps this drops to 0.3%. Today Kaspa can't accelerate to >10bps w/o harming conf times, but DAGKNIGHT will be implemented hopefully by Q3 at least on testnet, by which we will push for 25-40bps.
The cherry on top: RTD also implies netsplit resistance, as per the partial synchrony framework.
WWIII cyberwar resistance. Hypothetically speaking ofc.
(elaborated- hashdag.medium.com/in-which-…)
Zcash is private Bitcoin
Litecoin is faster Bitcoin
Kaspa is scalable Bitcoin
Decred is governance Bitcoin
Bitcoin Cash is big block Bitcoin
Ethereum is smart contract Bitcoin
Quantus is quantum resistant Bitcoin
Monero is reactionary fungible Bitcoin
“Bitcoin” is not just a ticker.
“Bitcoin” is not just one network.
Bitcoin is the name of a movement, the symbol of a revolution, and the ecash that actually changed the world.
77
660
1,648
155,359
Feb 20
the bazaar is converging in dag mode.
@JeremyRubin heres your CULT OF THE COVENANT
Feb 13
Thanks to @OriNewman and all core devs working on delivering technology and usefulness never before seen at this level on a L1/PoW.
Here's a Commoners break down of SilverScript.
🔏#SilverScript is #Kaspa’s first high-level smart contract language and compiler.
It allows developers to write contract logic in human-readable syntax and compile it directly into Kaspa script.
Inspired by #CashScript, it is designed specifically for #Kaspa’s UTXO model and native script engine.
This is experimental infrastructure, but it marks an important step in Kaspa’s programmable roadmap.
Simply Put
SilverScript lets developers write rules like:
• how funds can be spent
• how vaults unlock
• how assets move
• how DeFi logic executes
…without manually assembling low-level Kaspa script.
Readable code goes in.
Kaspa-native script comes out.
No external VM.
No separate execution layer.
Just Kaspa.
Technically Speaking
SilverScript is:
• A high-level language
• A compiler targeting Kaspa script
• Designed for contracts with local state in the UTXO model
It adds features like:
• loops
• arrays
• function calls
These make more expressive contract logic possible while still compiling down to Kaspa’s native script system. SilverScript is expressive but bounded. Execution remains limited by script size. Loops are unrolled at compile time, meaning there is no dynamic or unbounded runtime behavior.
Architecturally:
SilverScript focuses on local state contracts, where logic is tied to specific UTXOs and their spending conditions.
This makes it a complement to:
• Covenants
• new script engine capabilities
• future #KvProgs, which aim at shared state and ZK-verified models
Different roles. Same L1 foundation.
⚠️Important: Current Status
SilverScript is experimental.
• Breaking changes are expected
• Syntax and APIs may evolve
• Compiled output works only on Testnet 12
It relies on new script engine features recently enabled on #Testnet12. It is not mainnet-ready infrastructure yet.
This is a developer sandbox phase.
Why This Matters for Kaspa L1
This is a dev tool plus architectural progress.
SilverScript shows that:
• Programmability is being built inside Kaspa’s native script system
• Contract logic remains coupled to Kaspa consensus and security
• Growth does not require external execution layers with separate trust models
That means:
Kaspa’s L1 is evolving from “fast settlement” toward a base layer capable of supporting structured financial and asset logic while preserving its core architecture.
It strengthens:
• Native contract capability
• UTXO-based programmability
• The path toward a layered but unified L1 stack
This is foundational infrastructure work, not surface-level features.
So What? (Project-Level Impact)
For the Kaspa ecosystem, this means:
• Lower barrier for building native applications
• More practical vault, asset, and contract designs
• A clearer developer path for DeFi-style primitives on L1
• Expanded use of new script engine capabilities
It increases what can be built directly on Kaspa, not beside it.
So What? (Potential User-Level Impact)
This eventually impacts more than just developers or $KAS holders.
🧑💻Developers
• Much easier path to building on Kaspa
• Ability to write complex contract logic without hand-crafting low-level script
• Faster experimentation with vaults, asset controls, and DeFi-style primitives
• A more practical entry point into Kaspa’s script system
🤑Users/Spenders/senders
• Safer wallet logic and vault structures
• More advanced on-chain spending rules
• Native tools for asset and contract management
☕️Merchants
• More flexible payment conditions
• Escrow-style logic and programmable settlement
• Stronger foundations for automated payment flows
🏢Enterprise Markets
• Structured asset control models
• Rule-based fund flows
• On-chain enforcement of transaction logic
🧑🏽🏫Academics and Researchers
• A platform to study UTXO-based contract systems
• Practical experimentation with script-based programmability
• Real-world testing of contract design without a VM model
• SilverScript expands the types of systems that can be built on Kaspa’s L1, even if end users never see the language itself.
Summary
SilverScript is an experimental high-level language that makes it easier to build Kaspa-native contracts. It is early, but it represents a step toward deeper programmability inside Kaspa’s core architecture, rather than outside of it.
Follow @OriNewman's post for links to Github and other important resources.
10
124
480
22,530
Feb 16
instead-of-summary of new blogpost:
a few months ago I became conscious that I've been double-speaking about kaspa for a long time now: when I talk with regular people I show off kas' speed, but when I meet crypto informed folks I instinctively shift to its unique security, to dagknight's resilience under netsplits come 2026. I am talking out of both sides of my mouth and I'm barely aware of it.
if forced to choose one north star, what would that be?
then later it occurred to me that this doublespeak actually represents two sides of the same coin- partial synchrony, a consensus category describing just that- protocols that are parameterless hence fast in peace times hence slow-yet-secure when the network/internet breaks. so now I think I can go back to speaking out of both sides of my mouth, as this represents two prongs of real-timeness.
hardcore crypto recognizes defensive values- security, censorship resistance, privacy. I argue we need a new category or metric for how long it takes a chain to achieve these defensive traits. eg bitcoin achieves censorship resistance in about an hour, kaspa achieves the same level in 1-3 seconds. doesn't make sense to flatten the two traits under the same umbrella term "censorship resistance".
the limit of this metric is real-time decentralization- the ability to sample the consensus network in real time with very high granularity, and achieve all the good properties that proof-of-work gives us just in real-time. started diving into this in the post.
kaspa's north star is real-time decentralization, but did you know the north star is actually a triple? now you do
48
338
958
36,949
Feb 16
medium.com/@hashdag/in-which…
@zkDragon endnote 3's for u, negative security
11
107
369
41,061
Kaspa’s runtime architecture achieves scalability not by optimizing block-level throughput, but by rethinking the role of blocks entirely. Instead of treating state transitions as discrete batches that must be processed sequentially, Kaspa models them as a continuous stream of causally-related transactions, with blocks serving only as logical markers that define the boundaries of possible reorgs.
This shift in perspective moves the performance bottleneck away from "how fast can we process everything inside a block" toward "how can we parallelize all currently known tasks across the entire DAG". When a block contains a spike of non-parallelizable work, traditional blockchains must stall until the block is fully processed. Kaspa does not. Because unrelated transactions can be scheduled immediately - even those belonging to future blocks - the system avoids idle CPU cycles and eliminates the classic straggler problem.
Most existing DLT architectures tightly couple block production with state commitments, proofs, or other finalization steps, making their execution model inherently sequential. Even if they support some parallelism within a block, they still wait for a block to finish before moving on to the next one. This introduces unnecessary latency and forces the runtime to juggle responsibilities that are orthogonal to efficient workload distribution.
Kaspa’s strict separation of concerns allows the entire execution model to collapse into a minimal, expressive, and highly generic framework - small enough to run any ACL (access-control list) enabled VM at essentially bare-metal performance.
Its design models causal dependencies at the lowest hardware-relevant level, enabling an execution flow that is:
- completely lock-free
- free of WAL flushes or global sync barriers
- based entirely on eventual consistency
This results in a simpler, more scalable, and far more hardware-efficient architecture than anything deployed in blockchain systems today.
In effect, Kaspa does for distributed ledgers what TensorFlow and CUDA Graphs did for machine learning: it exposes a parallel execution model that can scale seamlessly with modern hardware, turning theoretical throughput into practical reality (the 64000 TPS that Solana achieves in the lab let's bring that to practice).
I am extremely excited about this as this is exactly what I always wanted to build with IOTA and now it's finally done.
We are still working on implementing the higher levels of abstraction like designing a capability based linear type system abstraction for state management and resource access that gets rid of the need for manual capabilities wiring like in SUI and there is still a bit of work left but I don't think that you will ever be able to build a more scalable architecture than directly modeling the causal structure of state changes down to the lowest hardware layer.
Kaspa is going to melt faces my friends and it's going to be so much better that it will be impossible to ignore!
And it's such a simple API with Rayon level abstraction ... I am seriously getting a nerd-gasm just looking at the code 😅: github.com/hmoog/kas-l2/blob…
This goes out to KEF and the entire community:
Thank you so much for allowing me to take part in this journey - this really feels like coming home! 🥰
113
480
1,293
155,873
12 Nov 2025
A few raw thoughts on the implications of shielding:
1. @maxibitcat raised the question of native shielding for kaspa. quick answer: zk_opcode upgrade would enable a shielding vprog, but note that plain shielded state can’t scale in throughput bc its history can’t be pruned - the shielded notes merkle tree history must be kept to compute spendable-note witnesses.
A new paper by @secparam and @ebfull proposes pruning the shielded state and relying on archival nodes to retrieve and compute witnesses. perhaps a reasonable compromise in the context of zcash - kaspa so far operated without relying on archival nodes and i dont think we should change that.
A vprog can definitely decide to rely on archival nodes to implement a scalable shielding pool. such tradeoffs highlight why dapp-autonomy is non-negotiable - the shielding vprog can decide whether to restrict its tps/gas/state size knobs or to lean on archival nodes; L1 stays oblivious to the dapp’s configs and assumptions.
New work with @ebfull on scaling Zcash and Zexe-derived protocols like Aleo and Aztec.
zkSNARKs are now a (fantastic) commodity. They were always just one piece of the puzzle: building a secure protocol architecture for "shielded state" manipulation.
eprint.iacr.org/2025/2031
29
144
521
56,275
12 Nov 2025
2. Sovereign money pov: prioritize features that let normies hold their wealth safely: smart wallet/account abstraction, social recovery (”if utxo inactive for x years allow these addresses to release my funds”), inheritance (ditto), cold-hot wallet rules (”block attempts to move more than 95% of my sov UTXO in a day”), wrench-attack-resiliency proofs (”here’s proof i am unable to help you steal >5% of my wealth even though you’re threatening my life”).
These features are compatible with shielding, they just require a general-purpose shielded state such as @AleoHQ (L1, mainnet) @Aztecnetwork’s (L2, testnet) turing-complete vm’s.
Again dapp-autonomy is a more realistic path vs L2's: privacy teams are less likely to clone their tech under someone else’s rollup; but if they own the arena, control state rules/ throughput/ proving incentives/ archivals - and enjoy kaspa’s sequencer - that they would consider.
2
42
250
20,216
12 Nov 2025
3. Shield vs defi: we need more talk on how shielded state is directly at odds with defi and composability. shielding=privacy confidentiality, obscuring both transactor and transaction. shared state is by definition transparent, hence any “shielded finance” variant moves away from shared state to dark pools and order flow internalization.
3
38
234
17,170
31 Oct 2025
ppl assume the based rollup model immediately alleviates the L1 L2 misalignment that eth suffers from.
case 1:
if L1 ends up having one primary programmable extension to L1 - a winner takes it all - then the winning entity will effectively become the "frontend" of kaspa for builders and all things defi, and will have effectively hijacked the network effect of kaspa for its own brand, token, shareholders. yes it pays miners for sequencing but other than that its entire focus would be on growing its monopolistic influence to shape the ecosystem in its own legit interests. this is what a pro CEO should do.
another pov on this: if L1 ends up having only one programmable extension then why do we need an L2? we're better off upgrading kaspa L1 to implement and become that extension. the L2 route here is conceding all the hard work we've put into a fairlaunch network.
case 2:
if L1 ends up having an oligopoly of programmable extensions then they would compete in a zerosum game on builders and liquidity, will naturally fragment the ecosystem - state wise, liquidity wise, toolchain wise - and the frontrunners will have little incentive to fix this. they would also have little incentive to contribute to any rnd that promotes the level field (the thread responded to was triggered by one anecdotal-yet-concrete example, i suggest rereading it @radical_ed_bad)
case 3:
L1 ends up having a healthy competitive market - one with many programmable extensions - these would inevitably be small hence scoped in activity. ie zk smart contracts, dapps, vprogs.
the vprogs philosophy is merely a/the only conclusion.
--
the counterargument that L2's have incentive to align with L1 in order for the community to keep supporting them, or to prevent the warning rants of obnoxious core members, hasn't substantially solved this for eth. it could in theory work in kaspa, but that's a huge bet that we should acknowledge with open eyes. paraphrasing on Reagan's statement on the constant battle to preserve freedom -
Layer One is never more than one layer away from extinction
31 Oct 2025
I don't understand where preciesly lies the distinction (that matters) between L1 to L2.
The R&D claim is a strawman afaics; is @Igra_Labs going to eat incentive for miners? I thought it uses L1 as sequencer so the answer is no(?).
It is a programmability extention for the L1.
52
160
681
88,648
30 Oct 2025
while butting heads with @CryptoAspect on panic failures in zkVMs I received this <from panic attacks to full night's sleep> newsletter from @chargrysolle.
i saw this as a divine calling to braindump my pov before implementing full night sleep.
for any VM system that implements metering - and for any zkVM system that implements provable metering - panic is a (non) special case requiring no special treatment. sure, one can architect a system which safely handles panic w/o metering, but not the reverse - and since based (rollups or the superior) programs / vprogs necessitate provable metering, panic/abort is "solved" or correctly wrapped for free.
as @Max143672 @CryptoAspect point out, SP1 as a single layer zkVM doesn't support (provable metering and doesn't support) panic handling - while this can be patched at the compiler level, this would guarantee safe abort of programs compiled using their toolchain only, whereas permissionless onchain registration of programs requires a more robust guarantee.
the implied conclusion is that based (rollup or the superior) program systems can either use bespoke VMs such as Polygon's and Scroll's zkEVMs, or the slower and less performant nesting of general purpose VMs, which would enable runtime analysis of the guest program.
but researching this I discovered a much neater alternative by @StarkWareLtd - the Sierra raw byte format, which iiuc achieves provable safety (and metering) via compile time static analysis. if true this is very very cool! cc @VolokhIlia
tldr CairoVM>>SP1
--
this discussion is orthogonal or at least complementary to the based vprogs design, a zk variant of Solana's design - the link is somewhere on kaspanet's github - which insists on sync composability on the program layer while allowing programs to live and maintain their own state - their own mini zkVMs.
vprogs optimize for dapp sovereignty, and will obviate the inherently parasitic L2 network/rollup entities which seek to lock and suck all dapp activity under their umbrella.
hopefully kas builders will optimize for sovereignty too.
cc @michaelsuttonil
47
209
872
78,067
Yonatan Sompolinsky retweeted
18 Oct 2025
Kaspa has 540k followers on CoinMarketCap and 409k sentiment voters, with 89% (±1%) bullish despite price action. If half adopt a 100W KS0 Ultra home miner, we become a self-sustained, anti-corporate solo miners' network, ensuring secure, decentralized PoW-based agile money. Stop diluting silver with memecoins; run a node, buy a home miner. Block mining isn't a lottery like in $BTC; it's a 2-day wait in solo mode. $KAS #blockchain #solomining #crypto
We are not PoS; don't be just another coin bag holder. Do something; we're the money. One node, one miner speaks louder than thousands of words on X.
17 Oct 2025
Guys, I was mistaken; I was looking at kaspa-nodes.org my worker stats, but I mined my first ever block yesterday at 16:21!
Run a $KAS node. Watch live logs. Get excited. Don't feed other miners with memecoins minting. Be the miner. Buy a second-hand miner and mine solo. Congratulations. You are the money now.
#crypto #blockchain #solomining
34
130
540
53,704