Public Record

Compliance Registry

The compliance registry is a permanent, public record of systems evaluated against the Bitcoin System Constitution. Every system receives one of seven badge classes based on verifiable evidence, published standards, and documented reasoning. No badge is granted by reputation, popularity, or politics.

How the Registry Works

Compliance is voluntary in applicability and strict in claim. A system enters the registry only after it publicly adopts the constitution or requests recognition under it. Registration does not create compliance by itself; it creates a public record that can be examined against the constitutional text and companion standards.

Every registered system is assigned exactly one badge class at any given time. Badge assignments are backed by a formal compliance decision record that documents the evidence, reasoning, and standards applied. All records are permanent — they can be updated with new decisions, but prior records are never deleted.

Core principle: The registry exists so that anyone — user, developer, auditor, or competitor — can independently verify whether a system's compliance claim is justified. No standing is required to inspect or challenge any record.

Badge Classes

Every system in the registry carries exactly one of the following seven badges. Badge assignment is based on verifiable evidence evaluated against the constitution and its binding companion standards.

Badge	Meaning
Compliant	System meets all constitutional requirements and binding standards. No unresolved breaches. No active disputes on material articles.
Provisional	System is in a disclosed transitional state (e.g., provisional custody). May not claim full compliance. Must disclose timeline and milestones.
Partial	System meets some but not all constitutional requirements. Must disclose which articles are satisfied and which are not.
Historically Breached	System has restored compliance but has a recorded breach history. Breach record is permanent.
Disputed	System's compliance status is subject to an active, unresolved dispute. Must disclose dispute details.
Non-Compliant	System fails to meet one or more constitutional requirements. Must disclose which articles are violated.
Out of Scope	System does not claim constitutional compliance and is not evaluated against this constitution.

Compliance Decision Records What every badge decision must include

Every badge assignment or change must be backed by a formal compliance decision record. These records ensure that no badge is granted, revoked, or changed without a documented, verifiable basis.

Required Elements

Every compliance decision record must include all ten of the following:

System identification — The name, version, and unique identifier of the system being evaluated.
Badge assigned — The specific badge class assigned as a result of this decision.
Date — The date the decision was issued.
Articles reviewed — The specific constitutional articles evaluated in this decision.
Evidence used — The evidence examined, including proof-of-reserves attestations, audit reports, public disclosures, on-chain data, or operational documentation.
Standards applied — The specific companion standards, checklists, or verification criteria applied during evaluation.
Disputes — Any active or resolved disputes relevant to the system at the time of evaluation.
Limitations — Any limitations, caveats, or scope restrictions that affect the decision.
Evaluator identification — The individual, organization, or process responsible for the evaluation.
Decision rationale — A plain-language explanation of why the badge was assigned, including which requirements were met, which were not, and what evidence was decisive.

Permanence rule: Compliance decision records are permanent. They may be updated with new decisions, supplemented with additional evidence, or superseded by later evaluations — but they are never deleted. The full history of every system's compliance record remains publicly accessible.

Standards Basis What badge decisions can and cannot be based on

Badge assignments must be grounded in published, verifiable criteria. This section defines what constitutes a valid basis for a compliance decision — and what does not.

Permitted Bases

Badge decisions may be based on:

The constitution itself — The full text of the Bitcoin System Constitution, including all articles and definitions.
Binding companion standards — Published companion standards that have been formally adopted as binding under the constitutional framework.
Published verification checklists — Checklists and evaluation criteria that are publicly documented and available for independent review.
Public dispute resolution records — Outcomes of formally filed disputes that have been resolved through the documented process.

Prohibited Bases

Badge decisions must never be based on:

Subjective impressions — Personal opinions, gut feelings, or informal assessments that are not documented or verifiable.
Favoritism — Preferential treatment based on relationships, affiliations, or commercial interests.
Popularity — Market share, user count, social media following, or public sentiment.
Politics — Political alignment, ideological agreement, or community faction loyalty.
Unpublished criteria — Standards, thresholds, or requirements that have not been publicly documented before being applied.
Ad hoc standards — Requirements invented after the fact or applied inconsistently across systems.

Transparency requirement: If a badge decision cannot cite a specific, published standard for every element of its reasoning, the decision is deficient and subject to challenge.

Dispute Process How badge assignments can be challenged

Any badge assignment can be formally disputed. The dispute process exists to ensure that compliance decisions remain accountable, correctable, and transparent.

Standing

Anyone can file a dispute. No standing is required — you do not need to be a user of the system, a holder of any token, or a participant in any governance process. The dispute stands or falls on its evidence, not on who filed it.

Filing Requirements

A valid dispute must include all of the following:

System identified — The specific system whose badge is being contested.
Badge contested — The current badge assignment that the dispute challenges.
Basis — The constitutional articles, companion standards, or decision record elements that the dispute is grounded in.
Evidence — Specific, verifiable evidence supporting the dispute claim.
Requested outcome — The badge change or corrective action the filer believes is warranted.

Response Timeline

Once a dispute is filed, a response is required within 14 days. The response must address the specific evidence and reasoning presented in the dispute. Failure to respond within the timeline is itself a matter of public record.

Permanence

All disputes — filed, pending, resolved, or withdrawn — are permanently accessible in the public record. Dispute history is never deleted, even after resolution. This ensures that patterns of repeated challenges, systemic issues, or governance failures remain visible.

Governance Transition From governance-led to standards-driven evaluation

The compliance registry is designed to transition from an initial governance-led phase to a fully standards-driven evaluation process.

Phase 1: Governance-Led

In Phase 1, badge assignments and compliance decisions are managed by the founding governance process. This phase exists because the companion standards, verification checklists, and dispute resolution mechanisms are still being published and refined. During this phase:

Badge decisions are made by identified evaluators operating under published criteria.
The governance process is responsible for publishing and maintaining the standards that badge decisions are based on.
All decisions remain subject to the same transparency, documentation, and dispute requirements as in Phase 2.

Phase 2: Standards-Driven

In Phase 2, badge assignments are determined entirely by published, independently verifiable standards. The role of governance is reduced to maintaining the standards themselves — not to making individual compliance decisions. During this phase:

Any qualified evaluator can issue a compliance decision record using the published standards.
Badge assignments are reproducible — different evaluators applying the same standards to the same evidence should reach the same conclusion.
Governance maintains the standards but does not control access to the evaluation process.

Anti-Capture Safeguard

12-month disclosure rule: If governance fails to publish a transition timeline from Phase 1 to Phase 2 within 12 months of the registry's first badge assignment, that failure is itself disclosed in the registry as a governance deficiency. This safeguard exists to prevent indefinite governance control over the compliance process.

How to Request Recognition

Publish a clear claim of applicability, identify the system and relevant layers, provide supporting documentation for reserves, liabilities, custody, governance, exit paths, and security assumptions, and submit the request for public review. Ambiguous marketing language is not enough.

A valid recognition request should include:

The system name, version, and unique identifier.
The constitutional layers claimed (Layer 1, Layer 2, Layer 3, or cross-layer).
Supporting evidence for each applicable article — proof-of-reserves, audit reports, custody documentation, governance disclosures, exit mechanism specifications.
Disclosure of any known limitations, provisional states, or areas of non-compliance.
A public point of contact for follow-up evaluation and dispute response.

Submit recognition requests through the GitHub repository for public review.

System Name	Layer(s)	Badge	Submission Date	Review Status	Details
No systems have registered yet.

Coming Soon

The registry structure and badge system are in place, but no public submissions have been recorded yet. When systems begin requesting recognition, this page will display the full review pipeline, badge assignments, decision records, and permanent compliance history.