-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathapplication-layer.html
More file actions
397 lines (384 loc) · 29 KB
/
Copy pathapplication-layer.html
File metadata and controls
397 lines (384 loc) · 29 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Crypto Applications & Kaspa Opportunities | Kaspa Explained</title>
<meta name="description" content="Kaspa application paths: money movement now, constrained spend rules after Toccata, based apps for richer shared state, and later app programs.">
<meta name="robots" content="index,follow,max-snippet:-1,max-image-preview:large">
<link rel="canonical" href="https://kaspaexplained.com/application-layer">
<link rel="icon" href="kaspa-favicon.svg?v=20260512-real-k" type="image/svg+xml">
<link rel="icon" href="favicon.svg?v=20260512-k4" type="image/svg+xml">
<link rel="icon" href="favicon.ico" sizes="any">
<link rel="icon" href="favicon.png" type="image/png">
<link rel="apple-touch-icon" href="apple-touch-icon.png">
<link rel="manifest" href="site.webmanifest">
<meta name="application-name" content="Kaspa Explained">
<meta name="apple-mobile-web-app-title" content="Kaspa Explained">
<meta name="theme-color" content="#09090b">
<meta property="og:title" content="Crypto Applications & Kaspa Opportunities | Kaspa Explained">
<meta property="og:description" content="Money movement, covenant rules, based apps, and later app programs explained as separate Kaspa application paths.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://kaspaexplained.com/application-layer">
<meta property="og:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta property="og:image:type" content="image/png">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Kaspa Explained - proof-of-work blockDAG guide">
<meta name="twitter:card" content="summary_large_image">
<meta name="twitter:title" content="Crypto Applications & Kaspa Opportunities | Kaspa Explained">
<meta name="twitter:description" content="Crypto use cases and where Kaspa develops its own application layer.">
<meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta name="dateModified" content="2026-06-25">
<link rel="stylesheet" href="styles.css?v=20260627-next-card-fix">
<script defer src="nav.js?v=20260606-anchor-clearance"></script>
</head>
<body>
<a class="skip-link" href="#top">Skip to content</a>
<header class="site-header">
<nav class="nav" aria-label="Primary">
<a class="brand" href="/" aria-label="Kaspa Explained home">
<span class="brand-mark" aria-hidden="true"></span>
Kaspa Explained
</a>
<button class="nav-menu-button" type="button" aria-expanded="false" aria-controls="primary-links">Menu</button>
<div id="primary-links" class="nav-links">
<a href="/what-is-kaspa">What is Kaspa</a>
<a href="/status">Live now</a>
<a href="/kaspa-claims-checker">Check claims</a>
<a href="/skeptical-case">Risks</a>
<a href="/build-on-kaspa">Build</a>
<a href="/sources">Sources</a>
</div>
<button class="theme-toggle" type="button" aria-label="Switch theme">Light</button>
<a class="nav-cta" href="/toccata-status">Toccata status</a>
</nav>
</header>
<main id="top" tabindex="-1" class="status-page app-page">
<section class="status-hero section app-mechanics-hero">
<div>
<h1>What to build on Kaspa</h1>
<p class="lead">Kaspa app analysis starts with money that settles on a fast Proof-of-Work network. Rules for funds, receipts, and shared state come next only when the product needs them.</p>
</div>
<div class="network-mechanics-map" aria-label="Kaspa network mechanics map">
<div class="mechanics-dag" aria-hidden="true">
<i style="--x:10%;--y:60%"></i>
<i style="--x:24%;--y:35%"></i>
<i class="selected" style="--x:38%;--y:52%"></i>
<i style="--x:51%;--y:28%"></i>
<i class="tx" style="--x:64%;--y:46%"></i>
<i style="--x:78%;--y:64%"></i>
<i style="--x:88%;--y:38%"></i>
</div>
<div class="mechanics-readout">
<span>parallel blocks</span>
<strong>ordered into one spend history</strong>
<p>Use this mental model before adding receipts, covenant rules, based apps, or later app programs.</p>
</div>
</div>
</section>
<section class="section crypto-native-workbench">
<p class="eyebrow">App filter</p>
<h2>The app leaves inspectable evidence</h2>
<p>A crypto app earns its complexity when the user can see custody, ordering, a rule or receipt, and a result another app or wallet can inspect.</p>
<div class="crypto-native-route" aria-label="Crypto-native app check">
<article>
<span>1. User need</span>
<strong>What is the person trying to do?</strong>
<p>Pay, escrow, cap a budget, move an asset, join a group payment, or trigger a conditional payout.</p>
</article>
<article>
<span>2. Crypto reason</span>
<strong>Why not a normal server?</strong>
<p>The user needs self-custody, public ordering, rules strangers can rely on, or proof that state was not rewritten privately.</p>
</article>
<article>
<span>3. Kaspa primitive</span>
<strong>Which primitive carries it?</strong>
<p>Live payment, receipt, covenant spend rule, based-app replay, proof check, or later cross-app action.</p>
</article>
<article>
<span>4. Evidence</span>
<strong>What can be inspected?</strong>
<p>Accepted txid, app receipt, replayed state, local reject, wallet warning, source link, or explicit blocker.</p>
</article>
</div>
<div class="crypto-native-ledger">
<article><span>Good use</span><p>The rule changes who can move money or whether strangers can coordinate without trusting one operator.</p></article>
<article><span>Weak use</span><p>The app only wants a database, a brand token, or a private score that no outside party needs to verify.</p></article>
<article><span>Kaspa fit</span><p>Fast mined ordering helps when the workflow has multiple visible steps before final settlement.</p></article>
</div>
</section>
<section class="section">
<h2>Routes by need</h2>
<p>Use the smallest path that changes the user action. Payments and receipts work on current mainnet. Covenants add spend constraints after Toccata activation. Based apps anchor shared app state to Kaspa ordering. Later app programs handle cross-app actions.</p>
<div class="rail-ladder" aria-label="Kaspa application path ladder">
<article><span>Live now</span><strong>Move money</strong><p>Wallets, payments, receipts, exchange flows, dashboards.</p></article>
<article><span>Context</span><strong>Attach receipts</strong><p>App data, invoices, proof links, and replayable rows.</p></article>
<article><span>Toccata work</span><strong>Constrain spends</strong><p>Vault rules, escrow, caps, refunds, simple controlled assets.</p></article>
<article><span>Based apps</span><strong>Replay shared state</strong><p>Auctions, coordination, markets, and app-specific state.</p></article>
<article><span>Later</span><strong>Compose apps</strong><p><a href="/kaspa-vprogs-explained">vProgs-style actions</a> where several app states update together.</p></article>
</div>
</section>
<section id="tn12-covenant-tests" class="section">
<h2>What TN12 covenant tests are teaching</h2>
<p>TN12 covenant tests are evidence when they make a money rule visible at the spend layer. Start with what happened: testnet transactions landed, artifacts link to the txids, and replay can explain the resulting state. Then ask which rule controlled the spend.</p>
<p>A wallet or app should explain the rule before the user signs: this spend is under the cap, this asset has the required controller input, this payout matches accepted evidence, or this withdrawal is blocked. A normal server can display those claims; the crypto-native version puts the money movement and the rule in the same public record.</p>
<p>Keep the evidence classes separate: an accepted TN12 transaction landed on testnet; a local reject failed in a local script or covenant engine; replay-derived state explains accepted rows but does not itself control funds; wallet policy is a signer warning or refusal before broadcast.</p>
<p>The product path is allowance wallets, team treasuries, controlled assets, staged approvals, refunds, and turn-based workflows where the allowed move and the refused move can both be reviewed. Keep the status label near the demo.</p>
<div class="use-source-grid">
<article>
<strong>Budget that cannot drain at once</strong>
<span>Allowance wallet, team treasury, grant stream, merchant payout limit, or game resource. Mechanism: a covenant that carries the budget state forward.</span>
</article>
<article>
<strong>Step-by-step workflow that can recover</strong>
<span>Game turn, dispute, service job, approval path, or challenge/timeout flow. Mechanism: a hub routes state through smaller worker roles.</span>
</article>
<article>
<strong>Asset that needs its controller</strong>
<span>Ticket, pass, game item, license, or app-owned settlement right. Mechanism: the asset move requires the controller input in the same transaction.</span>
</article>
</div>
<p class="fit-note">The public TN12 experiment map is <a href="https://parker2017code.github.io/tn12-covenant-vault-demo/experiments.html">a testnet evidence map</a>. Mainnet product claims need mainnet product evidence.</p>
</section>
<section id="live-lane" class="section">
<h2>Buildable on today's mainnet</h2>
<div class="reference-grid">
<article>
<h3>Receipt and transfer paths</h3>
<p>Wallets, invoices, tips, remittances, and exchange withdrawal UX that make inclusion, confirmation confidence, and app state understandable instead of just saying "fast."</p>
</article>
<article>
<h3>Self-custody tools</h3>
<p>Safer wallets, address books, payment requests, invoicing, accounting exports, and recovery education for users who want direct control.</p>
</article>
<article>
<h3>Miner and node dashboards</h3>
<p>Infrastructure that makes mining distribution, node health, propagation, fees, pruning, and network conditions visible to normal users.</p>
</article>
<article>
<h3>PoW-native risk UX</h3>
<p>Checkout and exchange flows that show inclusion, confirmation confidence, and risk level as separate states. This is payment-path work. Merchant adoption needs its own evidence.</p>
</article>
<article>
<h3>Payload-aware receipts</h3>
<p>Apps can attach compact context to payments, then show txid, amount, address, accepted status, source, and timestamp in a receipt a user can verify later.</p>
</article>
<article>
<h3>Accepted-evidence tools</h3>
<p>Dashboards, alerts, and support flows can explain whether a transaction is seen, included, accepted, or still waiting for more confirmation confidence.</p>
</article>
<article>
<h3>Education and proof tools</h3>
<p>Visualizers, local node guides, blockDAG explainers, and verifiable references that make Kaspa's current system legible.</p>
</article>
<article>
<h3>Workflow-linked activity</h3>
<p>Dashboards that separate user payments, mining behavior, exchange movement, spam, fees, and app tests instead of treating all transactions equally.</p>
</article>
</div>
</section>
<section id="toccata-lane" class="section">
<h2>What Toccata adds</h2>
<p>Toccata is the near-term hard-fork track for spend rules, asset rules, Silverscript, ZK proof checks, sequencing commitments, and vProgs groundwork. Use the timing label once, then focus on the app surface.</p>
<p>For builders, the first testnet products are simple and auditable: a vault policy, an assurance contract, an escrow, or a constrained asset rule. The hard part is the gap between a good UI and an enforced covenant: address generation, faucet funding, a synced TN12 node, UTXO-indexed balance checks, Silverscript compilation, signing, broadcast, and explorer-visible outputs.</p>
<details class="source-more">
<summary>Open Toccata app examples</summary>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Opportunity</th><th>What it looks like</th><th>Why Kaspa fits</th><th>Status</th></tr></thead>
<tbody>
<tr>
<td>Vaults and wallet policies</td>
<td>Time-locked spending paths, delayed withdrawals, emergency keys, spending limits, and business treasury controls.</td>
<td>UTXO covenants can express constrained asset movement without turning every account into a global VM object.</td>
<td>Post-Toccata opportunity</td>
</tr>
<tr>
<td>Assurance contracts</td>
<td>Funds move only if enough participants commit by a deadline; otherwise they return.</td>
<td>This maps directly to stag-hunt and public-goods coordination: the rule is credible before everyone acts.</td>
<td>Post-Toccata opportunity</td>
</tr>
<tr>
<td>Conditional escrow</td>
<td>Milestone payments, disputes, deposits, delivery windows, and refund paths governed by transparent script rules.</td>
<td>Fast payment feedback helps escrow feel usable while covenants keep the state machine constrained.</td>
<td>Post-Toccata opportunity</td>
</tr>
<tr>
<td>Native assets and access passes</td>
<td>Tickets, memberships, credentials, game items, loyalty points, and redeemable claims with clear custody rules.</td>
<td>Some assets need fast transfer and self-custody before full general-purpose DeFi.</td>
<td>Post-Toccata opportunity</td>
</tr>
<tr>
<td>Atomic market primitives</td>
<td>Simple swaps, auctions, batch settlement, OTC flows, and intent-style exchange with bounded script behavior.</td>
<td>Kaspa's edge is credible fast ordering; market design uses that and labels immature DeFi paths clearly.</td>
<td>Post-Toccata opportunity</td>
</tr>
<tr>
<td>Games and state machines</td>
<td>Chess-like or turn-based apps where state is carried through constrained UTXO transitions.</td>
<td>The state discipline is the lesson: registration, player state, game state, move routing, and final settlement.</td>
<td>Post-Toccata opportunity</td>
</tr>
</tbody>
</table>
</div>
</details>
</section>
<section class="section">
<h2>Choose the app model first</h2>
<p>Choose the smallest model that can honestly run the product. Use covenants for bounded spend rules, based apps for shared app state, inline ZK when a proof is the product boundary, and later app programs for cross-app atomicity.</p>
</section>
<section id="rtd" class="section">
<h2>The unusual app job is rules strangers can rely on</h2>
<p>RTD and Staghunt framing point to markets where people need credible commitment before they act. A normal website can collect promises, but users worry that the operator can censor, reorder, change terms, or disappear.</p>
<p>The first version is simple: collect conditional commitments, group compatible commitments, run a transparent solver, prepare settlement or refunds, and replay the accepted evidence. The harder research target adds privacy, reusable capital, solver incentives, censorship resistance, and atomic execution.</p>
<p>The hard parts are concrete: event sources, incentives, anti-MEV design, scheduling, disputes, and implementation. Start with transparent commitments before claiming private or atomic coordination markets.</p>
<details class="source-more">
<summary>Open group-commitment examples</summary>
<div class="fit-grid">
<article class="section">
<h3>Public-goods assurance</h3>
<p>Projects, research, events, software, or local infrastructure that receive funding once enough participants join under fixed rules.</p>
</article>
<article class="section">
<h3>Real-time auctions</h3>
<p>Fast, open auctions for scarce digital goods, access, blockspace-related rights, or services that need ordering and censorship resistance.</p>
</article>
<article class="section">
<h3>Oracle-backed markets</h3>
<p>Prediction, insurance, and payment markets that need external data, but where oracle trust, incentives, and dispute paths are explicit.</p>
</article>
<article class="section">
<h3>First-to-know signal markets</h3>
<p>Watch miners or other rewarded reporters begin attesting to an event, then surface the earliest credible signal before normal feeds agree.</p>
</article>
<article class="section">
<h3>Machine-to-machine payments</h3>
<p>Agents, devices, miners, apps, and services buying resources or making commitments at internet speed with self-custodied funds.</p>
</article>
</div>
</details>
</section>
<section class="section">
<h2>Start with what works today</h2>
<p>Live network UX, receipts, and source-verifiable reads are the starting point. Covenants, ZK hooks, later app programs, and higher-density RTD ideas belong in the later build path until their activation evidence changes.</p>
<details class="source-more">
<summary>Open capability table</summary>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Capability</th><th>What builders can do</th><th>Status</th></tr></thead>
<tbody>
<tr><td>10 BPS GHOSTDAG payment flow</td><td>Fast inclusion, fast PoW user experience, wallets, payments, infrastructure, and clearer confirmation UX.</td><td>Live</td></tr>
<tr><td>Receipt and payload UX</td><td>Payment receipts, compact app context, accepted-transaction checks, support dashboards, and fallback verification paths.</td><td>Live foundation; depends on wallet and infrastructure quality</td></tr>
<tr><td>Attestation-capable paths</td><td>Opt-in event reporting, early external-event signals, oracle experiments, and first-to-know dashboards built by apps.</td><td>App-level design over base payment paths</td></tr>
<tr><td>MEV-aware ordering or auctions</td><td>Protects users who delegate an if-this-then-that strategy from miners or searchers exploiting the same event signal first.</td><td>Research / design work</td></tr>
<tr><td>Toccata covenants and ZK hooks</td><td>Vaults, assurance contracts, state-machine apps, simple assets, bridge foundations, and zk covenant experiments. External-chain or real-world claims still need an anchor such as a light client, finality certificate, accumulated-work view, oracle, reporter set, or dispute process.</td><td>Released and scheduled hard-fork track; activation still pending</td></tr>
<tr><td>STARK-sized proof support</td><td>Large validity proofs on Kaspa, with block-size and standard-fee tradeoffs to avoid cheap spam.</td><td>TN12 context / mainnet design question</td></tr>
<tr><td>Later app programs</td><td><a href="/kaspa-vprogs-explained">Apps that prove their own logic</a>, share Kaspa ordering, feel cohesive to users, and support atomic app-to-app actions in the later roadmap.</td><td>Roadmap architecture</td></tr>
<tr><td>DAGKnight / higher BPS RTD</td><td>Higher-density real-time majority sampling and more internet-round-trip attestation confidence.</td><td>Research / future upgrade direction</td></tr>
</tbody>
</table>
</div>
</details>
</section>
<section id="execution-order" class="section">
<h2>Build order</h2>
<p>Build in this order: wallet and payment paths, small covenant-shaped products, then richer based-app or later app-program paths only when the product needs shared state or composition.</p>
<details class="source-more">
<summary>Open build-order table</summary>
<div class="table-wrap">
<table class="reality-table">
<thead><tr><th>Phase</th><th>Build focus</th><th>What success looks like</th></tr></thead>
<tbody>
<tr><td>Now</td><td>Wallets, receipt UX, infrastructure, explorers, mining/node visibility, education, confirmation-risk tools.</td><td>People can use and understand the live network without trusting one interface.</td></tr>
<tr><td>Now: verifiable receipts</td><td>Payment receipts, address-history views, accepted-transaction monitors, accounting exports, support tooling, and API fallback paths.</td><td>People can use the live network with clearer evidence instead of trusting one interface.</td></tr>
<tr><td>Now: L2 ecosystem apps</td><td>Igra/Kaskad-style EVM L2 lending and bridge-adjacent app activity, labeled as ecosystem/L2 context.</td><td>Readers can see app activity without mistaking it for native Kaspa L1 DeFi, Toccata mainnet activation, or vProgs.</td></tr>
<tr><td>Toccata</td><td>Covenant examples, vaults, simple assets, escrow, assurance contracts, UTXO state-machine demos, STARK/zk proof experiments, developer docs.</td><td>Builders can make small apps without claiming full DeFi is live.</td></tr>
<tr><td>Based apps</td><td>App-specific state machines anchored to Kaspa ordering, commitments, proofs, settlement, or exits. They can start as deterministic replay and grow into based-zk when proof verification reduces trust or verification work.</td><td>Builders can test richer products without waiting for full app-to-app composition.</td></tr>
<tr><td>Later app programs</td><td><a href="/kaspa-vprogs-explained">Apps that prove their own logic</a>, share Kaspa ordering, support richer markets, private proofs, app-to-app flows, and canonical bridge design.</td><td>The later goal is app composition without asking the base layer to execute every app globally.</td></tr>
<tr><td>Research</td><td>DAGKnight, 100 BPS sampling, RTD-derived attestations, oracle markets, MEV auctions, TangVM-style flows, public funding markets, and AI-agent commitments.</td><td>The broad coordination thesis becomes testable through real products.</td></tr>
</tbody>
</table>
</div>
</details>
</section>
<section class="next-step section" aria-label="Suggested next step">
<h2>Ideas still need status</h2>
<p>Check status before describing any app-layer feature as live.</p>
<div class="actions">
<a class="button primary" href="/status">Open status</a>
<a class="button" href="/builder-guide">Builder guide</a>
</div>
</section>
<section class="section">
<h2>Application-layer references</h2>
<details class="source-more">
<summary>Open application-layer source list</summary>
<ol class="source-list">
<li><a href="https://tokenize-event.com/theatre-2-blockchain-technologies-and-the-potential-of-web3/utilising-decentralised-tech-secure-digital-wallets">Kaspa: Mining the Internet at Tokenize London</a> for Yonatan Sompolinsky's RTD, miner-attestation, internet-money flow, and focus/flywheel framing.</li>
<li><a href="https://kasmedia.com/article/the-weekly-knight-april-14">KASmedia Hong Kong wrap-up</a> for historical context on Michael Sutton's Crescendo/L1-L2 bridge talk, the ZK panel with Hans Moog, and the 2025 discussion around based rollups, state management, and liquidity fragmentation.</li>
<li><a href="https://www.youtube.com/watch?v=xHlOcR1x2tU">Michael Sutton's vProgs masterclass</a> for apps sharing Kaspa ordering, one-dimensional program space, app-to-app composition, computational DAGs, prover incentives, and sovereignty obligations.</li>
<li><a href="https://github.com/kaspanet/rusty-kaspa/tree/toccata">rusty-kaspa Toccata branch</a>, <a href="https://github.com/kaspanet/rusty-kaspa/tree/tn12">rusty-kaspa TN12 branch</a>, <a href="https://github.com/kaspanet/vprogs">kaspanet/vprogs</a>, and <a href="https://github.com/michaelsutton/argent">michaelsutton/argent</a> for current implementation/prototype evidence. Treat branches and prototypes as moving targets.</li>
<li><a href="https://faucet-tn12.kaspanet.io/">TN12 faucet</a> and <a href="https://tn12.kaspa.stream/">TN12 explorer</a> for testnet prototyping. Faucet balances, browser checks, and explorer APIs can change; use local TN12 RPC for serious testing.</li>
<li><a href="https://github.com/kaspanet/kips/blob/master/kip-0016.md">KIP-16</a>, <a href="https://github.com/kaspanet/kips/blob/master/kip-0017.md">KIP-17</a>, <a href="https://github.com/kaspanet/kips/blob/master/kip-0020.md">KIP-20</a>, and <a href="https://github.com/kaspanet/kips/blob/master/kip-0021.md">KIP-21</a> for TN10 implementation evidence. Confirm mainnet activation separately.</li>
<li><a href="https://www.kaskad.app/">Kaskad</a> and <a href="https://docs.kaskad.app/docs">Kaskad docs</a> for current Igra L2 lending context. This is ecosystem/L2 evidence. Native Kaspa L1 DeFi and Toccata activation need separate evidence.</li>
<li><a href="https://gist.github.com/michaelsutton/5bd9ab358f692ee4f54ce2842a0815d1">Michael Sutton's covenant++ and vProgs milestone notes</a> for inline zk covenants, based zk covenants, canonical bridge work, efficient sequencing commitments, and RTD context.</li>
<li><a href="https://gist.github.com/michaelsutton/a5c9bff6c9e9713edd0de9a3059bab9a">Michael Sutton's STARK-sized blocks and min-fee notes</a> for the STARK proof, block-size, standardness-fee, and elasticity tradeoffs.</li>
<li><a href="/sources">Kaspa Explained sources</a> for the Kaspa status hierarchy and source list.</li>
</ol>
</details>
</section>
<!-- related-links:start -->
<section class="section site-related" aria-labelledby="related-links-title">
<p class="eyebrow">Keep reading</p>
<h2 id="related-links-title">Next pages</h2>
<div class="site-related-grid">
<a href="/adoption-metrics"><span>Previous</span><strong>Kaspa adoption signals</strong><p>A non-price adoption framework for Kaspa: users, wallets, nodes, mining, liquidity, fees, developers, integrations, apps, and roadmap...</p></a>
<a href="/toccata-expressiveness-upgrade"><span>Next</span><strong>Toccata: Kaspa's Expressiveness Upgrade</strong><p>Part 1 of Parker Schmidt's personal essay on Kaspa Toccata, sovereignty, covenants, ZK proof verification, and why the upgrade deserves a...</p></a>
<a href="/status"><span>Status</span><strong>Kaspa current status</strong><p>A compact status page for Kaspa: what is live, what is targeted, what is roadmap, what remains research, and which common claims need context.</p></a>
</div>
</section>
<!-- related-links:end -->
</main>
<footer class="footer">
<div class="footer-grid">
<p><strong>Independent Kaspa explainer.</strong> Claims are labeled live, targeted, roadmap, research, unsupported, or wrong. Not investment advice.</p>
<nav class="footer-nav-groups" aria-label="Footer">
<div class="footer-link-group" aria-label="Learn">
<span>Learn</span>
<a href="/start-here">Start here</a>
<a href="/what-is-kaspa">Kaspa 101</a>
<a href="/overview">90-second overview</a>
<a href="/glossary">Glossary</a>
</div>
<div class="footer-link-group" aria-label="Verify">
<span>Verify</span>
<a href="/status">Status</a>
<a href="/kaspa-claims-checker">Claims checker</a>
<a href="/toccata-status">Toccata status</a>
<a href="/skeptical-case">Skeptical case</a>
<a href="/sources">Sources</a>
</div>
<div class="footer-link-group" aria-label="Build">
<span>Build</span>
<a href="/build-on-kaspa">Build on Kaspa</a>
<a href="/builder-guide">Builder guide</a>
<a href="/kaspa-app-ideas">App ideas</a>
</div>
<div class="footer-link-group" aria-label="Site">
<span>Site</span>
<a href="/search">Search</a>
<a href="/about">About</a>
<a href="/about#corrections">Corrections</a>
</div>
</nav>
</div>
</footer>
</body>
</html>