What is Dash?

Dash is a cryptocurrency built for payments. Its name comes from "digital cash": money you can hand over and use again without waiting around for the payment to settle.

It launched in January 2014 as XCoin, became Darkcoin later that year, and adopted the name Dash in 2015. Its fast-payment feature arrived in 2015 as InstantX, now called InstantSend; ChainLocks followed in June 2019. These features address two parts of the same problem: making a payment safe to accept quickly and keeping its record secure afterward.

You're building the checkout for a ticket marketplace. Alice pays Bob in Dash for a ticket he's reselling, and your app sees the transaction. Bob needs to know whether he can release the ticket. Seeing a payment arrive isn't enough: what stops Alice from trying to spend those same funds somewhere else?

InstantSend: can Alice spend the same money twice?

Alice could send one transaction paying Bob, then another spending the same funds back to herself. These are conflicting transactions: both try to use the same existing money. Only one can succeed, but Bob needs to know which one before giving away the ticket.

InstantSend lets Dash settle that question before a miner includes the payment in a block. It locks the transaction's inputs, the existing funds that transaction spends, to that particular payment. Once nodes accept the lock, they reject a conflicting transaction trying to use those inputs.

Alice sending a second transaction back to herself won't undo the locked payment to Bob. The network enforces the lock; Bob doesn't have to trust Alice's promise or keep her wallet connected.

Dash automatically attempts to lock qualifying transactions, and locks usually arrive within seconds. Alice sends a normal payment without selecting a special fast mode. Your checkout does need to check that the lock actually arrived; broadcasting a transaction and obtaining a lock are separate events.

At this point, the payment can still have zero block confirmations, meaning no block contains it yet. Bob can nevertheless safely accept it because InstantSend has ruled out a conflicting spend.

Bob can also spend the funds he received, for example to buy a ticket of his own, before Alice's payment enters a block. "Locked" doesn't mean the recipient's money is frozen. It means the original inputs can't fund a competing payment; the recipient can spend the money they received in a new transaction.

Who makes the lock stick?

The checkout doesn't create that protection itself. Dash has masternodes, servers that validate the blockchain and provide additional services, including the locks used by InstantSend and ChainLocks. Groups of masternodes produce locks and share them with the network. Other nodes verify those locks and enforce them when deciding which transactions and blocks to accept.

An ordinary full node downloads and validates the blockchain against the network's rules. It can reject a transaction that breaks those rules, including one that conflicts with an accepted lock. But it doesn't take part in producing the locks as a masternode does. Miners still assemble and produce blocks; an InstantSend lock doesn't mine a block on their behalf.

Dash pays masternode operators for the extra services. A regular masternode requires 1,000 DASH as collateral, funds the operator must keep unspent while running it. This makes creating many masternodes costly and helps resist someone flooding that service layer with fake participants.

These roles explain how Bob gets an answer before mining. Masternodes supply the lock, and nodes enforce it. Ordinary validation alone doesn't supply that early decision; without the masternode service, Bob would lose the InstantSend assurance he relies on to release the ticket immediately.

ChainLocks: can the block disappear later?

Now a miner includes Alice's payment in a block. Your checkout shows one block confirmation. InstantSend has already prevented her from spending the same inputs elsewhere, but it hasn't chosen which block the network must keep.

Why would there be a choice? Two miners can produce different valid blocks at roughly the same time, each extending the same previous block. This creates a fork, two competing branches of the chain. Block A contains Alice's payment; block B doesn't.

Without a block lock, the network could later adopt the branch through B as miners add more work to it. Switching branches is a reorganization. Alice's payment would then lose its place in block A. That doesn't, by itself, mean she has successfully spent the funds twice: losing block inclusion and accepting a conflicting spend are different events.

ChainLocks protect the block and the history leading up to it. Masternodes can produce a ChainLock for a mined block. Once a node verifies that lock, it rejects any competing block at the same height, or position in the chain, and any chain built on that competing block.

If A receives the ChainLock, nodes won't switch to B, even if miners build more blocks on B. Alice's payment stays recorded in A. This protection covers the whole block, including the other payments inside it.

Why the checkout benefits from both

InstantSend lets Bob release the ticket before a block exists. A ChainLock needs a mined block, so it can't give that early answer. Once the payment is in a block, ChainLocks protect its place in the chain; an InstantSend lock alone doesn't choose which block stays.

The features also work together: Dash attempts a ChainLock only after every transaction in the block has an InstantSend lock, establishing any missing transaction locks first. You don't choose one feature instead of the other when sending a payment.

For your checkout, track InstantSend status separately from the block-confirmation count. A payment with a verified InstantSend lock and zero confirmations carries protection that an unlocked payment with the same count doesn't. Show that distinction so Bob can act on the lock without waiting for the counter to change.

Dash also supports applications beyond payments through Dash Platform, an application-data layer hosted by a type of masternode called an Evolution masternode.

Check your understanding

Restoring your progress…

4 correct to pass