Common Objections & FAQ

The Bitcoin System Constitution is a public domain standard (CC0 1.0) written by Satoshi Nohashi. It defines the non-negotiable principles for designing, operating, and evaluating Bitcoin-aligned systems. It is not a product, not a token, and not a company. It is a constitutional standard — publicly accessible, independently verifiable, and built to outlast the people who wrote it.

The constitution is voluntary in applicability and strict in claim. No system is automatically bound by it, but any system that claims compliance with it must actually meet its requirements.

No. The constitution is not a law, a regulation, or a license. It has no enforcement power in the traditional legal sense. It is a voluntary standard — a set of publicly documented principles that any system may choose to adopt.

Its power comes from transparency and verifiability. Anyone can read the rules, evaluate a system against them, and judge for themselves. Compliance is determined by actual behavior, not by claims or certifications. If a system says it is compliant but violates the rules, anyone can publicly demonstrate that fact.

Bitcoin Layer 1 works. The problem is the systems built around it. Exchanges, bridges, Layer 2 networks, and smart contract platforms often reintroduce the very dependencies Bitcoin was designed to remove — hidden leverage, trapped funds, custodians who cannot prove reserves, governance that never ends, and credit instruments disguised as money.

There is no shared standard for what "Bitcoin-aligned" actually means. Without one, every project defines it for themselves. This constitution provides that standard — a common set of rules that can be measured, verified, and held accountable.

The constitution draws the line at identity and discretion. Fee-based prioritization applied neutrally, uniformly, and based on published rules is not censorship. Congestion management with transparent queue rules is not censorship. Minimum fee requirements applied consistently are not censorship.

Censorship begins when valid transactions are selectively excluded, delayed, or disadvantaged based on the sender's identity, political context, transaction destination, or perceived purpose of funds. The test is simple: would this transaction be treated the same way if the sender were anonymous and unknown?

The Operational Independence Standard defines specific thresholds — sustained censorship is presumed when valid transactions are delayed beyond 2× the acceptable delay for more than 24 hours, or repeatedly disadvantaged across three or more 24-hour windows in a rolling 30-day period.

Yes. The constitution explicitly allows operators to refuse malformed transactions, invalid state references, transactions with insufficient fees, and spam — provided these rules are published, identity-blind, and generally applied. Not every operator must include every transaction. The requirement is that the system's architecture preserves a practical path to inclusion for valid transactions without discretionary gatekeeping.

The key distinction: spam resistance based on neutral technical criteria is fine. Selective exclusion based on who is sending is not.

This is a real tension, and the constitution does not pretend it is easy. The rule is: where proof obligations and privacy conflict, systems must minimize identity and balance exposure to the maximum extent compatible with reserve truth, liability truth, and non-custodial verification.

The chosen method must favor the least invasive proof approach reasonably achievable under current technology. Cryptographic proofs, zero-knowledge techniques, Merkle-tree proofs, and other privacy-preserving verification methods are constitutionally preferred over approaches that require exposing individual user balances or identities.

Privacy loss must not be normalized merely because it is administratively convenient. The burden is on the system to justify any data collection beyond what is constitutionally necessary.

The constitution prohibits identity disclosure as a condition of ordinary transactions, ordinary transfers, or normal downward exit within the protocol. External business practices and regulated interfaces at the edges do not redefine the core requirement.

A system can be designed so that regulated on-ramps and off-ramps exist at the edges while the core protocol remains identity-free for ordinary operations. Users who explicitly and voluntarily opt into identity-gated services can do so — but a plain, identity-free transfer path must exist as a native capability of the core.

If the only practical path for ordinary users to transact or exit involves identity checks, the system is in breach — even if the protocol technically allows identity-free operation somewhere in theory.

The constitution is explicit: no appeal to legal, regulatory, audit, compliance, or emergency necessity shall convert a non-compliant restriction into constitutional behavior. If a government orders a system to freeze user exits, the system may comply with the law — but it cannot then claim to be constitutionally compliant.

This is intentional. Constitutional compliance is a verifiable standard, not a legal defense. A system can be useful and lawful while remaining non-compliant with this constitution. Non-compliance does not mean illegitimate — it means only that the system does not meet these standards.

The constitution's warning is specific: "Regulatory capture often arrives as a reasonable-sounding exception. Such exception shall not create constitutional precedent."

The constitution does not require systems to ignore laws. It requires systems to be honest about the consequences. If regulatory compliance forces a system to block exits, surveil users, or freeze funds — fine. But then the system must not claim to be constitutionally compliant, because it isn't.

The value of the standard is precisely that it does not bend to accommodate every exception. If it did, it would be meaningless. "Bitcoin-aligned" would become a marketing label rather than a verifiable claim.

Systems that operate in regulated environments can still build toward constitutional compliance by designing the core protocol to be permission-free while placing regulatory interfaces at the edges.

The multi-signer requirement applies to reserve custody — the keys that control the reserves backing user claims. It does not apply to every transaction. Day-to-day operations can use faster delegated keys, hot wallets with spending limits, and other convenience structures.

The constitution explicitly allows delegated control, assisted custody, and managed signing — as long as these arrangements remain revocable and the user's path to independent control or downward exit is preserved. The separation between operational keys and ultimate control is a core requirement.

The Reserve Custody and Key Management Standard defines scaling custody bands: small reserves need fewer signers (3 minimum), while larger reserves require more (up to 9+). This is designed to match security to actual exposure.

Yes — this is exactly what provisional custody is for. A system may begin with a more concentrated custody structure than its long-term target, but it must:

• Publicly disclose the provisional status
• Publish a reserve cap during the provisional period
• Publish a maturity plan with deadlines and milestones
• Not claim full constitutional compliance

Provisional custody may not continue beyond 12 months from activation. Failure to mature on schedule becomes a compliance issue. And critically: provisional custody is not compliant custody. A system operating under it may only claim provisional or partial compliance.

This is precisely why the constitution separates reserve truth from custody safety. Article XIV establishes that "a reserve is not constitutionally sound merely because it is visible. It must also be held under a custody structure consistent with the constitutional safety claims of the system."

Proving that reserves exist is necessary but not sufficient. The reserves must also be held under distributed, multi-jurisdictional control with meaningful resistance to unilateral seizure, single-key failure, and coordinated capture. Visible reserves under weak custody are explicitly called out as an attack vector the constitution closes.

The constitution is deliberately rigid on this point. The timeline is: constitutional amendments close at year 5, governance decisions close at year 25, final implementation of approved changes must complete by year 30. After year 30, no further changes are permitted.

If a critical bug is found after year 30 and cannot be fixed without a protocol change, the answer is: that system becomes non-compliant, and any fix must launch as a new successor system that users voluntarily choose to enter. The constitution says explicitly: "Bugs or imperfections not deemed critical enough to be addressed within the allowed windows must be left alone."

This is intentional. Endless mutability is worse than imperfection. The whole point is that governance is a temporary weakness, not a permanent virtue.

Governance tokens may continue to exist as tokens — they just lose all protocol-level decision authority. After the governance sunset (year 25), a governance token confers no protocol-level voting rights, no amendment rights, no emergency rights, no reserve rights, and no authority over normal user movement or constitutional protections.

The token cannot be renewed, extended, renamed, mirrored, wrapped, or functionally replaced to continue governance beyond its sunset. If a new governance system is needed, it must be a new system entirely — not a continuation of the old one.

The constitution does not claim that any existing system is currently compliant. It provides a standard against which systems can be evaluated. The Compliance Registry will track systems that claim compliance, but no systems have registered yet.

Compliance evaluation can be performed by anyone — users, developers, auditors, institutions, automated systems, or AI. No evaluator is infallible, and no compliance label substitutes for understanding the actual rules and risks.

A system that violates the constitution does not automatically regain uninterrupted compliant status by later changing behavior. The breach remains permanently on record. The system may become "currently compliant" again, but it may never claim "continuously compliant" across the breach period.

Forward remediation — fixing bugs, restoring reserve visibility, correcting labels — may be acceptable. Impermissible retroactive correction — rewriting settled history, forced rollback of valid transfers — is never acceptable and renders the system permanently non-compliant under its current identity.

The Breach and Restoration Standard defines five severity levels, from minor deviation (automatically curable) to successor-required (only a new system can restore compliance).

Absolutely. The constitution says explicitly: "A system may be useful while remaining non-compliant with this constitution. Non-compliance does not automatically mean illegitimate. It means only that the system does not meet the standards of this constitution."

The constitution does not try to ban non-compliant systems. Its purpose is to provide a clear, verifiable standard so that anyone can distinguish between systems that meet these principles and those that don't. The prohibition is on claiming compliance while operating in violation — not on existing.

That is not a hole. That is a filter.

This constitution does not classify layers by marketing category or industry habit. It classifies them by trust boundary, exit properties, monetary role, and risk position. So if something calls itself "L2" but has long challenge exits, committee dependence, bridge dependence, weak downward movement, or strong operator choke points — then under this constitution it may simply not qualify as Layer 2.

Article XVII requires a maximum exit delay of 12 Bitcoin blocks (approximately 2 hours). Many current so-called Bitcoin L2s — especially optimistic rollups with 7-day challenge periods — would indeed be non-compliant as Layer 2. They may qualify as Layer 3, or as out of scope entirely.

This is not accidental. Layer 2 is a cash rail. 7-day exits are not cash-rail behavior. The constitution refuses marketing fraud.

The key principle: A system's constitutional layer classification is determined by its actual trust model, exit properties, monetary role, and user-risk boundary — not by its public branding, marketing category, or common industry label.

This is not an oversight. It is a constitutional choice.

The constitution intentionally prefers ossification over indefinite security patch discretion. If a critical vulnerability is discovered after the allowed governance and implementation windows, the old system may remain historically valid but operationally obsolete, and a new successor system may be required.

The deliberate tradeoff: the constitution treats endless mutability as a greater long-term threat than late-stage imperfection. Once you allow "critical fixes after the deadline" or "emergency patches after ossification," you have reopened the exact governance door you were trying to close. Then every future actor says "this is critical" and governance never really dies.

The history of software systems, financial institutions, and political bodies is filled with "temporary" emergency powers that became permanent. The constitution closes that door by refusing to create it in the first place.

What happens instead:

• Users may exit. Exit rights are constitutionally protected and entrenched.
• A successor system may emerge. Anyone can build an alternative under Article XXIII.
• The successor is evaluated independently. It does not inherit the original system's compliance status.
• The original system's history is preserved. No retroactive continuity claims.

This loophole does not exist. The constitution explicitly closes it.

Article XIV requires a public, bounded maturity path with defined milestones, timelines, and consequences for failure. The Reserve Custody and Key Management Standard goes further:

• 12-month hard cap — Provisional custody may not continue beyond 12 months from activation.
• Cap raise restrictions — The reserve cap must not be raised if prior maturity milestones have been missed.
• Consequences for failure — Missing deadlines constitutes a compliance issue that may escalate under the Breach and Restoration Standard.
• No full compliance claims — A provisional system may only claim "provisional" or "partial" status.

The constitution anticipated this gaming pattern. A project cannot hide behind "provisional" indefinitely. Milestones must be defined upfront with fixed timelines — not rolling updates that never converge. The clock starts from day one.

This is a deliberate sovereignty rule. The friction is intentional — and it is better than fake consent.

Article XXX forbids automatic migration because automatic migration destroys the distinction between the failed system and the successor, and substitutes operator choice for user consent. The abuse pattern it prevents: system breaks trust, operators launch "successor," balances are silently rolled over, users wake up in a new trust model, and continuity is claimed anyway.

But the constitution does not ban making migration easy. It bans making migration non-voluntary. A successor system is free to provide:

• User-initiated migration tools
• Export paths and guides
• One-click user-activated bridges
• Batch assist tools (user-triggered)
• Open migration software
• Compatibility tooling

What is forbidden: silent rollover, implied consent, automatic remapping, and operator-decided migration. The user must explicitly choose to leave the old system and enter the new one.