In brief
A Kaspa wallet is software for keys, addresses, signing, and transaction workflow. Network evidence is checked separately from what a wallet screen shows.
First Contact#
The Kaspa documentation often routes a new reader into wallet, node, and mining paths. This guide keeps that practical shape but adds a developer and evidence path. Each branch has a different job.
| Branch | What it does | Evidence to look for |
|---|---|---|
| Wallet | Builds keys, addresses, transactions, signatures, and user-facing balances. | Signed transaction data, wallet source/docs, and later accepted evidence. |
| Node | Validates, relays, stores, indexes, exposes RPC/wRPC, and follows consensus state. | Logs, RPC status, source paths, and network/version caveats. |
| Miner | Works from block templates and proof of work. | Template source, miner configuration, accepted block/transaction evidence. |
| Developer | Integrates RPC, SDKs, indexers, apps, scripts, and test environments. | Field preservation, replay behavior, source paths, tests, and release status. |
Mechanics#
No branch can prove the whole system alone. A wallet can produce a valid-looking signed transaction without proving it became accepted. A node can admit a transaction to its mempool without proving consensus acceptance. A miner can work on a template that later changes. An indexer can expose useful data while still needing replay and recovery checks.
Expanded Role Map#
The four practical roles overlap, but they do not prove the same thing. A wallet is closest to the user's intent: keys, addresses, transaction construction, signing, and balance presentation. A node is closest to validation and network participation: it validates, relays, maintains local state, and exposes interfaces. A miner is closest to block production: it works from templates and proof of work. A developer is closest to integration: they must preserve fields, understand RPC/wRPC/API boundaries, and choose the right evidence for application decisions.
The roles converge through the transaction lifecycle. A wallet can create a transaction, but the node may reject it. A node may admit it to mempool, but that is not accepted evidence. A miner may work on a template, but template inclusion is not final application evidence. A developer may read an API result, but the API result must be understood as an observation surface.
This is why the guide routes all four roles back to source discipline. Operational pages need current docs and release checks. Developer pages need field preservation and source paths. Mining pages need template and proof of work boundaries. Wallet pages need signing, backup, and accepted-evidence boundaries.