The Cryptocurrency Standards: properties, scalability, security and decentralisation

The source

The paper is short and describes one thing: cash that two people can send each other over the internet with no institution in between. Its abstract states the aim in its first sentence.

"A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution."
Abstract

Every later cryptocurrency answers it in some way, by copying the design, changing it or leaving it behind. That makes the paper the one reference every chain can be held to, and a fixed one: the text has not changed since 2008, while every chain, Bitcoin included, has. The standards are the document's, not any chain's, so a chain called Bitcoin can fail some of them.

The paper has twelve numbered sections. The standards draw on the introduction (§1), transactions (§2), proof of work (§4), the network (§5), the incentive (§6), reclaiming disk space (§7), simplified payment verification (§8), combining and splitting value (§9), privacy (§10), the calculations (§11) and the conclusion (§12). The full text is at bitcoin.org/bitcoin.pdf.

The ten properties

1. Anyone can mint

In the paper, new blocks are not made by appointed parties. Every node takes part on the same terms, and the right to add a block is won by work, not granted.

"Each node works on finding a difficult proof-of-work for its block."
§5 Network

"Nodes can leave and rejoin the network at will."
§12 Conclusion

§4 puts the same idea as "one-CPU-one-vote". The standard is met when block production is open to anyone willing to spend the resource the chain counts: proof of work, permissionless proof of stake or proof of space. A capped validator set, producers elected by token holders, an allow list or a council that admits validators is a door someone else holds, and fails.

2. Limited supply

The paper treats new coins as the network's start-up incentive and expects them to stop, with fees taking their place.

"Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free."
§6 Incentive

The standard is met by a maximum supply fixed by rule in advance, one no issuer, foundation or vote can raise. Issuance that continues without end, or a cap that governance can lift, fails.

Sound money. A predetermined supply is scarcity, the property a store of value rests on. The grade scores it as half of scarcity, beside where the supply sits on a scale that peaks at 21 million.

3. No pre-issuance or developer mint

The block reward is how coins first reach anyone, and the paper gives the reason.

"…provides a way to initially distribute coins into circulation, since there is no central authority to issue them."
§6 Incentive

If no central authority issues coins, none can be issued before the network starts. The standard is met when every coin came from the block rule, the first block included. Any allocation at genesis to founders, a company, a foundation or investors fails, whatever its size.

4. No developer tax

The same section says who receives each new coin.

"By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block."
§6 Incentive

The new coin pays the party that did the work of making the block. The standard is met when nothing of each reward is diverted elsewhere: a share routed to developers, a foundation or a treasury by the protocol fails.

5. No authority that can halt the chain or freeze funds

The introduction sets the paper against payment systems that rest on a trusted institution, one that can reverse a payment and so must be trusted by both sides.

"What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party."
§1 Introduction

§2 makes the point concrete: a coin is owned by whoever can sign for it, and nothing else decides. The standard is met when no issuer, foundation or validator council can stop the chain producing blocks, blacklist an address or reverse a payment. A chain where any of those is possible has put back the trusted third party the paper set out to remove.

Sound money. A chain that cannot be halted, frozen or rewound is what durability means for a ledger: money that keeps working and keeps its history, year after year.

6. No central team

This standard is a reading. The paper does not discuss who writes the software, but its conclusion describes a network that runs without anyone directing it.

"Nodes work all at once with little coordination. They do not need to be identified."
§12 Conclusion

"Any needed rules and incentives can be enforced with this consensus mechanism."
§12 Conclusion

Rules enforced by the nodes cannot belong to one company. The standard is met when no single company, foundation or lab controls the reference client in a way that lets it push a breaking change on everyone. Whether the code is published at all, as Bitcoin's was with its first version in January 2009, is scored separately, under network security: closed node software cannot be audited by the people who run it.

7. Fees under one cent

Also a reading. The introduction names what intermediated payments rule out.

"The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions."
§1 Introduction

§9 speaks of a transfer in cents. The paper gives no figure for a fee, so the standard draws one: a typical on-chain fee under $0.01, low enough that a small payment costs less to send than the smallest coin in a pocket. A chain whose fees price out small payments has the problem the paper set out to solve.

Sound money. Cheap transfers are portability, the property a medium of exchange needs most: value that crosses a room or an ocean at little cost.

8. Payments safe to accept within seconds

The third reading. The paper's payments go "directly from one party to another", and §11 works out how long a recipient must wait before a payment is safe from being reversed by an attacker with part of the hashrate.

"We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain."
§11 Calculations

In the paper safety is a probability that grows with each block. Cash at a counter is safe the moment it changes hands, so the standard asks for the same: finality within about five seconds, or unconfirmed payments the network itself protects through first-seen rules, double-spend proofs or instant locks. Fast blocks alone do not meet it, and a default that lets the sender replace an unconfirmed payment with a higher fee fails it.

Sound money. A payment that is safe at the counter is the other half of portability: money that moves cheaply has also to arrive in time to be accepted.

9. UTXO ledger

The paper defines a coin not as a balance but as a history of signatures, each owner passing it to the next.

"We define an electronic coin as a chain of digital signatures."
§2 Transactions

"To allow value to be split and combined, transactions contain multiple inputs and outputs."
§9 Combining and Splitting Value

Every payment spends earlier outputs in full and creates new ones, one for the recipient and usually one for change. That ledger of unspent transaction outputs, UTXO, meets the standard. The account model, a running balance per address that payments add to and subtract from, is a different design and does not.

Sound money. §9 is divisibility written into the transaction format: any output splits into smaller ones, down to the smallest unit the ledger records, and small outputs combine into a large payment. The same design carries fungibility: an output is an amount of one unit, not a numbered item, so a coin received is worth any other of the same amount. Its history of signatures makes payments traceable, which is a question of privacy, below, rather than of the units.

10. Privacy built into the protocol

The paper accepts that every transaction is public and moves privacy elsewhere.

"The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone."
§10 Privacy

Its method is keys that carry no names, with "a new key pair" for each transaction. Address reuse and chain analysis have since shown that this does not keep payments unlinked, so the standard asks for the paper's aim by means the protocol enforces: shielded transactions, ring signatures, stealth addresses or confidential amounts. Privacy a careful user can arrange with a mixer does not count. The grade's privacy section scores each kind on its own: hidden amounts, a hidden sender and receiver, and a node that hides where a transaction came from.

Scalability

The paper sizes the chain for its lightest users. A block header is about 80 bytes, and at one block every ten minutes the headers grow slowly enough for anyone to keep.

"If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year."
§7 Reclaiming Disk Space

"It is possible to verify payments without running a full network node."
§8 Simplified Payment Verification

A lightweight client keeps only those headers, so a ten-minute interval lets a phone follow the chain while the blocks themselves carry the payments. Those blocks have to be large enough for the demand: a chain that keeps its blocks small pushes fees up as use grows, and so loses the small casual payments of §1. Scalability is therefore not one property but a balance, scored on four measures, each on a log scale, and averaged:

• Fees. The typical fee of a simple transfer: $0.001 or less scores 10, $0.01 6.7, $0.10 3.3, $1 or more 0. A chain that is expensive to use is one fewer people use, whatever it can carry.
• Throughput. Capacity in simple transactions a second, against what the busiest networks actually carry: the median of the ten busiest layer-1 networks' 30-day averages scores 5, the highest single day of user traffic among them 10, and the score falls on the same log slope below the median. The line moves with real demand rather than with a figure picked once.
• Block time. Ten minutes scores 10, and the score falls away either side: one minute 6.4, ten seconds 2.8, one second 0, an hour 7.2. Every block adds a header that each node and light client must fetch and keep, so a faster cadence means more headers, more traffic and more cost to sync; a slower one keeps payments waiting.
• Block space. The block size limit per ten minutes, the limit times 600 divided by the block time: 0.1 MB scores 0, 1 MB 4, 4 MB 6.4, 32 MB or more 10. Counting it per ten minutes means fast blocks of moderate size are not punished for their interval twice: a 1 MB block every minute is 10 MB per ten minutes. A chain limited by gas, compute units or mass rather than bytes has no figure here.

A chain whose fees climb as it fills loses on fees; one with fast blocks loses on block time, however cheap; one with small blocks loses on block space and throughput.

Sound money. §8 is verifiability: a holder can check a payment against the chain's own headers instead of trusting a server, and §7's pruning lets a full node check every rule without keeping all of history. The grade's verifiability check asks for one of the two, with open-source node software. Fees and capacity, the measures above, are what portability reads.

Security and decentralisation

The paper's security argument is economic: an attacker must outspend the honest miners (§6, §11). The security part is nine points: miner pay a day on a scale, worth two, then seven checks, its own hashrate, no pool or validator over half, the largest three under three quarters, more than one maintained client, open-source node software, real use on chain and no 51% attack in five years. Decentralisation is three scales: who can mint, from proof of work down to an allow list; how many nodes check the rules; and how widely the coins are held. Both are set out in full in the grade's method and in what decentralisation means.

Sound money. An attack that must outspend the honest miners, and a record with no 51% attack, are what keep a ledger from being rewritten: the economics behind durability.

The ten properties at a glance

How the CoinSpectrum Grade uses the standards

The CoinSpectrum Grade groups the standards in five sections, twelve of its twenty criteria, each weighted like the rest: sound money, scalability, security, decentralisation with issuance in it, and privacy (method version 31); programmability is scored after them and is not a standard. Each of the ten properties is scored where it belongs (method version 30, 28 October 2026). A predetermined supply is part of sound money's scarcity; no authority over payments (censorship resistance) and no central team are criteria of decentralisation; a ledger of outputs is a privacy check, beside the paper's own privacy, keys not tied to an identity. Open minting is the who-can-mint ladder under decentralisation; no premine and no developer tax are the premine and developer-share criteria, which measure how much rather than whether any; sub-cent fees are the fees scale and payments safe in seconds a feature, both under scalability; and hidden amounts and parties are privacy checks. A property not yet researched is left out rather than guessed.

Each asset page groups the five sections, sound money first, under the Cryptocurrency Standards, one row per check and measure, with the source each was read from. They measure what a chain is, not how big it is, so a coin can meet every check and still grade low on liquidity or its record, and a coin that fails half can grade well elsewhere.

Questions