-
Notifications
You must be signed in to change notification settings - Fork 0
Expand file tree
/
Copy pathbuilder-guide.html
More file actions
522 lines (508 loc) · 28.7 KB
/
builder-guide.html
File metadata and controls
522 lines (508 loc) · 28.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
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
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>Kaspa Builder Guide | Kaspa Explained</title>
<meta name="description" content="A builder-specific guide to Kaspa programmability options: covenants, based apps, inline ZK, full vProgs, SDKs, indexes, and status boundaries.">
<meta name="robots" content="index,follow,max-snippet:-1,max-image-preview:large">
<link rel="canonical" href="https://kaspaexplained.com/builder-guide.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="Kaspa Builder Guide | Kaspa Explained">
<meta property="og:description" content="A status-labeled builder guide for choosing between covenants, based apps, inline ZK, and future full vProgs on Kaspa.">
<meta property="og:type" content="article">
<meta property="og:url" content="https://kaspaexplained.com/builder-guide.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="Kaspa Builder Guide | Kaspa Explained">
<meta name="twitter:description" content="Choose the right Kaspa app path without confusing builder tooling with live protocol status.">
<meta name="twitter:image" content="https://kaspaexplained.com/og-kaspa-explained.png">
<meta name="dateModified" content="2026-05-07">
<script type="application/ld+json">
{
"@context": "https://schema.org",
"@type": "TechArticle",
"headline": "Kaspa Builder Guide",
"url": "https://kaspaexplained.com/builder-guide.html",
"dateModified": "2026-05-07",
"description": "A status-labeled builder guide for Kaspa programmability options.",
"about": ["Kaspa", "Covenants", "Silverscript", "Based Apps", "Inline ZK", "vProgs"]
}
</script>
<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 - builder paths are 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="builder-page">
<section class="section">
<p class="eyebrow">Builder guide</p>
<h1>Kaspa builder guide.</h1>
<p class="lead">Kaspa builders should start with the user action: a payment, vault rule, asset rule, market, proof, or later app-to-app flow. Then choose the simplest state model that can support it.</p>
<div class="status-legend" aria-label="Status legend">
<span class="status-pill live">Live base</span>
<span class="status-pill target">Targeted</span>
<span class="status-pill roadmap">Roadmap</span>
<span class="status-pill research">Research</span>
<span class="status-pill not-live">Not live</span>
</div>
<p class="fit-note"><strong>Status rule:</strong> builder docs and open repositories show what people can study or prototype. Mainnet status still comes from activation, releases, and working applications.</p>
</section>
<section class="section">
<p class="eyebrow">Decision path</p>
<h2>Start with state and proofs.</h2>
<div class="table-wrap">
<table class="reality-table">
<thead>
<tr>
<th>Question</th>
<th>Use this path</th>
<th>Simpler path</th>
</tr>
</thead>
<tbody>
<tr>
<td>Many users touch the same app state at the same time.</td>
<td>Start with based apps or vProgs-compatible runtime work.</td>
<td>Start with covenants and L1 state outputs.</td>
</tr>
<tr>
<td>The product splits cleanly into independent states.</td>
<td>Covenants can still work for each separate state.</td>
<td>Shared-state app architecture becomes more natural.</td>
</tr>
<tr>
<td>Each action needs its own proof, privacy check, or custom validity rule.</td>
<td>Consider inline ZK, but expect more proof and operations work.</td>
<td>Use covenants or based apps first.</td>
</tr>
<tr>
<td>The proof depends on another chain, an oracle, a price, or a real-world event.</td>
<td>Name the anchor first: source root, finality certificate, accumulated-work view, oracle, reporter set, or challenge process.</td>
<td>The proof can stay inside the app's own state rules.</td>
</tr>
<tr>
<td>The app needs synchronous composition with other independent apps.</td>
<td>That is the future full-vProgs direction, especially if several app states must succeed or fail as one operation.</td>
<td>Build the narrow app first. Toccata-era apps can coordinate through L1 proofs and sequencing without claiming full atomic composition.</td>
</tr>
</tbody>
</table>
</div>
</section>
<section class="section">
<p class="eyebrow">Current options</p>
<h2>Match app model to state model.</h2>
<div class="reference-grid">
<article>
<h3>Covenants</h3>
<p><span class="status-pill target">Targeted</span></p>
<p>Best for asset rules and stateful outputs: vaults, treasury controls, escrow-like flows, unlock conditions, issuance policy, and small UTXO state machines.</p>
<p>One protected state advances one valid step at a time. Independent states can still run in parallel, but one hot state is sequential.</p>
</article>
<article>
<h3>Based apps</h3>
<p><span class="status-pill roadmap">Roadmap</span></p>
<p>Best when one app needs built-in accounts, balances, and shared-state execution. Users send actions through Kaspa L1, and a managed environment runs the Rust app logic.</p>
<p>This is construction-stage app architecture.</p>
</article>
<article>
<h3>Inline ZK</h3>
<p><span class="status-pill roadmap">Specialized</span></p>
<p>Best when each action needs its own proof or custom validity check before it settles: privacy-preserving actions, proof-verified workflows, or custom account models.</p>
<p>This path usually requires more prover design, proof infrastructure, and operational ownership. Outside data still needs a canonical anchor.</p>
</article>
<article>
<h3>Full vProgs</h3>
<p><span class="status-pill research">Future direction</span></p>
<p>Full vProgs are the future app-to-app composition direction: independent apps reading or calling one another in the same flow, with atomic combined outcomes instead of separate bridge-style waiting.</p>
<p>Treat this as architectural direction.</p>
</article>
</div>
</section>
<section class="section">
<p class="eyebrow">Build examples</p>
<h2>Map product ideas to a path.</h2>
<div class="table-wrap">
<table class="reality-table">
<thead>
<tr>
<th>Product shape</th>
<th>Likely starting path</th>
<th>Why</th>
</tr>
</thead>
<tbody>
<tr>
<td>Vault, treasury, inheritance, recovery, escrow</td>
<td>Covenants</td>
<td>The product is mostly about who can move funds and how stateful outputs evolve.</td>
</tr>
<tr>
<td>Native asset issuance or transfer policy</td>
<td>Covenants</td>
<td>The app logic is asset-native and can often stay close to L1 output rules.</td>
</tr>
<tr>
<td>Trading venue, game economy, shared balance app</td>
<td>Based app</td>
<td>Many users need to update the same app record without waiting for one UTXO path to move first.</td>
</tr>
<tr>
<td>Private action, custom validity check, proof-gated workflow</td>
<td>Inline ZK</td>
<td>The proof is part of every action, so verification becomes the product boundary.</td>
</tr>
<tr>
<td>Composable app network with calls across independent apps</td>
<td>Full vProgs later</td>
<td>The need is app-to-app synchronous composition, which belongs to the longer architecture target.</td>
</tr>
</tbody>
</table>
</div>
</section>
<section class="section">
<p class="eyebrow">Builder runway</p>
<h2>Use the new BUIDL path as the practical start.</h2>
<p class="lead">Kaspa.org now gives builders a cleaner first mile: try the SDK in-browser, pick an app or infrastructure path, then decide when public access is enough and when you need your own node.</p>
<div class="table-wrap">
<table class="reality-table">
<thead>
<tr>
<th>Builder question</th>
<th>Start here</th>
<th>When to go deeper</th>
</tr>
</thead>
<tbody>
<tr>
<td>I want to read chain data from a web app.</td>
<td>Use the Rusty Kaspa WASM browser examples and Public Node Network docs.</td>
<td>Run your own node or resolver path when reliability, privacy, or scale matters.</td>
</tr>
<tr>
<td>I want a wallet, payment, or transaction flow.</td>
<td>Start with the WASM SDK docs and upstream examples.</td>
<td>Move into native Rust or full-node RPC when signing, UTXO handling, or indexing becomes product-critical.</td>
</tr>
<tr>
<td>I want quick backend reads.</td>
<td>Use the community REST API for prototypes and constrained environments.</td>
<td>Treat hosted APIs as best-effort. Production apps should plan node/indexer ownership or redundancy.</td>
</tr>
<tr>
<td>I want infrastructure or analytics.</td>
<td>Use Rusty Kaspa, Docker, DB dumps, indexer projects, and node-hosting tools.</td>
<td>Decide whether you need live consensus access, historical query speed, or both.</td>
</tr>
<tr>
<td>I want covenants or app programmability.</td>
<td>Follow Toccata, TN12, Silverscript, KIPs, and vProgs references.</td>
<td>Keep TN12/testnet demos separate from mainnet claims until activation evidence changes.</td>
</tr>
</tbody>
</table>
</div>
<div class="actions">
<a class="button primary" href="https://kaspa.org/build">Open Kaspa.org BUIDL</a>
<a class="button" href="https://docs.kaspa.org/integrate/getting-started">Official getting started</a>
<a class="button" href="https://github.com/kaspanet/rusty-kaspa/tree/v1.1.0/wasm/examples">WASM examples</a>
<a class="button" href="https://kaspa.aspectron.org/rpc/pnn.html">Public Node Network</a>
<a class="button" href="https://api.kaspa.org/docs">REST API docs</a>
</div>
</section>
<section class="section">
<p class="eyebrow">Builder tooling</p>
<h2>Public tools to track.</h2>
<div class="reference-grid">
<article>
<h3>Official Kaspa docs</h3>
<p>Builder docs for choosing between programmability routes, connecting over RPC, wallet flows, transaction payloads, accepted-transaction listeners, and running node infrastructure.</p>
<p><a href="https://docs.kaspa.org/">Open Kaspa docs</a></p>
</article>
<article>
<h3>Getting started</h3>
<p>JavaScript, Rust, and Python examples for installing SDKs, connecting to a node over RPC, and reading live DAG data.</p>
<p><a href="https://docs.kaspa.org/integrate/getting-started">Open guide</a></p>
</article>
<article>
<h3>Programmability overview</h3>
<p>Decision path for Covenants, Based Apps, Inline ZK, and future Full vProgs. Useful for builder routing; still keep activation status separate.</p>
<p><a href="https://docs.kaspa.org/programmability">Open overview</a></p>
</article>
<article>
<h3>Silverscript</h3>
<p>Higher-level covenant tooling and examples for state transitions. Useful for learning the covenant direction; tooling and deployment workflows are still early.</p>
<p><a href="https://github.com/kaspanet/silverscript">Open Silverscript</a></p>
</article>
<article>
<h3>vProgs repo</h3>
<p>Early Rust framework work around based computation, scheduler/runtime/storage layers, L1 bridge concepts, and ZK proving components.</p>
<p><a href="https://github.com/kaspanet/vprogs">Open vProgs</a></p>
</article>
<article>
<h3>Python SDK</h3>
<p>Standalone Python SDK with v1.1.0 release evidence for GetVirtualChainFromBlockV2 and UtxoProcessor/UtxoContext bindings.</p>
<p><a href="https://github.com/kaspanet/kaspa-python-sdk/releases/tag/v1.1.0">Open release</a></p>
</article>
<article>
<h3>WASM SDK</h3>
<p>Browser and Node.js bindings from Rusty Kaspa for wallet flows, transactions, RPC access, and live browser examples.</p>
<p><a href="https://kaspa.aspectron.org/docs/">Open WASM docs</a></p>
</article>
<article>
<h3>Rusty Kaspa release</h3>
<p>The released node and native Rust crates are the main path for full nodes, RPC, wallet internals, indexing, and node-adjacent services.</p>
<p><a href="https://github.com/kaspanet/rusty-kaspa/releases/tag/v1.1.0">Open v1.1.0 release</a></p>
</article>
<article>
<h3>TxIndex</h3>
<p>Open PR for optional transaction-history indexing and GetTransaction RPC support. Relevant for wallets, explorers, and app infrastructure if merged and released.</p>
<p><a href="https://github.com/kaspanet/rusty-kaspa/pull/860">Open PR #860</a></p>
</article>
<article>
<h3>KRC ecosystem tooling</h3>
<p>KRC20/KRC721-aware wallets, indexers, and APIs can support issued tokens, NFT-style passes, coupons, event credits, and collectibles today. Required deploy/mint gas fees are miner fees, but interfaces may charge separately. Treat KRC as ecosystem-token rails, separate from Toccata covenants, native assets, and future vProgs.</p>
<p><a href="https://docs-kasplex.gitbook.io/krc20/">Open KRC20 docs</a></p>
</article>
</div>
</section>
<section class="section">
<p class="eyebrow">Access and infrastructure</p>
<h2>Useful builder surfaces.</h2>
<div class="reference-grid">
<article>
<h3>Public Node Network</h3>
<p>Community-operated node pool fronted by the Kaspa Resolver. Useful for demos and light reads; not a replacement for production infrastructure.</p>
<p><a href="https://kaspa.aspectron.org/rpc/pnn.html">Open PNN docs</a></p>
</article>
<article>
<h3>Community REST API</h3>
<p>Lightweight hosted API for constrained environments and quick reads. Treat it as best-effort with no SLA.</p>
<p><a href="https://api.kaspa.org/docs">Open REST API docs</a></p>
</article>
<article>
<h3>Transaction payloads</h3>
<p>Official guide for attaching application data to standard Kaspa transactions within mempool mass limits. Useful for receipts, tags, and lightweight app data.</p>
<p><a href="https://docs.kaspa.org/integrate/transaction-payload">Open payload guide</a></p>
</article>
<article>
<h3>Accepted transactions</h3>
<p>Official guide for polling or subscribing to accepted transactions, including payload-aware reads and reorg handling near active DAG tips.</p>
<p><a href="https://docs.kaspa.org/integrate/accepted-transactions">Open listener guide</a></p>
</article>
<article>
<h3>Docker node</h3>
<p>Rusty Kaspa Docker images are useful for local node setup. Persistent production nodes still need explicit storage, networking, and operations choices.</p>
<p><a href="https://hub.docker.com/r/kaspanet/rusty-kaspad">Open Docker Hub</a></p>
</article>
<article>
<h3>Explorer data dumps</h3>
<p>Explorer/API database dumps can help analytics, indexing, and historical-data work when an app does not need live consensus access.</p>
<p><a href="https://db-dl.kaspa.org">Open DB dumps</a></p>
</article>
<article>
<h3>DAG visualizer</h3>
<p>A live way to inspect blockDAG behavior and help users see that parallel blocks are ordered instead of discarded.</p>
<p><a href="https://kgi.kaspad.net/">Open DAGVIZ</a></p>
</article>
<article>
<h3>DeepWiki</h3>
<p>Generated Rusty Kaspa code navigation can help orientation, but code, releases, and docs remain the source of truth.</p>
<p><a href="https://deepwiki.com/kaspanet/rusty-kaspa">Open DeepWiki</a></p>
</article>
</div>
</section>
<section class="section">
<p class="eyebrow">Community infra</p>
<h2>Ecosystem projects to inspect.</h2>
<div class="reference-grid">
<article>
<h3>Simply Kaspa Indexer</h3>
<p>Standalone indexing project for Kaspa block and transaction data.</p>
<p><a href="https://github.com/supertypo/simply-kaspa-indexer">Open indexer</a></p>
</article>
<article>
<h3>DNS Seeder</h3>
<p>Bootstrapping infrastructure for the Kaspa peer-to-peer network.</p>
<p><a href="https://github.com/kaspanet/dnsseeder">Open DNS seeder</a></p>
</article>
<article>
<h3>kHost</h3>
<p>Tooling for running and contributing node capacity to the wider ecosystem.</p>
<p><a href="https://github.com/aspectron/khost">Open kHost</a></p>
</article>
<article>
<h3>kaspa-js</h3>
<p>Community-maintained JavaScript tooling around the Kaspa stack. Review current maintenance and fit before production use.</p>
<p><a href="https://github.com/K-Kluster/kaspa-js">Open kaspa-js</a></p>
</article>
</div>
</section>
<section class="section">
<p class="eyebrow">TN12 setup notes</p>
<h2>What helps before prototyping.</h2>
<div class="table-wrap">
<table class="reality-table">
<thead>
<tr>
<th>Need</th>
<th>Practical path</th>
<th>Status boundary</th>
</tr>
</thead>
<tbody>
<tr>
<td>Generate a test address</td>
<td>Use SDK or wallet tooling that produces a `kaspatest:` address, then paste that exact address into the TN12 faucet.</td>
<td>Testnet funds only. Do not reuse test keys for mainnet.</td>
</tr>
<tr>
<td>Get TN12 faucet tokens</td>
<td>Use the browser faucet at `faucet-tn12.kaspanet.io`. Automation may fail behind browser checks, so manual browser use is normal.</td>
<td>Faucet limits and availability can change.</td>
</tr>
<tr>
<td>Run a local TN12 node</td>
<td>Build or use a TN12-capable `rusty-kaspa` branch and start `kaspad --testnet --netsuffix=12 --utxoindex` with local RPC listeners.</td>
<td>Do not assume a generic stable mainnet binary supports every active TN12 setting.</td>
</tr>
<tr>
<td>Check balances locally</td>
<td>Query local wRPC JSON, often `127.0.0.1:18210`, after the node is synced and UTXO index is enabled.</td>
<td>Unsynced nodes can return misleading zero balances.</td>
</tr>
<tr>
<td>Move from mockup to app</td>
<td>Separate UI policy design from real Silverscript compilation, signing, transaction construction, broadcast, and explorer-visible outputs.</td>
<td>A simulator is not an enforced covenant until TN12 transactions prove it.</td>
</tr>
</tbody>
</table>
</div>
<p class="fit-note">Mainnet builders should use the released mainnet node and normal `kaspa:` addresses. TN12 builders should label every address, token, and transaction as testnet-only.</p>
</section>
<section class="section">
<p class="eyebrow">Verification habits</p>
<h2>Prove the state change.</h2>
<div class="table-wrap">
<table class="reality-table">
<thead>
<tr>
<th>Builder habit</th>
<th>Why it matters</th>
<th>Practical check</th>
</tr>
</thead>
<tbody>
<tr>
<td>Fetch accepted state after submit</td>
<td>Local construction does not prove accepted app state.</td>
<td>Record `is_accepted`, accepting block data, output script type, address, and amount.</td>
</tr>
<tr>
<td>Pin the submit surface</td>
<td>REST, JSON wRPC, Borsh wRPC, SDK versions, and testnet branches can expose different transaction shapes.</td>
<td>Log SDK version, node version, network id, endpoint, encoding, tx version, and input budget fields.</td>
</tr>
<tr>
<td>Compare with a known working spend</td>
<td>Witness order, signature preimage, redeem-script shape, and constructor keys are easier to check against a sibling transaction that already worked.</td>
<td>Diff the failing path against an accepted release, refund, or simple payment path before blaming protocol rules.</td>
</tr>
<tr>
<td>Label failed attempts narrowly</td>
<td>Tooling failures and consensus failures need different labels.</td>
<td>Keep the artifact, but mark it as bad config, stale tooling, submit mismatch, or confirmed consensus rejection.</td>
</tr>
</tbody>
</table>
</div>
<p class="fit-note">Testnet lesson: teach the verification habit without turning one prototype into a mainnet claim.</p>
</section>
<section class="section">
<p class="eyebrow">Status wording</p>
<h2>Say the stage first.</h2>
<ol class="learning-steps">
<li><strong>Covenants:</strong> <span>nearer L1 state-output path for constrained asset and UTXO-state rules.</span></li>
<li><strong>Based apps:</strong> <span>shared-state app direction for apps that need concurrency and account-style local state.</span></li>
<li><strong>Inline ZK:</strong> <span>specialized proof path for actions whose validity or privacy proof is the product boundary.</span></li>
<li><strong>External anchors:</strong> <span>ZK can check a statement about chosen inputs; builders must still define how source-chain roots, prices, events, or attestations become trusted inputs.</span></li>
<li><strong>Full vProgs:</strong> <span>future app-to-app atomic composition direction, beyond standalone based-app construction.</span></li>
<li><strong>KRC standards:</strong> <span>ecosystem token and NFT-style tooling available today through indexed data and wallet support, not native smart-contract activation.</span></li>
</ol>
<p class="fit-note">Use the positive stage first. Add caveats only where a reader might confuse builder work with live mainnet functionality.</p>
</section>
<section class="next-step section" aria-label="Suggested next step">
<p class="eyebrow">Next step</p>
<h2>Build from current status.</h2>
<p>Use this page to choose a model, then verify current implementation state before writing docs or product claims.</p>
<div class="actions">
<a class="button primary" href="/status.html">Open status</a>
<a class="button" href="/application-layer.html">App ideas</a>
<a class="button" href="/sources.html">Check sources</a>
</div>
</section>
<section class="section">
<p class="eyebrow">Sources</p>
<h2>Builder references used for this page.</h2>
<ol class="source-list">
<li><a href="https://progdoc.izio.fr/overview.html">Izio's Kaspa programmability overview</a> for the builder decision tree: covenants, based apps, inline ZK, and future full vProgs.</li>
<li><a href="https://progdoc.izio.fr/state-programs.html">Izio on Covenants</a> for sequential protected-output state, covenant IDs, and the current Silverscript builder reference.</li>
<li><a href="https://progdoc.izio.fr/app-vprogs.html">Izio on Based Apps</a> for shared-state app architecture and Rust app logic in a managed environment.</li>
<li><a href="https://progdoc.izio.fr/verified-actions.html">Izio on Inline ZK</a> for per-action proofs and proof-driven settlement.</li>
<li><a href="https://progdoc.izio.fr/full-vprogs.html">Izio on Full vProgs</a> for future app-to-app synchronous composition.</li>
<li><a href="https://github.com/kaspanet/rusty-kaspa/tree/tn12">rusty-kaspa TN12 branch</a>, <a href="https://github.com/kaspanet/silverscript">Silverscript</a>, and <a href="https://faucet-tn12.kaspanet.io/">TN12 faucet</a> for testnet covenant prototyping context. Treat these as testnet builder tools, not mainnet activation evidence.</li>
<li><a href="https://kaspa.org/build">Kaspa.org Build</a> for the current developer resource index: Rusty Kaspa, WASM SDK, public node access, REST API, Docker, DB dumps, testnet, KIPs, Silverscript, vProgs, community infra, and R&D links.</li>
<li><a href="https://docs.kaspa.org/">Kaspa docs</a>, especially <a href="https://docs.kaspa.org/integrate/getting-started">Getting started</a>, <a href="https://docs.kaspa.org/programmability">Programmability</a>, <a href="https://docs.kaspa.org/integrate/transaction-payload">Transaction payload</a>, <a href="https://docs.kaspa.org/integrate/accepted-transactions">Accepted transactions</a>, and <a href="https://docs.kaspa.org/integrate/kaspa-node">Kaspa node</a>, for current builder workflow guidance.</li>
<li><a href="https://kaspa.aspectron.org/docs/classes/RpcClient.html">Aspectron RpcClient docs</a> and <a href="https://kaspa-mdbook.aspectron.com/transactions/signing.html">Aspectron transaction signing guide</a> for the JavaScript SDK request shape used by current builder examples.</li>
<li><a href="/status.html">Kaspa Explained status</a> and <a href="/sources.html">source hierarchy</a> for live/targeted/roadmap/research boundaries.</li>
</ol>
</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>