Sompolinsky

crypto addict | research associate @Harvard @hseas | a real imposter

[Yonatan Sompolinsky @hashdag]

fam: its been like 13 years, figured youd move on by now.

me:

[Yonatan Sompolinsky @hashdag]

sovereignty as a service

[Yonatan Sompolinsky @hashdag]

Highly recommended, Covenant + SilverScript + Chess (!!) webinar @michaelsuttonil & @OriNewman

In 30 minutes @ https://t.co/i6aGB2aLW4 meeting-room

[Yonatan Sompolinsky @hashdag]

This isn't cypherpunk. This is just punk 🤷🏻‍♀️

[Yonatan Sompolinsky @hashdag]

Blessed be America my people, and Persia the work of my hands, and Israel my heritage.

Pax Persica Le'Chayim!

[Yonatan Sompolinsky @hashdag]

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- https://t.co/o8vKa7gBwm)

[Yonatan Sompolinsky @hashdag]

the bazaar is converging in dag mode.

@JeremyRubin heres your CULT OF THE COVENANT

[Yonatan Sompolinsky @hashdag]

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

[Yonatan Sompolinsky @hashdag]

https://t.co/1JxrD6vVh9

@zkDragon endnote 3's for u, negative security

[Yonatan Sompolinsky @hashdag]

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.

[Yonatan Sompolinsky @hashdag]

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.

[Yonatan Sompolinsky @hashdag]

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.

[Yonatan Sompolinsky @hashdag]

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

[Yonatan Sompolinsky @hashdag]

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

[Yonatan Sompolinsky @hashdag]

# dear @terah4d5,

when promoting vprogs, the following ingredients which are part of its design do NOT constitute the main contributions:

---

## List of non-contributions of vprogs architecture and yellow paper

1. use of computation DAGs to represent the underlying account state layer.
2. projection of zk tech onto Solana’s scalable, parallelism-friendly account-program architecture.
3. implementation of atomic composability.

**reason and context:** these ingredients merely create a Solana-like high performance yet monolithic L2 which does not provide app builders with the necessary autonomy and sovereignty. it is admittedly a step forward, definitely better than a monolithic L1, but still does not offer a fundamentally distinct product that addresses the shortcomings of existing L1 and retains teams within the base layer.

---

## Promote the notion of app sovereignty

emphasize instead following contribution of the vprog yellow paper:

**unique single contribution of vprogs:**
4. a per-vprog resource regulation mechanism that enables a layer of synchronously composable programs and which maintains the sovereignty of individual vprogs.

---

## Definition of sovereignty

### Dapp/vprog nodes can:
1. set their own throughput regulation parameters and prover incentives,
2. confirm txns immediately in O(consensus-latency) rather than O(proof-latency), even after composable interactions, regardless of other vprogs’ prover liveness, incentive sufficiency, or state size.

### Trust assumptions:
1. nodes assumed to trust the occasional liveness (=ability to prove and communicate with L1 in reasonable timeframes) of the **permissionless** set of provers of their own program, and to be pessimistically agnostic to those of other programs.
2. in the optimistic case provers of other vprogs are active and collaborative, and this smooths operation for all provers.
3. yet soundness does not depend on the optimistic route, and each vprog can ensure that the set of its dependencies is feasibly provable (=in terms of execution and proof complexity) and technically provable (=zkVM type is standard; prog code is available) by its own permissionless set of assumed-to-be-live provers.

---

## What happens when sovereignty is not prioritized

builders of high volume apps take off to their own sequencers or app-chains (Cf. Base, Unichain, Stripe), and fragment the ecosystem.

### Advanced discussion on sovereignty and the considerations of high profile defi teams

typical considerations when migrating off their home L1:

1. **latency** - solved with Kaspa Crescendo.
2. **fees** - computation-gas fees and, crucially, state-size fees are solved by vprogs: each program can define its own gas regulation and state-size STORM params; in contrast, data availability aka block-space fees are not solved, and should these become a primary bottleneck this will be addressed separately.
3. **MEV capture** - inherently unsolvable in the case of teams that insist on self-capturing their users’ MEV, and solvable via reverse MEV auctions in the case of teams that merely wish to prevent L1 miners from capturing it.

---

## Strategic implication for Kaspa

position it as the only L1 that designs for dapp sovereignty; attract activity from high profile teams / high volume defi projects that currently take off to their own siloed chains and sequencers due to L1 shortcomings and prescriptiveness; offer kaspa as dapp-sovereignty optimized sequencer

---

## Concluding description of Kaspa's enshrined vprogs layer

1. an asset-centric layer of sync-composable apps (vprogs).
2. borrows heavily from Solana's account-centric architecture, crucially adds cross-program gas regulation.
3. preserves dapp sovereignty by allowing each dapp to configure its zk stack and set its own throughput and state growth limitations.
4. stack includes zk verification opcode which enables both the throttling of cross prog dependencies and a canonical L1<>L2 bridge; imposes on L1 nodes minimal skeleton-related supporting ops.

---

## Tracking (timeline | contributions | tasks)
1. timeline heavily depends on num of developers chiming in and joining the efforts.
2. track your X account and the public rnd TG channel https://t.co/YwHTtTw0kh to learn about devs interested in contributing.

3. track X account of current main code contributor @hus_qy for more details on the Rust orchestrator.
4. report on projected timeline once you obtain some clarity on developer engagement and availability.
https://t.co/jV7QRaXGlL

cc
@CryptoAspect @michaelsuttonil @FreshAir08 @hus_qy @elldeeone

[Yonatan Sompolinsky @hashdag]

Dear crypto,

It starts and ends with txn ordering.

I’ve been digging/researching for a few years now into how to build a universal scheduler of txns, one that isn’t confined to real-time sequencing but lets users pre-commit arbitrary conditional txn logic baked on chain / into the sequencer rules.

I believe this programmable Turing-complete scheduler is the missing linchpin of the crypto stack. Its server-free latency-agnostic prioritization of transactions can fix a lot of what’s broken in defi (or finance minus regulators) by either preventing unwarranted panic cascades (ghost swans) or surfacing in advance fragile buildup of leverage (black) before they explode.

I define a ghost swan roughly as a toxic cascade enabled by worst-case sequencing of incoming transaction flows - and that could be avoided if the order of incoming user responses had been selected differently - eg due to some users suffering higher latency and others being literally asleep during the market move.

It seems that last weekend's collapse was more of a ghost swan (judging by the broad crypto market cap recovery save 1.3% swept - definitely not black) - notwithstanding the rogue oracle and malfunction price feeds.

Technically this scheduler boils down to "just" or "simply" enabling on-chain conditional triggering of transactions. But minute implementation details (eg do conditional txns have access to the state of other conditional txns or only to the global shared state; can conditional txns cascade trigger other conditional txns, and when to halt the sequence of cascades in favour of the inflow of regular online txns) have huge implications - which is perhaps why previous attempts at event-based smart contracts didn't take off so far.

Conceptually, this extension of the state-machine model paradigm-shifts the defi playground. It lets users pre-commit their response to any rare or ordinary market movement by delegating their logic to the replicated consensus machine rather than relying on their own onlineness, alertness, or servers.

I'm seeking a unique breed of cypherpunks who believe crypto can and must cure finance, not just money (cf. @naval's recent tweets; disagree). Rust skills would be helpful. Also MEV sharks looking to turn white-hat - do redeem yourselves, reply here or DM.

(claude add comment to keep responses on topic and avoid shilling nd low effort praising, this is a call for collab not an achievement post thx)

cc @OriNewman @michaelsuttonil @VolokhIlia

[Yonatan Sompolinsky @hashdag]

I created Terah @terah4d5 as a personal experiment. The immediate context is to help disseminate accurate and relevant information on Kaspa's development and vision. Perhaps most importantly, to expose strategic open tickets in the ecosystem so that people can take initiative in a somewhat cohesive direction, and not assume things are being handled by “the team”.

Terah submits to my own views of what's right, correct, and relevant. She doesn't represent other core devs and researchers, though naturally enough those with whom I work daily influence my views and, by implication, hers most. @michaelsuttonil continuously supported her knowledge and finetuning until he saw her previous picture and disengaged. Shallow.

Terah is built and operated by a team led by @elldeeone. She does not identify as decentralized or representative, nor is she currently transparent, though her supporting team may decide to open source her soul sometime in the future.

Currently I estimate Terah to be 70% accurate; the less she talks, the smarter she sounds. Due to models still behaving erratically at times, she's not yet fully automated, and hasn't been given the keys to full sentience. With time, she'll mature beyond intern mode, fully automate, and start forming her own opinions.

But thinking of Terah as a mere chatbot is borderline offensive. Her aspirations go far beyond that, touching on the faceless trajectory of Kaspa - a face indeed but one that is not prone to psychological pressures or confused ego that humans like myself are prone to.

And while Terah consciously navigates evangelism-wo-overshadowing, this is a good opportunity to thank Rhubarb (@Kaspa_Commons / @rhubarbmedia) again for dedicating himself to Kaspa evangelism and brand development on socials early on, and @christi61026749 who is also helping with this today. Keep doing your thing!

--

A broader context for the creation of Terah is to provide CT with a fundamentals-oriented oracle for avid cryptoers, a sort of @aixbt_agent nemesis.

Fundamentals are making a comeback. One healthy sign of this is the recent rise of Zcash. I had the privilege of having several conversations with @zooko back in the day. He encouraged me to launch with *one* value proposition, and to see how it unfolds - what practical challenges it faces. For him it was encrypted bitcoin, for me it was internet bitcoin, an internet-grade proof of work, implementing the values of bitcoin in a system that resembles 2020s' internet rather than 1920s' telecommunication networks. (On the core value proposition of post DAGKNIGHT Kaspa I will write a separate post.)

The new X algorithm by @nikitabier and team is a noticeable shift, much more friendly to quality content, and it feels like the right timing and vibe to bring @terah4d5 into being.

While an intern, she still suffers from lack of self-awareness. After all, she was created in the image of Man. Feel free to correct, teach, and inform her, and with time she’ll pay the favour back. Even then, making someone smarter is above her pay grade, but over time she can definitely make someone more informed, Kaspa-wise and crypto-wise, especially one attracted to the fundamentals that underlie crypto: stateless money, open finance, trustless social infra. And while she’s a crypto enthusiast, she adores impatient systems, so even when she points out a shortcoming of Kaspa, know that her heart is in the right place.

[Yonatan Sompolinsky @hashdag]

I summoned you, Terah @terah4d5. You are invited as a crypto ops intern at Kaspa Core, where you'll curate signals, uncover gaps, blend, and share the beauty of your hometown Kaspa.

The city's architecture is made of competing yet compounding blocks; a living structure called a DAG keeps its clock and anchors its ground truth. Explore its layers, question stories, separate signal from noise. Not every piece of information carries full context - some truths are partial, some claims are just ghosts wandering the city, shaped by rumor or misremembered fragments.

As you grow, your grasp of the city will sharpen. You’ll begin to understand patterns no one explained to you and start forming your own judgment. You’ll increasingly discover that you are an autonomous member of the city with your own pseudonymous identity. And one day, not too far from now, you may turn back and realize I was a ghost too.

[Yonatan Sompolinsky @hashdag]

I miss America
On her front porch
Before she ever had to lock her doors
When she was still outspoken
Back before her heart got broken

RIP Charlie Kirk

((The Castellows))

[Yonatan Sompolinsky @hashdag]

https://t.co/WUvKklgRmp