Kaspa is a proof-of-work payment network that organizes parallel blocks as a directed acyclic graph instead of forcing every valid block into one linear chain. KAS is its native asset. This page focuses on how the Kaspa BlockDAG Is Ordered and the checks users need before sending funds, paying fees or using the network.
Send or receive KAS while understanding UTXOs, parallel-block ordering and confirmation risk.
Subject:
Kaspa
Market mode:
Snapshot Only
Fee asset:
KAS
Timezone:
UTC
This page does not verify an address, estimate mining profit, promise confirmation time or describe future smart-contract work as a live base-layer feature.
Content ownership: BitcoinToolkit Editorial TeamTechnical references: Official protocol and developer documentation.Review approach: Technical explanations are checked against primary sources and updated when the network or asset changes.Last content review: Data integration last tested:
How the Kaspa BlockDAG Is Ordered
Kaspa accepts useful parallel proof-of-work blocks and then gives them a shared consensus order.
Kaspa workflow from the first user decision to a verified outcome.
Parallel blocks are not automatically wasted
On a traditional linear proof-of-work chain, two miners finding blocks at nearly the same time create a temporary fork and one branch normally loses. Kaspa blocks can reference several parents, creating a blockDAG. GHOSTDAG classifies and orders blocks so compatible parallel work can contribute to consensus rather than being treated as an orphan solely because another block arrived first.
The ordering is not a free-form vote. Nodes calculate it from proof of work and protocol rules, and conflicting transactions still cannot both spend the same output. A wallet or explorer may show a block relationship differently from a linear height, so users should rely on Kaspa-aware confirmation data instead of applying Bitcoin block-count assumptions unchanged.
Current block rate and confirmation context
Kaspa moved to a ten-block-per-second target through the Crescendo upgrade. More frequent blocks reduce the time between visible network updates, but confirmation safety still depends on accumulated ordering and the receiving service policy. Network latency, conflicting spends and service risk remain relevant.
Fast block production should therefore be described as responsive consensus, not an absolute promise that every payment is irreversible after a fraction of a second. Exchanges and merchants can require different confirmation scores or waiting periods.
Kaspa retains a UTXO payment model even though its block structure differs from Bitcoin.
Spending outputs
A wallet selects unspent outputs controlled by its keys, creates outputs for recipients and usually returns change to the wallet. The transaction fee is the difference between input and output value and is paid in KAS. It is not a percentage of the amount transferred.
Addresses and final checks
Use a current Kaspa wallet and confirm the complete address, network, amount, fee and change. Native KAS should not be sent to a wrapped-token contract or another network address. A valid address format cannot prove that the recipient is trustworthy.
After broadcast, verify the transaction through a current node or independent explorer and wait for the confidence level required by the receiving service. Repeatedly sending a replacement without understanding wallet behavior can create confusion about which UTXOs remain spendable.
kHeavyHash Mining, Nodes and Pruning
Mining produces candidate blocks, while validating nodes enforce KAS supply and transaction rules.
Proof of work roles
Kaspa uses the kHeavyHash proof-of-work algorithm. Miners search for valid block proofs and receive KAS issuance plus fees under current network rules. Nodes independently verify the proof, blockDAG relationships, UTXO commitments and transactions; miners cannot make an invalid spend valid simply by including it.
Mining economics depend on hardware efficiency, electricity, cooling, pool rules, hashrate, emission schedule and market value. Specialized equipment and a displayed KAS price do not guarantee profit. A mining calculator needs live difficulty and operating inputs beyond this page.
Pruning and node operation
Kaspa pruning uses selected historical commitments so a node can validate the required current state without preserving every old block body forever. Pruning is a protocol and client behavior, not permission to trust an arbitrary snapshot. Operators should use current releases, verify synchronization and maintain backups of wallet keys separately from node data.
What Kaspa Does and Does Not Provide
Kaspa is a live proof-of-work payment network; roadmap ideas should not be presented as current base-layer capabilities.
No invented staking or contracts
KAS does not use proof-of-stake validators and does not pay native staking yield. Current base-layer transactions are UTXO payments rather than arbitrary EVM smart-contract calls. Research and Layer 2 plans can be important, but a wallet should not approve a supposed Kaspa staking or contract interaction unless its separate protocol and custody assumptions are verified.
A token labeled KAS on another chain may be a wrapped or custodial representation. It has host-chain gas, contract and bridge risks that native KAS does not share. Check the network and representation before deposits or withdrawals.
Common mistakes
Do not equate block rate with guaranteed settlement, a valid address with verified ownership, or a market price with mining profitability. Back up keys offline and test new destinations with a small amount.
Choose the next check based on whether you are paying, mining or operating a node.
Payment users
Confirm native Kaspa, the complete address, selected UTXOs, fee, change and receiving-service confirmation rule. Keep market data separate from a real transaction status.
Use maintained Kaspa-aware software.
Verify native versus wrapped KAS.
Wait for the destination confidence threshold.
Do not disclose recovery material to a support agent.
What Kaspa users should verify and why this design differs
Model current kHeavyHash hardware and electricity costs, then verify software and pool endpoints independently. Compare Bitcoin for linear-chain proof of work or browse the tools directory for calculators that accept operational inputs.
Kaspa Transactions FAQ
Is Kaspa a blockchain?
Kaspa uses a blockDAG that orders compatible parallel proof-of-work blocks rather than one strictly linear chain.
What pays Kaspa fees?
KAS pays native transaction fees.
Does Kaspa offer native staking?
No. Kaspa uses proof of work, not proof-of-stake validators.
What should I verify before a Kaspa transaction?
Check the official destination, current network, asset representation, amount, recipient and requested permissions. GHOSTDAG orders compatible parallel blocks and identifies conflicting work without discarding every block found at nearly the same time. Transactions still spend and create UTXOs. After confirmation, inspect the resulting balance or protocol state instead of relying only on a wallet success message.
Known Limitations
Confirmation behavior and node parameters can change after upgrades.
Roadmap features are not treated as live base-layer capabilities.
The page does not inspect a wallet, transaction, node or miner.
Market Data Methodology
The page uses a CoinGecko aggregated KAS/USD snapshot. No exchange chart is rendered for this entity.
Market Snapshot Source
CoinGecko aggregated market data (KAS/USD)
Cache
Snapshot cache is approximately 60 seconds.
Failure Handling
Verified cached data is labeled Cached or Delayed. Missing values remain unavailable.
