Bitcoin
Networks · Layer-1Token Transparency Filing
Project & Team
Description of Project
Provide a concise narrative that clearly states each of (a)–(e) below.
- (a) Problem the project solves — The problem the project is solving.
- (b) Operational priorities — Provide a high-level description of how the project expects to support ongoing development and operations over time.
- (c) High-level project overview — How the project works at a high level.
- (d) Primary token functions — The primary functions of the token (e.g. gov participation).
- (e) Control surface reliance — If any, briefly describe the anticipated or possible evolution of the protocol's governance/control model.
(a) Problem the project solves
Bitcoin is a consensus network that enables a new payment system and a completely digital money, and it is described as the first decentralized peer-to-peer payment network powered by its users with no central authority or middlemen.
(Source: Press - Bitcoin, Bitcoin FAQ)
(b) Operational priorities
Operationally, the public record points to an open-source maintenance model rather than an issuer-led operating company: Bitcoin Core uses an open contributor workflow, project merge maintainers decide whether to merge pull requests while considering contributor consensus, and Bitcoin software is still described as beta software with incomplete features in active development.
(Source: Contributing to Bitcoin Core, Bitcoin Core :: About, Press - Bitcoin)
(c) High-level project overview
At a high level, Bitcoin relies on a shared public blockchain, digitally signed transactions, and mining as a distributed consensus system that confirms pending transactions, enforces chronological order, and allows different computers to agree on the state of the system.
(Source: How does Bitcoin work? - Bitcoin)
(d) Primary token functions
Publicly, Bitcoin’s primary functions are to act as digital money or "cash for the Internet," to transfer value between wallets, and to compensate miners through block rewards and transaction fees for transaction processing and network security.
(Source: Press - Bitcoin, Mining - Bitcoin, Transactions - Bitcoin)
(e) Control surface reliance
The public control surface is consensus-based rather than issuer-based. Bitcoin is controlled by users, developers cannot force protocol changes because users choose what software to run, and BIP authors are responsible for building community consensus while Bitcoin Core changes flow through the contributor workflow and merge maintainers.
(Source: About bitcoin.org, Bitcoin FAQ, BIP process, revised, Contributing to Bitcoin Core Bitcoin Core :: About)
Known Project Team
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 |
|---|---|---|---|
Blockworks note: Bitcoin is described as a user-controlled network with no official website or central authority, and Bitcoin Core as an open-source software project with contributors and maintainers rather than a corporate operator. No Labs/DevCo, Foundation, DAO, or onchain governance leadership body exists for Bitcoin. The public governance process operates through user consensus, the Bitcoin Improvement Proposal (BIP) process, and open-source contribution workflows rather than any formal officeholder structure. |
DAO Structure
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).
- (a) IP ownership & control — State what IP the DAO owns or controls (e.g., codebases/repos, trademarks/brands). Note any license if relevant.
- (b) Contract/admin powers — List onchain or administrative authorities and limits: pause/upgrade roles (e.g., multisig pause), governance-executor authorities, and the method of authority for each (e.g., veto, majority, super-majority).
- (c) Locked-token rights (conditional) — If locking/staking for additional rights exists, explain the additional rights and what tokenholders can and cannot decide. If no locking mechanism exists, leave absent.
- (d) Value accrual & holder rights — If any, describe the current rights of tokenholders over revenue distribution and the treasury.
- (e) Dissolution authority — State who can dissolve/wind up the DAO and by what mechanism (e.g., onchain vote threshold, board resolution of a legal wrapper).
(a) IP ownership & control
No DAO exists for Bitcoin. No DAO-specific IP ownership or control applies.
(b) Contract/admin powers
Bitcoin has no formal onchain governance body or legal-wrapper DAO. The protocol is controlled by users. Developers cannot force a protocol change because users choose what software to run. Mining is designed so that no group or individual can control what is included in the blockchain or replace parts of it to roll back their own transactions. The BIP process places responsibility on BIP authors to build community consensus, and Bitcoin Core's contributor workflow gives no developer class privileged authority.
(c) Locked-token rights (conditional)
No DAO exists for Bitcoin. No locking or staking mechanism grants BTC holders additional governance rights beyond normal user participation in the network.
(d) Value accrual & holder rights
No DAO exists for Bitcoin, and there is no protocol treasury, no issuer-controlled revenue stream, and no governance-approved distribution mechanism. BTC holders have no rights over revenue distribution in the conventional sense. Value accrual to holders is instead a function of three programmatic mechanisms embedded in the protocol itself:
- Hard supply cap: The protocol enforces a maximum supply of 21 million BTC. No new issuance is possible beyond this ceiling, which network nodes independently enforce. As of 2025, approximately 19.6 million BTC have been mined, representing roughly 93% of the total supply. No entity can expand the supply without a fundamental protocol change requiring near-universal network consensus, which is considered economically irrational for any stakeholder to support.
- Halving mechanism: New BTC issuance is cut by half approximately every four years (every 210,000 blocks). The most recent halving occurred in April 2024, reducing the per-block subsidy from 6.25 BTC to 3.125 BTC. This scheduled decline in new supply, against sustained or growing demand, creates a structural deflationary bias that has historically supported price appreciation for existing holders.
- Transaction fee market: As block subsidies decline toward zero around 2140, miner revenue will transition to being sourced entirely from transaction fees paid by users. This creates a market-driven security model in which network utility and fee demand become the primary economic support for the network's continued operation, directly tying the long-term security and value proposition of BTC to real usage demand.
There is no governance mechanism by which holders can vote on distributions, claim treasury assets, or redirect fees. Value accrual is entirely a function of supply scarcity, issuance schedule, and market demand dynamics.
(e) Dissolution authority
No DAO exists for Bitcoin. No dissolution or wind-up mechanism applies. The Bitcoin network has no legal wrapper that can be formally dissolved.
Blockworks note: No formal DAO exists for Bitcoin. There is no onchain voting body, no legal-wrapper DAO, and no DAO-held IP, administrative keys, or treasury. Bitcoin governance operates through mining-based consensus, user adoption of software, and the BIP process.
Primary Foundation
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.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over DevCo — Explain whether the foundation can exert direct or indirect influence over decision-making of the DevCo.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
No primary foundation exists for Bitcoin. The network has no official website, no central authority, and no single issuing entity. No foundation holds administrative powers over the protocol, treasury, or token issuance.
(Source: About bitcoin.org, Bitcoin FAQ)
(b) IP ownership & control
No foundation owns or controls Bitcoin protocol IP, source code repositories, or trademarks. The Bitcoin Core codebase is open-source software maintained by independent contributors under a public contributor workflow. No subsidiary entities were identified under any foundation structure.
(Source: About bitcoin.org, Bitcoin FAQ)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No foundation holds any powers over Bitcoin. There is no protocol treasury, no issuer-controlled token supply, and no foundation with authority over reward parameters or governance execution. Protocol changes require broad consensus adoption across miners, node operators, and users. No entity can unilaterally impose changes.
(Source: About bitcoin.org, Bitcoin FAQ)
(d) Powers over DevCo
Not applicable. Bitcoin does not have a primary foundation or DevCo.
(e) Contract/admin powers
No foundation holds pause, upgrade, or governance-executor authorities over the Bitcoin protocol. The public record shows protocol governance operates through the Bitcoin Improvement Proposal (BIP) process, open-source contributor review, and voluntary user adoption of software updates, not through any foundation-held administrative key or multisig role.
(Source: About bitcoin.org, Bitcoin FAQ)
(f) Current economic arrangements and distribution policies
No foundation-level economic arrangements or distribution policies exist. Bitcoin's ongoing development is funded through a decentralized ecosystem of independent grant organizations rather than a foundation with protocol-level economic rights. No entity holds protocol-level powers, token issuance authority, or rights over any Bitcoin treasury. Legal responsibility for individual contributions rests with individual contributors and their respective grant organizations. No single entity is legally responsible for Bitcoin's continued operation or development.
(Source: About bitcoin.org, Bitcoin FAQ)
Primary Dev Co
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.
- (a) Entity — Type and jurisdiction.
- (b) IP ownership & control — What IP the entity owns/controls (repos/code, trademarks/brand; license optional) and an explanation of any subsidiary entities.
- (c) Powers over DAO, treasury, protocol-controlled resources, and token administration — If any, describe the current powers over DAO governance, treasury actions, protocol-controlled resources (e.g. revenue), token administration, or reward parameters, and the method/threshold for each.
- (d) Powers over Foundation — Explain whether the DevCo can exert direct or indirect influence over decision-making of the Foundation.
- (e) Contract/admin powers — Pause/upgrade/governance-executor authorities and the method/threshold for each (e.g., veto/majority/super-majority; "3/5 multisig").
- (f) Current economic arrangements and distribution policies — Describe any current governance-approved, contractual, or programmatic mechanisms, if any, by which protocol-controlled resources, treasury assets, fees, revenue, rewards, or token distributions may be directed to this entity, its equityholders, contributors, or other participants. If no such mechanism currently exists, state that explicitly. Do not discuss hypothetical future dividends, repurchases, or distributions unless formally adopted.
(a) Entity
No primary DevCo exists for Bitcoin. Bitcoin Core is an open-source software project maintained by independent contributors operating under a public contributor workflow. It is not a corporate entity and was not involved in issuing BTC at launch. No company with issuer-side control over the token at genesis has been identified in the public record.
(Source: Bitcoin Core :: About, Contributing to Bitcoin Core, About bitcoin.org)
(b) IP ownership & control
No DevCo owns or controls Bitcoin protocol IP, the Bitcoin Core codebase, or related trademarks. The codebase is publicly available and maintained through open-source contributor review. No subsidiary entities were identified under a DevCo structure.
(Source: Bitcoin Core :: About, Contributing to Bitcoin Core, About bitcoin.org)
(c) Powers over DAO, treasury, protocol-controlled resources, and token administration
No DevCo holds any powers over Bitcoin. No protocol treasury exists, no DevCo holds token administration rights, and no entity can unilaterally alter Bitcoin's reward parameters. Protocol changes flow through the BIP process and require voluntary adoption by miners, node operators, and users to take effect.
(Source: Bitcoin Core :: About, Contributing to Bitcoin Core, About bitcoin.org)
(d) Powers over Foundation
Not applicable. Neither a primary DevCo nor a primary foundation exist for Bitcoin.
(e) Contract/admin powers
No DevCo holds pause, upgrade, or governance-executor authorities. Bitcoin Core merge maintainers, currently five individuals, hold de facto influence over what code enters the reference client, but they exercise no onchain administrative key, multisig role, or legal authority over the protocol or its users.
(Source: Bitcoin Core :: About, Contributing to Bitcoin Core, About bitcoin.org)
(f) Current economic arrangements and distribution policies
No DevCo-level economic arrangements or distribution policies exist. Individual Bitcoin Core contributors are funded through the independent grant organizations, none of which hold protocol-level economic rights or receive any programmatic share of transaction fees, block rewards, or token distributions. No governance-approved, contractual, or programmatic mechanism directs protocol-controlled resources to any DevCo or its equityholders because no protocol treasury or DevCo exists.
(Source: Bitcoin Core :: About, Contributing to Bitcoin Core, About bitcoin.org)
Token Supply & Allocations
Initial Allocation
Disclose launch and initial supply details in a single initial allocation schedule covering the token's launch.
- (a) Launch supply totals — The total number of tokens issued at launch, the total number of tokens locked at launch or the total number of tokens unlocked at launch.
- (b) Recipient categories & use of funds — The recipient categories with brief explanations as to how the category will use the tokens so an auditor can distinguish each bucket.
- (c) Initial price per token (if applicable) — The initial price per token at TGE. If the token launched via a liquidity bootstrapping mechanism, auction, or other price-discovery process rather than a fixed offering price, describe that mechanism and the final market set price instead. If no fixed price was set, state so.
- (d) Ticker / market symbol — The ticker/market symbol.
- (e) Total supply & supply regime — The total supply and whether the supply is fixed (if not explain inflation rate or deflation rate).
- (f) Initial vesting / release schedules — The initial vesting/release schedules (identify which categories/recipients are subject to vesting and the high-level timing logic).
(a) Launch supply totals
Bitcoin launched on January 3, 2009 with the mining of the genesis block (block 0), which contained a coinbase transaction of 50 BTC. That 50 BTC has never been spendable and is considered permanently locked. No tokens were pre-mined or issued to any party at launch outside of this first mined block. All subsequent BTC entered circulation exclusively through mining as subsequent blocks were added. There was no issuer-controlled locked or unlocked supply at launch beyond what the mining schedule programmatically released block by block.
(Source: Transactions - Bitcoin, Mining - Bitcoin, Bitcoin FAQ)
(b) Recipient categories & use of funds
The sole recipient category is miners. In solo mining, the block reward and transaction fees from each block go entirely to the individual miner who solved that block. In pooled mining, proceeds are shared among pool participants roughly in proportion to contributed hash power. There are no other recipient categories. No team allocation, no investor allocation, no foundation reserve, and no treasury bucket exist.
(Source: Mining - Bitcoin, Transactions - Bitcoin)
(c) Initial price per token (if applicable)
No fixed offering price was set at launch. Bitcoin used mining-based issuance rather than a fixed-price token sale, auction, or issuer-run launch event. No issuer-set price existed at TGE.
(Source: Bitcoin FAQ, Press - Bitcoin)
(d) Ticker / market symbol
BTC.
(e) Total supply & supply regime
Total supply is capped at 21 million BTC. The supply regime is fixed: issuance is programmatically determined and cannot exceed the cap. New BTC is issued to miners via block subsidies that halve approximately every four years (every 210,000 blocks). Issuance will continue declining until approximately 2140, after which no new BTC will be created and miners will rely solely on transaction fees.
(Source: Bitcoin FAQ, Press - Bitcoin)
(f) Initial vesting / release schedules
No vesting schedule applies. There were no team, investor, or foundation token allocations subject to lockup or release schedules. BTC issuance is governed entirely by the protocol's mining and halving schedule, which is identical for all miners and not subject to any issuer-imposed vesting logic.
(Source: Bitcoin FAQ, Mining - Bitcoin, Transactions - Bitcoin)
Airdrop Process
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.
- (a) Planned but not yet executed airdrop — If the project has planned but not yet airdropped, commit to publishing a recipient wallet list in a public channel and provide it to Blockworks quarterly until the initial TGE airdrop is fully completed. Additionally, generally state the possible target user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (b) Executed airdrop — If the project has already airdropped, point to a per-address source such as CSV/TSV/JSON files, a Dune table, a full Merkle dump, GitHub repo files embedding per-address allocations, or RPC endpoints that expose claim/amount data; explorer links alone do not count. Additionally, clearly state covered user segments (e.g., "stakers of X," "Aave users") and the allocation method (e.g., proportional to ve-balance or net position).
- (c) No airdrop planned or conducted — If the project does not plan to conduct an airdrop for TGE and has never conducted one, state so plainly (e.g., "We have never conducted an airdrop to date and do not plan to execute one").
- No airdrop planned or conducted: Bitcoin enters circulation through mining and no airdrop has ever been conducted for BTC
Transactions & Market Structures
Market Maker Agreements & Deals
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:
- (a) Market maker's name — the market maker's name;
- (b) Token allocation or loaned amount — the token allocation or loaned amount as a percentage of total supply;
- (c) Duration/term of agreement — the duration/term of the agreement; and, where applicable,
- (d) Name of agreement structure — label the financial vehicle being used in the agreement (i.e. loan, option/call, retainer model) without describing trading strategy or expected outcomes.
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: Bitcoin has no market-maker agreements. There is no central issuer, foundation, or DevCo with the legal standing to enter into such arrangements on behalf of the protocol.
CEX / DEX Agreements & Deals
Projects must disclose all material terms of centralized or decentralized exchange listings that affect token liquidity. For each listing, include in a table:
- (a) Exchange name / DEX pool — the exchange name (and, for DEX, the specific pool/pair);
- (b) Token allocation for listing — the token allocation supplied or committed for listing as a percentage of total supply;
- (c) Term Duration — the duration/term of any listing lockups, liquidity, or incentive programs; and, where applicable,
- (d) Native-token listing fees — whether any listing fees were paid in native tokens, with amounts (tokens or % of supply), recipients, and any vesting or lock terms tied to the partnership.
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: Bitcoin has no CEX or DEX listing agreements. There is no central entity to negotiate or enter such arrangements; exchanges list BTC on their own initiative without any issuer consent or token allocation.
Financial Disclosures & Risks
Prior Token Sales & Fundraising
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:
- (a) Series Name
- (b) Early-Stage Investment Instrument used (i.e. SAFT, STAMP, SAFE, SAFE+Token Warrant, etc.)
- (c) Date of sale (at least month & year)
- (d) Number of tokens sold (or % of total supply)
- (e) Vesting schedule
If no prior sales occurred, state that explicitly (e.g., "No prior fundraising, OTC, or discounted MM sales have occurred.").
Blockworks note: BTC enters circulation through mining, with coinbase transactions paying the block subsidy and collecting transaction fees. Bitcoin has never conducted an issuer-led token sale, fundraising round, or discounted market-maker sale.
(Source: Bitcoin FAQ, Mining - Bitcoin, Transactions - Bitcoin)
Previous Exploits Affecting The Native Token
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").
- (a) Date & component affected — Date (YYYY-MM or YYYY-MM-DD), chain(s)/component affected.
- (b) Exploit vector summary — Plain-language summary of the exploit vector (what the hack was).
- (c) Quantified impact — Quantified impact (assets/tokens affected or a clear "no loss of funds" statement).
- (d) Remediation/response taken — Remediation/response taken (patches, upgrades, governance actions, compensation).
- (e) Current status — Current status (resolved, in litigation, under investigation, refunded, etc.).
- (f) References (optional) — References (optional): link(s) to post-mortem/advisory/PR.
(a) Date & component affected
Incident 1: March 2013; blockchain consensus split between pre-0.8 and 0.8 Bitcoin nodes.
Incident 2: 2018-09-18 to 2018-09-20; Bitcoin Core / CVE-2018-17144.
(b) Exploit vector summary
Incident 1: A block with a larger number of total transaction inputs than previously seen was mined and broadcast, 0.8 nodes processed it, some pre-0.8 nodes rejected it, and the rejection caused an unexpected blockchain fork.
Incident 2: The disclosed issue combined a Denial of Service component with a critical inflation vulnerability, and the security-advisory index classifies critical bugs as the class that can allow protocol-level coin theft, out-of-schedule issuance, or permanent chain splits.
(c) Quantified impact
Incident 1: ~$26,000 in orphaned block rewards (24 blocks × 25 BTC) and one documented $10,000 double spend against OKPay; no user funds were permanently lost as all transactions from the abandoned chain were reprocessed on the canonical chain.
Incident 2: The disclosure states that Bitcoin Core was unaware of any attempts to exploit the vulnerability at the time of notice.
(d) Remediation/response taken
Incident 1: BTCGuild and Slush downgraded their 0.8 nodes to 0.7 so their pools would reject the larger block, restoring majority hashpower to the non-forking chain; later fixes included rejecting blocks likely to require more than 10,000 locks, limiting created block size to 500,000 bytes, and patching older versions to raise the lock limit to 537,000.
Incident 2: Bitcoin Core released fixes in versions 0.16.3 and 0.17.0rc4 on September 18, 2018 and urged affected users to upgrade and apply the latest patches.
(e) Current status
Incident 1: Historical incident resolved; the post-mortem states that on August 16, 2013 block 252,451 was accepted by the main network, forking unpatched nodes off the network.
Incident 2: Fixes were released and upgrade guidance was issued; the notice stated that affected users still needed to upgrade; the September 20, 2018 disclosure also stated that over half of Bitcoin hashrate had upgraded to patched nodes at that time.
Blockworks note: The public record identifies at least two material Bitcoin network or software incident surfaces: the March 2013 chain fork documented in BIP 50 and CVE-2018-17144 disclosed by Bitcoin Core in September 2018.
(Source: BIP 50: March 2013 Chain Fork Post-Mortem, Bitcoin Core :: Security Advisories, Disclosure of CVE-2018-17144, Bitcoin Network Shaken by Blockchain Fork)
Material Risk Factors (Regulation, Technology, Token Economics)
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?
(a) Regulatory, Legal & Tax Risks
Evolving regulation is more likely to affect exchangers, administrators, brokers, custodians, and users around Bitcoin than a single issuer-side entity.
FinCEN states that virtual currency does not have legal tender status in any jurisdiction, that users of virtual currency are not MSBs, and that administrators or exchangers are generally money transmitters unless an exemption applies. The IRS states that digital assets are treated as property rather than currency for U.S. tax purposes, that income from digital assets is taxable, that digital asset transactions may need to be reported whether or not they create gain or loss, and that broker reporting on Form 1099-DA begins with transactions on or after January 1, 2025. Bitcoin.org also states that bitcoin is not a fiat currency with legal tender status in any jurisdiction and that tax liability may still arise. Tokenholders and users therefore need to understand their own jurisdiction-specific legal and tax obligations.
(Source: Application of FinCEN's Regulations to Persons Administering, Bitcoin FAQ, About bitcoin.org, Digital assets | Internal Revenue Service, Press - Bitcoin)
(b) Protocol, Technology & Security Risks
The public record shows that Bitcoin’s security model depends on a shared public ledger, digitally signed transactions, and mining as a distributed consensus system. Mining enforces chronological order, protects network neutrality, and is designed so that no group or individuals can control what is included in the blockchain or replace parts of it to roll back their own spends.
That model still carries implementation and coordination risk. BIP 50 documents a March 2013 chain fork caused when some pre-0.8 nodes rejected a block with an unusually large number of transaction inputs, and the Bitcoin Core security-advisory index states that critical bugs can allow protocol-level coin theft, out-of-schedule issuance, or permanent chain splits. Bitcoin Core’s September 20, 2018 notice for CVE-2018-17144 disclosed both a Denial of Service component and a critical inflation vulnerability.
Public security measures include a formal disclosure channel through security@bitcoincore.org, severity classification, scheduled disclosure practices for lower-severity bugs, and ad hoc handling for critical bugs, but those measures do not eliminate the possibility of critical vulnerabilities or urgent network-wide upgrade requirements.
(Source: Bitcoin Core :: Security Advisories, How does Bitcoin work? - Bitcoin, BIP 50: March 2013 Chain Fork Post-Mortem, Disclosure of CVE-2018-17144)
(c) Token Economics, Unlocks & Incentive Risks
Bitcoin’s public monetary policy is fixed-rate issuance through mining, with new issuance halving over time until 21 million bitcoins exist, after which mining still continues and miners rely on transaction fees. Developer documentation also states that solo miners keep their own block rewards and fees, while pool participants share proceeds roughly according to contributed hash power.
(Source: Bitcoin FAQ, Mining - Bitcoin, Transactions - Bitcoin Press - Bitcoin)
Bitcoin has no formal DAO or single administrator, and public governance depends on user adoption and consensus rather than unilateral control by an issuer. Users choose what software to run, that BIP authors build community consensus, and that Bitcoin Core does not treat any developer class as privileged. That reduces obvious centralized control over monetary policy, but protocol rules can still change if a sufficient consensus process produces adoption.
(Source: Bitcoin FAQ, About bitcoin.org, BIP process, revised, Contributing to Bitcoin Core)
This Token Transparency Filing is provided for general informational purposes only and does not verify or warrant the accuracy of individual answers.