-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathapplication-layer.html
More file actions
326 lines (315 loc) · 25.7 KB
/
Copy pathapplication-layer.html
File metadata and controls
326 lines (315 loc) · 25.7 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
<!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 from Toccata's activated covenants, 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="#000000">
<meta property="og:title" content="Crypto Applications & Kaspa Opportunities | Kaspa Explained">
<meta property="og:description" content="Kaspa application paths: money movement now, constrained spend rules from Toccata's activated covenants, based apps for richer shared state, and later app programs.">
<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="Kaspa application paths: money movement now, constrained spend rules from Toccata's activated covenants, based apps for richer shared state, and later app programs.">
<meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained-20260514.png?v=20260514-logo-clearance">
<meta name="dateModified" content="2026-07-29">
<link rel="stylesheet" href="styles.css?v=20260729-spanfix">
<script defer src="nav.js?v=20260708-dark-default"></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">Money that settles on a fast Proof-of-Work network is only the starting point. Rules for funds, receipts, and shared state come next, once your product actually 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>Every app idea below rests on this: blocks mine in parallel, GHOSTDAG orders them into one history.</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 extra complexity only when the user can see custody, ordering, a rule or receipt, and a result another app or wallet can independently inspect.</p>
<div class="crypto-native-route grid-cards" 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. Name the verb before the architecture.</p>
</article>
<article>
<span>2. Crypto reason</span>
<strong>Why not a normal server?</strong>
<p>Self-custody, public ordering, rules strangers can rely on, or proof that state wasn't rewritten privately: one of these has to be true, or a server would do.</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: each has a different maturity level.</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 an explicit blocker: pick the one that actually exists.</p>
</article>
</div>
<div class="crypto-native-ledger grid-cards">
<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 just wants a database, a brand token, or a private score nobody outside needs to verify. A server already does this job.</p></article>
<article><span>Kaspa fit</span><p>Fast mined ordering earns its place when the workflow has multiple visible steps before final settlement rather than a single step.</p></article>
</div>
</section>
<section class="section">
<h2>Routes by need</h2>
<p>Use the smallest path that actually changes the user action. Payments and receipts already run on mainnet. Toccata covenants add spend constraints on mainnet. Based apps anchor shared app state to Kaspa ordering. Later app programs handle cross-app actions, and that piece isn't built yet.</p>
<div class="rail-ladder grid-cards" aria-label="Kaspa application path ladder">
<article><span>Live now</span><strong>Move money</strong><p>Wallets, payments, receipts, exchange flows, dashboards: everything a builder can ship on today.</p></article>
<article><span>Context</span><strong>Attach receipts</strong><p>App data, invoices, proof links, and replayable rows ride on top of the same payment.</p></article>
<article><span>Toccata work</span><strong>Constrain spends</strong><p>Vault rules, escrow, caps, refunds, simple controlled assets: the covenant rules Toccata activated on L1.</p></article>
<article><span>Based apps</span><strong>Replay shared state</strong><p>Auctions, coordination, markets, and app-specific state that several users touch at once.</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; this isn't built yet.</p></article>
</div>
</section>
<section id="tn12-covenant-tests" class="section">
<h2>What TN12 covenant tests are teaching</h2>
<p>A TN12 covenant test earns its keep when it makes a money rule visible at the spend layer. The transaction landed, the artifact links to the txid, replay explains the resulting state.</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, this withdrawal is blocked. An ordinary server can display those same claims. Here the money movement and the rule sit in the same public record.</p>
<p>Four kinds of result get read as the same result. An accepted TN12 transaction landed on testnet. A local reject failed inside a script or covenant engine on one machine. Replay-derived state explains accepted rows without controlling any funds itself. Wallet policy is a signer warning or refusal before broadcast, so the network never sees it.</p>
<p>The rules under test are the same three the Toccata table below covers: a covenant that carries a budget forward one valid step at a time, a hub that routes workflow state through smaller worker roles instead of one monolithic script, and an asset that cannot move without its controller input in the same transaction.</p>
<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>. Testnet evidence doesn't stand in for mainnet product evidence; <a href="/builder-evidence">builder evidence</a> covers what does.</p>
</section>
<section id="live-lane" class="section">
<h2>Buildable on today's mainnet</h2>
<div class="reference-grid grid-cards">
<article>
<h3>Receipt, transfer, and checkout UX</h3>
<p>Wallets, invoices, tips, remittances, checkout, and exchange withdrawal flows that show inclusion, confirmation confidence, and risk level as three separate facts. One word like "fast" collapses all three. This is payment-path work; merchant adoption needs its own evidence.</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 over keys.</p>
</article>
<article>
<h3>Miner and node dashboards</h3>
<p>Infrastructure that puts mining distribution, node health, propagation, fees, pruning, and network conditions in front of a normal user, beyond just an operator.</p>
</article>
<article>
<h3>Payload-aware receipts</h3>
<p>An app attaches compact context to a payment, then shows txid, amount, address, accepted status, source, and timestamp in a receipt the user can verify later, independent of the app.</p>
</article>
<article>
<h3>Accepted-evidence tools</h3>
<p>Dashboards, alerts, and support flows can state whether a transaction is seen, included, accepted, or still waiting on more confirmation confidence: four distinct states.</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 to someone who's never run a node.</p>
</article>
<article>
<h3>Workflow-linked activity</h3>
<p>Dashboards that separate user payments, mining behavior, exchange movement, spam, fees, and app tests, so one raw count stops passing for a signal.</p>
</article>
</div>
</section>
<section id="toccata-lane" class="section">
<h2>What Toccata adds</h2>
<p>Toccata activated on mainnet at DAA score 474,165,565 (Rusty Kaspa v2.0.1), adding covenant-style spend rules, asset rules, ZK proof checks, and sequencing commitments. Silverscript, the covenant language that compiles to those opcodes, still labels itself experimental and unstable, and recommends using its bytecode artifact only on testnet-10 until a first stable release. vProgs groundwork continues from here.</p>
<p>The first buildable products are simple and auditable: a vault policy, an assurance contract, an escrow, a constrained asset rule. The hard part is the gap between a good UI and an enforced covenant. Address generation, a synced mainnet node, UTXO-indexed balance checks, Silverscript compilation, signing, broadcast, and explorer-visible outputs all have to work before the covenant means anything. The TN12 covenant lab already tests this exact flow on testnet; mainnet wallet and explorer support for these rules are still catching up.</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 express constrained asset movement without turning every account into a global VM object.</td>
<td>Covenant rules live, app not shipped</td>
</tr>
<tr>
<td>Assurance contracts</td>
<td>Funds move only if enough participants commit by a deadline; otherwise they return automatically.</td>
<td>This is stag-hunt and public-goods coordination directly: the rule is credible before anyone has to act first.</td>
<td>Covenant rules live, app not shipped</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 makes escrow feel usable; covenants keep the state machine constrained the whole time.</td>
<td>Covenant rules live, app not shipped</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 general-purpose DeFi is even relevant.</td>
<td>Covenant rules live, app not shipped</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 builds on that, with immature DeFi paths labeled as such.</td>
<td>Covenant rules live, app not shipped</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, final settlement, each a distinct step.</td>
<td>Covenant rules live, app not shipped</td>
</tr>
</tbody>
</table>
</div>
</details>
</section>
<section id="rtd" class="section prose-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. An ordinary website can collect promises too. The difference is that users worry the operator can censor, reorder, change terms, or disappear.</p>
<p>Start transparent: collect conditional commitments, group the compatible ones, run a solver anyone can replay, then settle or refund. Privacy before the threshold, reusable capital, solver incentives, and atomic execution are all unsolved, so shipping the transparent version first is what keeps the claim honest. <a href="/kaspa-coordination-markets">Coordination markets</a> works through the design, the places it could fit, and what has to be solved before one launches.</p>
</section>
<section id="execution-order" class="section">
<h2>Build order</h2>
<p>Build in this order: wallet and payment paths first, small covenant-shaped products second, richer based-app or later app-program paths only once the product needs shared state or composition.</p>
<p>Two questions stay open at every rung, and neither has a shipped answer. If a user delegates an if-this-then-that strategy, nothing yet stops a miner or searcher from front-running the same event signal. And a validity proof large enough to be worth submitting trades block size against the standard-fee floor that keeps spam expensive. Any external-chain or real-world claim needs its own anchor too: a light client, finality certificate, accumulated-work view, oracle, reporter set, or dispute process.</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>Someone can use and understand the live network without trusting a single 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>Someone can use the live network with real evidence in hand, no need to take one interface's word for it.</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>A reader sees the 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 ship 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 start as deterministic replay and grow into based-zk once proof verification actually reduces trust or verification work.</td><td>Builders 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>App composition happens 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 gets tested against real products. Slide decks don't count.</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 calling any app-layer feature 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 grid-cards">
<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> covers Yonatan Sompolinsky's RTD, miner-attestation, and internet-money flow framing.</li>
<li><a href="https://kasmedia.com/article/the-weekly-knight-april-14">KASmedia Hong Kong wrap-up</a> gives 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> covers 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> hold current implementation/prototype evidence. Branches and prototypes are moving targets. Read them as current state, and recheck before quoting.</li>
<li><a href="https://faucet-tn12.kaspanet.io/">TN12 faucet</a> and <a href="https://tn12.kaspa.stream/">TN12 explorer</a> cover testnet prototyping. Faucet balances, browser checks, and explorer APIs can change without notice; use local TN12 RPC for anything that needs to be reliable.</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> document TN10 implementation evidence. Confirm mainnet activation separately: a merged KIP isn't an activation record.</li>
<li><a href="https://www.kaskad.app/">Kaskad</a> and <a href="https://docs.kaskad.app/docs">Kaskad docs</a> cover current Igra L2 lending context: ecosystem/L2 evidence, separate from native Kaspa L1 DeFi or Toccata-era app claims.</li>
<li><a href="https://gist.github.com/michaelsutton/5bd9ab358f692ee4f54ce2842a0815d1">Michael Sutton's covenant++ and vProgs milestone notes</a> cover 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> cover the STARK proof, block-size, standardness-fee, and elasticity tradeoffs.</li>
<li><a href="/sources">Kaspa Explained sources</a> holds the full 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="/kaspa-mining-cycle-visuals"><span>Previous</span><strong>The mining cycle, in pictures.</strong><p>Visual sketches for the Kaspa mining cycle: price, hash rate, ASIC markets, attack cost, fees, float, emissions, and proof-of-work...</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>What is live, targeted, roadmap, and research on Kaspa right now, checked against mainnet, releases, and KIPs.</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>