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.

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.

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.

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.

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.

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 standard asks only whether the protocol gives any such privacy; the grade's capabilities score 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: 1 scores 0, 10 3.3, 100 6.7, 1,000 or more 10.
• 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.

Security and decentralisation

The paper's security argument is economic: an attacker must outspend the honest miners (§6, §11). The security part is nine checks: miners paid over $1 million and over $100,000 a day, 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.

The ten properties at a glance

How the CoinSpectrum Grade uses the standards

The CoinSpectrum Grade scores every graded cryptocurrency on the four parts, six of its seventeen criteria, each weighted like the rest: properties, scalability, security, and decentralisation's three scales. Each property met is worth 1 point, scaled to 10 over the properties that could be checked; a property not yet researched is left out rather than guessed, and at least six are needed for a score at all. Scalability averages the measures it has, at least two of them.

Each asset page groups the four parts under the Cryptocurrency Standards, one row per property, measure and check, with the source each was read from. The properties measure what a chain is, not how big it is, so a coin can meet all ten and still grade low on liquidity or its record, and a coin that fails half can grade well elsewhere. Two overlap with other criteria on purpose: "anyone can mint" is also scored on a scale under decentralisation, and pre-issuance sits beside the premine criterion, which measures how much was pre-issued rather than whether any was.

Questions