Cryptoland
- Tweets 824
- Following 420
- Followers 38,838
- Likes 1,282
Yonatan Sompolinsky retweeted
Trapped by Design?
The Prisoner's Dilemma and Traditional Banking
The prisoner's dilemma is a thought experiment from game theory, formalized in the 1950s. Two suspects are arrested and held in separate rooms, unable to communicate. Each is offered the same deal:
If both stay silent (cooperate), they each get a light sentence.
If both betray each other (defect), they each get a moderate sentence.
If one betrays and the other stays silent, the betrayer walks free and the silent one gets the harshest sentence.
The payoff table looks something like this:
Look at it from one prisoner's point of view.
Whatever the other person does, betraying gives you a better individual outcome than staying silent.
If they stay silent, betraying gets you freedom instead of a year.
If they betray, betraying gets you 5 years instead of 10.
Betrayal is what game theorists call a dominant strategy and it's the better choice regardless of what the other player does.
The catch is that both players reasoning this way land in mutual betrayal... 5 years each, when mutual cooperation would have gotten them 1 year each.
Two individually rational choices produce a collectively worse outcome than the one that was actually available.
That gap between individually rational and collectively rational is the whole point of the dilemma, and it shows up anywhere people can't fully trust or coordinate with each other but share a common fate.
Why banking structures produce this exact shape
A modern bank doesn't hold your deposits in a vault.
Under fractional reserve banking, it keeps a fraction on hand and lends most of the rest out to mortgages, business loans, other depositors' withdrawals.
This works fine as long as depositors don't all want their money back at once. It depends on cooperation: everyone quietly trusting the system enough to leave their money in.
That's a real prisoner's dilemma, not just a metaphor for one. If you trust the bank and leave your money in, and everyone else does too, the system functions and you get your modest interest.
But if you suspect others might pull their money out, your individually rational move is to withdraw first... because the bank literally cannot pay everyone at once.
This is the mechanics of a bank run... each depositor's dominant strategy, once doubt creeps in, is to defect before the others do, and the collective result is a run that can take down a solvent institution.
It happened to regional banks as recently as 2023 (Silicon Valley Bank, Signature Bank), where uninsured depositors moved in hours, not days, because the individually rational move was obvious and everyone could see everyone else reasoning the same way.
I thought it would be handy to outline The Prisoner's Dilemma, before delving into @hashdag's prefered model, which is the Stag Hunt.
If you enjoyed this, you should definitely check out the full interview with @hashdag
piped.video/live/l_v3Mr5vigQ…
This episode is done on hard mode. No show notes, high speed traffic and on the fly repairs to the equipment.
Yonatan Sompolinsky/ @hashdag visited Romania for a short vacation and @Vladcostea did a road trip style interview with him whiledriving him to catch his flight.
He caught us up with everything he's been doing for the past year, from his philosophical obsession with stag hunts, to covenants on Kaspa kaspa:native and his admiration for Zcash.
Some highlights from the show
🌞ZK, born for privacy but lives for scaling
🌞The mental map: where Kaspa is unique
🌞Prisoner's dilemma vs stag hunt
🌞The Kaspa-Ethereum overlap
🌞Why DAGKnight survives a world war
piped.video/live/l_v3Mr5vigQ…
Made with AI
6
42
99
8,403
Yonatan Sompolinsky retweeted
Kaspa Covenants, Zcash, DAGs & Stag Hunts with @hashdag (Bitcoin Takeover Podcast S17 E36) nitter.net/i/broadcasts/1AKEmmEEX…
31
221
550
94,856
Yonatan Sompolinsky retweeted
The coordination and effort required to synchronize a complex upgrade across a truly decentralized network are a real challenge, and success is never a given. A good moment for a toast to all non-trivial life accomplishments
44
232
1,016
22,921
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.
65
296
987
56,501
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
72
339
15,882
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/…
52
316
906
146,142
Highly recommended, Covenant + SilverScript + Chess (!!) webinar @michaelsuttonil & @OriNewman
In 30 minutes @ discord.gg/kaspa meeting-room
spontaneous live session tomorrow with @iziodev on silverscript and complex multi-contract L1 flows, with chess being the primary demo/ showcase. deal?
16
173
582
28,634
Blessed be America my people, and Persia the work of my hands, and Israel my heritage.
Pax Persica Le'Chayim!
41
51
446
23,215
Yonatan Sompolinsky retweeted
counterpoint
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
11
4
59
19,835
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.
81
674
1,684
173,682
the bazaar is converging in dag mode.
@JeremyRubin heres your CULT OF THE COVENANT
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
123
482
24,525
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
336
953
38,366
medium.com/@hashdag/in-which…
@zkDragon endnote 3's for u, negative security
11
107
370
42,208
Yonatan Sompolinsky retweeted
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
469
1,274
156,738
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
28
140
514
57,997
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
40
244
20,771
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.
2
36
228
17,414