Bitcoin Cash (BCH): A Complete Beginner-Friendly Guide
Research updated: 21 September 2026. Network statistics and ecosystem availability can change. This article is educational, not financial advice.
What is Bitcoin Cash (BCH)?
Imagine a public notebook shared by thousands of computers. Anyone can ask the network to record a payment, but no bank owns the notebook. The computers check the same rules, and accepted payments are grouped into pages that are extremely difficult to rewrite. Bitcoin Cash is the digital payment system; BCH is its native money.
A cryptocurrency is digitally transferable value secured by cryptography. A blockchain is the ordered public record of transactions. A decentralized network has many independently operated computers rather than one controlling server. Peer-to-peer means users can transfer value directly through that network. “Digital cash” describes BCH's intended role: transferable electronic money that can be held and sent without asking a bank to update its private ledger.
BCH is a coin, not a token. It is the native asset used to pay fees and reward miners on the Bitcoin Cash blockchain. It is not an ERC-20 token and does not run on Ethereum or another host chain. Bitcoin Cash has its own blockchain, nodes, miners, consensus rules and transaction history.
Why was Bitcoin Cash created?
Bitcoin originally limited blocks to roughly 1 MB. As usage increased, a block could hold fewer transactions than users wanted to submit. Transactions competed for space, fees could rise, and confirmation could take longer during congestion.
The community disagreed about scaling. One broad camp preferred keeping base-layer blocks relatively constrained while expanding capacity through changes such as Segregated Witness (SegWit) and off-chain or layered systems. Another preferred increasing on-chain block capacity so more ordinary payments could fit directly into blocks.
Think of a crowded road. One group wants to keep the main road compact and add alternate routes; another wants to widen the road. Neither choice removes trade-offs.
On 1 August 2017, software enforcing Bitcoin Cash's new, incompatible rules split from Bitcoin at block height 478,558. BCH initially allowed blocks up to 8 MB and added replay protection. The chains shared all history before the split, then developed independently. Owners controlling bitcoin before the fork could generally control an equal numerical amount on each branch, subject to wallet and exchange handling.
What is a hard fork?
Nodes are computers that apply consensus rules: rules defining which transactions and blocks are valid. A soft fork tightens rules so upgraded blocks remain acceptable to older nodes in important respects. A hard fork introduces rules old software does not accept.
Suppose old nodes reject any block larger than X, while upgraded nodes accept a larger block. Once a larger block appears, old and new nodes disagree. If meaningful groups continue both rule sets, two chains result. That is what happened with BTC and BCH. A hard fork is a software-rule split, not simply a copy-and-paste marketing launch.
How BCH works: Alice sends 1 BCH to Bob
Alice's wallet builds a transaction using spendable outputs she controls.
It names those previous outputs as inputs and creates new outputs, including one for Bob and usually change for Alice.
Alice's wallet uses her private key to create a digital signature. The key itself is not broadcast.
The wallet broadcasts the signed transaction to peers.
Nodes independently check syntax, signatures, scripts, values, and whether the inputs are unspent.
Valid transactions propagate and wait in nodes' memory pools.
Miners select transactions and construct candidate blocks.
Mining hardware repeatedly hashes the block header, changing the nonce and related fields, seeking a hash below the current target.
A successful miner broadcasts the block.
Nodes verify the proof of work and every transaction. If valid, they extend their best valid chain.
Bob's payment now has one confirmation: one accepted block contains it.
Each valid block built on top adds another confirmation and makes reversal progressively more difficult.
A confirmation is not a message from one central authority. It means the transaction is buried at a particular depth in the most-work valid chain recognized by the node observing it. Merchants choose confirmation requirements according to value and risk; seeing an unconfirmed transaction is not the same as irreversible settlement.
BCH transactions: UTXOs, inputs and outputs
BCH does not maintain bank-style account balances at protocol level. It tracks unspent transaction outputs, or UTXOs.
Assume Alice controls one 2 BCH UTXO and wants to send 0.75 BCH. Her transaction can be represented as:
Component | Amount | Destination |
Input | 2.000 BCH | Previous UTXO Alice can unlock |
Output 1 | 0.750 BCH | Bob |
Output 2 | 1.249 BCH | Alice's change address |
Difference | 0.001 BCH | Miner fee |
The 2 BCH output is consumed completely. Two new UTXOs are created. The fee is not normally a separate output; it is the difference between total inputs and total outputs.
Each input references a previous transaction ID and output index and provides unlocking data, commonly a signature and public key. Each output contains an amount and a locking script describing the conditions for spending it. The transaction ID (TXID) is derived from serialized transaction data.
What is a UTXO?
A UTXO resembles a cash denomination. If you have a $100 bill and owe $20, you spend the whole bill and receive change; you do not erase $20 from the paper. Likewise, spending a BCH output consumes it and creates new outputs.
Unspent output: available to be used as a future input.
Spent output: already referenced by an accepted transaction and unavailable again.
Change: a new output returned to a wallet-controlled address.
Why it matters: UTXOs let every node detect double spending and calculate spendable value from independently verifiable records.
Wallets sum controlled UTXOs and display the result as a convenient balance.
Mining and Proof-of-Work
Miners do not guess an ordinary equation's answer. They create a candidate block header and apply double SHA-256 hashing repeatedly. A hash behaves like a compact digital fingerprint: a tiny input change gives an unpredictable output.
For a block to be valid, its header hash interpreted as a number must be at or below the network's target. Miners vary the nonce and other changeable data until somebody finds a qualifying hash. Greater difficulty means a lower target and, statistically, more attempts.
The winner may include a coinbase transaction paying the allowed subsidy plus transaction fees. As of 21 September 2026, the subsidy is 3.125 BCH per block. Coinbase outputs mature after 100 blocks before being spendable. Other miners immediately start building on the accepted block, so delaying or publishing invalid work risks losing electricity and revenue.
Miner revenue ≈ block subsidy + included transaction fees. It is not guaranteed profit; hardware, energy, facilities, pool fees and unsuccessful work create costs.
What is inside a BCH block?
A block contains transactions and an 80-byte header. Important header fields are:
version;
previous block hash;
Merkle root summarizing the block's transactions;
timestamp;
compact difficulty target (nBits);
nonce.
The block hash is derived from the header. The previous-hash field connects each block to its parent:
Block 100 → Block 101 → Block 102 → Block 103
Changing an old transaction changes its TXID, the Merkle root, and that block's hash. Later blocks would then point to the old hash, so an attacker would need to redo that block's proof of work and catch up with continuing honest work. This makes history costly to rewrite, not mathematically impossible.
Consensus and difficulty adjustment
Consensus is the result of independent nodes enforcing compatible rules. Nodes reject invalid blocks even if a miner created them. When valid branches compete, BCH follows the valid chain with the greatest cumulative proof of work—often shortened imprecisely to the “longest chain.”
BCH targets an average block interval of 600 seconds (10 minutes). Actual intervals vary randomly. Since November 2020, BCH has used ASERT (aserti3-2d), which adjusts the target smoothly based on time and height relative to an anchor. Its mainnet half-life parameter is 172,800 seconds (two days). If blocks trend too fast, mining becomes harder; if too slow, it becomes easier. The algorithm targets an average, not a ten-minute guarantee for each block.
Block size and scaling
BCH emphasizes base-layer, or on-chain, capacity. It began with an 8 MB limit and moved to 32 MB in May 2018. Since 15 May 2024, the Adaptive Blocksize Limit Algorithm (ABLA) adjusts the consensus maximum using prior block utilization.
The crucial current description is therefore not simply “BCH has a fixed 32 MB limit.” The algorithm began with—and cannot fall below—a 32 MB floor. Capacity may grow gradually when sustained usage justifies it and shrink gradually when it does not. Current BCHN software also applies a temporary 2 GB cap because of peer-to-peer and block-file format constraints. A miner's configured block template may be smaller than the consensus maximum.
Larger capacity can admit more transactions and reduce competition for space. The trade-off is that very large blocks need more bandwidth, storage, validation capacity and propagation performance, potentially raising node-operating costs. Low utilization also means current fees do not prove what fees would be under every future demand level.
Bitcoin (BTC) vs Bitcoin Cash (BCH)
Feature | Bitcoin (BTC) | Bitcoin Cash (BCH) |
Origin | Original network launched in 2009 | Hard fork of Bitcoin in 2017 |
Fork date | Not applicable | 1 August 2017, height 478,558 |
Blockchain | Independent BTC chain | Independent BCH chain |
Consensus | Proof-of-Work, most cumulative work | Proof-of-Work, most cumulative work |
Mining algorithm | Double SHA-256 | Double SHA-256 |
Target block time | About 10 minutes | About 10 minutes |
Capacity approach | Block weight; base block plus witness accounting | ABLA adaptive byte limit, 32 MB floor |
Supply cap | Approximately 21 million | Approximately 21 million |
Current subsidy | 3.125 BTC | 3.125 BCH |
Halving | Every 210,000 blocks | Every 210,000 blocks |
Transaction model | UTXO | UTXO |
Design emphasis | Scarce settlement asset with layered scaling | Peer-to-peer electronic cash with more on-chain capacity |
Typical fees | Demand-dependent, often higher during congestion | Demand-dependent, generally low under present utilization |
Scaling philosophy | More conservative base layer; layers such as Lightning | Larger/adaptive base-layer capacity; additional applications possible |
Programmability | Bitcoin Script, Taproot and related tools | BCH VM, CashTokens, covenants and 2025–26 VM upgrades |
Major uses | Savings/speculation, settlement, payments, Lightning | Payments, transfers, speculation, tokens and contract applications |
Neither column makes one network universally “better.” They share pre-fork history but now have incompatible rules, different assets and independent development directions.
Supply, issuance and tokenomics
Maximum supply: approximately 21 million BCH under current consensus rules.
Circulating supply: about 20.09 million BCH on 21 September 2026; data providers can differ slightly.
New issuance: created in the coinbase transaction, currently up to 3.125 BCH per valid block.
Schedule: subsidy halves every 210,000 blocks.
Inflation: new-supply inflation declines over time; it is not zero yet.
Lost coins: BCH controlled by lost keys may remain on-chain but be economically inaccessible. No authoritative lost-coin count exists.
Miner incentive: subsidy plus fees, less operating costs.
Circulating supply is an estimate of issued, circulating units; it is not market capitalization. Market capitalization is price multiplied by a supply measure.
BCH halvings
Event | Block height | Date | Subsidy after event |
BCH inherited pre-fork schedule | 420,000 | 9 July 2016 on shared history | 12.5 BCH-equivalent history |
First post-fork BCH halving | 630,000 | 8 April 2020 | 6.25 BCH |
Second post-fork BCH halving | 840,000 | 4 April 2024 | 3.125 BCH |
Next scheduled halving | 1,050,000 | Expected in 2028; exact date depends on blocks | 1.5625 BCH |
Halving reduces new issuance; it does not halve existing balances or guarantee a price change. It can change miner revenue and may influence how SHA-256 miners allocate hardware among compatible chains.
Who secures and uses the network?
Full nodes
Download and validate blocks and transactions against consensus rules. They do not blindly trust miners.
Miners
Assemble transactions, perform proof of work, order valid blocks and earn subsidy plus fees. Miners cannot make invalid coins acceptable to correctly validating nodes.
Wallets
Manage keys, discover controlled UTXOs, construct transactions and show human-readable balances. Coins are not literally stored inside the app; UTXOs exist in the blockchain record, while keys provide control.
Developers
Research, propose, implement, test and maintain node, wallet and application software. Code becomes a network rule only when the relevant ecosystem deploys and enforces it.
Users and businesses
Choose software and services, accept or reject BCH economically, and decide what confirmations and custody practices meet their needs.
Wallets, keys and addresses
A private key is secret signing material. A public key can be derived from it and used to verify signatures. An address is a payment destination derived from or committed to spending conditions. Think of an address as a mailbox slot and the private key as the only key that opens it—though blockchain payments are public records, unlike sealed mail.
A seed phrase backs up a hierarchy of wallet keys. Anyone with it may be able to spend the wallet's funds. Never send a seed phrase or private key to support staff, websites or strangers. Back it up offline and test recovery safely.
BCH commonly uses CashAddr, recognizable as bitcoincash: followed by an encoded payload; interfaces may omit the prefix. Legacy Base58 addresses also exist, and newer script types add further formats or semantics. Because some legacy BTC and BCH address encodings can look similar, never assume compatibility. Verify the asset, network, address format and receiving service before sending. A blockchain transfer normally cannot be reversed by customer support.
What BCH can be used for
Use | How and example | Potential benefit | Limitation |
Peer-to-peer payment | One wallet sends directly to another | No bank required to update the ledger | Volatility, key management and confirmation risk |
Merchant payment | Customer scans a merchant QR code | Fast broadcast and generally low current fees | Acceptance and refund procedures vary |
Remittance | Sender transmits BCH internationally | 24/7 network and fewer protocol intermediaries | Fiat on/off ramps, compliance and price movement can dominate cost |
Online or small payments | Website requests a small BCH amount | Fine-grained UTXOs and low-fee environment | Wallet friction and limited adoption |
Exchange transfer | User deposits or withdraws BCH | Portable between supporting platforms | Custodial delay, network mistakes and exchange risk |
Savings/speculation | User holds BCH as a scarce crypto asset | Self-custody possible | High market volatility; no guaranteed return |
Token and contract apps | CashTokens and BCH scripts create programmable UTXOs | Native tokens and conditional payments | Smaller developer ecosystem and different model from Ethereum |
These are capabilities, not proof of widespread use in every country.
Complete payment example: Sarah sends 0.1 BCH to Luke:
Sarah in USA buys BCH through a lawful service available to her. Luke sends a BCH CashAddr through a trusted channel. Sarah confirms that both wallets are using Bitcoin Cash— not BTC or an unrelated token network.
Her wallet might select a 0.15 BCH UTXO, estimate a fee from transaction size and policy, create 0.1 BCH for Luke and roughly 0.04999 BCH change for Sarah. Exact values depend on fee rate and serialized bytes. The wallet signs the selected input locally and broadcasts the transaction.
Sarah sees “sent” or “pending” and a TXID. Luke's wallet may detect the unconfirmed output within seconds, but that observation is not a block confirmation. Nodes check that the input exists, is unspent, has sufficient value, and satisfies its script. A miner includes it in a block; both wallets then show one confirmation. Later blocks increase depth. Luke can spend his new 0.1 BCH UTXO, subject to his wallet's policy; ordinary outputs do not need coinbase maturity.
Real-world caveats remain: exchange identity checks, USA and destination-country rules, conversion spreads, taxes, internet access and BCH price changes are outside consensus.
Transaction fees
A fee rewards the miner that includes a transaction and helps price scarce block resources. Wallets commonly estimate fees from serialized transaction size in bytes and a fee rate. More inputs, outputs or complex scripts usually mean more bytes and therefore a larger total fee at the same rate.
For example, a 250-byte transaction at 1 satoshi per byte costs 250 satoshis, or 0.00000250 BCH. That is only an illustration, not a promised network price. Nodes and miners can set relay/mining policies; demand and wallet estimation can change. BCH is not inherently free.
Current ecosystem snapshot
As of September 2026, active or documented categories include:
Node software: Bitcoin Cash Node (BCHN), BCHD and compatible implementations.
Wallets: Electron Cash, Paytaca, Selene and other custodial or non-custodial products; availability and maintenance should be checked before use.
Infrastructure: Fulcrum index servers, public explorers such as Blockchair and BCH-focused explorers, merchant APIs and developer libraries.
Exchanges/payment services: numerous global platforms list BCH, but jurisdiction, custody and withdrawal support vary.
Applications: payment tools and CashTokens-based exchanges, token projects and contract applications.
This is a category snapshot, not an endorsement. Check a project's current releases, reproducibility, security reviews, custody model and official domain before depositing funds.
Major BCH upgrades
Date | Major change | Purpose and consensus impact |
1 Aug 2017 | BCH hard fork; 8 MB capacity; replay protection | Created independent consensus rules and chain |
13 Nov 2017 | New DAA (CW-144) | Replaced emergency adjustment behavior; consensus change |
15 May 2018 | 32 MB limit; restored opcodes | More capacity and scripting; consensus change |
Nov 2018 | OP_CHECKDATASIG; canonical ordering; BCH/BSV split | Contract/data-signature changes; contentious consensus fork |
May/Nov 2019 | Schnorr signature support expanded | More efficient/flexible signatures; consensus changes |
15 Nov 2020 | ASERT DAA; BCH/eCash split | Smoother difficulty; consensus change |
15 May 2021 | Removed unconfirmed-chain limit at consensus level; multiple OP_RETURNs | Transaction chaining/data policy improvements |
15 May 2022 | Native introspection, larger script integers, new opcodes | Stronger covenants/contracts; consensus change |
15 May 2023 | CashTokens, P2SH32, transaction-version/minimum-size rules | Native tokens and contract/security improvements; consensus change |
15 May 2024 | ABLA | Adaptive block-size maximum with 32 MB floor; consensus change |
15 May 2025 | Targeted VM Limits and BigInt | More capable and efficiently bounded contracts; consensus change |
15 May 2026 | P2S, bounded loops, functions, bitwise operations | Reusable and more expressive scripts with bounded resources; consensus change |
Not every software release is a protocol upgrade, and not every proposal activates. Nodes must implement activated rules to remain compatible.
Security
Network security
Proof of work makes competing history costly. BCH uses the same SHA-256 algorithm as BTC, so miners can redirect compatible equipment. BCH's much smaller share of total SHA-256 work than BTC is a relevant security consideration: the cost of challenging BCH is not the same as challenging BTC.
A 51% attack means an attacker controls a majority of active hash power long enough to outpace honest miners. They could attempt to reverse their recent payments, censor transactions or reorganize blocks. They could not forge another user's valid signature or spend coins without keys. More confirmations raise the work needed to reverse a transaction, though no fixed depth eliminates all risk.
User security
Protocol rules cannot protect a user who reveals a seed phrase, installs malicious wallet software, sends to the wrong network, or trusts a fraudulent exchange. Use verified software, small test payments, hardware or offline key protection where appropriate, backups, and independent address confirmation for large transfers.
Risks and limitations
Market risk: BCH's price can change sharply, even during a payment.
Network risk: hash-rate concentration, pool outages, reorganizations and majority attacks remain possible.
Adoption risk: merchant, wallet and liquidity support varies and can decline.
Development risk: bugs, incompatible implementations or contentious upgrades can disrupt services.
Competition: BTC, stablecoins, other chains, cards, banks and mobile-payment systems compete on different strengths.
Regulatory risk: legality, taxation, reporting and service access differ by jurisdiction and change over time.
User error: wrong addresses/networks, lost backups, scams and malware can cause irreversible loss.
Capacity trade-off: larger blocks can improve throughput but increase resource demands.
Long-term incentive risk: halvings reduce subsidy, so sustainable miner revenue increasingly depends on BCH price, fees and use.
Common misconceptions
Is BCH the same as BTC?
No. They share history before August 2017 but are independent assets and networks.
Is BCH “just Bitcoin” or an ERC-20 token?
It descends from Bitcoin's code and ledger history, but it has its own chain. It is not an Ethereum token.
Is one company in control?
No single company can unilaterally make all independently validating nodes accept new rules. Influence is nevertheless uneven among developers, miners, pools, businesses and infrastructure operators.
Can BCH be mined, and does it use Proof-of-Work?
Yes. It uses double SHA-256 Proof-of-Work.
Is supply fixed?
Current consensus limits issuance to approximately 21 million BCH, with subsidy halvings every 210,000 blocks.
Are BCH and BTC addresses interchangeable?
No operationally. Some legacy encodings can look compatible, which increases danger. Always use the correct network and supported BCH address format.
Can I send BTC directly to a BCH address?
Do not do so. BTC and BCH transactions are recorded on different chains. Recovery may be impossible or require the receiving party's cooperation.
Is BCH centralized?
It is a decentralized protocol with multiple participants, but decentralization is not binary. Mining-pool shares, node diversity, development influence and service concentration should be evaluated separately.
Are transactions anonymous?
No. BCH is generally pseudonymous: addresses need not show legal names, but transactions and amounts are public and blockchain analysis may link activity to identities.
What if I lose my private key or seed?
If no backup or recovery mechanism exists, the BCH is usually permanently inaccessible.
BCH vs stablecoins for payments
Factor | BCH | Stablecoin |
Price | Market-driven and volatile | Targets a reference asset; can depeg |
Settlement | Native BCH chain settlement | Depends on issuer plus host chain |
Monetary policy | Algorithmic capped issuance | Issuer/redemption and reserve policy |
Censorship resistance | No central token issuer | Issuer may freeze supported tokens |
Fees | BCH network fee | Host-chain fee; sometimes additional service costs |
User experience | One native coin/network | Must choose correct issuer, token contract and chain |
Key risk | Volatility and network security | Issuer, reserve, depeg, contract and host-chain risk |
|
Stablecoins may reduce short-term price volatility; BCH offers a native, issuer-free monetary asset. The best fit depends on the transfer's purpose and constraints.
BCH vs traditional banking
Factor | Traditional international bank transfer | BCH transaction |
Intermediaries | Banks and sometimes correspondents | Wallet, peer network and miners; exchanges optional |
Hours | Service and settlement windows may apply | Network operates continuously |
Settlement | Institutional ledger process | Probabilistic finality through confirmations |
Fees | Bank, correspondent and FX charges | Network fee plus any exchange/spread costs |
Reversibility | Disputes, recalls or chargebacks may exist | Valid confirmed transfers are normally irreversible |
User control | Custodian controls account access | Self-custody possible |
Identity | Regulated institutions require identification | Protocol address creation does not; services may require KYC |
Unit stability | Fiat unit usually less volatile locally | BCH price can move sharply |
Protection | Legal, fraud and deposit protections may apply | Protections depend on service; self-custody has no help desk |
The systems solve overlapping but different problems. Banking's controls can add cost and delay but also consumer protection, regulated identity and recourse.
Beginner glossary
Term | Simple definition |
BCH | Native coin of the Bitcoin Cash network |
BTC | Native coin of the separate Bitcoin network |
Blockchain | Ordered, replicated history of valid blocks |
Block | Header plus a batch of validated transactions |
Node | Computer that communicates and applies network rules |
Miner | Participant building blocks and performing proof of work |
Proof-of-Work | Security mechanism requiring verifiable computational work |
Hash | Fixed-length fingerprint of data |
SHA-256 | Hash function used twice in BCH mining/block identification |
UTXO | Unspent transaction output available to spend |
Input | Reference to a prior output being spent |
Output | New amount plus conditions for spending it |
Private key | Secret used to authorize spending |
Public key | Public value used to verify a signature |
Address | Encoded payment destination or script commitment |
Wallet | Software/device that manages keys and transactions |
Seed phrase | Human-readable backup for deriving wallet keys |
Transaction | Data consuming inputs and creating outputs |
Confirmation | Inclusion in the accepted chain; depth increases with later blocks |
Block reward | Common phrase for subsidy plus fees; subsidy is newly issued BCH |
Transaction fee | Input value minus output value, claimable by miner |
Difficulty | Measure of how hard it is to find a valid header hash |
Hash rate | Hash attempts performed per second |
Halving | Subsidy reduction by half every 210,000 blocks |
Hard fork | Incompatible consensus-rule change |
Consensus | Shared validation outcome from compatible rules |
Merkle root | Header commitment summarizing block transactions |
Double spend | Attempt to spend the same output more than once |
51% attack | Majority-hash-power attempt to reorganize or censor chain activity |
If You Remember Only 10 Things About BCH
Bitcoin Cash is an independent blockchain and BCH is its native coin, not an ERC-20 token.
BCH split from Bitcoin through a hard fork on 1 August 2017 after a scaling dispute.
It aims primarily at peer-to-peer electronic payments with more on-chain capacity.
BCH uses UTXOs: transactions consume old outputs and create new recipient and change outputs.
Private keys authorize spending; losing the only key or seed can mean permanent loss.
Nodes validate rules, while miners order transactions and secure blocks with SHA-256 Proof-of-Work.
A confirmation means block inclusion; additional blocks increase reversal difficulty.
BCH targets ten-minute blocks, uses ASERT difficulty adjustment and has adaptive block capacity with a 32 MB floor.
Current issuance is 3.125 BCH per block, halvings occur every 210,000 blocks, and supply approaches 21 million.
BCH offers useful payment and contract capabilities but carries volatility, adoption, security, regulatory and user-error risks.
Sources and research notes
Primary and technical sources were preferred. Market figures are dated snapshots and may differ among providers.
Comments