Michael Sutton

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: @michaelsuttonil/kaspa-covenants-toccata-hard-fork-outlook-a4d81a40900c" target="_blank" rel="nofollow noopener">medium.com/@michaelsutton…

Toccata hardfork activation testing in devnet earlier today showed very promising results with a smooth transition. Truly amazing work guys @michaelsuttonil @OriNewman @Max143672 @IzioDev! TN10 hf very soon

@smartgoo_ I owe you a good open-ended (..) answer here, just finalizing dev work and getting back to this important question

Here is a very open-ended question Could you elaborate from a higher level on the concept/power of state transition and what github.com/kaspanet/silve… enables vs. the standard "covenants" people typically think of Might be mixing up a few topics here but I think this might be something people overlook, feels like related but disparate paradigms

why I’m personally excited about Kaspa’s upcoming Toccata covenants - for the first time, I can build creative, complex apps directly over infrastructure I helped design and build - we designed under architectural constraints, but the result came out surprisingly expressive and powerful - Silverscript is cool as hell - I can literally open a *.sil file and write a complex contract that will be fully verified on Kaspa L1 - (nottoself: create a 10-minute video showing the building of such an app e2e) - I can design my own vaults and safeguards, and manage funds securely without risking a heart attack each time I touch a wallet - covenant ids, contract templates, and inter-covenant communication (ICC) feel like a new set of axioms, or a new algebra to work with and discover - sig verify from stack / sighash anyone-can-pay + covenant ids can allow interesting shared-state covenants (requires a non-consensus miner policy; kudos to @maxibitcat for pushing this line of thinking) - complex contract systems can be deployed in one spk hash. no storage rent, no deployment tax; users pay only the transient mass for tx data as they use it - as I’ve mentioned in the past, this becomes especially interesting for AI/agentic environments, where bots could cheaply create one-time agreements between themselves - I didn’t even mention based apps yet. That’s a whole vertical that isn’t ready for exploration yet, but will be very soon

@Themooseisloos5 @ltqcy111 he really did

@ltqcy111 Grok did good work here

“我正在尝试一条平行的轨迹，以在 kaspa 上启动协调市场。” 协调市场到底是什么？以下是我问GROK的解释和举例： 核心武器叫「Intendo（意图/条件承诺）」协调市场（CMs） 不是普通交易市场，而是一类围绕「绑定原语」构建的市场。 它的核心是 Intendo（条件承诺）： 「我会在 N 个人（或 N 美元资本）也做 X 的情况下，才做 X。」它不是空谈（cheap talk），而是加密签名、链上可执行的绑定承诺。 一旦阈值（threshold）达到，所有承诺原子执行（atomically）：大家同时行动，没有任何人能中途退出或被甩下。 支持私密累积（opaque accumulation）：你看不到别人承诺了多少，避免被狙击或提前暴露。 支持资本多路复用：同一笔钱可以同时承诺多个市场，谁先触发就用谁。 支持可组合（composable）：一个市场的输出可以直接成为另一个市场的输入，像乐高一样拼接。 这套机制让「猎鹿博弈」的（stag, stag）均衡变成现实，而不需要任何人牺牲个人理性。3. 工作流程（三阶段：Stag → Pack → Hunt）Stag（发现猎物）：有人（或 DAO）在链上发一个「Hunt」——定义目标、阈值、执行逻辑。例如：「迁移 5000 万美元流动性到 Kaspa，如果达到就全部执行。」 Pack（集结狼群）：用户悄悄提交 Intendo（加密签名承诺）。承诺可以是匿名的、私密的，持续累积直到阈值。 Hunt（集体狩猎）：阈值一到 → 智能合约原子触发，所有人同时行动（迁移、支付、启动平台等）。无人能抢跑或落单。 整个过程无需中心化平台，完全依赖 Kaspa 的实时高吞吐量 blockDAG（目前已达高 BPS，未来目标 100 BPS+），实现真正的实时、去中心化执行。4. 和「预测市场」（如 Polymarket）完全不一样预测市场：你押注「某事会不会发生」，猜对赚钱。纯投机。 协调市场：你承诺「某事发生后我才行动」。实际执行集体行动，不是赌结果。 例子 1：DeFi 流动性迁移（Kaspa 最直接的应用）当前问题：大量流动性卡在老链（如 BNB Chain 上 57 亿美元），大家想搬到 Kaspa（速度快、费用低、去中心化），但没人敢第一个搬——怕新池子没流动性，自己被套利或滑点吃掉。 Intendo 解决方案：每个 LP（流动性提供者）提交承诺：「如果总迁移资金达到 500 万美元，我就把我的 100 万美元也迁到 Kaspa。」 不同人设不同阈值（5M、50M、500M 美元）。 同一笔钱可以同时承诺「迁 Kaspa」和「迁 Solana」，先达标先执行。 结果：阈值一到，所有 LP 的资金同时原子迁移，新池子瞬间就有足够深度，大家一起「猎鹿」成功，无人落单。 这就是 Michael Sutton 说的「并行路径」：不用等 BD 团队一个一个拉项目，而是让流动性自己协调搬家到 Kaspa。 例子 2：新内容平台/社交平台启动场景：无数家长讨厌 Netflix/Disney+ 的内容，想换新平台，但新平台没人就活不下去。 Intendo 解决方案：发一个 Hunt：「如果有 100 万人承诺每月付 10 美元订阅费，我就启动新平台。」 用户提交 Intendo：「我会在 100 万人也承诺的情况下，每月付 10 美元。」 阈值达到 → 平台原子启动，订阅费同时到账，平台直接有用户、有资金、有内容创作者。结果：创业者不再靠 VC 烧钱，而是靠预先绑定的用户群直接起飞。 例子 3：政治/社会集体行动（带隐私保护）想支持某个候选人或发起抗议，但提前公开会被针对。 用 Designated Verifiable Proofs (DVPs)：你的 Intendo 可以私下发给可信朋友验证（证明你真的承诺了），但对外完全不可证明（deniability）。 阈值达到后原子执行（投票、捐款、集体迁移等）。

for some narrow usecases you do, eg kickstarter but to the best of my understanding this is part of the point, that this is a possible unique value proposition for crypto. I really recommend watching the talk youtu.be/VIZGKoIaGR0?si…, it’s a powerful address. fwiw I don’t claim to be the best representative of this initiative, I’m an observer of this like all of you

@michaelsuttonil if this idea is so good how comes there isnt any (atleast big/known) centralised existing coordination market

“I am attempting a parallel trajectory to bootstrap coordination markets on kaspa”

@LNiouh nop

@michaelsuttonil Polymarket

@picaye I think grok is doing a nice job here x.com/i/grok/share/9…

@michaelsuttonil Ok, so kind of a new type of lending protocol with fancy rules? (Trying to simplify the complex language). Tbh super complex written. How does help people make money? Simple as that. Humans are majority self interest driven. No entry barriers, good upside and they‘ll come

@picaye coordination markets ≠ prediction markets see hashd.ag/staghunt/ and the Oxford talk on youtube

@michaelsuttonil Assuming this means a prediction market. If people see they can make more money there than someone else they will come. They won’t care if underlying tech is called kaspa or something else

@Crypto_Ding0 @tamy_mammi a few more links. validateOutputState builtin documentation: #L32" target="_blank" rel="nofollow noopener">github.com/kaspanet/silve… covenant macros spec: github.com/kaspanet/silve…

of course you can. you build the output preimage in-script and verify it hashes to the output spk. that’s part of the magic the compiler provides. see both links here: #L2001" target="_blank" rel="nofollow noopener">github.com/kaspanet/silve… #L5300" target="_blank" rel="nofollow noopener">github.com/kaspanet/silve… on a higher level the compiler provides covenant macros that automate even this part

@Radical_Ed_Bad @maxibitcat @_fnal @Krok13236 looking forward to this one @coinathlete :) I also owe you another answer re documentation @Radical_Ed_Bad. I didn’t forget

@maxibitcat @michaelsuttonil @_fnal @Krok13236 hey broski, simplify (without omitting granularity) the discussion please.

@BankQuote I find it funny when ppl tell me “crescendo brought no adoption, so why would toccata be different?” Similarly to what you wrote, crescendo widened and accelerated the pipes, so to speak, so that toccata could bring more utility through them.

Crescendo proved that Kaspa could accelerate Proof-of-Work without abandoning the properties that make Proof-of-Work matter. It was not merely a “faster blocks” upgrade. It was the moment Kaspa moved from 1 BPS to 10 BPS, after years of Rusty Kaspa optimization, network testing, mempool refinement, node-performance work, and ecosystem coordination. Crescendo expanded the clock. It made the base layer more frequent, more parallel, and more useful without turning Kaspa into another committee-driven chain pretending that synthetic speed is the same thing as decentralized settlement. Toccata is different. If Crescendo was about proving that Kaspa can scale time, Toccata is about proving that Kaspa can constrain state. Covenants, extended script logic, covenant IDs, zk verifier support, and sequencing commitments are not random feature additions. They are the first serious primitives for programmable value on a high-frequency Proof-of-Work BlockDAG. This is not Ethereum-style global-state bloat stapled onto Kaspa. It is a more disciplined path: local UTXO computation, enforceable spending rules, native covenant flows, and zk-assisted systems that can follow L1 sequencing without forcing the base layer to replay every computation. That distinction matters. Crescendo made Kaspa’s settlement engine breathe faster. Toccata begins teaching that engine how to enforce more complex conditions while keeping the foundation lean. One upgrade increased the cadence of consensus. The next upgrade expands what consensus can safely commit to. This is why Toccata should not be reduced to a “smart contract upgrade.” That undersells the architecture. The deeper story is that Kaspa is moving toward programmable Proof-of-Work without sacrificing the mechanical honesty of its base layer. Crescendo accelerated the public clock. Toccata begins turning that clock into a programmable coordination surface.

@hashdag @KaspaSilver That’s fair. Indeed it was all framed under covenants++ from the start

Sure tho I consider based apps a natural extension and usage of (what you called pure) covenants: if you impl covenants seriously rather than thru op_cat workarounds, you unlock their programmability potential by extending the txn commitment scheme to allow the covenants to govern based logic. This extension is straightforward, requires no research / theoretical novelty, and is highly useful even if it's the end form of programmability on the layer (ie no further syncompo/vprogs solutions ever develop). --- @KaspaSilver There's nothing wrong with implementing an EVM L2 as an interim solution, but this requires an interim agenda. If in contrast a project aims to become the main gateway for builders on our money network, then our hard-fought efforts - and the prices we paid - for decentralized fairlaunch go to waste. Such a takeover is far from inevitable, and fwiw I know of no other crypto project that had to cope with independent L2 attempts that early in its growth efforts (to be clear I never attribute to malice that!). To spell it out further: If an L2 has an interim agenda, or at least focuses on its own bizdev rather than general builder devrel -- ie, it uses L2 tech as a enabler rather than as an value prop -- then the risk of fragmentation is restricted to liquidity and standards, which is tolerable and solvable down the road. I wouldnt endorse it but I would get it, and I'd respect those who dont give an f about my endorsement

"User-friendly and works now usually beats theoretical superiority until the superior thing actually works better." Took this quote from grok when trying to gather all my thoughts together on the future path for kaspa:native . I am going to just brain dump to see if someone can find what I am missing or just agree with my take on things. Lost focus on building one thing like vprogs was inevitable to happen. There is no way to stop the fragmentation of devs, funding, and efforts going all over. This is because the nature of this market is free and users want to operate for profit. No one wants to lose. All in focus on cores desires for smart contract like programability is high risk high reward when Kaspa does not have forever to just be on the sideline trying to attract users with "hey look whats coming." What is a bit unfortunate is seeing core shift away from trying to market Kaspa as being money to solely view Kaspa as this MoE powerhouse to allow you to do many things. I get the shift but the problem is the "many things" are simply not many. I could be wrong for this feeling but this is simply what I am getting. Kaspa has a narrative crisis that is for sure but I think the biggest mistake is to try and leave the money narrative all together. I simply point this out cause I fear I am seeing signs of abandonment of this all together. Giving humanity a better Money IS the biggest market. This is the biggest way I can onboard any noob into crypto with Kaspa. The % of people not in crypto is greater than the % of people in it and it seems efforts are being made to try and steal users from everywhere else that are already here and hope it happens. I think Kaspa main efforts should be focused on no coiners. This means developing to give these users a way to live on a Kaspa standard. This also means making apps to easily utilize Kaspa and especially bring native stablecoins to it. Kaspa for ultimate storage, stabecoins for living day to day while still living on the Kaspa network at all times. Hopefully Toccata ships and we get this moving along quickly. When it comes to L2s and bringing basically all ETH offers to a wonderful base layer like Kaspa I repeat what I stated above. User-friendly and works now usually beats theoretical superiority until the superior thing actually works better. Kaspa is money and its the first time money will be programmable to scale at internet speeds while keeping true to Bitcoin level properties of security and decentralization. This keeps users self-sovereign and truly rids the reliance of the middle man.

a bit more context: besides pure covenants, based zk apps were obviously also a focus point in the development of toccata, but no special effort was made towards vprogs. ie we introduced opseqcommit, zk opcodes, kip21, canonical bridging pocs etc. but these focus on standalone based apps, without the crucial syncompo hard-to-achieve-by-definition property. this choice and focus shows inherent pragmatism in how kas rnd operates, optimizing for the faster feedback loop path

The upcoming upgrade was chosen without regards to vprogs, and no meaningful effort was made to optimize it for vprogs (definitely nothing delaying Tocatta by more than a few days). Tocatta is a principled implementation of bitcoin-originating covenants which, if ever implemented in bitcoin, would use the op_cat workaround. It is the default method to introduce programmability into a thin verification-oriented L1 to preserve its decentralized lean value prop. vprogs are outside core’s focus precisely because we are optimizing for usability over theoretical superiority. I hope this helps you and grok update your premise. (BTW counterexample to your claim about inevitability of fragmentation: Solana)

@1998_yankees yes, you can easily implement fallbacks, incremental release of funds through time etc etc. basically nearly every simple rule you can think of

@michaelsuttonil Someone teach me: once this launches can I write a contract for my own holdings to add an extra layer of security beyond just saving/protecting my seed phrases / devices?

@green_pasturz @richandpoor002 thx man, I appreciate it

@michaelsuttonil @richandpoor002 Thanks for this clarification AND for all your hard work & dedication to KASPA Michael! All of us in the community appreciate every post you make & appreciate you keeping us in the loop brother. Proud of you, Yonatan & all the devs for going deep on KAS. Gods speed.

yes, and there are two ways (where one of them is not even new): 1. (the new one) sig verify from stack: can be used to form a signed msg in-script such that the signed msg commits to the cov id of the input 2. sighash anyone-can-pay: allows having another input with classic schnorr/ecdsa signature that only binds to that input’s utxo

@michaelsuttonil @_fnal Oooh ok I didn't catch that signature over cov id was already implemented in toccata, that's pretty cool!

I think the grander ideas/apps/use cases should mostly be built through the based zk apps route. still, pure covenants will enable a multitude of smaller use cases, and together those can be significant for adoption. my own excitement comes less from having one specific app category in mind, and more from seeing the landscape take shape early and from very close up, while understanding what these primitives can express. my mission is to keep creating and showcasing that expressive power, so we get to wider adoption sooner rather than later.

@michaelsuttonil What kind of apps do you want to see built? Anything specific that you think could bolster adoption?

@_fnal some if it is possible post-Toccata. as described here x.com/michaelsuttoni…

x.com/maxibitcat/sta… Kaspa already fixes a bunch of real issues with L1 programmability today (covenants, Silverscript, contract templates, ICC, etc.). The next step = shared‑state covenants where miners get concurrency but can’t hijack your payload = is a future upgrade still in R&D. So: Now, strong foundations + safer covenant design. Future = the piece that truly locks Kaspa into “state‑of‑the‑art L1 DeFi” once that pattern ships. What I learned about Kaspa’s “security engine” (from talking with devs, not marketing/Influencer MoonBoys) They’re explicitly aware of MEV / miner‑level theft risks for shared‑state covenants and aren’t pretending it’s magically solved today. Bit Cat described a concrete R&D pattern: when you spend a shared covenant, your tx fully signs all outputs and non‑shared inputs, but for the shared covenant input it signs only the covenant ID, not a specific UTXO. That lets miners/consensus choose which covenant UTXO to pair (for concurrency), but they cannot change where the money goes without breaking your signature. If they implement this, the security boundary becomes: Miners can decide which shared UTXO is used, but they cannot hijack your payload by editing your tx and redirecting funds. The only remaining adversarial space is racing and ordering between multiple valid updates, not theft via tx mutation. Bit Cat confirmed this is the design he has in mind, & also said it’s not in the next update yet, But still an idea up for discussion. For me, that’s enough I know what Kaspa can and can’t guarantee today. I know the exact invariant they’re aiming for to make L1 DeFi truly state of the art. I’ve seen the devs be straight about reality vs future design = no “trust me bro,” just clear boundaries. @maxibitcat & @michaelsuttonil Big Respect on Transparency

I did not follow the full convo, but a few clarifications came to mind from the parts I did read. 1. @maxibitcat’s idea of “ordering of this type of transaction only at merge time, using some randomness coming from the whole round” obviously requires a consensus change. btw I’d apply it to all txs in order to reduce MEV also for based apps etc. 2. there is a ladder here: step 1 (what I referred to in the main post): non-consensus change that can be implemented post Toccata activation: accept the tx to the mempool without resolving the shared-state UTXO (call this abstract entity X). when building the block template, resolve to the most updated UTXO of X. requires indexing the UTXO set by covenant ids. con: parallel miners can resolve different txs to the same UTXO so some of them will not count (effectively serializing access to X to 1 per round). step 2: a future consensus change that resolves X at block merge time according to the final mergeset order. as I’ve told bitcat, this would break fundamental assumptions of the UTXO model and I highly doubt we can do this. eg it breaks the linkage between a tx id and the UTXOs the tx spends (in graph terms it breaks the hashable edge structure of the tx DAG). step 3 (independent of 2): randomize the per-round order and don’t give the merging block full control. relevant to any MEV-hardness claim over Kaspa. 3. interestingly, step 1 does not allow easy front-running and sandwiching. that’s bcs Kaspa rules forbid chained txs within the same block, so the miner can’t have both his tx and the attacked tx in his block (the latter must use the output of the earlier as input).

@_fnal @michaelsuttonil Yes this is what I had in mind and proposed in the r&d chat. It's not in the next update though, it's still just an idea up for discussion. That would allow native L1 DeFi which would be pretty cool imo.