kaspa-explained/application-layer.html at main · parker2017code/kaspa-explained · GitHub

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
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
<!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="A status-labeled map of crypto application layers, what builders can use now, and where Kaspa's Toccata, vProgs, RTD, and research lanes may matter later.">
  <meta name="robots" content="index,follow,max-snippet:-1,max-image-preview:large">
  <link rel="canonical" href="https://kaspaexplained.com/application-layer.html">
  <link rel="icon" href="favicon.svg?v=20260507-k" type="image/svg+xml">
  <meta name="theme-color" content="#09090b">
  <meta property="og:title" content="Crypto Applications & Kaspa Opportunities | Kaspa Explained">
  <meta property="og:description" content="What crypto application layers actually produced, and what Kaspa builders should study without confusing roadmap ideas with live products.">
  <meta property="og:type" content="article">
  <meta property="og:url" content="https://kaspaexplained.com/application-layer.html">
  <meta property="og:image" content="https://kaspaexplained.com/og-kaspa-explained.png">
  <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="A practical map of crypto use cases and where Kaspa could develop its own application layer.">
  <meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained.png">
  <meta name="dateModified" content="2026-05-07">
  <link rel="stylesheet" href="styles.css?v=20260507-ai">
  <script defer src="nav.js?v=20260507-ai"></script>
</head>
<body>
  <a class="skip-link" href="#top">Skip to content</a>
  <header class="site-header">
    <div class="announcement">Independent Kaspa research guide - application ideas kept status-labeled</div>
    <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="/start-here.html">Start</a>
        <a href="/crypto-from-zero.html">Zero</a>
        <a href="/why-crypto-has-value.html">Value</a>
        <a href="/coin-atlas.html">Coins</a>
        <a href="/tradeoff-map.html">Tradeoffs</a>
        <a href="/why-kaspa-matters.html">Kaspa</a>
        <a href="/application-layer.html">Apps</a>
        <a href="/builder-guide.html">Builders</a>
        <a href="/status.html">Status</a>
        <a href="/sources.html">Sources</a>
        <a href="/search.html">Search</a>
        <a href="/about.html">About</a>
      </div>
      <a class="nav-cta" href="/status.html">Check Status</a>
    </nav>
  </header>

  <main id="top" tabindex="-1" class="status-page app-page">
    <section class="status-hero section">
      <p class="eyebrow">Application layer</p>
      <h1>Kaspa app ideas, by status.</h1>
      <p class="lead">The app question is practical: what gets better when payments, commitments, vaults, markets, or proofs can use fast mined ordering instead of one company's database?</p>
    </section>

    <section class="section">
      <p class="eyebrow">Short version</p>
      <h2>Start with what exists now.</h2>
      <p>Start with the product boundary: payments now, ecosystem tokens now, constrained rules after Toccata, richer proven apps later.</p>
      <div class="human-summary-grid">
        <article>
          <span>Live now</span>
          <p>Make payments, wallets, dashboards, merchant flows, confirmation-risk UX, and KRC token/NFT support better around the current fast PoW network.</p>
        </article>
        <article>
          <span>After Toccata</span>
          <p>Use covenants and proof hooks for spend limits, vault rules, escrow, simple assets, and contracts that only allow specific state changes.</p>
        </article>
        <article>
          <span>Later roadmap</span>
          <p>Use vProgs and RTD-derived designs for markets, lending, app-specific proofs, attestations, public funding rules, and app flows that can act like one coordinated product.</p>
        </article>
      </div>
    </section>

    <section class="section">
      <p class="eyebrow">Read by goal</p>
      <h2>Pick the part you need.</h2>
      <div class="route-grid">
        <article>
          <span>Crypto-native reader</span>
          <h3>Compare app patterns.</h3>
          <p>Use the first sections to see what Bitcoin, Ethereum, Solana, stablecoins, TRON, Hyperliquid, and oracle networks taught.</p>
        </article>
        <article>
          <span>App designer</span>
          <h3>Find Kaspa-shaped ideas.</h3>
          <p>Skip to the native filter, live lane, Toccata lane, and execution order before designing anything.</p>
        </article>
        <article>
          <span>Protocol reader</span>
          <h3>Read by layer.</h3>
          <p>Use the Toccata, vProgs, RTD, and now/later sections to place base rails, app rules, and products in the right stage.</p>
        </article>
        <article>
          <span>Skeptic</span>
          <h3>Check the build stage.</h3>
          <p>Use the status wording and sources before repeating claims about native DeFi, DAGKnight, vProgs, or oracle-style apps.</p>
        </article>
      </div>
      <nav class="jump-list" aria-label="Application page shortcuts">
        <a href="#app-thesis">Thesis</a>
        <a href="#app-patterns">Patterns</a>
        <a href="#kaspa-native">Kaspa-native filter</a>
        <a href="#live-lane">Live lane</a>
        <a href="#toccata-lane">Toccata lane</a>
        <a href="#rtd">RTD ideas</a>
        <a href="#execution-order">Execution order</a>
      </nav>
    </section>

    <section id="app-thesis" class="section">
      <p class="eyebrow">Application thesis</p>
      <h2>The app thesis.</h2>
      <p>The application case starts with a lean Proof-of-Work money layer that can order payments quickly, keep ownership in UTXOs, enforce covenant rules, check proofs, and eventually host apps that prove their own logic.</p>
      <p>A good Kaspa app starts with a plain question: does this need self-custodied money, a public ordering record, fast PoW sampling, local UTXO rules, proof-backed execution, or later app-to-app actions? Ordinary server state belongs on ordinary servers.</p>
      <p>Proof-backed is not fact-backed by default. Apps that depend on Ethereum state, a Bitcoin payment, a price, a weather event, or another outside fact still need a way to make that fact an agreed input.</p>
    </section>

    <section class="section">
      <p class="eyebrow">What other networks taught</p>
      <h2>Match the app to the rail.</h2>
      <div class="reference-grid">
        <article><h3>Bitcoin</h3><p>Scarce self-custodied money can be the app.</p></article>
        <article><h3>Ethereum</h3><p>Shared programmable state made DeFi, NFTs, DAOs, and rollups composable.</p></article>
        <article><h3>Solana</h3><p>Fast UX changed what users were willing to try.</p></article>
        <article><h3>Stablecoins and app chains</h3><p>Boring transfer utility and focused products can beat broad narratives.</p></article>
      </div>
      <p class="fit-note">For broader comparisons, use the coin atlas and tradeoff map. This page stays focused on Kaspa-shaped applications.</p>
      <div class="actions">
        <a class="button primary" href="/coin-atlas.html">Open coin atlas</a>
        <a class="button" href="/tradeoff-map.html">Open tradeoff map</a>
      </div>
    </section>

    <section id="app-patterns" class="section">
      <p class="eyebrow">Pattern library</p>
      <h2>Reusable app patterns.</h2>
      <div class="reference-grid">
        <article><h3>DeFi building blocks</h3><p>Uniswap, Aave, Curve, Maker/Sky, Jupiter, Kamino, Drift, PancakeSwap, Venus, and Hyperliquid show the recurring stack: swaps, lending, collateral, derivatives, stable assets, liquidity routing, and risk engines.</p></article>
        <article><h3>Wallet gateways</h3><p>MetaMask, Phantom, Xaman, and exchange-linked wallets show that the first useful app is often the interface.</p></article>
        <article><h3>Token launch and attention markets</h3><p>Pump.fun, BONK, meme assets, launchpads, NFT mints, and social trading show what cheap creation plus liquidity can produce, including low-quality activity.</p></article>
        <article><h3>Stablecoin transfers</h3><p>USDT on TRON, USDC across major chains, and exchange transfer flows show that boring payment utility can drive real network demand.</p></article>
        <article><h3>Real-world infrastructure</h3><p>Helium, Hivemapper, Render, io.net-style compute, and RWA experiments show how tokens can coordinate hardware, data collection, or capital formation.</p></article>
        <article><h3>Prediction and funding rules</h3><p>Polymarket-style markets, assurance contracts, DAOs, grants, and public-goods funding show crypto as rules that many parties can commit to before trusting one another.</p></article>
      </div>
    </section>

    <section id="kaspa-native" class="section">
      <p class="eyebrow">Kaspa's native question</p>
      <h2>Kaspa-native filter.</h2>
      <p>Start with the properties Kaspa has or is explicitly working toward: fast mined inclusion, UTXO ownership, GHOSTDAG ordering, covenants, ZK verification, sequencing commitments, and apps that can prove what they did.</p>
      <p>The filter is simple: who controls the record, who can censor it, who holds the assets, how quickly an action is seen, and whether strangers can commit to rules before trusting one another.</p>
      <blockquote>Use Kaspa where fast mined ordering changes the product.</blockquote>
    </section>

    <section class="section">
      <p class="eyebrow">Community advantage</p>
      <h2>Community-built apps.</h2>
      <p>Kaspa's app layer can come from many builders: wallets, dashboards, payment flows, covenant examples, vaults, funding tools, docs, and analytics around the same base asset. The standard is concrete: build something people can use, label the stage, and check security before asking users to trust it.</p>
    </section>

    <section class="section">
      <p class="eyebrow">Translate patterns</p>
      <h2>Possible Kaspa versions.</h2>
      <p>Use the short list first: wallets, payments, vaults, escrow, assurance contracts, simple assets, auctions, and proof-backed markets. The details depend on Toccata, vProgs, and later research.</p>
      <p>Based rollups belong in the later execution lane. They matter if they give builders richer app state while preserving Kaspa L1 sequencing and a path toward vProgs; they are not needed for the first L1 covenant examples.</p>
      <p>The biggest later app change is atomic composition. Two app actions can be fast or proof-linked without being one operation. Full vProgs aim at the stronger model: one user action can update several app states together, with the combined action succeeding or failing as a unit.</p>
      <details class="source-more">
        <summary>Open pattern translation table</summary>
        <div class="table-wrap">
          <table class="reality-table">
            <thead><tr><th>Pattern elsewhere</th><th>Kaspa-native version</th><th>Why it fits Kaspa</th><th>Status lane</th></tr></thead>
            <tbody>
              <tr><td>MetaMask / Phantom / Xaman</td><td>A wallet that explains inclusion, confirmation confidence, UTXO control, vault policy, and app permissions in plain language.</td><td>Users need to understand fast PoW risk states and balances.</td><td>Live foundation now; richer policies post-Toccata</td></tr>
              <tr><td>TRON USDT transfer</td><td>Fast self-custodied transfers for merchants, remittances, tips, payroll batches, and exchange flows.</td><td>Kaspa already has fast mined payment feel; the missing work is product UX, liquidity, and integrations.</td><td>Live foundation now</td></tr>
              <tr><td>ERC-20 / ERC-721 style assets</td><td>KRC20 tokens for simple credits, rewards, event tokens, or community assets; KRC721-style NFTs for coupons, access passes, tickets, memberships, collectibles, or proof-of-attendance objects.</td><td>These can use Kaspa's live data and payment rails, with required deploy/mint gas fees paid to miners. The useful product still depends on wallets, indexers, metadata, redemption rules, and the issuer honoring the claim.</td><td>Ecosystem live; not native smart contracts</td></tr>
              <tr><td>Uniswap / Jupiter</td><td>Simple swaps and liquidity routing after asset and covenant rails mature.</td><td>Market apps need public fast ordering, but native DeFi needs the right foundations.</td><td>Post-Toccata / vProgs</td></tr>
              <tr><td>Aave / Maker / Kamino</td><td>Collateral vaults, guarded lending, stable assets, and risk-managed liquidity with explicit liquidation and oracle assumptions.</td><td>Fast payment and UTXO vault policy could be useful now. Later vProgs matter if a lending position, market position, and settlement rule need to update atomically instead of through separate steps.</td><td>vProgs / roadmap</td></tr>
              <tr><td>Hyperliquid</td><td>A focused Kaspa-anchored market app: auctions, collateralized perps, hashpower markets, or real-time liquidity.</td><td>The lesson is focus: build one product that uses Kaspa's ordering and payment rails.</td><td>vProgs / app-specific architecture</td></tr>
              <tr><td>Based rollup app</td><td>A small rollup-side app that still uses Kaspa ordering, proof checks, or settlement as its anchor.</td><td>This can test richer execution without pretending the L1 covenant examples need an L2.</td><td>Research / future execution lane</td></tr>
              <tr><td>Polymarket</td><td>Prediction and assurance markets for events, public goods, research bounties, software funding, and group-action problems.</td><td>These markets need public commitments and explicit oracle assumptions.</td><td>Toccata for simple contracts; research for deeper oracle markets</td></tr>
              <tr><td>Helium / Hivemapper / Render</td><td>Proof-of-service or proof-of-resource markets for bandwidth, compute, sensing, local infrastructure, or AI-agent work.</td><td>High-frequency PoW and public group-commitment research may help later attestation designs.</td><td>Research / architecture</td></tr>
              <tr><td>ENS / Farcaster / social graphs</td><td>Identity, handles, reputation, access passes, and portable group membership tied to self-custody.</td><td>The first useful versions may be simple access and membership systems.</td><td>Post-Toccata / vProgs</td></tr>
              <tr><td>Pump.fun / meme launchpads</td><td>Launch and bonding tools with clearer risk labels, anti-scam defaults, and transparent liquidity paths.</td><td>Cheap creation creates attention markets; the design question is whether they can be less extractive.</td><td>Post-Toccata opportunity</td></tr>
            </tbody>
          </table>
        </div>
      </details>
    </section>

    <section id="live-lane" class="section">
      <p class="eyebrow">Live lane</p>
      <h2>Useful before Toccata.</h2>
      <div class="reference-grid">
        <article>
          <h3>Fast PoW payments</h3>
          <p>Wallets, merchant flows, tips, remittances, and exchange withdrawal UX that make confirmation confidence 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 payment UX</h3>
          <p>Point-of-sale and exchange flows that show inclusion, confirmation confidence, and risk level as separate states.</p>
        </article>
        <article>
          <h3>KRC20 token use</h3>
          <p>Simple fungible tokens can represent points, event credits, limited-use rewards, community assets, or closed-loop perks where the organizer controls redemption and support. The required KRC deploy/mint fee is a miner fee, while interfaces may add their own charges.</p>
        </article>
        <article>
          <h3>KRC721-style passes</h3>
          <p>NFT-style records can represent coupons, membership passes, ticket claims, collectibles, proof-of-attendance objects, or gated access. The useful part is the claim and redemption workflow, not speculation.</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>Real activity measurement</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">
      <p class="eyebrow">Toccata lane</p>
      <h2>Toccata lane.</h2>
      <p>Toccata is the near-term hard-fork track for spend rules, asset rules, Silverscript, ZK proof checks, sequencing commitments, and vProgs groundwork. Its public lane stays targeted until primary activation evidence changes that status.</p>
      <p>For builders, the first useful 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>
      <div class="table-wrap">
        <table class="reality-table">
          <thead><tr><th>Opportunity</th><th>What it could look like</th><th>Why Kaspa may fit</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 more than full general-purpose DeFi at first.</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 should use that rather than pretending mature DeFi is already here.</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 useful point is state discipline, not the game itself: registration, player state, game state, move routing, and final settlement.</td>
              <td>Post-Toccata opportunity</td>
            </tr>
          </tbody>
        </table>
      </div>
    </section>

    <section class="section">
      <p class="eyebrow">Builder path</p>
      <h2>Choose the app model first.</h2>
      <p>Covenants, based apps, inline ZK, and future full vProgs answer different state and proof problems. Start with the smallest model that fits the product, then check the current implementation stage.</p>
      <div class="actions">
        <a class="button primary" href="/builder-guide.html">Open builder guide</a>
        <a class="button" href="/status.html">Check status</a>
      </div>
    </section>

    <section id="rtd" class="section">
      <p class="eyebrow">RTD and group commitments</p>
      <h2>The unusual app lane 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 may still worry that the operator can censor, reorder, change terms, or disappear.</p>
      <p>The hard parts are concrete: event sources, incentives, anti-MEV design, scheduling, disputes, and implementation. At 10 BPS this remains an app/research lane; stronger RTD claims depend on later sampling density and consensus work.</p>
      <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 where ordering and censorship resistance matter.</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>
    </section>

    <section class="section">
      <p class="eyebrow">Now / later boundary</p>
      <h2>Now and later pieces.</h2>
      <p>Live network UX and KRC ecosystem tooling are the starting point. Covenants, ZK hooks, vProgs, and higher-density RTD ideas belong in later lanes until activation evidence changes the status.</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 it enables</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>KRC20 / KRC721 ecosystem standards</td><td>Issued tokens, NFT-style passes, coupons, rewards, event credits, collectibles, and token-aware wallet or indexer UX.</td><td>Ecosystem live; depends on tooling and off-chain redemption rules</td></tr>
              <tr><td>Attestation-capable rails</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 rails</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>Targeted hard-fork track, not live until activated</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>vProgs</td><td>Apps that prove their own logic, 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>Denser real-time majority sampling and stronger internet-round-trip attestation confidence.</td><td>Research / future upgrade direction</td></tr>
            </tbody>
          </table>
        </div>
      </details>
    </section>

    <section class="section">
      <p class="eyebrow">Short list</p>
      <h2>Coordination app examples.</h2>
      <div class="reference-grid">
        <article><h3>Assurance markets</h3><p>Funds move when enough people commit by a deadline. This is the cleanest public-goods and stag-hunt fit.</p></article>
        <article><h3>Prediction and event markets</h3><p>Useful only with explicit oracle, reporter, dispute, and legal assumptions. Fast payment feedback does not remove those hard parts.</p></article>
        <article><h3>First-to-know terminals</h3><p>Apps could reward fast attestations and surface early confidence changes before normal feeds agree.</p></article>
        <article><h3>Merchant escrow and vaults</h3><p>Live payment UX can improve now; covenant policies could later add refunds, limits, delays, and recovery paths.</p></article>
        <article><h3>Hashpower and service auctions</h3><p>PoW culture and fast ordering fit markets for scarce technical resources, proofs, compute, data, and app-specific services.</p></article>
        <article><h3>AI-agent commitments</h3><p>Agents need small, machine-readable commitments: deposits, task payment, completion proofs, and dispute rules.</p></article>
      </div>
    </section>

    <section class="section">
      <p class="eyebrow">Builder filter</p>
      <h2>App idea checklist.</h2>
      <ol class="learning-steps">
        <li><strong>Needs a neutral shared record.</strong> <span>The app gets meaningfully better when no single operator controls the database.</span></li>
        <li><strong>Benefits from fast mined ordering.</strong> <span>Real-time Proof-of-Work feel changes user experience, risk, or group action.</span></li>
        <li><strong>Uses UTXO constraints well.</strong> <span>The app can be modeled as bounded state transitions, vaults, commitments, assets, or payment flows.</span></li>
        <li><strong>Names off-chain assumptions.</strong> <span>If the app depends on outside facts, it names the source root, oracle, reporter, light-client, challenge, and dispute assumptions clearly.</span></li>
        <li><strong>Can start narrow.</strong> <span>The first version solves one concrete problem before claiming to replace finance, identity, games, or law.</span></li>
      </ol>
    </section>

    <section id="execution-order" class="section">
      <p class="eyebrow">Execution order</p>
      <h2>Build order.</h2>
      <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, payment 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: ecosystem assets</td><td>KRC20/KRC721-aware wallets, indexers, coupon/pass flows, event-credit experiments, token catalogs, merchant redemption tools, and safety warnings.</td><td>People can try practical token and NFT workflows while still understanding that these are ecosystem standards, not native smart contracts.</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 useful apps without claiming full DeFi is live.</td></tr>
            <tr><td>vProgs</td><td>Apps that prove their own logic, share Kaspa ordering, support richer markets, private proofs, app-to-app flows, and canonical bridge design.</td><td>Applications can become more useful 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>
    </section>

    <section class="next-step section" aria-label="Suggested next step">
      <p class="eyebrow">Next step</p>
      <h2>Use ideas, then return to status.</h2>
      <p>Use this page for ideas. Check status before describing any app-layer feature as live.</p>
      <div class="actions">
        <a class="button primary" href="/status.html">Open status</a>
        <a class="button" href="/builder-guide.html">Builder guide</a>
        <a class="button" href="/why-kaspa-matters.html">Why Kaspa matters</a>
        <a class="button" href="/sources.html">Check sources</a>
      </div>
    </section>

    <section class="section">
      <p class="eyebrow">Sources</p>
      <h2>Use these as maps, not investment recommendations.</h2>
      <details class="source-more">
        <summary>Open application-layer source list</summary>
        <ol class="source-list">
          <li><a href="https://www.coingecko.com/en">CoinGecko market-cap pages</a> for a current top-asset snapshot; rankings change and should not be treated as advice.</li>
          <li><a href="https://ethereum.org/apps">Ethereum.org apps</a> for Ethereum application categories and examples.</li>
          <li><a href="https://solana.com/learn/exploring-solana-applications">Solana application guide</a> and <a href="https://solana.com/solutions/depin">Solana DePIN page</a> for Solana app categories and DePIN examples.</li>
          <li><a href="https://xrpl.org/">XRPL.org</a> for XRPL payment, DEX, token, and payment-channel primitives.</li>
          <li><a href="https://dappbay.bnbchain.org/ranking">BNB Chain DappBay rankings</a> for BNB Chain dApp categories and examples.</li>
          <li><a href="https://developers.tron.network/docs/tron-economic-model">TRON developer docs</a> for TRON's stablecoin and DeFi ecosystem framing.</li>
          <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>, and <a href="https://github.com/kaspanet/vprogs">kaspanet/vprogs</a> for current implementation/prototype evidence. Treat branches 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/pull/36">KIP-21 pull request</a> for partitioned sequencing commitments and O(activity) proving direction; confirm final status before calling it activated.</li>
          <li><a href="https://docs-kasplex.gitbook.io/krc20/">KRC20 documentation</a> and <a href="https://docs.kastle.cc/">wallet support documentation</a> for KRC20/KRC721 ecosystem-token context. Treat these as ecosystem tooling references, not core-protocol activation 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.html">Kaspa Explained sources</a> for the Kaspa status hierarchy and source trail.</li>
        </ol>
      </details>
    </section>
  </main>

  <footer class="footer">
    <div class="footer-grid">
      <p><strong>Independent resource.</strong> Kaspa-positive research guide, not investment advice.</p>
      <nav aria-label="Footer">
        <a href="/status.html">Status</a>
        <a href="/sources.html">Sources</a>
        <a href="/search.html">Search</a>
        <a href="/about.html">About</a>
        <a href="/CLAIMS.yml">Claims</a>
        <a href="https://github.com/parker2017code/kaspa-explained">GitHub</a>
      </nav>
    </div>
  </footer>
</body>
</html>