Records
Who owns what? Who paid whom? Which update happened first?
Crypto from zero
Crypto starts with shared records.
Money, balances, tickets, game items, stablecoins, and crypto all depend on records. The hard question is who can update the record, who checks the update, and why everyone else should accept it.
Crypto keeps one shared digital record without one trusted operator. That creates new problems around keys, consensus, incentives, markets, and group action.
The ladder
From zero to Kaspa.
Keys
A private key lets a user authorize updates without asking a platform login server.
Transactions
A transaction is a signed instruction asking the shared record to change.
Blocks
A block packages valid updates into a proposed piece of shared history.
Consensus
Independent computers need rules for which history counts when updates conflict.
Incentives
Unknown operators need reasons to follow rules and costs for attacking them.
Markets
Tokens trade because users, miners, validators, investors, and apps need entry and exit.
Kaspa
Kaspa keeps PoW and UTXO design, then uses a blockDAG to reduce the single-chain bottleneck.
Layer 0
Why digital ownership is hard.
Physical cash has location.
If Alice hands Bob a banknote, Alice no longer has that same banknote. The physical object cannot be in both wallets at once.
Digital data copies easily.
A file can be copied. A database row can be edited. A screenshot can be duplicated. Digital money therefore needs rules that make one accepted ownership state hard to fake.
Beginner line: Coins do not fly through the internet. A valid transaction changes an accepted record.
Trusted operator
Why a bank database is simpler.
A normal system has an operator. A bank, exchange, payment app, game company, or platform runs the database and decides which updates count. This is efficient because one authority can fix mistakes, block fraud, reverse payments, close accounts, and coordinate upgrades.
| Operator model | What it gives you | What it can cost |
|---|---|---|
| Bank or payment app | Customer support, reversals, fraud handling, legal recourse. | Account freezes, censorship, operating hours, jurisdiction limits, counterparty risk. |
| Exchange or platform | Fast internal balances and easy UX. | Custody risk, hidden liabilities, withdrawal risk, policy changes. |
| Public crypto network | Rules can be checked by independent participants. | More complexity, irreversible mistakes, public data, slower coordination. |
Why cryptography
Crypto needs proof without a login desk.
Private key
The secret that controls spending authority. If someone steals it, the network cannot magically know they are not the owner.
Public key or address
A way for others to verify that a valid signature was produced without learning the private key.
Signature
Proof that the holder of the key authorized a transaction. This replaces usernames, passwords, and a central account admin at the protocol layer.
Hash
A fingerprint for data. Hashes let blocks link to prior history and make tampering detectable.
What breaks without keys: the system needs a central login authority or real-world identity registry to decide who can update balances.
Transactions and blocks
Why transactions and blocks exist.
Transaction
A signed update request. It says, in effect: given the current rules, spend this value, create that new value, and pay this fee.
Why it exists: the network needs a precise object to validate.
Block
A proposed batch of valid transactions linked to prior history. A block is a consensus object, not an ordinary network packet.
Why it exists: the network needs a shared unit of history to accept or reject.
Consensus
Why records need agreement.
A record only matters if other people accept it. If Alice can show Bob one ledger and Carol another, Alice can attempt a double-spend. Consensus exists because independent computers see messages in different orders and still need one accepted state.
Which transaction came first?
Which block counts?
Was the same value spent twice?
Did a miner or validator follow the rules?
Can history be rewritten cheaply?
Can users verify the supply?
Security
Security means the record resists lies.
| Attack | Plain meaning | Why users care |
|---|---|---|
| Theft | Spend value without the rightful key holder's consent. | Ownership is meaningless if signatures can be forged or keys are stolen. |
| Double-spend | Try to spend the same value in two conflicting ways. | Recipients need to know which payment counts. |
| Rewrite | Replace accepted history with a different history. | Settlement needs confidence that old payments stay settled. |
| Censorship | Prevent valid transactions from entering history. | Open access fails if a control point can cheaply block users. |
| Hidden inflation | Create value outside the rules. | Supply rules matter only if users can independently reject invalid supply. |
Mining and staking
Consensus has to cost something.
Proof of Work
PoW makes fake history expensive through external cost: hardware, electricity, time, operations, and competition. Miners propose blocks and earn rewards if their work becomes part of accepted history.
Tradeoff: energy use, ASICs, mining pools, and industrial concentration pressure.
Proof of Stake
PoS makes fake history expensive through internal collateral: validators lock the native asset and can lose rewards or stake for bad behavior, depending on the design.
Tradeoff: wealth concentration, delegation, staking-provider power, and more complex social recovery questions.
Tokens
Why public networks often use tokens.
A permissionless network often needs an internal economic unit for value, fees, rewards, spam resistance, collateral, governance, or security budget. A project wanting a token is not enough.
Object tracked
The ledger records ownership of the asset itself.
Fee asset
Users pay for scarce block space and avoid free spam.
Security reward
Miners or validators are paid to operate and defend the system.
Market entry
Open markets let users, miners, validators, apps, and investors enter or exit without one issuer approving every participant.
Simple check: many tokens do not need to exist. Ask what the token does that BTC, ETH, USDC, or a normal database cannot already do.
UTXO and account models
Two ways to track state.
Account model
Looks like a balance table. Alice has 10, sends 3, and now Alice has 7 while Bob has 3. This is intuitive and common for smart-contract platforms. Shared mutable state can become complex.
UTXO model
Looks more like cash notes. Alice spends a 10-coin output, Bob receives a 3-coin output, and Alice receives a 7-coin change output. The old output becomes spent, not spendable again.
Kaspa, like Bitcoin, uses a UTXO model. That matters for validation, parallelism potential, and the shape of future programmability.
UTXO intuition: the old output is consumed once. New outputs carry the next spendable state.
Kaspa appears here
Where Kaspa enters.
Bitcoin-style chains usually choose one block path at a time. That conservative design makes high block rates difficult because honest blocks found in parallel can conflict. Kaspa tests whether a mined UTXO network can include more parallel honest work, order it with GHOSTDAG, and make payments feel closer to real time.