Provide a concise narrative that clearly states each of (a)–(e) below.
Bitcoin Cash is publicly described as carrying forward the vision of affordable peer-to-peer electronic cash for the world, with low fees and reliable confirmations for everyday digital commerce.
(Source: Bitcoin Cash, Bitcoin Cash - Wang elektronik langsung P2P)
The cited materials point to a decentralized maintenance model rather than an issuer-run operating company. Publicly stated priorities include keeping transactions fast and inexpensive, maintaining reliable confirmations, evolving the protocol through the public CHIP process, and coordinating security disclosures through node-implementation maintainers.
(Source: Bitcoin Cash, HF-20210515, Responsible disclosure - Bitcoin Cash Node documentation)
At a high level, Bitcoin Cash is a peer-to-peer network secured by SHA-256 proof-of-work in which blocks contain a miner-created coinbase transaction plus additional transactions. Public protocol materials also show that BCH continues to evolve through coordinated hard-fork upgrades such as ASERT in 2020, ABLA in 2024, and a scheduled May 15, 2026 upgrade that implements four additional consensus-level CHIPs.
(Source: Bitcoin Cash, Bitcoin: A Peer-to-Peer Electronic Cash System, Block 2020-11-15 ASERT, Bitcoin Cash Node v27.0.0, Bitcoin Cash Node v29.0.0 2026-05-15 Network Upgrade Specification)
Publicly, BCH functions as electronic cash, pays for transaction activity on the network, and compensates miners through block rewards and transaction fees. The reviewed public homepage also states that BCH supports tokenized applications through CashTokens, but BCH itself remains the native asset used for fees and miner incentives.
(Source: Bitcoin Cash, Block)
The reviewed public control surface is consensus- and implementation-based rather than issuer-based. Public materials state that no single group or project can control Bitcoin Cash, while the CHIP process allows any community member to propose changes that are evaluated publicly and scheduled only after sufficient support among node developers.
(Source: Bitcoin Cash, HF-20210515)
For each existing entity: Labs/DevCo (e.g., Founder, CEO, CTO, COO), Foundation (e.g., President, Executive Director, CFO, COO), and DAO / onchain governance leadership (if applicable) list the: (a) full names, (b) official titles, (c) and prior experience of key team members. For any non-existent entity, explicitly mention it does not exist. External links may be included but they will not factor into the score.
Full Name | Entity | Official Title | Prior Experience |
|---|---|---|---|
freetrader | Labs | Lead Maintainer | freetrader is one of the original creators of Bitcoin Cash and a co-founder of Bitcoin ABC, the reference client used at the August 2017 chain split. He was a contributor to the BTCfork project and a member of Bitcoin Unlimited prior to founding BCHN. |
Calin Culianu | Labs | Maintainer and Developer, BCHN, Fulcrum & Electron Cash | The cited BCHN team page identifies parallel experience with Fulcrum and Electron Cash. |
Fernando Pelliccioni | Labs | Contributor | The cited BCHN team page identifies Fernando Pelliccioni as Knuth Node Lead Developer. |
Tracy Chen | Labs | BCHN Representative | Tracy Chen entered the cryptocurrency industry in 2018 as a traditional media professional. Prior to joining BCHN she worked in the marketing teams of Bitmain and Matrixport. |
Blockworks note: No primary foundation, DAO or onchain governance leadership body exists for Bitcoin Cash. |
Provide a structured description of the DAO's governance, powers, and economic rights. If a DAO does not exist, state so. Address the lettered items below. Even if there is no DAO, there must be an answer to (d).
No formal DAO exists for Bitcoin Cash. No DAO-specific IP ownership or control applies.
No formal DAO was identified in cited materials. Publicly, coordinated protocol authority appears through the CHIP process and voluntary software adoption: any community member can publish a CHIP, proposals are evaluated publicly, and a supported CHIP is scheduled into a future hard fork only after sufficient support among node developers. Public BCH materials also state that no single group or project can control the network.
(Source: HF-20210515, Bitcoin Cash)
No BCH locking or staking mechanism exists that grants holders additional governance rights. The reviewed BCH record instead describes proof-of-work mining, miner block rewards, and open protocol coordination rather than token-lock governance.
(Source: Block, Bitcoin Cash)
No formal DAO exists for Bitcoin Cash and there is no protocol treasury or issuer-controlled revenue stream. BCH tokenholders have no rights over revenue distribution. Value accrual to holders is instead a function of three programmatic mechanisms embedded in the protocol: a fixed supply cap of 21 million BCH enforced by network nodes; a halving mechanism that cuts the block subsidy in half every 210,000 blocks, with the most recent halving reducing the per-block reward to 3.125 BCH; and a transaction fee market that will serve as the primary miner incentive as the block subsidy approaches zero. No governance mechanism exists by which holders can vote on distributions, claim treasury assets, or redirect fees.
(Source: Bitcoin Cash, HF-20210515)
No formal DAO exists for Bitcoin Cash. No dissolution or wind-up mechanism applies.
For the Primary Foundation do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
No primary foundation exists for Bitcoin Cash.
Not applicable. No primary foundation exists for Bitcoin Cash.
Not applicable. No primary foundation exists for Bitcoin Cash.
Not applicable. No primary foundation exists for Bitcoin Cash.
Not applicable. No primary foundation exists for Bitcoin Cash.
Not applicable. No primary foundation exists for Bitcoin Cash.
For the Primary DevCo do the following independently. If an entity does not exist, state that explicitly. Items (a)–(f) apply only if that entity exists; state explicitly that the entity doesn't exist. Definitions: The primary Foundation and DevCo can be explained as those entities which are directly involved in the issuance of the native token at launch.
No primary DevCo exists for Bitcoin Cash. The August 2017 chain split involved no single issuing entity; multiple independent implementations exist and no single group or project controls the network. Public BCH sources do identify BCHN as one named implementation team with listed maintainers, developers, and a representative, but BCHN's launch materials describe it as an alternative client created to avoid a chain split and supported by contributors from several other BCH implementations. That public record does not amount to a protocol-wide primary DevCo with unilateral BCH control.
(Source: Team | Bitcoin Cash Node, Announcement regarding Bitcoin Cash Node, Full nodes, Bitcoin Cash)
Not applicable. No primary DevCo exists for Bitcoin Cash.
Not applicable. No primary DevCo exists for Bitcoin Cash.
Not applicable. No primary DevCo exists for Bitcoin Cash.
Not applicable. No primary DevCo exists for Bitcoin Cash.
Not applicable. No primary DevCo exists for Bitcoin Cash. The reviewed BCHN public record instead shows post-launch implementation-team funding through donations, a Flipstarter campaign, and a 3-of-5 multisig operating wallet, but those materials are not presented as protocol-wide BCH token-distribution policies.
(Source: Bitcoin Cash, BCHN Financial Report 2023-12-31, BCHN flipstarted - thank you to the community)
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
Reviewed public launch materials state that Bitcoin Cash was born when the chain split at block 478558 on August 1, 2017 and that holders of Bitcoin at that split became owners of BCH. Using that cited split height together with the cited BCH subsidy schedule of 50 BCH halving every 210,000 blocks, the implied issued supply at the split height is approximately 16,481,987.5 BCH. The reviewed public BCH record does not provide a separate canonical locked-versus-unlocked launch table. All approximately 16,481,987.5 BCH existing at the split block were immediately accessible to their holders; zero BCH was locked at launch under any issuer-imposed schedule.
(Source: Bitcoin Cash, Bitcoin Cash - Wang elektronik langsung P2P, Block)
Publicly identifiable launch recipients were the Bitcoin holders whose balances existed at the split block. The reviewed public BCH source set did not identify a separate launch allocation schedule for a foundation, DevCo, treasury, or investor-sale bucket.
(Source: Bitcoin Cash - Wang elektronik langsung P2P, Bitcoin Cash)
No fixed initial offering price was identified in reviewed public BCH sources because the reviewed launch record describes a chain split to existing Bitcoin holders rather than an issuer-run sale, auction, or liquidity bootstrapping event.
(Source: Bitcoin Cash - Wang elektronik langsung P2P, Bitcoin Cash)
Bitcoin Cash is commonly represented by BCH/BCC, with XBC also used for ISO 4217 compatibility. Bitcoin Cash - Wang elektronik langsung P2P
Reviewed public BCH sources describe a fixed-cap supply regime. Public materials state that there will never be more than 21 million coins in existence, while protocol documentation states that the block reward started at 50 BCH and decreases by half every 210,000 blocks.
(Source: Bitcoin Cash, Block)
No issuer-run vesting or release schedule was identified in reviewed public BCH sources. The reviewed public launch record instead describes inherited holder balances at the split block plus continuing mining issuance.
(Source: Bitcoin Cash - Wang elektronik langsung P2P, Block)
Address each of the following sub-items based on the project's airdrop status. If a sub-item does not apply to the project's situation, state that explicitly.
No airdrop planned or conducted: BCH has never conducted an airdrop. Tokens originated via the August 1, 2017 chain split, which distributed BCH to all Bitcoin holders at block 478558 on a 1:1 basis by protocol mechanics rather than through a project-run airdrop program.
(Source: Bitcoin Cash - Wang elektronik langsung P2P, Bitcoin Cash)
Projects must disclose all material terms of market-making arrangements that affect token liquidity. If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. For each market maker, include in a table:
If the project has no agreements or deals with market makers, state that explicitly; doing so earns full credit. If no native tokens were loaned or allocated to market makers, state that explicitly; cash/fiat retainers or fees are not required for this item.
Blockworks note: BCH has no market maker agreements or token loans. No issuing entity exists with legal standing to enter such arrangements on behalf of the protocol.
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
If the project has no agreements or deals with CEX or DEX, state that explicitly; doing so earns full credit; cash/fiat fee amounts are not required for this item.
Blockworks note: BCH has no project-side CEX or DEX listing agreements and no native-token listing fees. No issuing entity exists to negotiate such arrangements; exchanges list BCH on their own initiative.
Disclose all prior token sales by the Project — including fundraising rounds, any material OTC sales to investors, and any discounted market-maker sales. For each sale, provide:
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Blockworks note: No prior fundraising, OTC, or discounted market maker sales have occurred for BCH. The token originated via the August 2017 chain split with no issuing entity and no token sale.
(Source: Bitcoin Cash - Wang elektronik langsung P2P, Bitcoin Cash)
If any, list prior exploits or incidents that directly affected the token, token supply, tokenholder balances, token contract, minting controls, burn mechanics, or custody of token supply. This question is not asking about general protocol, application, or smart contract exploits unless the incident directly affected the native token itself. If no prior incidents, state this explicitly (e.g., "No exploits affecting tokenholders or protocol funds as of YYYY-MM-DD").
Reviewed public BCH sources identify multiple documented software-security incidents affecting node implementations and mining operations rather than a cited loss of protocol treasury assets. Bitcoin ABC published a May 7, 2018 incident report for a critical vulnerability applicable to miners using Bitcoin-ABC 0.17.0, and a May 28, 2019 incident report for a zero-day vulnerability affecting mining in Bitcoin ABC 0.18.x and 0.19.0 through 0.19.5. Later Bitcoin Cash Node release notes also documented a patched JSON-RPC denial-of-service issue in v0.21.1 and operational hardening changes around RPC exposure in v26.0.0.
(Source: Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0)
The 2018 Bitcoin ABC report says an attacker could construct a malicious transaction with the 0x20 signature-hash bitflag set so that Bitcoin-ABC 0.17.0 would accept and mine a block that other compliant Bitcoin Cash implementations would reject, creating unintended chain-split risk. The 2019 Bitcoin ABC report says specially crafted transactions exploited incorrect sigops counting for OP_CHECKDATASIG, causing getblocktemplate failures that prevented miners running affected Bitcoin ABC versions from constructing non-empty blocks. Bitcoin Cash Node v0.21.1 separately describes CVE-2019-18936 as a malformed-JSON path that could crash a node for attackers with limited JSON-RPC access.
(Source: Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1)
The 2019 Bitcoin ABC report says the mainnet exploit lasted for approximately two hours, prevented confirmation of non-coinbase transactions during that period, and created no risk to user funds. The 2018 Bitcoin ABC report frames the earlier issue as a critical vulnerability that could have split Bitcoin ABC and BUCash nodes from the majority BCH chain if exploited. The BCHN release notes describe node-crash risk for exposed JSON-RPC surfaces in v0.21.1 and warn in v26.0.0 that public RPC exposure is insecure, while also noting separate operational risks such as possible out-of-memory errors, scalenet hangs, and Windows wallet-folder corruption if multiple instances share the same wallet directory. None of the documented incidents affected BCH native token supply, user balances, or custody. The 2018 vulnerability was patched before exploitation. The 2019 exploit disrupted block template construction for approximately two hours but, per the incident report, created no risk to user funds. The BCHN JSON-RPC and RPC-exposure issues affected node operation only. No protocol treasury exists for BCH, so no treasury assets were at risk in any of these incidents. As of May 2025, no exploit affecting BCH token supply, user balances, or protocol-level funds has been identified.
(Source: Bitcoin ABC Incident Report (15MAY2019), Bitcoin-ABC incident report (26APR2018), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0)
The reviewed incident reports say Bitcoin ABC prepared patches and private releases for miners, advised affected operators to upgrade, and later stated it was improving response time, improving testing, and discussing a formal bug-bounty system. The 2018 issue was fixed in Bitcoin ABC 0.17.1, and the 2019 issue was fixed in Bitcoin ABC 0.19.6. Bitcoin Cash Node v0.21.1 patched CVE-2019-18936 and a consensus-relevant reconsiderblock issue, while BCHN v26.0.0 changed rpcbind and rpcallowip behavior and warned users not to expose RPC over public networks.
(Source: Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0)
The cited incidents were publicly reported as mitigated through patched releases and operator upgrades. The reviewed public source set does not identify a cited loss of protocol funds from these incidents, but it does show that BCH node software and mining operations have experienced critical vulnerabilities, exploit attempts, and continuing hardening work over time.
(Source: Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0)
The principal cited incident references are the public Bitcoin ABC incident reports from May 7, 2018 and May 28, 2019, plus the Bitcoin Cash Node v0.21.1 and v26.0.0 release notes.
(Source: Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0)
Describe material risk factors across the three categories below. Each category includes prompts to address at a minimum.
(a) Regulatory, Legal & Tax Risks — Describe how evolving laws and regulations could affect the project by answering, at a minimum, questions like:
Impact of Regulatory Change on TGE and Listings: (If applicable) How could evolving or conflicting laws and regulations affect your ability to complete the TGE, deliver tokens to purchasers, and list or maintain the token on trading venues in key jurisdictions?
Entity-Level Regulatory Impact: (If applicable) How could regulatory or legal changes impact your core entities (Foundation, DevCo, DAO, affiliated service providers), including enforcement actions, licensing requirements, or forced changes to structure or operations?
Tokenholder Tax Treatment: (If applicable) What uncertainties exist around how tokenholders may be taxed, and make clear that tokenholders are responsible for understanding their own tax obligations?
Jurisdictional & User Access Restrictions: (If applicable) If the project restricts access for certain jurisdictions or user types (e.g., U.S. persons, sanctioned countries, retail vs. professional), what are those restrictions and what risks do they create for users and for the project?
(b) Protocol, Technology & Security Risks — Describe risks to network and contract reliability, correctness, and safety by answering, at a minimum, questions like:
Bugs and Design Flaws: (If applicable) What bugs, design flaws, or implementation errors could exist in your core protocol code, smart contracts, and any bridges, rollups, or oracles that you depend on, and how could these lead to loss of funds or disruption of the protocol?
Security Measures & Their Limitations: (If applicable) What security measures have you taken (audits, formal verification, bug bounties), and what types of failures might these measures still fail to detect or prevent?
(c) Token Economics, Unlocks & Incentive Risks — Describe how the token's economic design and supply schedule could affect holders by answering, at a minimum, questions like:
Critical Economic Assumptions: (If applicable) Which economic assumptions (e.g., staking yields, fee revenue, liquidity incentives, MEV capture, demand for blockspace) are critical for protocol security, utility, and governance, and what happens if those assumptions fail?
Governance Control over Monetary Policy & Rewards: (If applicable) To what extent can governance change monetary policy, fee parameters, or reward allocations (e.g., inflation rate, treasury flows, incentive programs), and how could such changes adversely affect tokenholders?
Public BCH sources describe a permissionless open network and state that no single group or project can control it, but they do not eliminate venue-level or jurisdiction-level regulatory risk. Changes in exchange, custody, payments, or sanctions regulation could still affect BCH access, listings, and market infrastructure even if the protocol itself remains publicly accessible. No primary foundation or DevCo directly involved in BCH issuance was identified in cited materials, and the Bitcoin Cash Foundation publicly describes itself as an outreach effort that does not control BCH development and has no pre-mine or war chest. That public posture reduces evidence of a central issuer, but node operators, exchanges, custodians, and service providers may still face regulation in their own jurisdictions. No project-specific public tax guidance or project-imposed jurisdictional/user-access restrictions were identified in cited sources. Tokenholders are therefore responsible for understanding their own tax obligations and the rules that apply to any venue or service they use.
(Source: Bitcoin Cash, HF-20210515, Bitcoin Cash Foundation – P2P Electronic Cash for the world)
BCH depends on proof-of-work, peer-to-peer propagation, and software correctness across multiple independent implementations. Public BCH materials say there is no single development team and that multiple independent teams maintain software implementations, and ecosystem directories list BCHN, Bitcoin Unlimited, Bitcoin Verde, Knuth, and BCHD as separate node efforts. That diversity reduces single-operator dependence but also means implementation divergence or coordination failures can disrupt block production, confirmations, or interoperability if a widely used client ships a defect. The reviewed public incident record shows that this risk is not merely theoretical. Bitcoin ABC reported in 2018 that a vulnerability in Bitcoin-ABC 0.17.0 could have caused an unintended BCH network split, and reported in 2019 that an exploited zero-day in affected Bitcoin ABC releases prevented miners from constructing non-empty blocks for approximately two hours, although the report also said there was no risk to user funds. Bitcoin Cash Node v0.21.1 later documented a malformed-JSON denial-of-service vulnerability affecting limited JSON-RPC exposure, BCHN v26.0.0 documented insecure-public-RPC, wallet-corruption, and scalenet-hang risks, and BCHN v29.0.0 still lists a possible out-of-memory error at high excessiveblocksize values while stating that ABLA is temporarily capped at 2GB because of p2p and block-file limitations. Reviewed public BCH sources do show some security measures. Bitcoin Cash Node publishes a responsible-disclosure policy, requests encrypted reporting to security@bitcoincashnode.org, and BCHN's goals emphasize specification-driven development, node diversity, and cooperative testing intended to protect BCH from catastrophic failures. Bitcoin ABC's 2018 and 2019 incident reports also describe follow-up testing improvements and public discussion of a bug-bounty system. Those measures may reduce exposure windows, but the cited incident history shows they cannot eliminate every consensus, implementation, or operational failure. The public record also shows that BCH consensus policy continues to change through upgrades such as ASERT in 2020, ABLA in 2024, and the scheduled May 15, 2026 activation of P2S, bounded loops, functions, and bitwise operations. Those upgrades may improve network behavior, but they also mean future design mistakes, coordination failures, or client-implementation errors in upgrades could affect reliability or transaction processing.
(Source: Bitcoin Cash, Bitcoin Cash - Die elektronischi Peer-to-Peer Währig, Bitcoin: A Peer-to-Peer Electronic Cash System, Full nodes, Bitcoin-ABC incident report (26APR2018), Bitcoin ABC Incident Report (15MAY2019), Bitcoin Cash Node v0.21.1, Bitcoin Cash Node v26.0.0, Bitcoin Cash Node v29.0.0, 2020-11-15 ASERT, 2026-05-15 Network Upgrade Specification)
Public BCH monetary-policy sources show that network security depends on miner incentives funded by block rewards and transaction fees. Because the subsidy started at 50 BCH and halves every 210,000 blocks, long-run security assumptions depend increasingly on sustained transaction demand, fee generation, and sufficient hashpower remaining committed to BCH. Reviewed public BCH sources do not identify tokenholder governance over treasury flows or reward allocation. Instead, protocol-level changes proceed through CHIPs, public review, and support among node developers and software adopters. That means monetary-policy-adjacent or throughput-related changes can still occur through social and technical coordination even though the public record does not show tokenholder voting rights over those parameters.
(Source: HF-20210515, Bitcoin Cash Node v27.0.0, Block)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.
