Layer 1 blockchain
Bitcoin ticker BTC
Summary
Miners search for a block-header hash below the current target; fully validating nodes accept only blocks that satisfy their consensus rules and follow the valid chain with the most accumulated proof of work. Value is held as unspent transaction outputs guarded by Script. 123
Design
- System
- Layer 1 blockchain
- Settlement family
- Bitcoin family
- Scarce resource
- Work (proof of work)
- State model
- UTXO
- Finality
- Probabilistic
- Who makes blocks
- Miners (usually coordinated through pools) propose blocks by performing proof of work; nodes independently decide whether each block is valid.
- Fork choice
- Valid chain with the most accumulated work, not the greatest height. Settlement confidence grows with confirmations but no depth is mathematically final.
Tradeoffs
- Emphasizes
- Decentralization and Security
- Gives up
- Base-layer throughput and fast settlement: blocks target roughly ten minutes and confirmations give growing, not final, confidence, so high-volume payments are pushed to layers such as Lightning.Hashrate concentration is a real risk signal but not by itself a complete decentralization score.
- Full node at home
- Practical at home 819Bitcoin.org lists 2 GB RAM, 7 GB free disk at 100 MB/s or faster, 400 kbit/s upload, about 740 GB first-time download, 6 hours a day online, and over 750 GB unpruned. Its 7 GB pruned figure looks low: the prune setting caps only block and undo data (minimum 550 MiB), while every node also keeps the full set of unspent coins, which mempool research measured at about 11 GB on disk in April 2025. Plan for roughly 12 GB or more pruned. Initial sync and unpruned storage are the main costs.
- Throughput claims
- No classified figure recorded
Scaling layers
- Lightning Network · Payment channels, mainnet 591011
Payments move within two-party channels whose balances limit what can be sent or received (inbound/outbound liquidity). A party must stay online or use a watchtower to punish a breach with an old channel state; disputes settle on Bitcoin using timelocked scripts. LND describes itself as beta software. - Liquid Network · Sidechain, mainnet 12
Separate federated sidechain, not a rollup. At least two-thirds of the block signers must sign each block and the federation controls the two-way peg, so users trust the federation rather than Bitcoin proof of work. Peg-ins wait 102 Bitcoin confirmations. Peg-outs are permissioned: the public cannot peg out alone and must go through a functionary or authorized participant. A timelock lets a set of three emergency keys reach all pegged funds if the network stops working for an extended period.
Capabilities
| Capability | How it is provided | Notes and sources |
|---|---|---|
| Account abstraction | Structured assessment pending | Not yet assessed for any chain. |
| Atomic swaps | Unknown | Not yet assessed under the current definitions; Script supports hash-locked, time-locked (HTLC) outputs that release funds on a preimage or refund after a timeout, and BIP 199 describes the pattern (its document status is Closed); the timelock opcodes it relies on are deployed. These are building blocks with which swaps can be built; no cited source shows a swap tool live on mainnet. 57 |
| Authenticated data publication | Unknown | Not yet assessed under this row's current definition. |
| Light clients | Built into the protocolFull scope | Protocol: consensus produces the proof-of-work header chain that a light client checks, with Merkle proofs of transaction inclusion; the whitepaper describes this simplified payment verification. BIP 157 client-side block filtering, marked Deployed, lets nodes serve filters that improve light-client privacy over BIP 37. 16 |
| Native staking or delegation | Structured assessment pending | Not yet assessed for any chain. |
| On-chain governance | Structured assessment pending | Not yet assessed for any chain. |
| Parallel execution | Structured assessment pending | Not yet assessed for any chain. |
| Payment or state channels | Ecosystem software (publisher not distinguished) Earlier definition | Lightning payment channels run through separate node implementations such as LND, using Bitcoin timelock and hash-lock scripts for settlement and disputes. See the Lightning entry among the scaling options described in this profile. 59 |
| Programmable spending | Native (protocol or core-team software) Earlier definition | Outputs carry Script or witness-program spending conditions, extended by SegWit and Taproot. This constrains how outputs are spent; it is not an account VM with persistent contract storage. 34 |
| Protocol-verified messaging | Structured assessment pending | Not yet assessed for any chain. |
| Reversible transfers or recovery | Unknown | Not yet assessed under the current definitions; relative timelocks (CHECKSEQUENCEVERIFY) are building blocks with which wallets can build escrow-with-timeout and delayed or revocable spend paths, but no cited source shows a sender-reclaim window or pre-arranged recovery path live on mainnet. Consensus cannot reverse a confirmed payment. 5 |
| Rollups | Unknown | No rollup anchored to Bitcoin was reviewed for this profile. Lightning is a channel network and Liquid is a federated sidechain; neither is a rollup. |
| Shielded transfers | Structured assessment pending | Not yet assessed for any chain. |
| Signed partial offers | Unknown | Not yet assessed under the current definitions; with a BIP 174 partially signed transaction a seller can sign one input and its matching output with SIGHASH_SINGLE|ANYONECANPAY, and a buyer adds inputs to settle both sides in one transaction. The traded non-BTC asset (ordinals or runes) exists only in indexer state, so the tooling publisher would set the value; no cited source shows such tooling (msigner) live in the 12 months before review, and ord's rune sell offers are a proposal. Limits: one signed input-output pair per listing, and no native multi-asset support. 3222324 |
Reading these values
- How this feature is provided
- Built into the protocol, core-team software or independent software says where a feature lives and who can change it. These are implementation layers, not quality: core-team software is not closer to the protocol than independent software.
- Structured assessment pending
- The shared review has not assessed this feature for any chain yet (Account abstraction, Native staking or delegation, On-chain governance, Parallel execution, Protocol-verified messaging and Shielded transfers). That does not mean it is absent, and a chain’s profile may already describe it.
- Unknown
- The review has not established this for this chain under the current definition; the note beside it says why. Unknown is not absent and not a low score. A feature reads “Not present” only when a source shows it is absent.
- Earlier definition
- Payment or state channels, Programmable spending and Rollups keep the earlier definition until the next fact-check. There, “Native” does not separate the protocol from core-team software, “Ecosystem software” does not say who publishes it, and “Partial” does not say which layer.
- Reading across rows
- The list of capabilities is incomplete. Do not read these rows as a chain leading or lagging overall.
Ecosystem & custody
| Product type | Status | Notes and sources |
|---|---|---|
| Automated market makers | Unknown | Bitcoin's base protocol has no built-in AMM. Token venues defined by indexers were not reviewed: Oyl's site says Alkanes tokens are live on Bitcoin mainnet and shows an Oyl AMM, but does not say whether that AMM is live. Venues on sidechains or other chains were not reviewed either. 25 |
| Issuer-native stablecoins | Unknown | Bitcoin Script has no native asset issuance; stablecoins issued through indexer protocols or sidechains were not reviewed. |
| Algorithmic stablecoins | Unknown | No algorithmic stablecoin with material usage on Bitcoin was identified, but stablecoins issued through indexer protocols, sidechains or other chains were not reviewed, so absence is not established. |
| Bridges | Established in the ecosystemLiquid two-way peg, WBTC | Liquid pegs BTC into a federated sidechain. WBTC is a token on other chains (the WBTC site lists Ethereum, Solana, Tron, BNB Chain and Base among its networks) backed by BTC in custody; BitGo announced in August 2024 that custody would move to a joint venture with BiT Global, spreading operations from the US to Hong Kong and Singapore. Risk: Both rely on trusted parties, not Bitcoin consensus. Liquid peg-outs are permissioned, and a timelocked set of three emergency keys can reach all pegged funds. Only identity-verified merchants approved through DAO governance can mint and burn WBTC; custody sits with the BitGo and BiT Global joint venture, which BitGo called a partnership with Justin Sun and the TRON ecosystem, and Chaos Labs on the Aave forum questioned the new partner's regulatory standing. 12132021 |
| Block explorers | Established in the ecosystemmempool.space, Blockstream Explorer (Esplora) | Both run open-source explorer software that can be self-hosted; a public instance's view is provider data, not independent validation. 141516 |
| Hardware wallets | Established in the ecosystemLedger, Trezor | See the Ledger and Trezor custody entries in this profile: both vendors document native Bitcoin support in their own wallet apps. 1718 |
Hardware-wallet custody
| Device maker | Status | What users can and cannot do |
|---|---|---|
| Ledger | Native supportSame as native: Yes | Can: Manage BTC accounts in Ledger Wallet (formerly Ledger Live) with each transaction verified and signed on the device Can: Use Native SegWit by default, or Legacy and Taproot account types 17 |
| Trezor | Native supportSame as native: Yes | Can: Use BTC on all Trezor models Can: Manage BTC in Trezor Suite or supported third-party wallets 18 |
Public data
Your AI can request these lookups through the connection. The website itself runs no lookups. Networks: mainnet, signet.
| Lookup | Status | What it covers and its limits |
|---|---|---|
| Address or account | Available | native BTC summary plus caller-bounded associated UTXOs and recent transactions |
| Tokens and assets | Needs a provider key on our server | native BTC classification plus bounded Ordinals inscription and Runes inventory when a server-side Xverse key is configured |
| NFTs | Not available yet | Not implemented in this build |
| Transactions | Available | one mainnet or Signet transaction with exact aggregates and first 20 outputs |
Sourced developments
Developments: Review overdue Reviewed Sep 26, 2026; next review was due Oct 6, 2026.
Publication date · newest first
-
Bitcoin Core 32.0 release candidate 2 published
Bitcoin Core v32.0rc2 is a signed release-candidate tag for testing the forthcoming 32.0 software line. It is prerelease software and is not represented here as a final release, a production recommendation, or a consensus activation.
- Stage:Reported
Sources: Bitcoin Core contributors — Bitcoin Core v32.0rc2 (external site) · Bitcoin Core contributors — Bitcoin Core 32.0 release schedule (external site)
-
Bitcoin Optech Newsletter #423 published
Newsletter #423 covers mining-pool variable-difficulty behavior, a proposed Utreexo initial-block-download improvement, a draft for unspendable Taproot internal keys, software releases, and implementation changes. It is a technical discovery and summary source; individual claims should be followed to their linked primary discussions and changes.
- Stage:Reported
Source: Bitcoin Optech — Bitcoin Optech Newsletter #423 (external site)
-
Bitcoin Core 29.4 released
Bitcoin Core 29.4 is a maintenance release for the 29.x line. Its release notes include a fix for excessive chainstate database rewrites and other implementation fixes; it does not represent a new consensus-rule activation.
- Stage:Release
Source: Bitcoin Core contributors — Bitcoin Core 29.4 release notes (external site)
-
Bitcoin Core 30.3 released
Bitcoin Core 30.3 is a maintenance release for the 30.x line. Its release notes include a fix for excessive chainstate database rewrites and other validation, wallet, P2P, build, and test fixes; this is client-software maintenance, not a Bitcoin protocol activation.
- Stage:Release
Source: Bitcoin Core contributors — Bitcoin Core 30.3 release notes (external site)
-
Bitcoin Core 31.1 released
Bitcoin Core 31.1 is a maintenance release that fixes excessive chainstate database rewrites and an IP-address leak affecting the PrivateBroadcast feature, along with validation, wallet, P2P, build, and test fixes.
- Stage:Release
Source: Bitcoin Core contributors — Bitcoin Core 31.1 release notes (external site)
-
Bitcoin Core disclosed a PrivateBroadcast IP-address leak
Bitcoin Core disclosed that the PrivateBroadcast feature introduced in 31.0 could, under specified transaction-submission, Tor, and peer conditions, reveal an originator's IP address. The project said the flaw would be fixed in 31.1, whose release notes subsequently list the fix.
- Stage:Reported
Sources: Bitcoin Core contributors — Disclosure of an IP address leak in PrivateBroadcast (external site) · Bitcoin Core contributors — Bitcoin Core 31.1 release notes (external site)
-
Bitcoin Core disclosed CVE-2024-52911
Bitcoin Core disclosed a high-severity use-after-free crash issue in versions after 0.14.0 and before 29.0 when processing a specially crafted invalid block. The project states that the issue was fixed in 29.0, released in 2025, and disclosed after the last vulnerable 28.x line reached end of life.
- Stage:Reported
Source: Bitcoin Core contributors — Disclosure of CVE-2024-52911 (external site)
-
Bitcoin Core 31.0 released
Bitcoin Core 31.0 introduced implementation changes including cluster-mempool-related behavior and the initial PrivateBroadcast feature. It is a major client-software release; later security guidance corrected the privacy expectations for PrivateBroadcast and 31.1 contains the related fix.
- Stage:Release
Sources: Bitcoin Core contributors — Bitcoin Core 31.0 release notes (external site) · Bitcoin Core contributors — Disclosure of an IP address leak in PrivateBroadcast (external site) · Bitcoin Core contributors — Bitcoin Core 31.1 release notes (external site)
Publication date unknown
-
BIP 54 Consensus Cleanup is marked Complete
BIP 54 specifies proposed consensus cleanups addressing timewarp behavior, worst-case validation cost, Merkle-tree weaknesses, and duplicate-transaction handling. Complete is a proposal status under BIP 3; this record does not claim mainnet activation.
- Stage:Proposal
Sources: Bitcoin BIP contributors — BIP 54: Consensus Cleanup (external site) · Bitcoin BIP contributors — BIP 3: Updated BIP Process (external site)
-
Taproot activated on Bitcoin mainnet
BIP 341 records Taproot deployment on mainnet at block height 709632. This is retained as a historical example of the distinction between a proposal, implementation support, and a network activation.
- Stage:Activation
Source: Bitcoin BIP contributors — BIP 341: Taproot (external site)
Topics your AI can explain
Your AI can explain these topics for Bitcoin through the connection, with sources.
Known gaps
What this profile's review did not establish:
- No throughput figure is listed; no primary-source rate was classified for this profile.
- Rollups claiming Bitcoin anchoring were not reviewed.
- Stablecoins, fiat-backed or algorithmic, issued via Bitcoin indexer protocols, sidechains or other chains were not reviewed.
- Token venues defined by indexers (ordinals, runes, Alkanes) were not reviewed; whether Oyl's AMM for Alkanes is live on mainnet is unconfirmed.
- Bridges other than the Liquid peg and WBTC were not reviewed.
- Current WBTC key holding was not confirmed from a primary source: a reported 2026 key-management change announced by BiT Global could not be fetched, so the note relies on BitGo's August 2024 announcement.
- Who holds Liquid's three emergency keys and how long its timelock runs are not stated in the cited overview.
- The pruned-node disk estimate combines bitcoin.org's prune rule with an April 2025 measurement of the unspent-coin set; the current size was not measured for this profile.
- Lightning network size, liquidity and routing reliability are not measured here.
Sources
Oldest dated source check: Source checked Sep 27, 2026 Next check due Oct 27, 2026.
- Bitcoin: A Peer-to-Peer Electronic Cash System (external site)
- Bitcoin Developer Guide: Block Chain (external site)
- Bitcoin Developer Guide: Transactions (external site)
- BIP 341: Taproot (external site)
- BIP 112: CHECKSEQUENCEVERIFY (external site)
- BIP 157: Client Side Block Filtering (external site)
- BIP 199: Hashed Time-Locked Contract transactions (external site)
- Running A Full Node (external site)
- LND: Lightning Network Daemon (external site)
- Understanding Liquidity (external site)
- Watchtowers (external site)
- Liquid technical overview (external site)
- Wrapped Bitcoin (WBTC) (external site)
- mempool.space (external site)
- Blockstream Explorer (external site)
- Esplora HTTP API (external site)
- Bitcoin wallet on Ledger Wallet (external site)
- Supported coins and assets (external site)
- UTXO Set Report (external site)
- BitGo to Move WBTC to Multi-Jurisdictional Custody to Accelerate Global Expansion Plan (external site)
- Chaos Labs - wBTC BitGo Custody Update (external site)
- BIP 174: Partially Signed Bitcoin Transaction Format (external site)
- msigner: Bitcoin Ordinals PSBT signer library (external site)
- Proposed Specification for Asynchronous Rune Sell Offers (issue #4290) (external site)
- Oyl (external site)
Report an error
Found something wrong or out of date? Reporting is free, and every chain goes through the same process. Published corrections appear in the public log.
Funding disclosure
Funding disclosures appear here when an upkeep arrangement exists, in the form “Upkeep funded by [name]; verdicts unaffected.” The funder ledger has not been published yet. Neutrality & funding