Eight questions to ask about any digital asset

"Crypto" covers thousands of assets whose governance, issuance and failure modes have almost nothing in common. That makes it useless as a description, and it is why comparisons that begin "crypto is…" tend to be arguments rather than analysis.

There is a better approach than deciding which side of that word something falls on, and it is one you can apply yourself to anything, including things that do not exist yet. Ask who can change the rules, and what it would cost them. The eight questions below are that question, broken into parts you can actually check.

Bitcoin is used as the worked example throughout, because it is what this site is about and because its answers happen to be verifiable. The point is the method rather than the verdict.

1The eight questions

For each one: what is being asked, and what a good answer looks like. None of them is about price.

Notice what is absent. Nothing here asks whether the technology is clever, whether the team is credible, or whether adoption is growing. Those are real questions and they are not structural ones. They describe how well something is going rather than who it depends on.

2Bitcoin's answers, and how to check them

Worked example. Each of these is checkable by someone with a node and a browser, which is the standard the questions were chosen to allow.

• Issuance follows a halving schedule capping supply just under 21 million. Changing it would need a large majority to voluntarily run incompatible software, and anyone declining keeps the existing rules.
• Allocation: no pre-mine and no founder allocation. Its creator left, and no successor inherited authority.
• Verification: a node computes total issuance from the chain and rejects any block that overpays. You do not take the number on report. The auditability is the point, and the figure is downstream of it.
• Rewriting history means redoing proof of work faster than everyone else produces new work. An ongoing physical cost, not a setting.
• Validation: anyone can run a node on ordinary hardware and check every rule: signatures, issuance, block validity, supply.
• Denial of service: the protocol has no user registry and no freeze function. The businesses and jurisdictions around it have both, and use them.
• Self-custody: you can hold your own keys, which removes the counterparty entirely and transfers the whole burden of key management to you.
• Roadmap: changes are proposed in the open and take effect only for those who choose to run them. Who decides the rules covers how that has actually played out.

3What the weak answers look like together

None of the following is illegal in itself, and none proves fraud. They are the structural features that make extraction from later buyers possible, which is why they are worth spotting rather than condemning.

• Concentrated ownership. A small number of entities hold enough supply to move the market at will.
• Pre-mines and insider allocations. Founders and funds receive large blocks at or before launch, at prices unavailable to anyone else.
• Discretionary issuance. The issuer can mint more, unlock vested tranches, or change the emission schedule.
• Paid promotion and manufactured community. Undisclosed influencers and bot-amplified sentiment standing in for organic use.
• Promised returns. Guaranteed yield, "risk-free" staking, or returns funded by new deposits rather than revenue.
• A small team controlling upgrades, infrastructure and treasury. Admin keys, upgradeable contracts, one sequencer, a discretionary treasury.
• Single points of dependence. One company, one website, one founder whose departure ends the project.
• Thin liquidity. Order books too shallow to absorb insider selling, which is what lets insiders exit onto retail buyers.

Read together, those describe a system whose outcome depends on the continued honesty and solvency of particular people. That is a fact about structure, and you can establish it without forming a view about anyone's intentions.

4Twice, the answers needed people

Applying the method honestly means applying it to the worked example too, and bitcoin has twice failed to simply carry on. Both occasions bear on question three, whether the supply is enforced or promised, so they belong here rather than in a footnote.

August 2010: the supply cap failed for five hours

Block 74638 contained a transaction that created roughly 184 billion bitcoin. The code checking transactions did not account for outputs so large that summing them overflowed, so the block was accepted and mined.

A patched client was released within about five hours, rejecting overflow transactions, and the honest chain overtook the bad one by block 74691. No permanent inflation, no user funds lost.

Note what actually held the cap. Not arithmetic operating unattended. People noticed, wrote a fix, and ran it. The rule was enforced by the participants who enforce it, which is a weaker and more precise claim than "the cap cannot fail".

March 2013: the chain split in two

Bitcoin Core 0.8 moved from Berkeley DB to LevelDB and lost an accidental limit the old database had imposed. A block arrived that 0.8 nodes accepted and older nodes rejected, and the network ran as two chains for roughly six hours until miners downgraded.

It was not free. BIP 50, the project's own write-up, records at least one large double spend during the split, by someone testing whether it was possible rather than robbing anyone, and notes that the two pool operators who downgraded first to restore the older chain did so "despite the fact that this caused them to sacrifice significant amounts of money". BIP 50 does not report customers left permanently out of pocket, and this page is not going to invent any. What it does record is that money moved which should not have, and that mining revenue was thrown away on purpose to end it.

Which is why "it has run continuously since 2009" is not quite true, and a page about checking claims should not repeat one it has not checked.

5What the method does not tell you

Structural answers are narrow on purpose, and the limits are part of using them properly rather than caveats bolted on.

• Nothing about price. Monetary properties and market price are different things. Bitcoin has repeatedly lost most of its value, with drawdowns beyond seventy per cent more than once, and may again.
• Nothing about volatility. A fixed supply means demand shocks are absorbed entirely by price. That follows from the design rather than contradicting it.
• Nothing about safety. Software bugs, key loss, theft, mining centralisation and regulatory action against on- and off-ramps are all real and none is answered by these questions.
• Nothing about the businesses. Exchanges, lenders, custodians, ETFs and miners are ordinary companies that can be insolvent, negligent or fraudulent, and several have been.
• Nothing about intent. Some projects with weak structural answers are honest experiments. The questions describe dependencies, not motives.

That fourth point is where most losses actually happen, and the route out of a platform balance is a page of its own. Four ways a platform loses your bitcoin walks through four collapses with four different mechanisms, and the thing they had in common was that the customer held a claim rather than a coin. Holding bitcoin at a custodian means holding that custodian's risks, whatever the protocol underneath does.

6Using it

• Ask the eight questions of anything before you form a view about it, including things this site recommends. A method you only apply to other people's assets is not a method.
• Verify rather than trust. Read the rules, run a node, audit the supply. Treat anything you cannot check, including this page, as unconfirmed.
• Separate the protocol from the businesses built on it. They have different answers to every question above, and almost everything that goes wrong in this industry goes wrong at the businesses.
• Be wary of promised returns specifically. Anyone guaranteeing you a yield is describing a business, whatever asset it is denominated in.

The short version

Whether something counts as "crypto" is a question about vocabulary. Who can change the rules, who was allocated what, and whether you can check the supply yourself are questions about structure, and they have answers you can go and establish. Bitcoin's answers are unusual and are also a matter of record rather than assertion, including the two occasions when holding the line required people to notice and act.

The 2010 value overflow is catalogued as CVE-2010-5139; the March 2013 split, the double spend during it and the pools' sacrificed revenue are all recorded in BIP 50, alongside the alert Bitcoin published at the time. Supply, issuance and validation behaviour are checkable against a node you run, which is the standard this page asks of itself.