Understand

Nobody sees everything
at the same time.

Kaspa keeps blocks that honest miners find at the same time. Start with two miners, delay the news between them, then see why both blocks can stay while a double spend cannot.

Why blocks arrive in parallelInteractive model
Two miners. Two independent blocks.

Miner 2 found C before hearing about B. Both blocks build on A.

Arrows reference earlier blocks.
A BLOCK earlier TRANSACTIONS Earlier block B BLOCK ref A TRANSACTIONS Miner 1 · 100 ms C BLOCK ref A TRANSACTIONS Miner 2 · 400 ms A BLOCK earlier TRANSACTIONS Earlier block B BLOCK ref A TRANSACTIONS Miner 1100 ms C BLOCK ref A TRANSACTIONS Miner 2400 ms

An illustrative two-miner model. Discoveries stay fixed at 100 and 400 ms. The same delay applies both ways. Packet positions show elapsed delivery, not physical distance.

Model assumptions and event times

Delivery occurs before discovery at an exact tie. Real mining is random. D is a possible later block, not a timed discovery. This example calculates neither GHOSTDAG nor confirmation confidence.

TimeEvent
0 msBoth miners know A.
100 msMiner 1 finds B, referencing A.
400 msMiner 2 finds C, referencing A.
600 msMiner 2 receives B.
900 msMiner 1 receives C.

A delay can change the shape of the history.

News arrives in time

Miner 1 finds B. If miner 2 hears about B before finding C, C can reference B.

News arrives too late

Miner 2 finds C without knowing B. Both blocks reference A. They are parallel, even though both miners followed the rules.

A later block connects them

Once a miner receives both branches, a later block can reference both. A chain selects a branch; Kaspa represents parallel work in a blockDAG.

Inspect GHOSTDAG’s selection and ordering

GHOSTDAG chooses the parent with the greatest accumulated blue work, with hash tie-breaks. It classifies newly joined blocks using the parameter k: the blue set permits a bounded number of mutually unrelated blocks.

Blue and red are graph classifications, not labels for honest and dishonest miners. The implementation orders each merge set from its selected parent, then merges the other blocks by blue work and hash. Arrival order is not the ordering rule.

GHOSTDAG paper · Parent selection and classification · Merge-set ordering

Proof of work commits to block contents

Choose transactions

A miner prepares a candidate block. Its contents are committed through the block header used in the work calculation.

Search for valid work

The miner tries work calculations until it finds a result that satisfies the target. Changing the committed contents requires searching against a different header.

Let other nodes check

Nodes verify the work and the consensus rules. Frequent discoveries let work accumulate over short intervals. They sample hashpower, not a count of independent people.

Parallel blocks let the network represent contributions that arrive before miners have heard from one another. They do not remove communication delay or make each discovery a complete round of agreement. GHOSTDAG paper

Both blocks can stay.
The same money cannot be spent twice.

Once blocks are ordered, nodes still check each transaction against the ledger.

One output, two spending attemptsConstructed example
Available output10 KASBoth attempts refer to this same output.
Pay Alice10 KASAccepted
Pay Bob10 KASAlready spent
Alice’s payment consumes the output. Bob’s attempt cannot spend it again. Keeping both blocks does not make both payments valid.

The ordering is chosen here to expose the consequence. It is not a GHOSTDAG calculation. Fees are omitted from this conservation example.

Inclusion, acceptance, and confidence

A payment through the networkIllustrated sequence
Sender
Signed paymentPermission to spend an output
Network
Block
Your payment
Other transactions
Recipient
AcceptedA spendable outputIn the currently accepted history
The payment is accepted in the current history. The recipient may still wait before treating it as settled.

This sequence has no clock or confirmation count. Inclusion, acceptance, and a recipient’s confidence are different things.

Inclusion

A transaction appears inside a block. This alone does not establish that it was accepted.

Acceptance

The transaction is accepted in the current agreed history. Applications must still handle changes near the tips.

Confidence

Additional honest work makes replacing history more demanding under the security assumptions. The recipient chooses a policy appropriate to the payment.

Accepted-transaction integration · GHOSTDAG paper

Block rate, throughput, and the limits

Mainnet targets ten blocks per second. A 100-millisecond interval is neither guaranteed transaction inclusion nor a finality promise. Transaction mass, validation cost, bandwidth, and demand limit what the network can process.

Parallel blocks do not provide free throughput. Nodes still have to receive, validate, store, and order the work.