Advisory Guidance

Constitutional Commentary

Article-by-article explanation of the intent, reasoning, and context behind every rule in the Bitcoin System Constitution. This commentary is advisory — it does not create binding obligations beyond the articles themselves.

About this commentary: For each article, this commentary covers: the origin (what problem motivated it), the intent (what it protects or prevents), what it allows, what it forbids, gray areas requiring judgment, connections to other articles, and the line between constitutional principle and implementation detail. This commentary is interpretive and advisory — it may inform understanding but cannot override the constitutional text itself.

Origin

Definitions drift was identified as one of the highest-risk attack surfaces. A constitution can look strict while still being hollow if later actors simply redefine words like "trust-minimized," "direct Bitcoin claim," "plain transferability," or "material breach."

Intent

This article locks the meaning of the terms that carry the rest of the constitution. It exists to stop capture by semantic drift.

Allows

  • Property-based definitions that remain technologically flexible.
  • Companion standards that refine measurement without changing core meaning.
  • New implementations that fit constitutional categories even if their technical design is novel.

Forbids

  • Rebranding a credit instrument as a "utility balance."
  • Calling a trusted multisig bridge "trust-minimized" merely because it uses signatures.
  • Calling a stale reserve statement "proof" because it was once valid.
  • Pretending a support system is constitutionally harmless when it has become a choke point.

Gray areas

  • A support system that starts non-critical but later becomes operationally central.
  • A component that mixes several functions across more than one constitutional layer.
  • A system with multiple canonical paths rather than one.

Connection

This article protects every later article by preventing word games.

Implementation vs constitutional

The constitution defines the words. Later standards may define measurement methods, thresholds, or test procedures.

Origin

Many systems begin by claiming to "extend Bitcoin" and end by treating Bitcoin as merely one input among many. The article exists to prevent higher layers from becoming covert replacements for the base money.

Intent

Bitcoin is the root money, final settlement layer, and highest trust anchor. Everything above it is subordinate.

Allows

  • Faster layers built on top of Bitcoin.
  • Bitcoin-denominated utility layers.
  • Application layers that serve Bitcoin users.

Forbids

  • Marketing a fast smart-contract layer as effectively equal to Bitcoin L1.
  • Treating wrapped balances as if they erase base-layer trust differences.
  • Designing L2 or L3 so users are expected to remain there permanently for safety.

Gray areas

  • A very strong L2 may become highly trusted, but it still must not claim equality with L1.
  • A system can be highly useful without being equally sovereign.

Connection

This anchors Articles III, VI, IX, XVI, and XXXI.

Implementation vs constitutional

The constitution states the hierarchy. Implementation decides how to preserve it.

Origin

Without clean role separation, layers blur together and users stop knowing where risk begins. That is how experimental systems quietly become money systems.

Intent

Each layer has a job: L1 is the fortress, L2 is the cash rail, L3 is the experimental city.

Allows

  • Multiple internal modules or sublayers inside L2 or L3.
  • Several technical components serving one constitutional layer.
  • Different implementations of the same functional role.

Forbids

  • Smuggling L3-style risk into L2 while keeping the L2 label.
  • Claiming that a layered system is still "three layers" while hiding a fourth trust boundary.
  • Using internal complexity to evade constitutional duties.

Gray areas

  • A privacy module inside L2.
  • A settlement engine used by both L2 and L3.
  • Components that provide support without holding money.

Connection

This article works with Article I definitions and Article IV risk hierarchy.

Implementation vs constitutional

The constitution defines roles, not exact architecture.

Origin

A recurring failure pattern in finance and crypto is that risk is moved, re-labeled, and hidden until users no longer know what they actually hold.

Intent

Risk must be visible. The closer to money, the harder and simpler. The farther from money, the more optional and disclosed.

Allows

  • A risky application layer with explicit opt-in.
  • Faster but weaker systems that clearly say so.
  • Experimental assets that are openly labeled as speculative.

Forbids

  • Presenting L3 balances like L1 cash.
  • Hiding risk inside design language like "efficiency" or "innovation."
  • Structuring layers so ordinary users cannot tell where risk jumps.

Gray areas

  • A useful L3 product that is safe enough for some users but not equivalent to L2.
  • A bridged asset that is safer than most L3 tokens but still weaker than L1.

Connection

This article is the tone-setter for Articles IX, XII, XVI, XXVIII, and XXXI.

Implementation vs constitutional

The constitution demands honesty. UX and implementation documents decide how that honesty is shown.

Origin

Many systems that claim fixed supply quietly reintroduce inflation through accounting tricks, synthetic balances, or hidden claims.

Intent

No supply manipulation. More precision is allowed. More claims are not.

Allows

  • Sub-sat accounting.
  • Internal precision expansion.
  • New software layers that preserve exact ownership ratios.

Forbids

  • Treating divisibility as monetary expansion.
  • Issuing extra balances against unchanged reserves.
  • Hidden liabilities disguised as harmless abstractions.

Gray areas

  • Accounting migration events.
  • Denomination changes in display units.
  • Synthetic products that are clearly labeled as not direct Bitcoin.

Connection

This article protects Articles VIII, XII, and XIII.

Implementation vs constitutional

The constitution forbids fake supply. Companion standards can define how to audit implementations for hidden claim creation.

Origin

A Bitcoin-centered system needs a practical money layer for actual economic life. Without that, users are pushed either back to traditional banking or up into overly risky execution layers.

Intent

Layer 2 must preserve spendability without corrupting scarcity.

Allows

  • Fast payments.
  • Merchant settlement.
  • Salary and remittance flows.
  • Fine-grained accounting.

Forbids

  • Turning L2 into a playground for endless product expansion.
  • Designing L2 mainly for speculation instead of everyday use.
  • Making L2 so complex that it loses its cash-rail character.

Gray areas

  • How much optional functionality can be added before L2 stops being "boring enough."
  • Privacy or routing improvements that increase complexity but preserve mission.

Connection

This article works closely with Articles VII, VIII, IX, and XXIV.

Implementation vs constitutional

The constitution gives L2 its mission. Product and technical standards decide the specific mechanics.

Origin

Every money layer attracts pressure to monetize itself. DeFi, governance, token sprawl, hidden leverage, and "temporary" features all tend to creep in.

Intent

L2 must resist mission creep.

Allows

  • Features that directly support Bitcoin payments and settlement.
  • Internal mechanisms needed for batching, routing, or sub-sat handling.
  • Improvements that strengthen cash functionality.

Forbids

  • L2-native money tokens.
  • Hidden leverage.
  • Governance games around reserve logic.
  • Oracle-driven money behavior.

Gray areas

  • A narrowly scoped liquidity tool.
  • Optional privacy or queueing mechanisms.
  • Support features that look financial but do not create monetary confusion.

Connection

This article supports Article VI by naming the temptations that would destroy it.

Implementation vs constitutional

The constitution draws the red lines. A later L2 implementation standard can test features against them.

Origin

If Bitcoin succeeds, sat-level accounting may become too coarse for ordinary pricing, wages, and machine-scale commerce. The problem is not supply. It is usability.

Intent

Allow ever-finer accounting without creating more money.

Allows

  • Internal sub-sat units.
  • Dynamic or very high precision accounting.
  • Dust tracking that preserves ownership.

Forbids

  • Burning away small balances because they are inconvenient.
  • Quietly rounding ownership downward for operational convenience.
  • Using divisibility changes to smuggle in supply expansion.

Gray areas

  • Long-lived dust accumulation.
  • How remainders are carried forward or netted.
  • Settlement to L1 when L1 precision is coarser.

Connection

This article is an application of Article V to practical money use.

Implementation vs constitutional

The constitution says what must not happen. Detailed remainder handling belongs in implementation standards.

Origin

Financial systems become cages when users must ask permission to leave. That is true whether the gate is a government, a company, a bridge committee, or a polite compliance workflow.

Intent

Downward exit must remain a right.

Allows

  • Rule-based exit queues.
  • Bounded withdrawal delays.
  • Trust-minimized exit paths with known assumptions.

Forbids

  • Identity-gated normal exit.
  • Committee-controlled exit.
  • "Temporary" legal excuses that become permanent gatekeeping.
  • Systems where only approved institutions can leave reliably.

Gray areas

  • Truly external fiat ramps that are outside protocol scope.
  • Congestion periods where exit remains possible but slower.
  • Distinguishing actual legal edge behavior from protocol-level dependence on it.

Connection

This article is central. It links to Articles X, XI, XVI, XVII, XXIII, and XXVI.

Implementation vs constitutional

The constitution states the right. The exact operational path may vary.

Origin

A system may allow exit in theory while suppressing the actual transactions needed to use that right. That makes formal freedom meaningless.

Intent

Protect practical inclusion, not just structural permission.

Allows

  • Refusing malformed or underfunded transactions.
  • Congestion management.
  • Spam controls.
  • Deterministic fee or queue rules.

Forbids

  • Refusing valid transactions because of who sent them.
  • Selectively delaying politically disfavored users.
  • Allowing one operator cluster to suppress ordinary transfers indefinitely.

Gray areas

  • Spam filtering that disproportionately affects some users.
  • Fees that are economically neutral in theory but exclusionary in practice.
  • Routing systems where censorship is hard to distinguish from repeated outage.

Connection

This article strengthens Article IX. Exit without inclusion is fake exit.

Implementation vs constitutional

The constitution states the anti-censorship principle. The operational standard can later define metrics.

Origin

Exit under surveillance is not full freedom. People may technically be allowed to move value while being practically chilled, tracked, or punished for doing so.

Intent

Financial privacy is not a luxury. It is part of meaningful freedom.

Allows

  • Privacy-preserving tools.
  • Limited data collection when genuinely unavoidable for protocol operation.
  • Public proof systems that do not expose unnecessary user detail.

Forbids

  • Treating surveillance as a substitute for safety.
  • Making ordinary movement require unnecessary identity exposure.
  • Building the architecture around total observability of all users.

Gray areas

  • Public ledgers with privacy-enhancing overlays.
  • Disclosures needed for proof of reserves versus user-level privacy.
  • Balancing auditability with confidentiality.

Connection

This article protects the spirit of Article IX and supports Article XXVIII.

Implementation vs constitutional

The constitution protects the principle. Privacy technology choices belong in implementation standards.

Origin

This article exists because shadow banking and crypto banking both work by blurring claims, credit, and money until users no longer know what they own.

Intent

A user must never mistake someone else's promise for money.

Allows

  • Credit markets on L3 with explicit labeling.
  • Bitcoin-denominated utility balances with clear risk disclosure.
  • Optional lending products.

Forbids

  • Presenting a lendable claim like unencumbered Bitcoin.
  • Calling an IOU "cash."
  • Treating utility balances and direct claims as interchangeable.

Gray areas

  • Partially backed systems.
  • Wrapped assets with mixed custody models.
  • Revenue-bearing products that look like custody balances.

Connection

This article is one of the anti-bank core articles. It supports XIII, XIV, XVI, XXVIII.

Implementation vs constitutional

The constitution requires clear asset-class separation. UX and labeling rules help enforce it.

Origin

Many systems show a wallet and call that proof, while hiding liabilities, encumbrances, or stale data. This article exists because proof without timing or liabilities is theater.

Intent

Reserves must be real, liabilities must be shown, and proof must stay current enough to matter.

Allows

  • Public cryptographic proof systems.
  • Declared proof cadence with maximum lag.
  • Systems that openly label proof as stale when cadence is missed.

Forbids

  • Showing reserve assets without liabilities.
  • Calling 18-month-old proof "current."
  • Quietly lending reserves while still treating claims as fully backed.
  • Using compliance or efficiency language to override reserve integrity.

Gray areas

  • Architectures where real-time proof is impossible.
  • Reserve privacy versus public proof.
  • Liability proof methods that are technically hard but still constitutionally required in principle.

Connection

This article works directly with XII and XIV.

Implementation vs constitutional

The constitution names the obligations. Proof mechanics and cadence thresholds belong in later standards.

Origin

Visible reserves under weak custody are not safe reserves. One key, one jurisdiction, or one coordinated signer group can make proof irrelevant in practice.

Intent

Reserve custody must resist theft, seizure, coercion, and concentration. And over time it should open rather than harden into an aristocracy.

Allows

  • Distributed custody.
  • Public signer criteria.
  • Provisional bootstrap phases if honestly disclosed and bounded.

Forbids

  • Single-key custody.
  • Single-entity exclusive reserve control.
  • Silent custody downgrades.
  • Treating provisional custody like mature compliance.

Gray areas

  • A very small early system with reserve caps and public disclosure.
  • Signer growth that is formally open but practically cartelized.
  • Jurisdiction distribution that looks broad but shares one controlling party.

Connection

This article makes XIII real. Reserve proof without custody independence is hollow.

Implementation vs constitutional

The constitution states the custody principles. Exact signer counts, jurisdictions, ceremonies, and thresholds belong in the Reserve Custody and Key Management Standard.

Origin

Money stops being money when every transfer must go through policy logic, identity logic, or contracts. But users still need voluntary smart controls.

Intent

Keep plain transfer native. Let contracts be opt-in, not compulsory.

Allows

  • A user receiving a plain balance and later locking it in a vault.
  • Contract-based transfers chosen explicitly by the holder.
  • Business-specific contract flows at the edge.

Forbids

  • Requiring all L2 or base L3 movement to occur through contracts.
  • Turning ordinary transfer into programmable banking by default.
  • Using regulated business practices to redefine the constitutional core.

Gray areas

  • Wallets that steer users toward contracts.
  • Account abstraction that is convenient but still preserves plain transfer underneath.
  • Business users that choose contract mediation for all of their own flows.

Connection

This article protects the money character of L2 and the base utility balance of L3.

Implementation vs constitutional

The constitution sets the rule. App-layer design can offer many voluntary paths above it.

Origin

A system needs a place for experimentation. It must not pretend that place is the same as money.

Intent

L3 is where speed, programmability, and optional risk live. It is not the constitutional vault.

Allows

  • Smart contracts.
  • Application-specific risk.
  • Optional credit, derivatives, or automation systems.
  • Gas tokens.

Forbids

  • Marketing L3 risk as money safety.
  • Structuring L3 so Bitcoin utility balances cannot retreat downward.
  • Imposing app risk as a condition of the base protocol.

Gray areas

  • L3 applications that become extremely important economically.
  • Gas tokens that gain governance weight.
  • Apps that are safe enough to become normal, but still not constitutional money.

Connection

This article protects the hierarchy created by II, III, and IV.

Implementation vs constitutional

The constitution limits the role. The app ecosystem can still be broad and creative.

Origin

Bridges and cross-layer paths are where many systems lie the most. They often market movement as seamless while hiding trust, committees, delays, or insolvency risk.

Intent

Movement across layers must disclose its trust assumptions and protect downward escape.

Allows

  • Trust-minimized canonical L1-L2 paths.
  • Weaker but still rule-based L2-L3 paths.
  • Explicit opt-in trusted or contractual paths.
  • Bridges that independently prove compliance.

Forbids

  • Committee-controlled normal movement.
  • Adjacency-based compliance inheritance.
  • Saying "it connects two good systems, therefore it is good."
  • Structuring fees or delays so ordinary exit becomes fictional.

Gray areas

  • A bridge that is safe enough operationally but weaker than canonical paths.
  • Several canonical paths rather than one.
  • A non-compliant bridge used by fully informed users voluntarily.

Connection

This article is where many other articles meet: IX, X, XIII, XIV, XVIII, XXIII, XXIV.

Implementation vs constitutional

The constitution governs disclosure, bounded risk, and non-discretionary movement. Exact bridge architecture belongs in technical standards.

Origin

When systems get stressed, the first temptation is always the same: pause withdrawals, preserve the institution, and tell users it is temporary.

Intent

In uncertainty, user withdrawal matters more than growth or image.

Allows

  • Risk warnings.
  • Growth feature slowdowns.
  • Additional monitoring and disclosure.
  • Greater emphasis on conservative operation.

Forbids

  • Freezing exits because it is convenient for operators.
  • Letting the parties who benefit from a freeze declare the emergency.
  • Treating compliance pressure as a valid excuse to suspend rights.

Gray areas

  • Extreme congestion versus intentional restriction.
  • Recovery actions that help restore exit without creating new gatekeepers.
  • Short-lived technical faults that look like stress but are just outages.

Connection

This article protects IX in the moments when institutions usually fail.

Implementation vs constitutional

The constitution biases the system toward user freedom under stress. Monitoring and alerting systems can be built separately.

Origin

The constitution assumes that long-lived governance is usually a permanent opening for capture, not a virtue to celebrate.

Intent

The rules should harden over time. Governance must end. Systems are allowed to fail. Endless mutability is not allowed.

Allows

  • A limited founding amendment window.
  • A longer but still finite governance window.
  • A final implementation grace period for already-approved work.

Forbids

  • Infinite governance.
  • Extension by excuse.
  • Open-ended authority carried over past sunset.
  • Reopening the constitution because something is inconvenient.

Gray areas

  • Whether a bug is critical enough to justify using remaining governance time.
  • How specific an approved change must be before year 25 to survive into the final implementation window.
  • Whether a "module" change is really a protocol-level change.

Connection

This article is a hard anti-capture backbone. It supports XX, XXI, XXVII, XXIX, and XXX.

Implementation vs constitutional

The constitution sets the time windows. Process details may be elaborated separately.

Origin

Governance tokens are often sold as participation while functioning as plutocracy, soft equity, or a mechanism to preserve permanent politics.

Intent

If governance tokens exist at all, they must be bounded, temporary, and constitutionally subordinate.

Allows

  • Governance tokens on L3 or optional extensions.
  • Limited operational governance within a constitutional box.
  • Time-limited governance power.

Forbids

  • Governance tokens on L2.
  • Governance tokens controlling core rights.
  • Renewing governance by renaming the token or mirroring it after sunset.
  • Treating token holders like constitutional sovereigns.

Gray areas

  • A gas token that also has some bounded governance role.
  • A successor system that chooses token governance openly.
  • Whether some decisions are truly "application-layer" or actually constitutional in disguise.

Connection

This article is an enforcement arm of XIX.

Implementation vs constitutional

The constitution sets limits and sunsets. Token distribution and voting mechanics belong in separate standards.

Origin

Many systems die not by one coup, but by a sequence of small changes, technical patches, and "clarifications."

Intent

Foundational protections must be harder to change than ordinary settings, and cumulative drift must count as weakening.

Allows

  • A limited amendment process inside the founding window.
  • Clear notice and exit periods.
  • Honest creation of a new system when the old one is no longer being honored.

Forbids

  • Sneaking constitutional changes into technical updates.
  • Slow gutting through cumulative changes.
  • Pretending a materially weakened system is the same constitutional system.

Gray areas

  • Whether a technical change has constitutional effect.
  • Whether several small changes amount to one large weakening.
  • Whether a new implementation is still the same system or already a successor.

Connection

This article protects the durability of the whole constitution.

Implementation vs constitutional

The constitution requires entrenchment. Exact procedural templates can be specified later.

Origin

Without fixed clocks, operators can play timing games forever: delayed launch, soft-launch, beta forever, or reset the timeline by republishing the constitution.

Intent

Separate the life of the constitutional rules from the life of live user-facing components.

Allows

  • One constitutional clock for the whole system.
  • Separate activation clocks for modules or later-launched parts.
  • Honest staging of rollout.

Forbids

  • Resetting the constitutional clock by word games.
  • Pretending a live production system is "just a preview" to avoid obligations.
  • Launch-timing ambiguity used to extend mutability or avoid review.

Gray areas

  • Very limited pilots with no meaningful user reliance.
  • Test environments that have real code but not real user exposure.
  • Later modules that are live but still not central.

Connection

This article makes XIX enforceable.

Implementation vs constitutional

The constitution defines the timing model. Operational compliance documents can define evidence standards.

Origin

A partially centralized system becomes dangerous when one operator path becomes the only practical path. Exit requires not only user rights, but builder rights.

Intent

No incumbent gets to be the exclusive doorway.

Allows

  • Parallel implementations.
  • Alternative routing.
  • Alternative custody-escape tools.
  • Competing operator sets.
  • Anonymous or pseudonymous builders, so long as risks are not misrepresented.

Forbids

  • Incumbent permission requirements.
  • Exclusivity over constitutional functions.
  • Identity revelation as a condition of building escape infrastructure.
  • Soft monopolies over compliant pathways.

Gray areas

  • Trademark and naming issues.
  • Security review of alternative paths.
  • Whether an alternative path is truly compliant or merely available.

Connection

This article strengthens IX and XXIV. Exit is stronger when builders can create new exits.

Implementation vs constitutional

The constitution protects the right. Compatibility rules and testing belong elsewhere.

Origin

A system may be formally correct and still function like a controlled gatekeeper if operation is too concentrated.

Intent

Decentralization is not a slogan. It is a direction of travel and a practical operational condition.

Allows

  • Starting from an imperfect initial state.
  • Operational concentration that is openly disclosed and improving.
  • Sliding-scale standards that account for actual network size and participation.

Forbids

  • Permanent practical dependence on one company, one cloud provider, one jurisdiction, or one operator cartel.
  • Claiming decentralization because node count looks large while choke functions remain monopolized.
  • Entrenching concentrated control while praising decentralization in marketing.

Gray areas

  • Small early systems with few operators.
  • Shared cloud usage that is common but not yet dominant.
  • Apparent diversity that hides correlated control.

Connection

This article reinforces X, XIV, XVII, and XXIII.

Implementation vs constitutional

The constitution states the principle. The Operational Independence and Concentration Standard should later define metrics.

Origin

Keys alone are not enough if software drift can make valid funds appear invisible. Silent derivation changes and wallet mapping drift are a real form of loss.

Intent

A user who once validly controlled funds must be able to rediscover them later without vendor dependence or silent semantic drift.

Allows

  • Explicit opt-in recovery-model upgrades.
  • Archival recovery tools.
  • Exportable recovery-critical metadata.

Forbids

  • Silent derivation changes.
  • Breaking discoverability with an update.
  • Vendor dependence for rediscovery.
  • "Your money is safe, the wallet just changed" as an excuse.

Gray areas

  • Complex migrations where old and new models coexist.
  • Recovery metadata that is hard to expose but still constitutionally needed.
  • Long-term support of obscure legacy paths.

Connection

This article protects real-world self-custody and continuity.

Implementation vs constitutional

The constitution states the non-drift rule. The Software and Security Architecture Standard can define design patterns.

Origin

Some users will always choose assistance, delegation, or managed custody. The problem is not that dependence exists. The problem is when it becomes a prison.

Intent

Convenience must not silently turn into irrecoverable surrender.

Allows

  • Assisted custody.
  • Managed recovery.
  • Operator help.
  • Delegated control with clear revocation and exit rules.

Forbids

  • Permanent dependence caused by one temporary choice.
  • Hidden conversion of convenience rights into ownership rights.
  • Lack of a route back to self-control.

Gray areas

  • Complex recovery arrangements that require bounded waiting periods.
  • Delegation models that are revocable in theory but costly in practice.
  • Systems where an operator disappears and the recovery path becomes difficult but not impossible.

Connection

This article complements IX and XXV.

Implementation vs constitutional

The constitution requires escape from dependence. Specific user flows belong in UX and software standards.

Origin

Systems often break rules, patch the problem, and then pretend the breach never happened. That destroys the meaning of continuity.

Intent

A system may repair itself going forward, but it may not erase the record or rewrite the past to cosmetically restore legitimacy.

Allows

  • Publicly disclosed restored compliance.
  • Forward remediation within allowed windows.
  • Honest admission of historical breach.

Forbids

  • Retroactive history rewriting as "restoration."
  • Memory-holing breach periods.
  • Claiming uninterrupted compliance after material violation.
  • Using restoration language to excuse structural betrayal.

Gray areas

  • Which breaches are continuity-breaking versus restorable.
  • How much user harm can be repaired without successor treatment.
  • Whether a bug fix affects only future behavior or also past ownership claims.

Connection

This article protects the integrity of the constitution over time and points to the Breach and Restoration Standard.

Implementation vs constitutional

The constitution states the principles. The separate Breach and Restoration Standard should classify severity and restoration paths.

Origin

A system can be technically well-designed and still fail users if it hides what they hold or uses language designed to make risk feel smaller than it is.

Intent

The user must be able to tell what asset class they hold.

Allows

  • Multiple asset types in one ecosystem.
  • Bitcoin utility balances on L3.
  • Gas tokens and credit products, if clearly labeled.

Forbids

  • Blurring utility balances with direct claims.
  • Naming that encourages false equivalence.
  • Label tricks in code or UI.

Gray areas

  • Wallet interfaces that aggregate balances.
  • Assets with partially shared properties.
  • Contextual naming that is accurate in one layer but misleading in another.

Connection

This article is the user-facing counterpart to XII.

Implementation vs constitutional

The constitution states the clarity obligation. The UX constitution should express it in interface terms.

Origin

This constitution is meant to be a standard, not a magical force field. Systems must choose to adopt it, and others must not inherit compliance by proximity.

Intent

Applicability is voluntary. Claims are strict.

Allows

  • Existing systems to remain outside the constitution.
  • New systems to adopt it prospectively.
  • Third parties to evaluate compliance.

Forbids

  • Claiming compliance by brand association.
  • Claiming retroactive purity without proof.
  • Using the name while materially violating the rules.

Gray areas

  • Systems that partially adopt the constitution.
  • Whether a module can be compliant when the host system is not.
  • How to speak honestly about partial alignment.

Connection

This article prevents the constitution from being diluted into branding.

Implementation vs constitutional

The constitution states when it applies and how claims work. Evaluation frameworks may be developed separately.

Origin

A common abuse pattern is silent migration: "same brand, same team, same users, new trust model."

Intent

New systems require new consent.

Allows

  • Honest successor systems.
  • Voluntary migration.
  • Fresh claims of compliance that are independently demonstrated.

Forbids

  • Silent rollover.
  • Balance remapping as implied consent.
  • Treating lineage as legitimacy.

Gray areas

  • Migration tools that are optional but heavily promoted.
  • Shared infrastructure between old and new systems.
  • Whether a change is big enough to count as a successor.

Connection

This article protects the meaning of continuity and complements XXVII and XXIX.

Implementation vs constitutional

The constitution protects consent. Migration tooling is an implementation matter.

Origin

A constitution needs an orienting picture of what success looks like, not just a list of things forbidden.

Intent

The end state is a hierarchy where: Bitcoin remains the final truth, Layer 2 makes Bitcoin usable as everyday money, Layer 3 carries experimentation, and users can always retreat downward for safety.

Allows

  • Innovation above the money.
  • Growth in utility and experimentation.
  • Multiple compliant implementations of the same layered philosophy.

Forbids

  • An architecture where experimentation swallows the money layer.
  • A world where users are stuck in the fast system because exit is too costly or too controlled.
  • Treating freedom language as branding while dependence hardens underneath.

Gray areas

  • Whether a very successful L3 product starts to distort the role of L2.
  • Whether new layers beyond three can still remain constitutionally aligned.
  • How much convenience centralization is tolerable before the system loses its soul.

Connection

This article is the destination image for the whole constitution.

Implementation vs constitutional

This article defines the direction, not the roadmap.

Final note: If future readers are ever unsure how to interpret a disputed clause, the correct reading is the one that best protects honest hierarchy, visible risk, current proof, free exit, and the user's ability to escape control.