Binding Standards

Companion Standards

Seven binding companion documents that operationalize the constitutional requirements. Each standard supports specific articles and defines the detailed thresholds, procedures, and rules referenced by the constitution.

Note: All companion standards are currently in Draft status. Where a companion standard is designated binding, its binding force is limited to the scope assigned to it by the constitution. Click any standard below to expand its full content.

Breach and Restoration Standard
Defines how breaches are classified, disclosed, evaluated, cured, and recorded.

Binding · Draft

Governing Rules

This standard uses the definitions in Article I of the constitution exclusively.
Where more than one classification could apply, the highest applicable severity controls.
Where no exact case is listed, classification must default to the nearest more conservative reading, not the more forgiving one.
Aggravating factors may elevate a breach by one level where constitutionally justified. Mitigating factors may affect cure conditions, but do not reduce a breach below its baseline classification.
No claim of restored compliance is valid unless the conditions in this standard are met publicly and verifiably.
In the absence of a companion technical or operational standard, interpretation must default to the reading that best protects:

exit rights
reserve and liability truth
custody independence
non-discretionary operation
censorship resistance
practical path to inclusion
constitutional time limits
user freedom

Disputes over breach classification, restoration, continuity, or evidence may be reviewed under the Constitutional Dispute and Review Standard of Bitcoin System Constitution where that document exists. In its absence, the public evidence and conservative-reading rules in this document control.
A system's own classification of its breach status is non-authoritative. Compliance status is determined by observable behavior and evidence under this standard and may be independently evaluated by external parties.

Section 1. Failure Severity Classes

Overview Table

Level	Class	Description	Continuity Effect	Typical Cure Status
1	Minor deviation	Technical non-conformance without material user impact	No continuity break by default	Automatically curable or curable with disclosure
2	Material breach	Violation affecting constitutionally protected user interests	Continuity may survive, depending on severity and disclosure	Usually curable with disclosure or scarred
3	Continuity-breaking breach	Material breach severe enough to end uninterrupted constitutional continuity	Continuous compliance is broken	Scarred or not curable under same continuity claim
4	Permanent non-compliance	The system cannot restore compliance under its current identity	Current identity cannot truthfully claim compliance	Not curable under current identity
5	Successor-required	A new system is required if constitutional compliance is ever to be claimed again	Current system identity cannot continue as compliant	Only cure is a new successor system with fresh consent

Level 1. Minor deviation

A minor deviation is technical non-conformance that does not materially impair user rights, reserve integrity, custody safety, constitutional time limits, governance sunsets, asset-class clarity, or practical ability to transact or exit.

Typical examples

A documentation mismatch that does not affect actual behavior.
A proof publication formatting defect where the proof itself remains current and independently verifiable.
A temporary non-critical implementation inconsistency with no material user effect.

What it is not

It is not a minor deviation if it affects:

exit rights
reserve truth
liability truth
custody safety
credit versus money distinction
governance authority or time windows
user asset clarity
practical transaction inclusion

Level 2. Material breach

A material breach is a breach that affects constitutionally protected user interests, even if the system may still remain recoverable under its current identity.

Typical examples

Functional exit blocking.
Hidden reserve lending.
Missing proof cadence repeatedly.
Presenting stale proof as current.
Misrepresenting a credit instrument as money.
Transaction-level censorship of valid ordinary transactions.
Governance action after the governance sunset date, where the act is isolated and immediately disclosed.

Typical effect

A Level 2 breach may or may not break continuity. Severity, concealment, duration, and user impact determine whether it escalates to Level 3.

Level 3. Continuity-breaking breach

A continuity-breaking breach is a material breach severe enough that the system can no longer truthfully claim uninterrupted constitutional continuity from the point it adopted the constitution.

Typical examples

Discretionary freezing of normal downward exit.
Repeated undisclosed reserve impairment.
Misrepresentation of constitutional compliance during a known material breach.
Continued governance operation after sunset in a way that materially affects users.
Silent migration behavior that materially changes trust assumptions without fresh consent.
Repeated proof cadence failure combined with concealment or active current-backing claims.

Typical effect

The system may possibly become currently compliant again later, but it is permanently historically breached and may never claim uninterrupted compliance across the breach period.

Level 4. Permanent non-compliance

A permanent non-compliance event means the system, under its current identity, can no longer restore constitutional compliance.

Typical examples

Protocol-level changes after the final hard stop window.
Governance continuing after the governance window in a sustained or structural way.
Constitutional amendment attempts after the constitutional amendment window closes.
Replacing governance or constitutional authority through disguised renamed structures after sunset.
Persistently operating core functions through a model that is constitutionally incompatible and not reversible under the same identity.

Typical effect

The current system identity may continue to exist technically, but it cannot truthfully claim compliance.

Level 5. Successor-required

A successor-required event means the only path back to constitutional compliance is a new system that users voluntarily enter.

Typical examples

Forced migration into a new trust model.
Silent remapping of balances into a new system.
Retroactive rewriting of ownership or settlement history as a supposed cure.
Continuing a permanently non-compliant system while claiming continuity under a refreshed brand or architecture.
Governance or constitutional authority being functionally restarted under a new wrapper within the same claimed system identity.

Typical effect

The current system identity must not continue to claim constitutional compliance. Only a successor, with fresh voluntary consent, may seek compliance.

Section 2. Cure Types

Type A. Automatically curable

This applies where the system corrects itself through ordinary operation without requiring a special constitutional disclosure process, and without any material user impact.

Typical fit: Level 1 only.

Type B. Curable with disclosure

This applies where a fix is possible, but the system must publicly disclose:

what happened
when it happened
who was affected
what changed
whether continuity was impacted

Typical fit: Level 1 or Level 2.

Type C. Scarred

This applies where the system may return to current compliance, but the breach history is permanently part of its record. It may not claim uninterrupted compliance across the breach period.

Typical fit: Level 2 or Level 3.

Type D. Not curable

This applies where the system cannot restore constitutional compliance under its current identity.

Typical fit: Level 4 or Level 5.

Section 3. Time Sensitivity, Uncertainty Notices, and Disclosure Windows

3.1 Acknowledgment duty

A system must acknowledge a known or reasonably suspected breach without unreasonable delay.

For binding evaluation, the following principles apply:

Breaches affecting exit, reserves, liabilities, custody, governance authority, constitutional clocks, constitutional naming, or compliance status require the fastest acknowledgment.
If full facts are not yet known, the system must publish an uncertainty notice rather than remain silent.
Silence when a material breach is known or reasonably inferable is itself an aggravating factor and may elevate the breach independently of the underlying cause.

3.2 Uncertainty notice requirements

An uncertainty notice is a temporary preliminary disclosure. It must include, at minimum:

what is known
what is unknown
what users should assume conservatively for now
whether exit, reserves, liabilities, custody, governance, or proof cadence may be affected
what the immediate user implications are
when the next update will be published

An uncertainty notice does not suspend the system's broader disclosure obligations. It only bridges the period before fuller disclosure is possible.

3.3 Hard deadlines for uncertainty notices and fuller disclosure

High-severity issue classes

For reasonably suspected issues affecting:

exit
reserve truth
liability truth
custody
governance authority or governance time limits
constitutional clocks
compliance misrepresentation
constitutional naming
proof cadence failure involving reserve-backed claims

the following hard deadlines apply:

uncertainty notice: within 24 hours
fuller disclosure: within 72 hours
update cadence while uncertain: every 24 hours

Lower-severity issue classes

For lower-severity issues without current material effect on user rights, reserves, custody, governance, or exit:

uncertainty notice: within 72 hours
fuller disclosure: within 7 days
update cadence while uncertain: every 72 hours

3.4 Maximum uncertainty period

An uncertainty notice may not remain the system's sole disclosure state beyond the applicable maximum uncertainty period above.

At the end of that period, the system must publish the fullest disclosure then available, including:

all facts known
all facts still unknown
current user impact
worst-case implications if uncertainty remains
next remedial steps

A system may not avoid fuller disclosure by claiming it still lacks perfect information.

3.5 Consequences of missed uncertainty deadlines

Failure to issue:

the initial uncertainty notice on time,
the required interim updates on time,
or the fuller disclosure by the hard deadline

constitutes an aggravating factor and may itself be treated as a separate disclosure breach.

Repeated or strategic use of uncertainty status to avoid harder obligations should generally elevate severity by one level.

3.6 Silence as breach

Failure to disclose a known or reasonably inferable material breach within the required timeframe shall be treated as a minimum Level 3 continuity-breaking breach, regardless of the underlying breach classification.

Section 4. Historical Integrity Rules

Breach history cannot be erased.
A system may be:

currently compliant
currently non-compliant
restored to compliance
historically breached
permanently non-compliant

"Currently compliant" and "continuously compliant" are not the same claim.
A system that suffered a continuity-breaking breach may never claim uninterrupted compliance across that breach period.
Material breach history is permanent on the constitutional record.
Minor deviations should remain in technical history, even if they do not permanently scar constitutional standing.
All material breach disclosures must remain permanently accessible in a public, durable location. Breach records must not be removed, rewritten, buried, or made practically inaccessible over time.

Practical meaning

A system may say:

"currently compliant, historically breached"

but may not say:

"continuously compliant"

if continuity was broken.

Section 5. Evidence Requirements for Claiming Restored Compliance

The burden of proof always lies on the system claiming restoration.

5.1 Required public disclosure

At minimum, the system must disclose:

the nature of the breach
the scope of the breach
the timing of the breach
the affected functions, balances, or users
the constitutional article or articles implicated
the remediation taken
whether the breach broke continuity
whether the system claims:

current compliance
restored compliance
or successor treatment

All such disclosures must be made in a public, durable location reasonably discoverable by affected users.

5.2 Evidence standard

Claims of restoration must be supported by the strongest publicly available evidence appropriate to the breach, including where relevant:

on-chain evidence
cryptographic proof
updated proof-of-reserves and liabilities
custody disclosures
governance records
published timelines
public code or configuration changes
independently checkable operational evidence

5.3 Minimum restoration conditions

No system may claim restored compliance until:

the breach has been publicly disclosed
the remediation is actually active, not merely promised
users have had a practical opportunity to understand the breach and, where relevant, exercise normal downward movement after disclosure under conditions that are not rendered illusory by excessive fees, excessive delays, or discriminatory access conditions
the system is no longer engaging in the breaching behavior
the system is not falsely presenting the breach period as uninterrupted compliance

5.4 Minimum remediation periods before claiming restored compliance

Level 1

No earlier than 24 hours after full disclosure and active remediation.

Level 2

No earlier than 72 hours after full disclosure and active remediation, where the affected protections include:

exit
reserve or liability truth
custody
proof cadence for reserve-backed claims
governance or constitutional clocks
compliance status or naming

Level 3

A system may never claim restored continuity.

It may claim current compliance only as historically breached and no earlier than 7 days after full disclosure and active remediation, with all scar conditions disclosed.

Level 4 and Level 5

No restored compliance claim is available under the same system identity.

5.5 Exit accessibility during remediation

A restoration claim is invalid if exit remains technically available but practically inaccessible due to excessive fees, delays, or discriminatory conditions. Exit must remain reasonably accessible to ordinary users during the restoration period.

5.6 Restoration claim publication

Restoration claims must be published in the same public, durable location as the original breach disclosure and must be directly linked to it. Restoration claims must not be scattered across multiple locations or hidden within unrelated communication channels.

5.7 Independent verification

Where a breach concerns:

reserves
liabilities
custody
governance authority
constitutional clocks
or system state needed for exit

the claim of restoration should be independently verifiable to the maximum extent technically possible.

Section 6. Naming Consequences

6.1 Minor deviation

A system may continue using constitutional naming if the deviation is corrected and did not create material user confusion or harm.

6.2 Material breach

A system may continue using constitutional naming only if it does not misrepresent itself as continuously compliant and if it discloses the breach honestly.

6.3 Continuity-breaking breach

A system may use constitutional naming only with clear breach disclosure. It may not present itself as uninterruptedly compliant.

6.4 Permanent non-compliance

A system must not present itself as constitutionally compliant. It may describe itself as a former implementation, legacy implementation, or non-compliant implementation, but not as currently compliant.

6.5 Successor-required

A new system must not inherit constitutional naming by default. It must independently demonstrate compliance and obtain user trust on its own.

6.6 Misrepresentation

A system that continues to use constitutional naming while materially violating this standard or the constitution is engaged in misrepresentation.

Section 7. Forward Remediation vs Impermissible Retroactive Correction

This section is central.

7.1 Forward remediation

Forward remediation means correcting future behavior without rewriting valid prior constitutional reality.

Forward remediation is generally acceptable if it:

occurs within the allowed constitutional and governance windows
is publicly disclosed
does not retroactively alter valid ownership or settlement
does not erase breach history
does not require users to pretend the breach never happened

7.2 Impermissible retroactive correction

Impermissible retroactive correction means rewriting or undoing prior valid system history, ownership, settlement, or constitutional reality in order to cosmetically repair a breach or undo an undesirable outcome.

This is generally not acceptable.

7.3 Hard rule on rollback and history rewrite

A rollback, reorganization, or state reversal performed to:

undo theft
rescue users from bad contract programming
reverse liquidation outcomes
reverse politically painful but valid economic results
or cosmetically repair a breach

is an impermissible retroactive correction.

If a system performs such a correction, the current system identity becomes permanently non-compliant, and any constitutionally compliant continuation must occur only through a successor system with:

a new identity
new clients
no automatic migration
no inherited constitutional continuity
manual user exit and manual entry only

7.4 Invalid-state correction and core-rule breakage

If the system's published core monetary or consensus intent was broken, such as:

more coins being created than the published rules allow
objectively invalid blocks being accepted as if valid

actors may choose to correct that invalid state, but such correction does not restore constitutional continuity for the existing system identity if it requires rollback, reorganization, or state reversal of already-observed history.

In that case:

the old system becomes permanently non-compliant
a new system may be launched if users choose to trust it
there is no automatic migration path
users must move manually by exiting the old system and entering the new one

The purpose of this hard consequence is deterrence. It ensures that any actor considering rollback or history rewrite understands that the constitutional cost is severe and public.

7.5 Classification table

Action	Classification
Fixing a core bug that enabled theft, going forward	Acceptable forward remediation
Patching a vulnerability prospectively	Acceptable forward remediation
Prospectively tightening governance rules within allowed windows	Acceptable forward remediation
Chain reorganization to undo theft or rewrite already-valid settled history	Impermissible retroactive correction
Rolling back state to before an exploit by rewriting valid final state	Impermissible retroactive correction
Retroactively changing governance rules to justify past actions	Impermissible retroactive correction
Retroactively changing ownership mapping to erase a breach	Impermissible retroactive correction
Rollback or reorganization to erase invalid supply creation or objectively invalid accepted blocks	Impermissible retroactive correction under current identity; only successor path remains if actors choose to proceed

7.6 General test

Ask:

Does the action change future behavior only, or does it rewrite past valid state?
Does it preserve the constitutional truth model of the affected layer?
Does it require users to accept that history changed rather than that the system learned?
Does it erase evidence of the breach rather than disclose it?

If the answer points to rewriting past valid reality, it should generally be treated as impermissible retroactive correction.

Section 8. Specific Breach Classifications

These are presumptive classifications. Aggravating or mitigating circumstances may shift the final level, but not below the constitutional seriousness of the act.

Event	Presumptive Severity	Typical Cure Type	Notes
Governance action after year 25	Level 2, Material breach	Curable with disclosure or scarred	May escalate if sustained or concealed
Continued protocol decisions after year 25	Level 3, Continuity-breaking breach	Scarred or not curable	Likely breaks continuity
Any new protocol-level change after year 30	Level 4, Permanent non-compliance	Not curable	Only successor path remains
Hidden reserve lending	Level 2, Material breach	Curable with disclosure or scarred	May escalate if prolonged or concealed
Functional exit blocking	Level 2, Material breach	Curable with disclosure or scarred	May escalate if sustained
Misrepresenting compliance status	Level 2, Material breach	Curable with disclosure or scarred	May escalate if intentional and prolonged
Missed proof cadence, promptly disclosed, affected claims marked stale or unproven	Level 1 or 2	Curable with disclosure	Severity depends on duration and user impact
Repeated or persistent failure to meet declared proof cadence	Level 2, Material breach	Curable with disclosure or scarred	May escalate if prolonged or paired with reserve uncertainty
Failure to publish proof while continuing to present claims as currently backed or currently proven	Level 2 or 3	Scarred or curable with disclosure	Concealment and duration matter
Backdating, falsifying, or misleading proof timestamps or cadence records	Level 3, Continuity-breaking breach	Scarred or not curable	May escalate if tied to reserve impairment
Stale proof presented as current proof	Level 2, Material breach	Curable with disclosure or scarred	May escalate if tied to reserve distress
Reserve custody downgrade without disclosure	Level 2, Material breach	Curable with disclosure or scarred	May escalate if user funds materially endangered
Transaction-level censorship of valid ordinary exits	Level 2 or 3	Curable with disclosure or scarred	Depends on duration and concentration
Forced migration into new trust model	Level 5, Successor-required	Not curable	Requires new system and fresh consent
Silent balance remapping into successor	Level 5, Successor-required	Not curable	Identity continuity is broken
Governance continuation by renamed wrapper after sunset	Level 4 or 5	Not curable	Depends on continuity claim and migration behavior
Retroactive rewriting of valid settled history to "repair" a breach	Level 5	Not curable	Successor treatment required

Section 9. Concurrent Breaches and Propagation

9.1 Local classification

Every breach shall first receive an independent local classification by:

article violated
affected function
severity level
cure type

Lower-severity breaches do not disappear merely because a higher-severity breach also exists.

9.2 Propagation assessment

After local classification, each breach shall also receive a propagation assessment:

Isolated

confined to a bounded optional component or non-core function

Core-propagating

affects constitutional core guarantees strongly enough to set system-wide status

Cross-contaminating

interacts with other breaches in a way that raises total system severity

9.3 Core-propagating breaches

A breach is core-propagating when it materially affects:

normal downward exit
reserve truth
liability truth
reserve custody independence
constitutional clocks
governance sunset or governance scope
forced migration
compliance misrepresentation
constitutional continuity

A core-propagating breach sets the minimum system-wide current status at its severity level, even if other breaches are lower.

9.4 Cross-contamination

A breach is cross-contaminating when concurrent breaches share:

a common cause
a common operator set
a common concealment pattern
a common choke point
or materially compounded user impact

Cross-contaminating breaches may elevate the system-wide classification by one level where constitutionally justified, even if each breach alone would be classified lower.

9.5 Isolated breaches

A breach may remain function-scoped only where it is clearly bounded, fully disclosed, and does not materially impair any constitutional core guarantee.

9.6 Example

If a system has:

a Level 3 breach in exit rights, and
a Level 2 breach in reserve labeling,

then:

the exit breach is likely core-propagating
the system-wide current status is at least Level 3
the reserve labeling breach remains independently recorded
the labeling breach may act as an aggravating factor if it worsened user confusion during the Level 3 event

9.7 Cross-contamination example

If a system:

misses its declared proof cadence for reserve-backed claims, and
simultaneously uses a misleading interface, notification, or public status display that conceals, downplays, or fails to clearly present that stale-proof condition,

then:

the proof cadence breach and the clarity breach may be classified as cross-contaminating
the shared operator set and shared concealment pattern may justify elevation of the system-wide classification
the compounded harm is greater than either breach alone because users are deprived not only of current proof, but also of their practical ability to detect the missing proof and respond

This remains true even if each individual breach might otherwise appear curable in isolation.

Section 10. Aggravating and Mitigating Factors

10.1 Aggravating factors

These factors may elevate the severity class by one level where constitutionally appropriate:

concealment
delayed disclosure
operator enrichment during the breach
insider advantage
repeated occurrence
misleading public statements
impairment of user exit
impairment of reserve truth
impairment of user ability to distinguish asset class
rewriting history rather than disclosing failure
remaining in uncertainty status beyond the maximum allowed period

10.2 Mitigating factors

Mitigating factors may influence cure conditions but do not erase the breach. Examples include:

prompt disclosure
fast and honest remediation
absence of operator benefit
preserved user exit during remediation
public evidence sufficient for independent verification

Section 11. Interpretive Priority

When breach classification is disputed, the preferred classification is the one that best prevents the following abuse patterns:

hiding a serious breach behind technical wording
treating disclosure as cure without real remediation
remaining indefinitely in uncertainty mode
rewriting history to cosmetically restore legitimacy
claiming continuity after a constitutionally significant break
using short duration as an excuse for severe breach
using branding to preserve trust after constitutional reality has changed

This standard exists to make breach handling honest, not convenient.

Constitutional Dispute and Review Standard
How disputes about interpretation, breach classification, and compliance are raised and resolved.

Binding · Draft

Governing Principles

The constitution remains primary. This standard interprets, applies, and records; it does not override the constitution.
Public evidence outranks self-serving assertion.
Conservative reading controls where uncertainty remains unresolved.
No system may be the sole judge of its own compliance status.
Dispute review must remain transparent, replayable, and permanently recorded.
Review may be decentralized and plural. It need not produce one global official court.
Where multiple reviewers disagree, the strength of the evidence and fidelity to the constitution control, not mere reviewer prestige.
Advisory commentary may inform interpretation, but binding outcomes must remain grounded in the constitution and its binding companion standards.

Section 1. Who May Raise a Dispute

1.1 Standing

A constitutional dispute may be raised by any of the following:

A user affected by the disputed behavior.
An operator, implementer, or maintainer of the system under dispute.
An independent reviewer, auditor, researcher, or evaluator.
Another system claiming constitutional compliance.
A group acting collectively on behalf of affected users.
An automated monitoring or analysis system, including artificial intelligence, provided that the dispute is published in a form humans can inspect and evaluate. Automated disputes must include a human attestation that the evidence bundle has been reviewed by a person before formal submission, or must be categorized as preliminary filings requiring human confirmation before entering the formal dispute record.

1.2 Anonymous and pseudonymous disputes

Disputes may be raised anonymously or pseudonymously.

No dispute may be dismissed solely because the disputing party does not reveal legal identity, provided the evidence is publicly inspectable and the claim is specific enough to evaluate.

1.3 Minimum threshold to initiate a dispute

A dispute must include, at minimum:

The constitutional article or companion standard allegedly implicated.
A factual claim, not merely a conclusion.
A supporting evidence bundle or clear pointer to publicly available evidence.
The specific classification, interpretation, or remedy being requested.

Bare accusation without evidence is not sufficient to initiate a formal constitutional dispute record.

1.4 Frivolous and bad-faith disputes

A dispute that fails to meet the minimum evidentiary threshold in Section 1.3, and is not cured within a reasonable period after the deficiency is identified, may be formally closed as unsubstantiated.

Closure of a frivolous dispute must itself be published in the precedent record with an explanation of why the threshold was not met.

The dispute mechanism must not become an attack surface. Deliberate abuse of the dispute process — including filing multiple thin disputes to force constant disclosure obligations, drain operator resources, or manufacture a false cloud of dispute status over a clean system — may itself be recorded as a pattern in the precedent record and taken into account when evaluating future disputes from the same source.

Section 2. Subject Matter Scope

The following disputes fall within scope:

Breach classification disputes.
Restoration claim disputes.
Constitutional continuity disputes.
Naming and compliance representation disputes.
Interpretation disputes regarding article meaning, definition scope, edge cases, or cross-article interaction.
Disputes over whether a component, bridge, support system, or extension is compliant, partially compliant, non-compliant, or out of scope.
Cross-standard disputes involving alleged contradiction, ambiguity, or hierarchy conflict between companion documents.

The following are generally outside scope unless they directly implicate constitutional protections:

Purely commercial disputes.
Private contractual disagreements not tied to constitutional functions.
Application-level losses that do not affect constitutional rights, exit, reserve truth, custody truth, or compliance representation.
Subjective disputes about aesthetics, popularity, or market success.

Section 3. Dispute Disclosure Requirements

3.1 What the disputing party must publish

A disputing party must publish:

The identity or pseudonymous identifier of the disputing party, if any.
The system or component under dispute.
The article, clause, or companion standard at issue.
The factual allegations.
The evidence relied upon.
The requested classification, interpretation, or corrective outcome.
The date the dispute was initiated.

3.2 What the system under dispute must publish

Once a formal dispute is raised, the system under dispute must respond within the following windows:

For disputes involving exit, reserve truth, custody, censorship resistance, or compliance representation: within 24 hours, consistent with the uncertainty notice deadline in the Breach and Restoration Standard.
For lower-severity interpretation or procedural disputes: within 7 days.

The system must:

Acknowledge the dispute.
State whether it admits, denies, or partially disputes the claim.
Identify which facts are agreed, disputed, or unknown.
Publish any contrary evidence it relies upon.
State whether the dispute affects current compliance claims, restoration claims, or naming claims.

3.3 Silence by the system

Silence by the system under dispute is not treated as automatic concession of every claim.

However:

Silence may be treated as an aggravating factor.
Silence weakens the system's credibility in the dispute record.
Silence does not suspend constitutional consequences that already arise under the constitution or the Breach and Restoration Standard.

3.4 Public visibility of dispute status

The existence and current status of a formal constitutional dispute must be publicly visible in a durable and reasonably discoverable location.

A dispute must not be hidden in private channels while public-facing materials imply no dispute exists.

Section 4. Review Process

4.1 Who may review

A dispute may be reviewed by:

Independent users.
Auditors.
Researchers.
Technical reviewers.
Compliance evaluators.
Artificial intelligence or automated review systems.
Multi-party review panels, provided they satisfy the independence rules in this standard.

4.2 Nature of review

Review under this standard is binding for constitutional classification only to the extent that the published evidence and constitutional reasoning support it.

This standard does not create coercive enforcement power. It creates authoritative public classification power grounded in transparent reasoning.

4.3 Review method

A valid review must be:

Article-cited.
Evidence-cited.
Publicly inspectable.
Clear about what is fact, what is interpretation, and what is judgment.

4.4 Conservative-reading default

Pending final resolution of a genuine dispute, the conservative-reading and public-evidence rules from the Breach and Restoration Standard continue to control.

A system may not use "dispute pending" status to suspend the constitutional default protections owed to users.

4.5 Naming during review

A system under formal unresolved dispute may continue to use constitutional naming only if:

It publicly discloses that the dispute exists.
It does not present the dispute as already resolved in its favor.
It does not claim uninterrupted compliance where the dispute directly contests that claim.

Where the dispute plausibly concerns material breach, continuity, or misrepresentation, a failure to disclose the unresolved dispute may itself constitute misrepresentation.

4.6 Time limits

A dispute review must not remain open indefinitely without status updates.

At minimum:

An initial response window must be declared.
A review status update must be published at reasonable intervals.
Final classification or explicit unresolved status must be published within a bounded review period defined by the reviewing body or companion operational procedure.

If a review remains unresolved beyond that period, the conservative-reading default continues unless and until better evidence changes the outcome.

4.7 Maximum dispute duration

No dispute may remain in active review status for more than 90 days from the date of formal initiation without a published final classification.

If no final classification is published within 90 days:

The dispute automatically enters permanent unresolved status.
The conservative-reading default from the Breach and Restoration Standard locks in as the controlling classification.
The system must publicly disclose the unresolved status and the conservative default that applies.
The dispute may be reopened only under the re-review conditions in Section 6.4.

No reviewing body may extend this ceiling by self-definition, procedural amendment, or mutual agreement with the system under dispute.

4.8 Conflicting reviews

Where two or more credible reviewers publish conflicting classifications of the same dispute, backed by equally strong evidence and genuine constitutional ambiguity:

The more protective classification controls pending resolution.
The conflict must be publicly documented in the precedent record.
Resolution may come through new evidence, a Definitions and Interpretive Notes update that resolves the ambiguity, or a subsequent review that addresses the specific disagreement with stronger reasoning.

General reviewer prestige does not break ties. Constitutional protectiveness does.

4.9 Parallel dispute coordination

Where multiple reviewing bodies are simultaneously reviewing the same dispute:

Each reviewing body should publish awareness of the other's process.
Evidence sharing between parallel reviews should be coordinated where possible to avoid purely procedural divergence.
Users must not be left without clear guidance — the more protective published classification controls until the parallel reviews converge or one is superseded by stronger evidence.
Parallel reviews reaching opposite conclusions must both be recorded in the precedent record with full reasoning.

Section 5. Interim Rules During Dispute

5.1 System behavior during dispute

While a material dispute remains unresolved:

The system must not present the disputed matter as settled in its own favor.
The system must not erase, bury, or downgrade visibility of facts relevant to the dispute.
The system must continue to preserve user rights already required by the constitution.

5.2 Naming restrictions during unresolved dispute

During an unresolved dispute, a system may be required to qualify its naming claims, such as:

compliance disputed
restoration disputed
continuity disputed
naming disputed

The exact required qualifier depends on the subject matter of the dispute.

5.3 Disclosure during dispute

The system under dispute must continue to disclose:

The existence of the dispute.
The status of the dispute.
Whether it affects current user trust assumptions, exit, reserve truth, custody, or naming.

5.4 Conservative-reading control pending resolution

Where a dispute concerns user rights, exit, reserve truth, custody truth, proof cadence, censorship resistance, or compliance representation, the conservative-reading default from the Breach and Restoration Standard controls pending resolution.

5.5 Disputes involving absent companion standards

Where a dispute hinges on a threshold or requirement that should be defined in a companion standard that does not yet exist, reviewers must apply the conservative-reading default from Article XXIX.5 of the constitution: interpretation defaults to the reading that best preserves exit rights, reserve and liability truth, custody independence, non-discretionary operation, censorship resistance, constitutional time limits, and user freedom.

The absence of a companion standard must not be used as grounds to defer resolution indefinitely or to argue that no threshold exists.

Section 6. Resolution and Precedent

6.1 Publication of resolutions

Every resolution must be published in a durable, publicly accessible location and must include:

The dispute identifier or title.
The parties or participants, if disclosed.
The evidence reviewed.
The constitutional articles and standards relied upon.
The final classification, interpretation, or unresolved determination.
The date of publication.

6.1a Evidence preservation

All evidence bundles submitted in support of a dispute — by any party — must be archived in the same durable location as the resolution and must remain accessible for the life of the system.

A resolution published without its supporting evidence bundle is incomplete. An incomplete resolution may not be relied upon as binding precedent.

6.2 Precedent status

Resolutions may create interpretive precedent, but no precedent may override the constitution.

A precedent is persuasive only to the extent that:

Its reasoning is publicly inspectable.
Its evidence remains available.
Its interpretation remains consistent with the constitution and binding standards.

6.3 Precedent record

A durable, publicly accessible precedent record should be maintained where feasible.

That record should allow users and evaluators to inspect:

prior disputes
prior classifications
interpretive patterns
unresolved tensions

6.4 Appeal and re-review

A dispute may be reopened or re-reviewed where:

Material new evidence appears.
A prior review is shown to have had a conflict-of-interest defect.
A later companion standard resolves a previously ambiguous threshold.
The underlying facts materially change.

Appeal does not automatically suspend the prior published resolution unless the appeal itself identifies a credible basis for reclassification.

A re-review request must identify specific new evidence or a specific identified defect that was not available or not considered in the original review. General disagreement with the outcome is not sufficient to reopen a closed dispute.

Section 7. Anti-Capture Protections

7.1 Reviewer independence

No review body may act as sole authoritative reviewer where it is:

Controlled by the system under dispute.
Funded solely by the system under dispute without disclosure.
Operationally dependent on the system under dispute in a way that creates material conflict.

7.2 Conflict-of-interest rules

Reviewers must disclose material conflicts of interest, including:

direct funding
governance role
operational role
legal representation
business dependency
significant token or reserve exposure where relevant

7.3 No sole operator-funded arbiter

An operator-funded or operator-selected review body may participate in review, but must not be treated as the sole arbiter of the system's constitutional standing.

7.4 Funding and governance transparency

Any structured review body must disclose:

How it is funded.
How reviewers are selected.
Whether the system under dispute has any appointment, veto, or funding influence.
What rules govern recusals and conflicts.

Section 8. Interaction with Other Standards

8.1 Breach and Restoration Standard

This standard works together with Breach and Restoration Standard.

Where a dispute concerns breach classification, restoration, continuity, uncertainty notices, or naming consequences, the Breach and Restoration Standard supplies the substantive classification rules, while this standard supplies the dispute process.

8.2 Constitutional Commentary

Constitutional Commentary is advisory. It may inform interpretation, but cannot override binding constitutional text or binding companion standards.

8.3 Definitions and Interpretive Notes

Definitions and Interpretive Notes provides interpretive guidance for defined terms and edge cases. Where a dispute turns on defined language, that document should be consulted alongside the constitution itself.

8.4 UX Constitution

UX Constitution is binding. Where a dispute concerns interface-level compliance — including dark patterns, label blurring, misleading compliance signals, reveal control abuse, or notification manipulation — the UX Constitution provides the substantive standards, while this standard provides the dispute process.

Article XXVII.11 of the constitution explicitly states that UX-level misrepresentation can constitute a constitutional breach. Disputes arising from interface behavior must be evaluated against both the UX Constitution and the protocol constitution.

8.5 Verification Checklist

Verification Checklist may assist evaluators in applying this standard consistently, but does not by itself override the constitution or this standard.

Constitutional Authority

This standard must not weaken, blur, or contradict the principles defined in the Bitcoin System Constitution.

In the absence of this standard, the conservative-reading and public-evidence rules in the Breach and Restoration Standard control.

No procedure created by this standard may be used to delay or suspend constitutional protections that would otherwise apply.

Definitions and Interpretive Notes
Interpretive guidance for defined terms, edge cases, and anti-gaming notes.

Interpretive · Draft

1. Core Structure Terms

Bitcoin

Interpretive note:

The definition of Bitcoin is intentionally narrow. It refers to the Bitcoin network and its native monetary unit, not to any wrapped, represented, bridged, or synthetic form of Bitcoin on another layer or system.

Inside the definition:

Bitcoin held directly on Layer 1.
Bitcoin UTXOs controlled under Bitcoin consensus rules.

Outside the definition:

A wrapped BTC token on another network.
A custodial IOU denominated in BTC.
A Layer 2 balance, even if fully backed and redeemable.

Anti-gaming note:

Actors may try to exploit branding by saying "this is Bitcoin" when they mean "this is a Bitcoin-linked asset." The constitution requires stricter classification than common marketing language.

Layer 1

Interpretive note:

Layer 1 is not merely the oldest chain in a stack. It is the final monetary truth layer recognized by the constitution.

Inside the definition:

Final settlement.
Long-term self-custody.
Bitcoin-native consensus truth.

Outside the definition:

A fast settlement network that periodically checkpoints to Bitcoin.
A sidechain or rollup that derives security from Bitcoin but has its own operational rules.

Usage guidance:

If a system offers convenience but still depends on another system for final truth, it is not Layer 1 under this constitution.

Layer 2

Interpretive note:

Layer 2 is defined by its role, not by one technical pattern. It is the cash rail and support layer for real economic life.

Inside the definition:

Fast Bitcoin-denominated transfer systems.
Payment-oriented systems with finer accounting and lower fees than Layer 1.
Systems designed to be safer and more conservative than Layer 3.

Outside the definition:

A generic smart contract chain with a BTC token.
A speculative execution layer that happens to support Bitcoin.

Anti-gaming note:

Calling something "Layer 2" does not make it a constitutional Layer 2. It must function as the transactional support layer described by the constitution.

Layer 3

Interpretive note:

Layer 3 is the place for programmability, experimentation, and optional higher risk. It is constitutionally downstream from both Layer 1 and Layer 2 in trust.

Inside the definition:

Smart contract environments.
App layers.
Tokenized systems and optional risk-bearing execution environments.

Outside the definition:

Core transactional Bitcoin rail functions that should belong to Layer 2.
Systems marketed as fast but expected to function as final money.

Usage guidance:

If a system is designed to be the place where users build, automate, speculate, or take app-level risk, it is likely Layer 3.

Constitutional layer

Interpretive note:

This is a functional category, not a physical topology requirement. A constitutional layer may be composed of many technical parts.

Anti-gaming note:

A project may not avoid constitutional duties by saying, "This is only a subsystem, not the layer itself," if that subsystem performs core constitutional functions of the layer.

Component, sublayer, module, support system

When does a support system become a component with constitutional duties

A support system becomes a component with constitutional duties when failure, capture, concentration, or misbehavior in that system can materially affect:

reserve truth
liability truth
custody safety
normal downward exit
transaction inclusion
constitutional timekeeping
user ability to distinguish what they hold

Examples:

A read-only public dashboard showing proof data is likely a support system.
A relayer network that users must rely on to exit is no longer a harmless support system. It has constitutional significance.
An indexer used only for convenience may be a support system.
An indexer whose failure makes balances undiscoverable becomes constitutional in effect.

Is an indexer a support system

Usually yes at first.

No, if users cannot meaningfully discover or prove balances without it.

Is a fee market a module

Yes, if it is a distinct functional unit governing transaction ordering, inclusion, or exit economics.

How to evaluate whether internal decomposition weakens, obscures, or evades protections

Ask four questions:

Did the decomposition make risk harder for users to see.
Did it reduce practical exit rights.
Did it move a core duty into a supposedly non-critical subsystem.
Did it create a new choke point while keeping the old constitutional label.

If the answer to any is yes, constitutional concern exists.

2. Monetary Asset Classes

Direct Bitcoin claim

Interpretive note:

A direct Bitcoin claim is stronger than a Bitcoin-denominated balance, but weaker than actual Layer 1 Bitcoin. It is redeemable against Bitcoin reserves through a non-discretionary published process.

Inside the definition:

A claim backed by publicly verifiable reserves and liabilities with a non-discretionary redemption path.
A BTC representation whose reserve and claim set can be independently verified.

Outside the definition:

A balance redeemable only by committee approval.
A BTC IOU issued by a company without proof of liabilities.
A wrapped token with no enforceable or visible reserve process.

Usage guidance:

A direct claim is still a claim. It should never be confused with Layer 1 Bitcoin itself.

Anti-gaming note:

A project may try to say "redeemable under normal conditions" while reserving emergency discretion. That is not non-discretionary redemption.

Bitcoin transactional balance

Interpretive note:

A Bitcoin transactional balance is for use on Layer 2 as money in motion. It may be backed, but it is not defined primarily by reserve marketing. It is defined by its role in ordinary transfer and economic life.

Inside the definition:

A Layer 2 payment balance.
A cash-like BTC-denominated balance used for normal transfers and commerce.

Outside the definition:

A credit position.
A time-locked application-specific position on Layer 3.
A balance that can only move through complex contracts by default.

How to distinguish from a direct Bitcoin claim in practice

A direct Bitcoin claim emphasizes redemption against reserve.

A Bitcoin transactional balance emphasizes everyday movement under Layer 2 rules.

A system can have both features, but the constitutional classification depends on the actual role and user-facing trust model.

Bitcoin utility balance

Interpretive note:

A Bitcoin utility balance is a Bitcoin-denominated balance used inside Layer 3 rules and risk. It is not ordinary money unless the user is fully informed that it remains subject to Layer 3 conditions.

Inside the definition:

A BTC-denominated balance used in a Layer 3 smart contract environment.
A balance used as app collateral, execution fuel substitute, or contract-side asset.

Outside the definition:

A plain Layer 2 cash balance.
A direct Bitcoin claim marketed as current reserve-backed exit money.
A credit instrument paying yield from reserve use.

When does a Bitcoin utility balance cross into being a credit instrument

It crosses over when the holder's position depends on:

lending
rehypothecation
maturity transformation
discretionary repayment
reserve usage for yield

If the balance earns yield because the underlying reserve is being put to work, the balance or associated position has become credit-like.

Native gas token

Interpretive note:

A native gas token is not automatically speculative, but it is not Bitcoin unless it truly is Bitcoin. Clear separation matters.

Anti-gaming note:

Systems often try to create emotional equivalence between a native token and Bitcoin utility balances. The constitution rejects that blur.

Governance token

Interpretive note:

A governance token is defined by authority, not branding. If a token materially influences protocol decision making, it is governance-like even if called something softer.

Credit instrument

Interpretive note:

This definition is intentionally broad because history shows that money-substitute fraud often begins with narrow loopholes.

Examples inside the definition:

BTC lending receipts.
Yield-bearing wrapped balances whose reserves are deployed.
Rehypothecated custody positions.
Maturity-mismatched liabilities presented as stable value.

Examples outside the definition:

A plain transactional balance with no lending or discretionary repayment risk.
A direct Bitcoin claim backed by unencumbered reserve.

Reserve, liability, encumbered reserve, unencumbered reserve

Examples of encumbered reserve

Reserve BTC lent out to earn yield.
Reserve pledged as collateral.
Reserve committed into staking or bonded control.
Reserve subject to third-party lien or claim.

Examples of unencumbered reserve

Reserve held solely to back its claims.
Reserve not lent, pledged, or committed elsewhere.

Edge case: staking rewards

If "staking rewards" arise because reserve assets are being committed into another protocol or risk-bearing arrangement, then the reserve is encumbered and the resulting structure creates either:

a credit instrument
a new liability
or both

It does not remain constitutionally clean reserve merely because the system calls the yield "efficiency."

3. Trust and Movement

Canonical interlayer path

Interpretive note:

A canonical path is the constitutionally recognized normal route or routes for moving balances between layers under the system's core safety promises.

Usage guidance:

A system may have more than one canonical path if each is published, standard, and covered by the claimed protections.

Anti-gaming note:

A team may try to treat a weak path as canonical when convenient and as "just optional" when criticized. The classification must be stable and public.

Trust-minimized

Interpretive note:

Trust-minimized does not mean magical or risk-free. It means bounded, visible, rule-based trust assumptions that do not depend on a specific party's discretion.

Who evaluates "honestly"

No single actor gets to define this unilaterally. Honest evaluation should be based on:

published threat model
available alternatives
disclosed tradeoffs
later companion standards when they exist

Anti-gaming note:

Calling something trust-minimized because it uses signatures or smart contracts is not enough. The real question is whether users still depend on specific actors' judgment or favor.

Strongest available security model

Interpretive note:

This is not a license for self-serving marketing. It is a discipline of public justification.

A credible claim should be able to answer:

What stronger alternative was considered.
Why it was rejected.
What trust assumptions remain.
Why those assumptions were unavoidable at the time.

Until a later standard exists, the conservative reading applies.

Examples of insufficient justifications

The following are generally not enough on their own:

"This was easier to ship."
"This was what our team knew how to build."
"No one else had shipped the stronger option yet."
"We used a trusted multisig because coordination was simpler."
"We call this strongest available because it is the strongest version we personally implemented."

Examples that may count as stronger justification

A published explanation of why a stronger design was technically infeasible at launch.
A clear statement of what stronger model was considered and what concrete dependency blocked it.
Honest disclosure that the current design is transitional rather than ideal.

Trusted path

Interpretive note:

A trusted path depends on trust in specific actors, even if it uses good software or cryptography around that trust.

Examples:

A company-controlled redemption path.
A bridge where a signer council can halt or selectively approve movement.

Contractual path

Interpretive note:

A contractual path depends on law, terms of service, business process, or signed agreements rather than protocol-enforced outcome.

Examples:

Redemption guaranteed by legal contract only.
A business-operated withdrawal path governed by customer account terms.

Non-discretionary

Interpretive note:

Non-discretionary means rule-based operation. It does not mean every human role disappears. It means rights and outcomes do not depend on case-by-case favoritism or politics.

Inside the definition:

deterministic queues
published timeout rules
fixed challenge processes

Outside the definition:

manual review boards
emergency committee approval
selective compliance judgments

Downward exit

Interpretive note:

Downward exit is movement toward a harder, more sovereign layer. It is not merely "moving somewhere else."

Normal downward movement

Interpretive note:

Normal downward movement means ordinary use of a standard exit path under standard conditions, not a one-off rescue by operator grace.

Functional exit blocking vs structural exit blocking

Functional exit blocking examples

Exit is "allowed" but only through KYC intermediaries.
Fees make ordinary exit economically impossible.
Delay is so extreme that exit is practically unusable.
Operators refuse to route specific users.

Legitimate operational limits

Congestion with uniform published rules.
Fee pressure that is neutral and not strategically exclusionary.
Timeouts required by known challenge windows.
Invalid or malformed transactions being rejected.

When does fee-based difficulty become exit interference

When the system is intentionally structured or operated so that ordinary users cannot realistically exercise exit, especially if insiders or institutions retain easier access.

Exit interference

Interpretive note:

Exit interference includes more than formal prohibition. Delay, fees, dependency, or operator favoritism can all count if they materially impair ordinary movement.

Plain transferability

Interpretive note:

Plain transferability protects the idea that money should be movable without mandatory policy wrappers.

Examples inside the definition:

sending a Layer 2 balance directly to another user
receiving a Layer 3 base utility balance without forced contract mediation

Examples outside the definition:

a transfer that can only occur through a mandatory permission contract
a balance that cannot move unless identity data is provided

Voluntary encumbrance

Edge case: time-locked contracts

A time-locked contract is a voluntary encumbrance if:

the holder explicitly opted in
the terms were visible
the lock is part of a known contract condition

It becomes a structural problem if:

users are forced into such contracts to use ordinary money functions
the lock is hidden or unavoidable
the lock cannot unwind into plain transferability on known terms

Bridge

Interpretive note:

A bridge is defined by function, not branding or implementation style. If a mechanism moves value across systems or trust boundaries by locking, wrapping, custodian release, message-mediated release, or equivalent logic, it is a bridge.

When does a bridge become a component with constitutional duties

A bridge becomes a constitutional component when its failure, capture, or discretion can materially affect:

reserve truth
movement between systems
normal downward exit
user asset classification
practical access to Bitcoin-denominated balances

A bridge that merely observes or reports is not usually a constitutional component. A bridge that holds, locks, wraps, releases, or intermediates value usually is.

Is a smart contract automatically a bridge

Not automatically. A smart contract is a bridge when it performs bridge behavior, such as:

locking funds in one system and causing release in another
issuing wrapped balances against locked assets
coordinating cross-system redemption or claims

A contract that only automates internal L3 behavior is not a bridge merely because it is a contract.

Does a bridge between two systems inside the same broader constitutional stack still count

Yes, if it crosses a distinct trust boundary, movement boundary, or asset-class boundary. The fact that two systems are within the same broad stack does not erase bridge risk.

Anti-gaming note:

Teams may try to say "this is not really a bridge, it is just internal routing." If the mechanism introduces bridge-like custody, wrapping, release logic, or trust assumptions, it should be evaluated as a bridge.

4. Governance and Change

Constitutional genesis

Interpretive note:

Constitutional genesis is fixed to stop timeline games. It is not a marketing date. It is the earliest durable public publication date.

Activation

Interpretive note:

Activation is about real exposure, not labels.

Examples of activation:

real users deposit value
real users rely on the component for transfer
funds are at risk in production

Examples that may not count:

closed internal testing with no user reliance
public testnets with no meaningful production value

Anti-gaming note:

"Beta" does not save a system from activation if real users are already depending on it.

Constitutional amendment vs protocol-level change

A constitutional amendment changes:

the text
the meaning
or the operative effect of constitutional protections

A protocol-level change changes:

implementation behavior
parameters
routing
features
operational rules

A technical change becomes constitutional if it materially changes:

exit rights
reserve truth
custody safety
governance reach
the meaning of core protected terms

Governance authority

Interpretive note:

Governance authority is broader than token voting. Any mechanism that can make binding protocol decisions is governance authority, even if it uses:

multisigs
councils
operator committees
foundations
delegated roles

Protocol-level decision and protocol-level change

Interpretive note:

These terms exist so governance cannot hide behind wording like "operational adjustment" or "technical housekeeping" when the change really affects users.

Final implementation

Interpretive note:

Final implementation means the approved change is actually deployed and active, not merely coded, proposed, or announced.

Governance sunset

Interpretive note:

Governance sunset is meant to be real, not ceremonial. After sunset, governance cannot continue by renaming itself, wrapping itself, or acting through new intermediaries.

Examples of violation:

replacing token governance with a council that keeps the same practical authority
creating an "advisory" vote that all operators are expected to obey
introducing a new governance token after sunset within the same claimed compliant system

Constitutional continuity

Interpretive note:

Constitutional continuity means no material break in compliance since public adoption of the constitution by that system.

A short-lived issue does not automatically preserve continuity simply because it was brief. What matters is:

whether the breach was material
whether user rights were impaired
whether system truth was broken
whether continuity-breaking categories in the constitution were triggered

A system may be currently compliant but still lack uninterrupted constitutional continuity.

Anti-gaming note:

Teams may argue that a breach was "too short to count." Duration matters, but materiality matters more.

Successor system

Interpretive note:

A successor system is not defined by branding alone. It is defined by meaningful discontinuity in trust model, rights structure, migration consent, or core operating assumptions.

When does an upgrade become a successor system

A change increasingly looks like a successor system when it:

changes the trust model materially
changes the constitutional rights users rely on
changes the meaning of core asset classes
changes governance authority or sunset structure
requires users to accept a new dependency or custody model
migrates balances or assumptions in a way that goes beyond normal protocol evolution

A large technical upgrade is not automatically a successor. But when users are effectively being asked to trust a different constitutional system, successor logic should apply.

Pre-declared authority

Interpretive note:

Pre-declared authority means authority that was:

published publicly
durably recorded
sufficiently specific to identify the governed subject matter
published before the constitutional amendment window closed

Vague statements like "governance may act as needed for protocol health" do not count.

Examples of governance scope expansion disguised as technical change

adding new emergency powers while calling it "resilience tooling"
moving a reserve function under governance by labeling it "parameter tuning"
giving governance authority over new domains through a generic upgrade module

Parallel implementation right

Interpretive note:

The right to build alternative implementations is meaningless if incumbents can suppress it through legal mechanisms while claiming the protocol is open. Article XXIII.7 closes this gap.

What counts as legal blocking:

Patent threats or litigation against interoperable implementations.
API licensing that requires permission, payment, or identity disclosure to access constitutional functions.
Trademark enforcement against accurate, non-deceptive compatibility claims (e.g., "compatible with X protocol").
Certification or compliance programs that gate access to core protocol features.
Terms of service that prohibit reverse engineering, interoperability, or independent tooling.
Legal threats designed to make independent implementation economically unviable even if technically permitted.

What does NOT violate this right:

Enforcing trademark against actually deceptive branding (e.g., claiming to BE the official implementation when you are not).
Protecting trade secrets that are not necessary for constitutional function implementation.
Requiring accurate disclosure of non-affiliation.
Standard open-source license compliance (e.g., attribution, copyleft obligations).

Anti-gaming note:

The test is whether the legal structure makes truthful independent implementation practically possible for an independent party with ordinary legal resources. A system that says "anyone can implement" while maintaining a patent portfolio aimed at implementers, or requiring expensive licensing for API access, fails this test.

Relationship to protocol openness:

Protocol-level openness (published specs, open code) is necessary but not sufficient. Legal openness is also required. A system with open code but closed legal posture is not compliant with Article XXIII.

5. Custody and Control

Custody structure

Interpretive note:

Custody structure is not just key count. It includes who can coordinate, who can compel, who can replace signers, and what real-world chokepoints exist.

Unilateral control

Interpretive note:

Unilateral control includes practical unilateral control, not just formal single-key control. One person controlling several nominally different signers may still create unilateral control in substance.

Signer

Interpretive note:

A signer is any actor with real reserve-moving authority, even if the technical role is called guardian, operator, validator, committee member, or shard holder.

Independent control domain

Interpretive note:

Independence must be real, not cosmetic. Different shells under one real controller are not independent domains.

Custody concentration

Interpretive note:

Custody concentration exists when reserve control is too dependent on too few real-world control points.

Examples:

Many signers hosted by one company.
Signers spread across legal entities but controlled by one parent group.
Signers in several countries but all vulnerable to one practical coordination channel.
A threshold that looks large but can still be satisfied by one hidden clique.

Anti-gaming note:

Apparent signer count is not enough. Real independence matters more than headline diversity.

Provisional custody

Interpretive note:

Provisional custody is a transitional state, not a rhetorical excuse. It must be:

publicly disclosed
bounded
capped
and directed toward constitutional maturity

A mere statement of intent is not enough.

What provisional custody should include

At minimum:

a public explanation of why full compliant custody is not yet in place
a bounded timeline or declared review/expiry point
a cap on reserve size while provisional custody remains
clear statement that the custody model is not fully compliant
a path or criteria for maturation

What provisional custody must not become

a permanent excuse
a vague "we are still growing" status
a marketing label used to imply near-compliance without real progress

6. Breach and Compliance

Compliant and non-compliant

Interpretive note:

Compliance is about actual behavior, not branding, affiliation, aspiration, or code comments.

Restored compliance

Interpretive note:

Restored compliance is not amnesia.

How much disclosure is enough

At minimum:

what happened
when it happened
what users were affected
what was fixed
whether continuity was broken
whether the system is currently compliant but historically breached

If that is not disclosed, "restored compliance" is not honest.

Timing of restored compliance claims

A system should not claim restored compliance merely because it has published a patch. At minimum:

the breach must be disclosed
the remediation must actually be active
users must have had a meaningful opportunity to understand the breach and, where relevant, exit after disclosure

This document does not set a fixed universal number of days. But immediate next-day "restored compliance" claims after a material breach should generally be viewed skeptically.

Material breach

Interpretive note:

A material breach is one that strikes the constitution where it actually protects users.

Examples:

freezing exit
hiding reserve encumbrance
disguising credit as money
using governance after sunset
silent migration to a successor system

Materially weakens

Threshold guidance

A change materially weakens a protection if it reduces the real-world ability of ordinary users to rely on that protection, even if the text remains untouched.

This includes weakening by:

ambiguity
cumulative drift
concentration
stale proof
fee pressure
discretionary operation
hidden dependency

Examples

Ambiguity: redefining "ordinary transaction" so politically disfavored transactions are no longer treated as ordinary.
Cumulative drift: several small fee increases, queue changes, and operator exceptions that together make ordinary exit unrealistic.
Concentration: shifting more and more choke functions to one company while keeping protocol rules unchanged.
Stale proof: continuing to market balances as backed while proof cadence is missed.
Fee pressure: structuring costs so only large users can exit normally.
Hidden dependency: making all practical exit rely on a legally controlled intermediary.

Misrepresentation

Examples in naming, branding, and marketing

calling a BTC IOU "Bitcoin"
calling stale proof "verified backing"
calling a discretionary bridge "trust-minimized"
using constitutional branding while materially violating the articles

7. Transaction and Inclusion Terms

Ordinary transaction

Interpretive note:

An ordinary transaction is a standard, technically valid, publicly supported request to move value or execute a supported operation through the normal rules of the system. It is defined by rule-conforming behavior and use of published pathways, not by the identity, intent, politics, reputation, or social standing of the sender.

Inside the definition:

A correctly formatted transfer request using supported transaction types.
A redemption request that follows published rules.
A Layer 2 payment using documented parameters.
An exit transaction within published size, fee, and formatting bounds.
Any transaction that would be processed the same way if the sender were anonymous and unknown.

Outside the definition:

A malformed or technically invalid request.
A request that violates explicit published protocol or policy limits.
A request that depends on unsupported behavior, exceptional privileges, or unpublished operator discretion.
A request that triggers a publicly predeclared exploit-mitigation or emergency invalidity rule that existed before the request was submitted.

Anti-gaming note:

The key test is whether the transaction would be treated the same way if the sender's identity, politics, and relationships were unknown. Systems may not redefine "ordinary" to exclude transactions based on:

sender identity
political context
regulatory pressure on specific users
transaction destination
perceived purpose of funds

An ordinary transaction remains ordinary regardless of who sends it or why, so long as it uses a supported path under the published rules.

Usage guidance:

When the constitution protects ordinary transactions from censorship, it means technically valid requests using supported public paths. A system cannot claim compliance while selectively refusing transactions that are rule-conforming but politically inconvenient.

Valid transaction

Interpretive note:

For constitutional purposes, a valid transaction is one that satisfies all published, neutral, identity-blind technical and policy requirements for inclusion under the relevant path. Validity is not merely whatever an operator says it is, and it is not limited to raw consensus validity if the system also relies on published inclusion rules.

Inside the definition:

A transaction with correct cryptographic signatures.
A transaction meeting the published minimum fee or fee rule, where applicable.
A transaction referencing real, usable state or inputs, where applicable.
A transaction within published size, complexity, and format limits.
A transaction that passes the same automated validation checks applied to comparable transactions.

Outside the definition:

A transaction with invalid or missing signatures.
A transaction referencing unusable or nonexistent state or inputs.
A transaction that violates hard protocol rules.
A transaction that fails published neutral validation or anti-spam rules.
A transaction rejected under a rule that is unpublished, selectively applied, or identity-dependent.

Anti-gaming note:

Validity is objective and rule-bound. A system may not declare a transaction invalid because:

it dislikes the sender
it faces pressure regarding the recipient
external parties flagged the transaction
the amount or pattern is politically inconvenient
an operator wants to suppress the use case

If a transaction passes the same published checks that other comparable transactions pass, it is valid. Selective invalidity claims based on identity, politics, or pressure are censorship, not validation.

Relationship to ordinary transaction:

Most ordinary transactions are valid transactions submitted through normal supported paths. Some technically valid edge-case transactions may be unusual without losing constitutional protection. The constitution's baseline test is whether valid public use remains available to ordinary users without special privilege.

Practical path to inclusion

Interpretive note:

A practical path to inclusion is a route by which an ordinary user can get a valid transaction processed within reasonable time and cost bounds, using documented tools and public procedures, without needing special access, insider relationships, exceptional capital, or extraordinary technical measures.

Inside the definition:

A public mempool or submission path that accepts transactions from any user under published rules.
A standard endpoint with documented, neutral acceptance criteria.
A fee market where paying the generally applicable rate provides inclusion without identity checks.
A queue system that processes requests in published order without favoritism.
More than one route to inclusion, where at least one remains practical to ordinary users.

Outside the definition:

A path that requires KYC or identity verification for basic inclusion.
A path that requires a relationship with specific operators.
A path where insiders or large players have systematically faster or cheaper access to the same constitutional function.
A path that is technically open but practically inaccessible due to extreme fees, extreme delays, hidden requirements, or undocumented steps.
A path that exists on paper but is not actually operational for ordinary users.

Threshold guidance:

"Practical" means achievable by an ordinary user with ordinary resources, ordinary technical knowledge, and the documented public tools of the system. The test is not whether inclusion is theoretically possible. The test is whether a typical user can actually achieve it without extraordinary effort or privilege.

Factors that may make a path impractical include:

materially elevated fees without neutral, generally applicable justification
materially elevated delays relative to comparable transactions under comparable conditions
requirements for specialized infrastructure, relationships, or insider knowledge
undocumented queues, hidden approval layers, or informal gatekeeping

Exact operational thresholds should be defined in a later operational standard. Until then, the conservative reading applies.

Anti-gaming note:

A system may claim "anyone can submit transactions" while structuring the actual path so that only insiders, wealthy actors, or specialists can realistically use it. This is functional censorship even if formal censorship does not exist.

The constitutional test is whether ordinary users actually have practical access, not whether documentation claims they do.

Ordinary user

Interpretive note:

An ordinary user is a person or entity using the system through the public, documented, non-privileged path, with ordinary resources, ordinary technical skill, and no special insider access. This term sets the minimum accessibility floor for constitutional protection. It does not reduce protections for users who are more sophisticated, wealthier, or more technically capable.

Inside the definition:

A user with standard technical literacy who can use a wallet and follow documented procedures.
A user with typical financial resources who does not require institutional-scale capital to participate.
A user without special relationships to operators, developers, governance participants, or service providers.
A user relying on published interfaces and documented processes.
A user who expects the system to work as publicly represented.

Outside the definition:

A user relying on private, undocumented, privileged pathways unavailable to the public.
A user receiving preferential treatment through operator relationships, legal arrangements, or insider coordination.
A user whose success depends on exceptional infrastructure or informal access that the system does not publicly promise to ordinary users.

Important clarification:

A sophisticated user, wealthy user, expert, institution, or developer is not excluded from constitutional protection merely because they are sophisticated. The question is whether the right being evaluated is available through the ordinary public path, not whether some protected user is unusually capable.

Usage guidance:

When the constitution refers to rights that must be available to users, the ordinary-user standard is the baseline test. A system cannot claim compliance by saying:

sophisticated users can still exit
large holders can still transact
experts can still recover funds

If ordinary users cannot do the same through the public path, the system is constitutionally weak.

Anti-gaming note:

Systems may try to define their real user base narrowly to exclude the users they find inconvenient. The constitutional test is this: would a reasonable person, seeing the system's public positioning and documented flows, expect to be able to use it through the normal path? If yes, that person counts as an ordinary user for constitutional evaluation.

Relationship to other terms:

Ordinary users submit ordinary transactions.
Ordinary users need practical paths to inclusion.
Ordinary users must be able to exercise exit rights without extraordinary measures.
The constitution's protections are not limited to ordinary users, but ordinary-user accessibility is the minimum test for whether those protections are real.

Constitutional breach from transaction suppression

If valid ordinary transactions are suppressed by coercion and no practical neutral path to inclusion exists, the system is in constitutional breach — except where the restriction arises from a voluntary, explicit, user-chosen encumbrance whose terms were known in advance and are being enforced as written.

Final Interpretive Principle

When a disputed interpretation arises, the preferred reading is the one that best prevents:

hidden credit becoming money
stale proof becoming acceptable truth
temporary governance becoming permanent control
dependence becoming captivity
centralization becoming the only door
constitutional language becoming branding theater

The constitution exists to keep systems honest under pressure, not merely elegant on paper.

Operational Independence and Concentration Standard
Measurable thresholds for when operational concentration becomes constitutionally unacceptable.

Binding · Draft

Governing Principles

The constitution protects users from practical gatekeeping, not merely from formal rule violations.
Concentration is evaluated by control over choke functions, not by raw node counts alone.
Thresholds must scale with real operational participation and real user dependence.
A small network and a large network are not judged by the same raw numbers, but both remain bound by minimum floor expectations.
"We are still early" is never a permanent excuse for dangerous concentration.
User preference for one provider in an otherwise genuinely open market is not by itself a constitutional breach. Structural chokepoints, incentive lock-in, or dependency traps are.
Where uncertainty exists, measurements and classifications shall default to the more conservative reading that best protects exit, inclusion, reserve truth, and user freedom.

Section 1. Sliding-Scale Anti-Concentration Framework

1.1 Measurement window

Unless otherwise specified, concentration shall be measured over a trailing 90-day window.

If the system or relevant component is younger than 90 days, measurement uses the full lifetime of the live system to date.

1.2 Independent control domains

For each choke function, the system must identify the set of independent control domains actively participating in that function during the measurement window.

Let:

N = number of independent control domains actively performing the choke function during the measurement window.

For this standard, N is used only to compute dynamic thresholds. It is not a constitutional validator-count requirement.

1.3 Dynamic threshold functions

For any choke function with active participation count N, the following thresholds apply.

Single-cluster thresholds

Used for:

largest operator share
largest jurisdiction share
largest infrastructure-provider share
largest client-implementation share
largest exit-dependency share

Green threshold:

SG(N) = max(0.15, min(0.50, 1.25 / N))

Yellow threshold:

SY(N) = max(0.25, min(0.67, 1.75 / N))

Red threshold:

SR(N) = max(0.35, min(0.80, 2.25 / N))

If a measured single-cluster share exceeds SR(N), that metric is in the Critical zone.

Top-three concentration thresholds

Used for:

top-three operator share
top-three coordinated-cluster share

Green threshold:

TG(N) = max(0.45, min(0.90, 3.25 / N))

Yellow threshold:

TY(N) = max(0.60, min(0.95, 4.25 / N))

Red threshold:

TR(N) = max(0.75, min(0.98, 5.25 / N))

If a measured top-three share exceeds TR(N), that metric is in the Critical zone.

1.3A Design intent of threshold constants

The constants used in the threshold functions are not arbitrary. They are chosen to create three properties at once:

A small network is not judged by the same raw counts as a larger network.
Early networks are not permanently excused from meaningful distribution.
As the number of active independent control domains grows, acceptable concentration tightens rather than remaining flat.

The constants are calibrated so that, for small and mid-sized live systems, Green status requires visibly meaningful distribution across independent domains, Yellow status warns before concentration becomes constitutionally dangerous, and Red status captures concentration severe enough to threaten ordinary operation or exit.

These functions are binding unless amended through the constitutionally valid process. Disagreement with the constants is not by itself grounds to suspend their application.

1.4 Floor expectation

Regardless of formula output:

A core choke function with only one active independent control domain cannot be Green.
A core choke function with only one active independent control domain is Red at minimum, and may be Critical if it controls ordinary operation, reserve custody, or normal downward exit.
A core choke function with fewer than three active independent control domains cannot be Green unless the system is in a declared provisional phase with public caps, deadlines, and decentralization milestones.

1.5 No permanent bootstrap excuse

A system may begin above its long-term concentration target, but:

that concentration must be publicly disclosed
its reduction path must be published
it must have deadlines
failure to reduce concentration on that path has constitutional consequences

Section 2. Choke Function Analysis

2.1 Choke-function principle

A choke function is any operational function whose failure, capture, concentration, or coordination can materially affect:

transaction inclusion
normal downward exit
reserve truth
reserve custody
proof publication
settlement publication
bridge release or redemption
protocol mutability
practical user access to constitutional rights

2.2 Core choke functions

The following are core choke functions:

Transaction ordering or sequencing.
Block production, validation, or equivalent acceptance of state updates where those functions affect ordinary inclusion.
Canonical bridge operation or release where a canonical path depends on it.
Normal downward exit processing.
Reserve custody for direct Bitcoin claims or Layer 2 transactional balances.
Proof generation, proof publication, or authoritative reserve-state publication for reserve-backed claims.
Upgrade deployment while protocol mutability still exists.

2.3 Auxiliary choke functions

The following may be auxiliary choke functions, but become core if practical user dependence is high:

Fee setting, where operator-controlled.
Routing and mempool access.
Settlement publication if ordinary users materially depend on it.
Withdrawal batching or release services.
Shared relayer systems.
Common attestation pipelines.

An auxiliary choke function becomes a core choke function when either of the following is true:

More than 50 percent of ordinary users depend on it for normal operation or normal downward exit.
Its failure, capture, or concentration would delay normal downward exit beyond the constitutional maximum or materially impair practical path to inclusion.

Once an auxiliary choke function becomes core, it must be measured and zoned under the same rules as any other core choke function.

2.4 What matters more than node count

A system must not rely on raw node count as its primary concentration defense if practical control of choke functions remains concentrated elsewhere.

Section 3. Concentration Measurement

3.1 Unit of measurement

Concentration must be measured by effective control, not merely by nominal participation.

Effective control may include aggregation across:

the same legal entity
the same corporate family
the same operator cartel
the same funding controller
the same infrastructure cluster
the same jurisdictional capture domain
the same code implementation if a common failure or exploit would disable all of them together

3.2 Required concentration measures

For each core choke function, the system must publish, at minimum:

Largest operator share

The share of the choke function controlled by the single largest independent control domain.

Top-three operator share

The cumulative share controlled by the three largest independent control domains.

Largest jurisdiction share

The share capturable by one legal or regulatory jurisdiction.

Largest infrastructure-provider share

The share dependent on the same cloud provider, datacenter family, or equivalent infrastructure cluster.

Largest client-implementation share

The share dependent on the same codebase or client implementation for that choke function.

Largest exit-dependency share

The share of users whose normal downward exit depends on the same operational cluster.

3.3 Correlated failure domains

Operators that would likely fail together under the same stress event shall be measured together where constitutionally relevant.

Examples include:

same corporate parent
same major cloud dependency
same jurisdictional seizure path
same client monoculture
same signer-hosting provider

3.4 Reserve custody overlap

Where reserve custody exists, this standard measures operational concentration of custody clusters. Exact signer requirements remain governed by Reserve Custody and Key Management Standard.

3.5 Materiality floor

For this standard:

A change is presumptively material if a measured concentration, delay, dependency, or resilience metric worsens by more than 5 percent relative deterioration within a single reporting period, unless a publicly documented and constitutionally neutral justification is provided.
A comparison is materially comparable only where the transactions, users, or operational conditions being compared are similar in type, fee conditions, network conditions, and constitutional function.
Comparisons that mix unlike conditions in order to dilute concentration, delay, or censorship findings are invalid.

3.6 Anti-gaming measurement rule

Trailing-window averages do not excuse short periods of constitutionally dangerous concentration.

If any concentration metric exceeds the applicable Red threshold for more than 7 consecutive days within the reporting window, that metric shall be treated as Red for the reporting period unless the system proves that the excursion was caused solely by a neutral and temporary failure outside operator control.

If any concentration metric exceeds the applicable Critical threshold for more than 72 consecutive hours, that metric shall be treated as Critical for the reporting period unless the system proves that the excursion was caused solely by a neutral and temporary failure outside operator control.

Temporary cosmetic expansion of nominal participants that does not create durable independent control domains does not reduce concentration for purposes of this standard.

Section 4. Censorship Resistance Thresholds

4.1 Practical path to inclusion

A practical path to inclusion exists only if an ordinary user can submit a valid ordinary transaction through a public, documented, and non-discretionary path without:

special relationships
identity-gated access
insider-only routing
extraordinary technical effort
extraordinary fee burden

4.2 Acceptable delay

Under normal conditions, a valid ordinary transaction is considered within acceptable delay if it is included within:

the greater of 3 times the rolling median inclusion time for comparable transactions under comparable fee conditions, or
12 blocks where the transaction is part of normal downward movement

This threshold may be refined by later review, but not weakened without public justification.

4.3 Sustained censorship

Sustained censorship is presumed where valid ordinary transactions, or a specific affected class of such transactions, are:

delayed beyond 2 times the acceptable-delay threshold for more than 24 hours, or
repeatedly subjected to materially worse inclusion than comparable transactions across three or more distinct 24-hour windows in a rolling 30-day period, without neutral justification

4.4 No practical path to inclusion

A practical path to inclusion is presumed absent where:

All public submission paths are identity-gated, relationship-gated, or practically inaccessible to ordinary users.
Fees required for inclusion exceed materially comparable neutral market fees without publicly justified and generally applied reasons.
The only paths require insider coordination or extraordinary infrastructure.
A single operator or coordinated cluster can indefinitely refuse inclusion for valid ordinary transactions.

4.5 Neutral reasons that do not count as censorship

The following do not by themselves constitute censorship, provided they are published, identity-blind, and generally applied:

malformed transaction rejection
invalid state rejection
minimum fee rules applied consistently
temporary congestion management
anti-spam rules applied neutrally
contract terms that the user explicitly and voluntarily accepted

4.6 Economic coercion and incentive-based suppression

Where there is credible evidence that financial incentives, bribery, side payments, induced coordination, or other economic coercion are being used to systematically exclude, delay, or disadvantage a class of valid ordinary transactions, that pattern shall be evaluated as censorship under this standard.

The standard does not distinguish between suppression by formal command and suppression by economic inducement.

Such a pattern may qualify as sustained censorship even if no written rule prohibits inclusion.

Section 5. Directional Decentralization Measurement

5.1 Progress, stagnation, regression

Directional decentralization is measured across reporting periods.

A system is progressing if:

at least three core concentration metrics improve over two consecutive reporting periods, and
no core concentration metric materially worsens

A system is stagnating if:

concentration remains materially unchanged across two consecutive reporting periods, and
network participation, user reliance, or value under operation has grown materially

A system is regressing if:

a core metric worsens by more than 10 percent relative deterioration across a reporting period, or
operator or governance decisions entrench existing chokepoints

If a system crosses into a worse compliance zone under Section 7, the zone transition governs current compliance status immediately, regardless of whether the directional deterioration threshold in this section has been crossed.

5.2 Entrenching centralization

A system is presumed to be entrenching centralization if it:

keeps a provisional structure open-ended
preserves incumbent privilege in operator admission
resists addition of independent control domains without public justification
allows concentration to worsen as participation or value grows
shifts more choke functions under the same actor set

5.3 Required reporting cadence

A system must publish concentration and decentralization reports at least every 90 days, and additionally within 7 days of entering a worse compliance zone.

Such reports must be published in a public, durable, and reasonably discoverable location. Reports published only in obscure technical channels, private dashboards, or inaccessible API outputs do not satisfy this requirement.

Section 6. Phase-Based Expectations

6.1 Principle

The sliding scale must not become a permanent excuse for dangerous concentration because the network is still small.

6.2 Provisional phase

A system may be treated as in a provisional decentralization phase only if all of the following are true:

The concentration is publicly disclosed.
The affected choke functions are named.
The system publishes a public decentralization plan.
The plan includes deadlines and measurable milestones.
Reserve size or operational exposure is bounded where constitutionally relevant.
The system does not present provisional operation as mature compliance.

6.3 Required decentralization plan

A constitutional decentralization plan must publish:

the current concentration state
the target state
measurable milestones
deadlines
blocker explanations
consequences if milestones are missed

6.4 No permanent early-phase excuse

No system may rely indefinitely on claims such as:

"we are still early"
"we are still decentralizing"
"this is temporary"

without measurable progress.

Persistent failure to progress converts provisional concentration into a compliance problem.

6.5 Exit from provisional status

A system exits provisional decentralization status only when:

it has met its published decentralization milestones
it satisfies the applicable Green-zone requirements for all core choke functions
it has remained outside provisional caps and exception logic for at least two consecutive reporting periods
no material concentration exception remains undisclosed or unresolved

A system may not remain labeled provisional after these conditions are satisfied, nor may it claim mature compliance before they are satisfied.

Section 7. Compliance Zones

7.1 Zone definitions

Zone	Status	Meaning
Green	Compliant	Concentration within acceptable bounds for current network size and structure
Yellow / Warning	At risk	Concentration approaching constitutional concern; corrective action required
Red / Failure	Non-compliant	Concentration too high to call the system compliant
Critical	Continuity-threatening	Concentration so severe it may break constitutional continuity

7.2 Zone assignment

For each core choke function, assign a zone based on the worst applicable measured metric:

Green if all measured metrics are within Green thresholds
Yellow if any metric exceeds Green but none exceeds Yellow
Red if any metric exceeds Yellow but none exceeds Red
Critical if any metric exceeds Red

The system-wide zone is the worst zone among its core choke functions, adjusted upward where cross-function dependence materially compounds risk.

7.3 Zone consequences

Green

compliant with this standard

Yellow / Warning

mandatory public disclosure within 7 days
corrective action plan within 30 days
no claim that concentration is safely resolved

Red / Failure

current non-compliance under this standard
presumptive material breach under Breach and Restoration Standard
public disclosure within 72 hours
corrective action plan within 14 days

Critical

presumptive continuity-breaking breach
may trigger successor logic if sustained, concealed, or combined with other core breaches
immediate disclosure required under the Breach and Restoration Standard
in addition to immediate public disclosure, Critical zone status requires active notification to users through the system's primary user-facing interface within the same disclosure timeframe, where such an interface exists

7.4 Transition rules

A system enters a worse zone immediately upon crossing the threshold.

A system returns to a better zone only after:

two consecutive reporting periods at the better level, and
public disclosure of the transition

7.5 User preference safeguard

A system is not in breach merely because many users prefer one provider, wallet, or interface, so long as:

alternatives remain genuinely open
alternatives remain practical for ordinary users
the protocol and incentives do not structurally entrench one chokepoint

Section 8. Interaction with Other Standards

8.1 Constitution

This standard operationalizes:

Article XXIV (Directional Decentralization and Operational Concentration)
Article X (Transaction-Level Censorship Resistance)

8.2 Breach and Restoration Standard

Red and Critical zone conditions may trigger classification under Breach and Restoration Standard.

8.3 Reserve Custody and Key Management Standard

Where concentration concerns reserve custody specifically, this standard works together with Reserve Custody and Key Management Standard.

8.4 Verification Checklist

Verification Checklist may assist evaluators in applying this standard consistently, but does not override this standard.

8.5 UX Constitution

Where concentration manifests through user-facing access paths to constitutional functions, including wallet dominance, interface routing dominance, or practical monopoly over visible exit paths, this standard applies together with UX Constitution.

A chokepoint in user-facing access may constitute operational concentration even where alternative paths exist in theory, if ordinary users are not given a practical and visible way to use them.

Final Rule

The real question is not:

"How many validators or operators do we have?"

The real question is:

"How easy is it for one pressure point to control meaningful operation or exit right now?"

If that answer becomes dangerously favorable to one pressure point, the system is in constitutional danger, no matter how good the code looks.

Reserve Custody and Key Management Standard
Exact custody thresholds, signer requirements, key ceremony rules, and concentration limits.

Binding · Draft

Governing Principles

No reserve backing direct Bitcoin claims or Layer 2 transactional balances may be subject to unilateral control.
Apparent signer count is not enough. Real independence matters more than headline diversity.
A custody structure must be secure against:

single-key failure
single-operator compromise
small-clique collusion
single-jurisdiction coercion
infrastructure monoculture
silent signer substitution

Provisional custody is allowed only as a disclosed, bounded, capped transition. It is not full compliance.
Signer growth must reduce concentrated control, not merely expand the appearance of decentralization.
If a custody threshold or requirement is not explicitly met, the more conservative compliance reading applies.

Section 1. Scope and Applicability

1.1 In-scope reserves

This standard applies to all reserves backing:

direct Bitcoin claims
Bitcoin transactional balances on Layer 2
any other balance that the system presents as reserve-backed Bitcoin access

1.2 Out of scope

This standard does not directly govern:

purely optional Layer 3 credit instruments
unbacked utility balances
speculative balances not presented as reserve-backed Bitcoin

However, if any such system is marketed or functionally presented as reserve-backed Bitcoin access, this standard applies.

1.3 Measurement basis

Where thresholds depend on reserve exposure, exposure shall be measured as the highest daily reserve-backed balance observed during the trailing 30-day window, denominated in BTC.

Section 2. Custody Bands and Minimum Threshold Requirements

2.1 Principle

Thresholds scale with reserve exposure. Lower exposure does not excuse unsafe custody forever, but higher exposure demands materially stronger custody.

2.2 Minimum operational signer bands

Reserve-backed exposure (BTC)	Minimum active operational signers (N)	Minimum spend threshold (T)	Minimum independent jurisdictions
>0 to 250 BTC	3	2	2
>250 to 2,500 BTC	5	3	3
>2,500 to 25,000 BTC	7	5	4
>25,000 BTC	9	6	5

2.3 Higher bands allowed

A system may voluntarily adopt the thresholds of a higher band than required by current exposure. Doing so is constitutionally favored.

2.4 Full-compliance floor

A system meeting only the minimum of the lowest band is not automatically fully compliant if other independence, concentration, or provisional-custody conditions are not met.

2.5 Threshold rule

For any operational signer set:

The spend threshold must always be greater than one.
The spend threshold must always exceed one half of the active signer count once N is 7 or greater.
No single signer and no subset below the threshold may unilaterally move, steal, or encumber reserves.

Section 3. Jurisdiction, Entity, and Infrastructure Distribution

3.1 Single-jurisdiction limit

No single jurisdiction may control, host, or legally compel enough operational signers to satisfy the spend threshold by itself.

3.1A Jurisdiction definition for custody purposes

For purposes of this standard, a jurisdiction means a distinct legal and regulatory compulsion domain in which a single legal order could compel all signers located within it simultaneously.

Jurisdictional independence is measured by practical compulsion risk, not by superficial geographic labeling.

Different subdivisions within the same sovereign legal order do not automatically count as separate jurisdictions if the same legal or regulatory process could compel them together.

3.2 Jurisdiction concentration rule

For fully compliant custody:

no single jurisdiction may contain more than T - 2 active operational signers
and no single jurisdiction may contain more than one third of active operational signers, whichever is stricter

3.3 Corporate-family limit

No single legal entity or corporate family may control more than:

1 operational signer in any band
2 recovery quorum members in any band

This limit applies regardless of provisional status.

Provisional custody may relax exposure band requirements and maturity timing only where explicitly allowed by this standard. It does not relax independence requirements.

3.4 Infrastructure concentration limit

No single cloud provider, hosting cluster, datacenter family, managed key provider, or equivalent infrastructure concentration point may support more than:

one third of active operational signers for bands at or above 7 signers
one half of active operational signers for bands below 7 signers

3.5 Client implementation concentration

For bands at or above 7 operational signers:

no single signing software implementation may support more than two thirds of active operational signers

For exposures above 25,000 BTC:

no single signing software implementation may support more than one half of active operational signers

3.6 Correlated domains

Where several signers share the same effective control, failure domain, or compromise path, they shall be measured together.

Section 4. Key Ceremony Requirements

4.1 Required public ceremony record

Every initial key ceremony and every full re-ceremony must generate a durable public record sufficient to verify:

ceremony date
signer count
threshold
participating jurisdictions
hardware or HSM class used
software versions or signing stack versions
cryptographic identifiers or fingerprints of resulting public keys
whether the ceremony was initial, replacement, or emergency

4.2 Secret handling

Private key material must not be transmitted in plaintext or reconstructed outside the declared secure ceremony process.

4.3 Witnessing and attestation

Each ceremony must produce signed attestations from participating custody operators that:

the declared process was followed
the stated threshold and signer distribution are accurate
no undeclared shared control exists to the best of the attestors' knowledge

For reserve-backed exposure above 2,500 BTC, at least one independent non-signer witness must attest to ceremony conduct. That attestation must be published alongside participant attestations and must identify whether the witness observed any deviation from the declared ceremony process.

4.4 Emergency ceremonies

Emergency re-ceremonies are allowed, but must be publicly disclosed within 24 hours of completion unless disclosure would itself materially endanger funds. In that case, disclosure must occur as soon as the acute danger has passed.

Section 5. Hardware Security Requirements

5.1 Core requirement

Operational and recovery signing material must be generated, stored, and used in hardware-isolated environments appropriate to their role.

5.2 Prohibited practices

The following are prohibited for reserve-backed custody:

storing reserve-signing keys in general-purpose hot wallets
using browser-managed key storage for reserve movement authority
exporting plaintext private key material after generation except where constitutionally required for a separately protected archival recovery process
relying on ordinary cloud VM memory as the primary long-term home of reserve-signing keys

5.3 Acceptable control environments

Reserve-signing material must use one or more of:

dedicated HSMs
hardware wallets or signing devices with verified firmware paths
air-gapped signing environments
secure enclaves with public attestation, where constitutionally appropriate
functionally equivalent secure hardware architectures

5.4 Recovery hardware

Recovery quorum material must be held in colder and materially more isolated environments than routine operational signers.

Section 6. Rotation, Review, and Signer Changes

6.1 Regular review cadence

All signer assignments, jurisdictions, infrastructure dependencies, and software stacks must be reviewed at least every 180 days.

6.2 Rotation cadence

Operational signing material must be rotated or re-attested no less often than every 24 months, unless the system publishes a stronger security justification for a longer interval and that interval does not exceed 36 months.

6.3 Immediate rotation triggers

Immediate rotation or removal action is required upon:

suspected key compromise
confirmed signer compromise
undisclosed shared control discovered
critical software compromise in the signing stack
signer legal capture that materially changes coercion risk
signer insolvency
signer regulatory shutdown, dissolution, or equivalent forced cessation
material violation of this standard by a signer

Upon a mandatory immediate rotation trigger, the affected signer's authority must be suspended as soon as constitutionally and operationally possible pending completion of rotation or replacement. It is not sufficient merely to schedule rotation while the compromised or constitutionally impaired signer remains active.

6.4 Public disclosure of signer changes

Planned signer addition, removal, or replacement must be publicly disclosed at least 7 days before taking effect.

Emergency changes may occur faster, but must be disclosed within 24 hours unless acute risk temporarily prevents disclosure.

6.5 Auditability

A durable public record of signer additions, removals, replacements, and threshold changes must be maintained.

Section 7. Recovery Quorum Rules

7.1 Independent recovery requirement

A reserve-backed custody system must maintain a recovery quorum independent from the daily operational signer path.

7.2 Minimum recovery quorum

Reserve-backed exposure (BTC)	Minimum recovery quorum members	Minimum recovery threshold	Minimum independent jurisdictions
>0 to 2,500 BTC	5	3	3
>2,500 to 25,000 BTC	5	4	3
>25,000 BTC	7	5	4

7.3 Overlap limit

No more than 40 percent of recovery quorum members may also be active operational signers.

In addition:

overlap members must not by themselves be sufficient to satisfy both the operational spend threshold and the recovery threshold
the overlap set must not create a practical path for the same small coordinated group to dominate both ordinary reserve movement and recovery reconstitution

If a band-specific configuration would allow such dual domination despite numerical compliance, the custody structure is non-compliant.

7.4 Recovery quorum strength

A recovery quorum must not be materially easier to compromise than the operational custody path. If a lower threshold is used for recovery, the system must justify why the colder environment and stronger isolation offset the lower numerical threshold.

7.5 Recovery trigger

Recovery quorum authority may be used only for:

reconstituting the operational signer set
restoring user control after operator disappearance or refusal
replacing compromised signers
preserving funds when operational quorum is no longer reliable

It must not be used as a convenience shortcut for ordinary reserve movement.

Section 8. Anti-Sybil Admission Requirements

8.1 Objective criteria

Signer admission criteria must be:

public
rule-based
specific
measurable

8.2 Independence proof

A candidate signer must demonstrate independent control domain status through one or more of:

public disclosure
cryptographic attestation
legal separation evidence
operational separation evidence
jurisdictional separation evidence
privacy-preserving but reviewable independence attestations that can be evaluated under the Constitutional Dispute and Review Standard process, with evidence made available to that process under appropriate confidentiality protections

Self-assertion alone is insufficient.

8.3 No arbitrary incumbent veto

Incumbent signers may reject applicants only for failure to meet published criteria, not for competitive, political, or social preference.

8.4 Anti-sybil aggregation

Candidates with shared beneficial control, shared coercion path, or shared infrastructure dependency may be counted as one effective control domain for compliance purposes.

Section 9. Signer Removal Procedures and Conditions

9.1 Mandatory removal or suspension triggers

A signer must be suspended or removed when:

compromise is confirmed
prolonged unavailability exceeds published maximum tolerance
false independence claims are proven
required rotation or re-attestation is refused
the signer becomes part of an unconstitutional concentration cluster
the signer materially violates this standard

9.2 Emergency suspension

Emergency suspension may occur before full investigation where credible risk to reserves exists. Such suspension must be followed by public disclosure and review.

9.3 No silent removal

Signer removal must not occur silently.

9.4 Replacement safety

Adding or replacing signers must not:

lower threshold protections
worsen jurisdiction concentration
worsen operator concentration
worsen infrastructure monoculture
make recovery weaker

For planned changes, a post-change concentration analysis must be published at least 7 days before the change takes effect.

That analysis must be publicly reviewable and sufficiently detailed for independent evaluators to assess whether concentration, independence, and recovery posture are materially weakened.

Emergency changes may occur faster, but the same analysis must be published within 24 hours after the change unless acute risk temporarily prevents disclosure.

Section 10. Provisional Custody Rules

10.1 Principle

Provisional custody is a transitional state only. It is not fully compliant custody.

10.2 Minimum provisional requirements

A system claiming provisional custody must, at minimum:

satisfy the lowest exposure band thresholds
disclose its provisional status publicly
publish a reserve cap
publish a maturity plan
publish deadlines and milestones
disclose the precise ways in which it is not yet fully compliant

10.3 Duration limit

Provisional custody may not continue beyond 12 months from activation of the reserve-bearing component unless a stricter project-specific deadline has already been declared.

10.4 Reserve cap

A provisional system must hard-cap reserve-backed exposure at a publicly declared amount before accepting user funds.

That cap:

must be technically enforceable or publicly auditable
must not be raised without 30 days prior public notice
must not be raised if prior maturity milestones have been missed
may be raised only after the immediately preceding maturity milestone has been publicly verified as complete

Being merely not-yet-late is not sufficient to justify a cap increase.

10.5 No full compliance claim

A provisionally custodied system must not claim:

full constitutional compliance
full compliance with Article XIV
full reserve-custody compliance

It may only claim provisional or partial compliance, with explicit disclosure.

10.6 Failure to mature

Failure to meet the published maturity path or deadline constitutes a compliance issue under the constitution and may escalate under the Breach and Restoration Standard.

Section 11. Recovery if Many Signers Disappear

11.1 Operational quorum loss

If operational signer availability falls below threshold:

ordinary reserve movement must halt unless constitutionally necessary for user protection
recovery quorum procedures must begin under published rules
public disclosure must occur within 24 hours

Such a halt must not block users from initiating normal downward exit through the recovery quorum path or any other constitutionally valid alternative path that remains available.

11.2 Recovery quorum degradation

If recovery quorum availability also falls below threshold:

the system must publicly disclose that reserve recovery is at risk
affected balances must not continue to be represented as normally secure
constitutional breach evaluation may be triggered

11.3 Reconstitution

Reconstitution of signer sets must preserve or improve:

threshold security
independence
jurisdictional spread
concentration posture

It must not be used as a pretext to consolidate power.

Section 12. Concentration Limits and Compliance Zones

12.1 Green

Custody is Green only if:

all applicable band thresholds are met
no concentration limit is exceeded
no provisional-custody status remains
recovery quorum requirements are met
signer changes are fully auditable

12.2 Yellow / Warning

Yellow applies where:

a concentration limit is approached or slightly exceeded
a required rotation is overdue but not dangerously so
independence evidence is incomplete
a signer cluster has become temporarily too correlated

Yellow requires:

public warning within 7 days
corrective action plan within 30 days

12.3 Red / Failure

Red applies where:

a required threshold or distribution rule is materially violated
provisional custody overstays its deadline
one operator cluster or jurisdiction materially dominates reserve movement
recovery quorum requirements fail but no actual loss or rewrite has yet occurred

Red is non-compliant and should be classified under the Breach and Restoration Standard.

12.4 Critical

Critical applies where:

unilateral or near-unilateral reserve movement becomes possible
a single coercion domain can practically compel reserve movement
reserve recovery is plausibly impossible under current conditions
signer concentration makes immediate user loss realistically likely

Critical conditions may constitute continuity-threatening breach.

12.5 Return to Green

A system that has entered Yellow, Red, or Critical custody status may return to Green only after:

meeting Green requirements for all applicable custody metrics
maintaining those conditions for two consecutive reporting periods
publicly disclosing the return-to-Green claim with supporting evidence

A temporary single-period improvement is not sufficient to re-establish Green status.

Section 13. Relationship to Other Standards

13.1 Constitution

This standard operationalizes Article XIV of the Bitcoin System Constitution.

13.2 Operational Independence Standard

Where custody concentration overlaps broader operator concentration, this standard works together with Operational Independence Standard.

13.3 Breach and Restoration Standard

Violations of this standard are classified under Breach and Restoration Standard.

13.4 Verification Checklist

Verification Checklist may assist evaluators in applying this standard consistently, but does not override this standard.

13.5 UX Constitution

User-facing disclosure of custody structure, custody-zone status, provisional custody status, and material custody-zone changes is governed jointly by this standard and UX Constitution.

Where custody status changes materially affect user trust assumptions, users must be informed through constitutionally compliant interface disclosure.

Final Rule

A reserve backing Bitcoin access is constitutionally sound only when:

it is real
it is current
it is unencumbered
and no single person, operator cluster, jurisdiction, or hidden clique can quietly take it away

Software and Security Architecture Standard
Required implementation behaviors for custody, recovery, delegation, and long-term system integrity.

Binding · Draft

Governing Principles

The constitution remains primary. This standard operationalizes, but does not override, Articles XXV and XXVI.
Operational control must never silently become ultimate ownership control.
Delegation is permitted. Irrevocable dependence is not.
Recovery must remain possible even if daily operators disappear, are captured, are offline, or refuse service.
Recovery-critical semantics must remain stable across time.
Recovery-critical software must be verifiable, preservable, and not silently mutable.
Any implementation choice that weakens revocability, separation, archival recoverability, or user escape is non-compliant unless explicitly authorized by the constitution.
This standard uses definitions from Article I exclusively. Any undefined technical term used here is descriptive only and does not override constitutional definitions.

Section 1. Delegated, Revocable, Rotating Capability Trees

1.1 Required model

Where a system supports delegated control, it must implement delegation through a capability structure anchored in a colder, harder-to-compromise root authority or a functionally equivalent control model.

A compliant delegation architecture must ensure that delegated authority is:

scoped
revocable
time-bounded or rotation-bounded
distinguishable from ownership
incapable of silently overriding recovery rights

Literal tree data structures are not mandatory, but the implemented architecture must provide equivalent guarantees.

1.2 Capability scope

Delegated capabilities must be limited by one or more of the following:

action type
value range
asset class
time window
layer or context
destination policy
frequency or rate limit

Open-ended delegation without scope is prohibited for any authority that can materially affect user funds.

1.3 Cold roots

Any architecture using delegation must anchor ultimate recovery or revocation power in a colder control domain than the one used for routine operations.

Cold roots must not be:

permanently online by default
required for routine daily operation
silently replaced or bypassed by operator convenience paths

1.4 Recovery quorums

Where recovery quorums are used, they must be independent of the day-to-day operational key path.

A recovery quorum must not be reducible to the same operator set that controls ordinary operations.

1.5 Rotation

Delegated operational authority must rotate on a declared schedule or under a declared rotation policy.

Long-lived operational keys are permissible only if:

they remain clearly subordinate to root and recovery control
they are revocable without delegate cooperation
they cannot trap or irreversibly transfer ownership

1.6 No hidden broadening of delegated authority

No software update, operator intervention, or policy change may silently broaden the scope of an existing delegated capability.

Any broadening of capability scope must be explicit, visible, and separately consented to by the delegator.

Section 2. Separation of Operational and Ultimate Control

2.1 Core requirement

Day-to-day operational keys and ultimate ownership or recovery keys must remain meaningfully distinct.

2.2 Prohibited control collapse

No operational key, hot key, operator key, session key, API credential, or delegated capability may by itself:

irreversibly transfer ownership
permanently disable recovery
permanently change the recovery profile
rebind a user into a new trust model without explicit higher-authority consent

2.3 Ownership transfer vs convenience delegation

The system must clearly distinguish between:

convenience delegation
temporary authority
operational authorization
ownership transfer

Routine use of a delegated path must not be treated as implied transfer of ownership.

2.4 Location and environment separation

Where possible, ultimate control and operational control must be held in materially different control environments.

Operational convenience is not a sufficient reason to collapse all control into the same device, service, or operator path if doing so would eliminate meaningful recovery independence.

2.5 Replacement and succession rules

Changes to operational control must not automatically affect ultimate control.

Changes to ultimate control must require a stronger consent path than changes to operational control.

Section 3. Revocability of Delegation

3.1 Core requirement

All delegation must be revocable by the delegator or by a constitutionally valid recovery path.

3.2 No delegate cooperation requirement

Revocation must not require cooperation, approval, availability, or good behavior from the delegate.

A delegate must not be able to hold the delegator hostage by refusing to participate in revocation.

3.3 Time-bounded delegation

Time-bounded delegation is preferred over open-ended delegation wherever practical.

If delegation is open-ended, the system must justify why a bounded model was not used and must still preserve immediate or bounded revocation.

3.4 Revocation path independence

The revocation path must be available even if:

the delegate is offline
the delegate is hostile
the delegate has been captured
the operator service is unavailable
the software vendor has disappeared

3.5 Declared revocation latency

If revocation is not immediate, the system must declare the maximum revocation latency.

For delegation that materially affects normal downward exit, user withdrawal capability, or restoration of independent control over reserve-backed or Bitcoin-denominated balances, the declared revocation latency must not exceed the constitutional maximum downward movement delay.

For other forms of delegation, the declared revocation latency must be specifically disclosed, technically justified, and bounded strongly enough that escape does not become practically illusory.

Any declared revocation latency that renders escape, exit, or independent control practically unavailable to ordinary users may constitute a breach under the constitution and Breach and Restoration Standard.

3.6 Revocation must not weaken funds recoverability

A revocation process must not force the user into a worse trust model merely to revoke a delegate.

Section 4. Recovery Independence from Daily Operators

4.1 Core requirement

Recovery must not depend on the same actors, infrastructure, or control path that run the system's ordinary daily operations.

4.2 Independent recovery path

A compliant system must provide an independent recovery capability sufficient to restore user control under the conditions contemplated by Article XXVI.6.

4.3 Required failure assumptions

Recovery must remain possible if the ordinary operator:

disappears
is captured
refuses service
is legally restrained
experiences prolonged outage
becomes malicious

4.4 No single-operator recovery choke point

No single operator, company, hosted API, or centralized service may be the only path by which a user can recover from dependence.

4.5 Recovery documentation

The system must document, in technically accurate but user-legible form:

how recovery works
what prerequisites are needed
what happens if the operator disappears
what happens if the user loses routine access but still holds ultimate recovery material
what conditions, delays, or thresholds apply

4.6 Distinction from normal use

Recovery architecture is not required to be convenient for daily use.

It is required to be real, independent, and durable.

4.6A Partial recovery quorum failure

The system must document the recovery path where one or more recovery quorum participants become unavailable, hostile, seized, or uncooperative during the recovery process.

That path must not require the cooperation of the hostile or unavailable party to complete, provided the remaining constitutionally sufficient recovery authority still exists.

If quorum loss below the required threshold would make recovery impossible, that condition must be explicitly disclosed as part of the recovery model.

4.7 External data dependency

Recovery, revocation, and restoration of independent control must not depend on external data sources whose unavailability, compromise, or manipulation would block or indefinitely delay recovery.

This includes, where relevant:

oracles
price feeds
attestation services
external state proofs
third-party API responses

If an external data source is used, the architecture must preserve a bounded, non-discretionary fallback path that allows the user to recover, unwind, or otherwise regain control without waiting indefinitely for that source to return.

Section 5. Archival Offline Recovery Environments

5.1 Core requirement

Recovery must be possible from archival offline materials without dependency on operator-controlled live servers for key interpretation, address discovery semantics, or fundamental recovery logic.

5.2 What offline recovery must preserve

An archival offline recovery environment must preserve, at minimum:

recovery-critical software behavior
recovery profile semantics
key and metadata interpretation
address derivation semantics
descriptor or script interpretation, where relevant
documentation sufficient to perform recovery

5.3 Allowed online dependencies

Network access may still be required to:

fetch blockchain data
broadcast transactions
synchronize chain state

But operator-controlled live services must not be required for any step of the recovery process beyond standard blockchain data access and transaction broadcast.

A recovery path that depends on operator-controlled live services for interpretation, authorization, execution, or completion of recovery is non-compliant.

5.4 Offline recovery package

A compliant system must provide, directly or through verifiable archival means, a recovery package or equivalent recoverability set containing:

recovery documentation
recovery-critical software or source
cryptographic hashes
version identifiers
recovery profile data
metadata needed to reconstruct ownership and discovery logic

5.5 Longevity requirement

The archival recovery path must be designed for long-term viability, not merely short-term backup convenience.

5.6 No archive bait-and-switch

A system must not publish archival recovery materials and later render them useless through silent semantic drift.

Section 6. Hash-Pinned Reference Implementations

6.1 Core requirement

Recovery-critical software versions must be cryptographically identifiable and verifiable.

6.2 Hash pinning

A compliant system must publish cryptographic hashes for recovery-critical software, including where relevant:

binaries
scripts
deterministic build outputs
source references
manifests

6.3 No silent updates

Recovery-critical software must not be silently updated.

Any update affecting recovery semantics, key handling, profile interpretation, descriptor interpretation, or discovery logic must be:

visible
documented
versioned
opt-in where constitutionally required

Any change to recovery-critical software or recovery-profile semantics must result in active notification to affected users through the system's primary user-facing interface, where such an interface exists. Publication in a changelog or technical note alone is insufficient.

6.4 Known-good verification

Users must be able to verify that they are running a known-good reference implementation or a functionally equivalent implementation.

6.5 Public release record

A durable public record of recovery-critical releases must be maintained.

Recovery-critical release records must be maintained for the longer of:

the life of the system
or 10 years from the last active use of the relevant recovery profile

6.6 Reproducibility where reasonably achievable

Where reasonably achievable, recovery-critical reference implementations should support reproducible verification paths. If not, the system must document what substitute integrity guarantees exist.

Section 7. Frozen Recovery Profiles

7.1 Core requirement

A compliant system must provide a defined recovery profile or set of recovery profiles whose semantics do not silently change over time.

7.2 Meaning of a recovery profile

A recovery profile includes, where relevant:

derivation path
descriptor structure
script type
address discovery logic
profile version
key interpretation rules
required metadata

7.2A Activation timestamps and applicability record

Each recovery profile version must carry a publicly recorded activation timestamp or activation block reference.

The system must maintain a durable record of:

which recovery profile version was in force
during which time window
and, where reasonably achievable, which balances or deposits were placed under that profile

This record must be sufficient to determine which recovery semantics applied at the time a user entered the system.

7.3 Profile stability

If a user follows the recovery procedure in force at the time funds were placed under that profile, the user must remain able to recover those funds later, provided the user still possesses the required secrets and the publicly documented chain data.

7.4 No silent derivation or mapping changes

No compliant implementation may silently change:

derivation paths
descriptor interpretation
wallet mapping rules
discovery behavior
script interpretation

for existing balances.

7.5 Legacy discovery preservation

Legacy discovery must remain available for previously supported balances, either:

natively in current software
or through a fixed archival recovery path that preserves prior semantics

7.6 New profiles

New recovery profiles may be introduced prospectively, but the existence of a new profile must not make old profiles unreadable, undiscoverable, or unsupported for existing balances.

7.7 Profile export

Recovery profiles must be exportable in an open, durable, machine-readable form sufficient to support independent recovery.

Exported recovery profiles must:

use publicly documented formats
be free from IP restrictions that prevent independent parsing or implementation
be interpretable without vendor-specific tooling
contain enough information to reconstruct profile semantics independently

Section 8. Relationship to Other Standards

8.1 Constitution

This standard operationalizes:

Article XXV (Long-Term Recoverability and Compatibility Continuity)
Article XXVI (Dependence Must Remain Escapable)

8.2 UX Constitution

The user-facing implications of this standard, including warnings, recovery walkthroughs, and continuity disclosures, are governed by UX Constitution.

8.3 Definitions and Interpretive Notes

Interpretation of edge cases, terminology, and anti-gaming guidance is informed by Definitions and Interpretive Notes, but this document remains binding within its scope.

8.4 Breach and Restoration Standard

Violations of this standard may constitute breach conditions and are classified under Breach and Restoration Standard.

8.5 Operational Independence and Concentration Standard

Where delegation, custody, revocation, or recovery architecture creates operational concentration in signers, operators, jurisdictions, infrastructure, or user access paths, this standard applies together with Operational Independence Standard.

A software architecture that is formally correct but operationally concentrated may still be constitutionally weak.

Final Rule

A user who still possesses valid recovery authority must not lose control merely because:

a hot key was compromised
an operator disappeared
a service was captured
a vendor changed software
a live server stopped functioning
a delegated path failed

If the user can still prove rightful control under the constitution, the architecture must still provide a real path home.

UX Constitution
Required wallet-level and user-facing behavior for systems claiming constitutional compliance.

Binding · Draft

Section 2. Migration Prompts and Upgrade Confirmations

Supports: Governance, Mutability, and Ossification, Long-Term Recoverability and Compatibility Continuity, Successor Systems and Voluntary Migration

Rules

Users must explicitly confirm before any change that alters:

trust model
custody model
recovery model
asset class
layer context
governance exposure
bridge dependency

No silent upgrade may change the effective risk properties of a user's balances or recovery assumptions.
Upgrade prompts must explain in plain language:

what is changing
why it is changing
whether the change is optional
whether the user may stay on the prior path
whether the change alters constitutional protections

No prompt may use artificial urgency, countdown pressure, fear-based manipulation, or "last chance" framing to push users into trust-model changes.
If a proposed upgrade would move the user into a successor system, that fact must be stated directly.
If an upgrade changes the process for sending, receiving, or moving between layers, the prompt must state whether the old process remains available.

Forbidden patterns

"Continue" buttons that mask a trust-model change.
"Recommended" labels that steer users into weaker custody without equal disclosure.
Hidden automatic migration to new contract logic, bridge paths, or recovery semantics.

Section 3. Human-Readable Labels

Supports: Distinction Between Bitcoin, Claims, Utility Balances, and Credit, Clarity to Users

Rules

All asset types must be labeled clearly and consistently.
Labels must distinguish at minimum:

Bitcoin on Layer 1
direct Bitcoin claim
Bitcoin transactional balance
Bitcoin utility balance
native gas or utility token
governance token
credit instrument
speculative asset

Protocol-level naming must match user-facing naming closely enough that the user is not misled by cosmetic rebranding.
No label may blur categories by using Bitcoin-like language for non-Bitcoin instruments without explicit qualification.
If a system uses non-standard layer names, the UX must still make the constitutional trust position understandable to a normal user.
Asset classification labels must persist across all screens where balances are displayed or actions may be initiated. Labels must be visible at the point of decision, including send, receive, bridge, stake, or any commitment action.

Labels must not:

disappear after onboarding
be reduced in visibility during normal use
be replaced by ambiguous icons or branding

Asset classification is a permanent interface requirement, not an onboarding aid.

Example

A system may call something:

Settlement Rail
Utility Zone
Contract Context
Layer 1.5
Layer 4
Layer 5

But the UX must still make clear:

whether it is stronger, weaker, or simply different from the current context
whether it is base-chain Bitcoin or not
whether the user is holding money, claim, utility balance, gas token, governance token, or credit

Section 4. Recovery Walkthroughs and Test Restore Flows

Supports: Long-Term Recoverability and Compatibility Continuity, Dependence Must Remain Escapable

Rules

Self-custody systems must provide users with a way to verify that their recovery backup works without risking live funds.
Recovery procedures must be documented in plain language.
Recovery-critical metadata must be exportable in a way the user can actually understand and preserve.
No UX may imply that a seed phrase or backup is sufficient if additional hidden metadata is required to restore access.
No interface may rely on vendor lock-in as the normal or only recovery path.
If recovery assumptions change, the user must be explicitly informed before the change takes effect.

Required recovery flow properties

testable
documented
repeatable
vendor-independent to the maximum extent possible
honest about what is and is not backed up

Section 5. Anti-Dark-Pattern Rules

Supports: Honest Risk Hierarchy, Clarity to Users, Dependence Must Remain Escapable

Rules

No deceptive defaults.
No prechecked opt-ins for:

custody delegation
yield products
credit exposure
contract-based encumbrance
migration into weaker trust contexts

No visual manipulation that steers users toward riskier or more centralized options while hiding safer ones.
No burying of self-custody, plain transfer, or downward exit options.
No misleading color, icon, badge, or status system that suggests constitutional safety where it does not exist.
No "safety" language may be used merely because a product is popular, regulated, insured by a private party, or widely adopted.
No reveal control may be used to hide the fact that a user is entering credit, losing plain transferability, becoming custodial, or entering a weaker trust context.
Communications, including push notifications, emails, SMS messages, and in-app alerts, must adhere to the same anti-dark-pattern rules as the interface itself.

Such communications must not:

use artificial urgency to pressure user action
create fear-based decision-making
steer users toward weaker trust models
obscure the true nature of an action or change

Any communication prompting a user to:

move funds
change custody
accept an upgrade
enter a new context

must include clear disclosure of:

the trust change involved
the asset class implications
whether the action weakens user control or exit rights

Section 6. Context, Layer Position, and Relative Trust

Supports: Functional Layer Order, Honest Risk Hierarchy, Clarity to Users

Rules

The user must always be able to see their current operational context.
The current context display must tell the user, at minimum:

what system or sub-system they are in
which constitutional layer or equivalent trust zone they are in
what asset class they currently hold
whether the current context is stronger, weaker, or simply different from the one below it

If a system uses more than three layers, sublayers, internal trust domains, or hybrid layer names, the UX must still present the current position clearly.
Developer naming is flexible. User-facing clarity is not.
Shared address formats, account metaphors, or reused wallet visuals must not be relied on as the sole indicator of where the user is.

Special rule for same-address or same-identifier designs

If the same address format, account string, or receiving identifier is reused across multiple trust contexts, the UX must provide an explicit context marker strong enough that a normal user cannot reasonably confuse:

base-chain Bitcoin
claim balances
utility balances
custodial balances
contract-governed balances

Section 7. Cross-Layer and Cross-Context Confirmation

Supports: Exit as a Right, Interlayer Coupling and Movement, Plain Transferability and Voluntary Encumbrance

Rules

Any action that changes:

layer
trust model
custody model
asset class
compliance context
contract status

must require explicit confirmation.

The confirmation must state in plain language:

what the user is moving out of
what they are moving into
what protections are lost, gained, or changed
whether the move is reversible
whether the move depends on a bridge, contract, or operator

No cross-context move may be hidden inside a generic send, deposit, bridge, stake, continue, or next flow.

Required special confirmation cases

Moving from Layer 1 Bitcoin into any claim-based or bridged context.
Moving from a transactional balance into a utility balance.
Moving from plain transferability into contract-governed state.
Moving from self-custody into assisted, delegated, or custodial control.
Entering a non-compliant, partially compliant, or out-of-scope component.

Section 8. How Risk Is Shown on Screen

Supports: Honest Risk Hierarchy, Clarity to Users, Scope and Compliance

Rules

The screen must always make visible:

current operational context
current asset class
custody status
compliance context, where relevant

Trust assumptions of the current context must be accessible directly from the primary balance or action screen without navigating away from that screen or entering secondary menus such as settings, profile, or configuration pages. Access must be clearly labeled and discoverable without requiring search, guesswork, or prior knowledge of the interface.
The UX must not blur:

self-custodial versus custodial state
compliant versus non-compliant context
plain transfer versus contract-governed state
money versus credit

If a user is about to take an action that weakens their current trust position, that weakening must be visible before commitment.
UX requirements must be satisfied across all device classes, including mobile, desktop, web, and embedded environments.

Where screen size or interface constraints limit simultaneous visibility, the following must remain persistently visible on the primary action screen:

asset classification (money, claim, utility, credit)
custody status (self-custodial, delegated, custodial)
compliance context where relevant

Supporting detail may use progressive disclosure, provided that:

first-level classification is always visible
no core classification is hidden behind reveal controls
reduced space is not used to omit or obscure constitutional disclosures

Revealable detail rule

A compliant UX may use layered disclosure, including reveal controls, to present deeper implementation detail without overwhelming the user. However, the following must be visible without requiring reveal:

asset classification
current trust position
custody status
compliance context
movement into credit
movement into a weaker trust layer
movement into custodial or delegated control
movement into contract-governed state

Reveal mechanisms may deepen understanding but must not be required to determine the nature of the asset, trust model, custody state, or compliance context.

Core classifications must be represented by persistent visible text or clearly understandable symbols on the primary action screen. These classifications must not rely solely on:

tap interactions
hover states
hidden panels
expandable sections

Reveal controls are permitted only for additional detail, not for core classification.

Minimum trust-assumption disclosure

At minimum, the user must be able to find:

whether exit is permissionless or conditional
whether reserves are direct, claimed, or absent
whether a bridge or operator is involved
whether governance or committee control exists
whether the current balance is money, claim, utility balance, gas token, governance token, or credit

Section 9. Compliance Context Disclosure

Supports: Scope, Extensions, Compliance, Naming, and Voluntary Applicability

Rules

The interface must clearly disclose whether the current context is:

compliant
partially compliant
non-compliant
out of constitutional scope

A user must not be left assuming constitutional protection merely because the interface is inside a broader ecosystem that uses constitutional branding.
If a user is routed into a non-compliant, partially compliant, or less-proven context, that boundary must be disclosed before commitment.
Compliance status must not be hidden in documentation while the UI implies stronger protection.

Examples

Allowed:

"You are entering a non-compliant bridge path. Exit rights and proof standards may differ."

Forbidden:

using the same visual trust signals for compliant and non-compliant components with only tiny footnote differences

Section 10. Self-Custody Must Not Be Visually Discouraged

Supports: Dependence Must Remain Escapable, Long-Term Recoverability and Compatibility Continuity

Rules

Where self-custody is available, it must be at least as visually accessible as custodial or delegated alternatives.
No interface may use asymmetrical warning language to portray self-custody as uniquely dangerous while presenting reliance on third parties as normal or safer by default.
No compliant UX may default users into custodial or delegated arrangements when a self-custodial path is available and practical.
No compliant UX may portray self-custody as merely "advanced" while portraying dependence on third parties as neutral baseline reality.
If a custodial or delegated path is offered, the UX must also explain the path back out.

Important note

This section does not require every user to choose self-custody.

It requires the system not to stack the deck against it.

Section 11. Compliant Plus Designation

Type within this document: Optional higher UX designation

Purpose: To recognize systems that not only remain honest, but also preserve long-term workflow continuity for routine money actions.

Principle

A Compliant Plus system does not force users to relearn core money actions unnecessarily. It preserves confidence, habit, and operational continuity across upgrades.

Qualifying rules

Routine money tasks must remain operationally stable across upgrades wherever reasonably possible.
Users must not be forced onto a new workflow for:

sending Bitcoin
receiving Bitcoin
moving up or down layers
checking custody state
confirming what asset they hold

if the old workflow can still be preserved safely.

A system may introduce new workflows, new screens, new features, or safer processes, but must not force users to abandon prior core money paths without a safe continuity path.
The old process or a functionally equivalent compatibility path must remain available long enough for users to continue accessing their money without panic, retraining shock, or operational paralysis.
If an old process is genuinely unsafe and cannot remain, the system must preserve the old mental model as closely as possible through:

compatibility mode
legacy mode
guided safe bridge
functionally equivalent path

No upgrade may strand a user by radically changing the location, naming, or sequence of core money actions without a safe continuity path.
A system that repeatedly redesigns core money workflows for style, novelty, or product preference rather than necessity should not qualify for Compliant Plus.

Evaluation and accountability

Compliant Plus status is not self-authoritative. Any system claiming Compliant Plus status is subject to the same evaluation, disclosure, and breach classification processes as base constitutional compliance.

Claims of Compliant Plus status must be:

publicly stated
supported by evidence of meeting the criteria defined in this section
subject to independent evaluation by users, auditors, or other evaluators

Misrepresentation of Compliant Plus status constitutes a form of compliance misrepresentation under the constitution.

Safety exception

If an old workflow is genuinely unsafe, Compliant Plus does not require preserving the dangerous behavior itself. It requires preserving the user's confidence path to the money as closely as safely possible.

Practical examples

Allowed for Compliant Plus:

adding a new send flow while keeping the old send flow available
introducing a safer cross-layer confirmation while preserving the old action location and logic
providing legacy mode for users trained on an earlier interface

Not allowed for Compliant Plus:

moving send, receive, or exit into new locations with no legacy path
requiring a new app for a routine action that users previously performed in the existing app
repeatedly renaming basic actions in ways that force retraining

Re-evaluation and erosion

Compliant Plus status requires periodic reaffirmation following major UX changes.

A system must be re-evaluated for Compliant Plus status:

after any significant interface or workflow change affecting core monetary actions
at reasonable periodic intervals if continuous changes occur

Incremental changes that individually appear minor but collectively degrade workflow continuity must be evaluated in aggregate.

A system may lose Compliant Plus status if cumulative changes materially violate the continuity principles defined in this section, even if no single change independently constitutes a breach.

Section 12. Third-Party Interfaces

Third-party wallets, interfaces, and applications interacting with a compliant system must adhere to this UX Constitution when presenting or operating on constitutional functions.

A system must not:

rely on third-party UX behavior to obscure or misrepresent constitutional properties
outsource user-facing truth obligations to external interfaces

If third-party interfaces misrepresent constitutional properties:

the system must not endorse, default to, or silently route users through such interfaces
continued reliance on such interfaces may constitute a breach under Breach and Restoration Standard

Section 13. Accessibility

All required disclosures, warnings, classifications, and confirmations must be accessible to ordinary users, including those with visual, cognitive, or language limitations.

Critical risk information must:

not rely solely on color, icons, or small text
be readable in plain language
be accessible via screen readers and assistive technologies where applicable

Accessibility limitations must not be used as justification to omit required constitutional disclosures.

Section 14. Relationship to the Protocol Constitution

Rules

This document is binding on all user-facing behavior of systems claiming compliance.
No UX behavior may weaken, blur, or contradict protocol-level protections.
A system that materially misrepresents asset class, trust model, custody state, exit conditions, or compliance context through its user interface may be classified as in breach under Breach and Restoration Standard, regardless of underlying protocol correctness.
If a conflict appears to exist between what is technically true and what the user is led to believe, the stronger requirement is:

truth in the protocol
honesty in the UX

Where this document is silent, interpretation should default toward:

clearer disclosure
stronger user understanding
easier self-custody
easier downward exit
less chance of mistaking weaker layers for stronger ones

Final UX Principle

A compliant system must make it easy for a normal user to answer four questions at all times:

Where am I?
What do I hold?
Who or what do I depend on right now?
What changes if I move from here?

If the user cannot answer those questions quickly and honestly from the interface itself, the UX is not constitutionally sound.