Skip to main content

Compliance

This page defines the CLUE compliance perimeter in whitepaper terms for protocol contributors, interface teams, and regional operators.

CLUE uses a protocol-first legal framing: the core protocol is on-chain infrastructure, while many jurisdiction-specific obligations arise at the service/operator layer.

The intent is to provide a common compliance vocabulary across engineering, legal, and operations teams. When all parties use the same boundary model, decisions become faster, clearer, and less error-prone during audits, launches, and incident scenarios.

Regulatory principles​

CLUE’s compliance framing begins with a protocol-first principle: the core system is documented as deterministic on-chain infrastructure rather than a centralized discretionary service. This distinction is essential for legal analysis, because many regulatory classifications depend on how control, custody, and policy enforcement are actually implemented.

In the normal governance path, material changes are expected to be routed through DAO procedures, not hidden unilateral admin shortcuts. This creates procedural transparency that improves both technical and legal defensibility.

At the same time, CLUE does not assume that protocol-level design automatically resolves service-level legal obligations. Interface and operator entities can trigger additional duties in specific jurisdictions, including onboarding controls, eligibility restrictions, and disclosure requirements. Legal qualification therefore depends on local law, regulator interpretation, and factual operating model.

Transparency is treated as a compliance enabler across all layers: on-chain events, governance execution history, and deterministic state transitions make audits and legal review materially more reliable.

This transparency does not eliminate legal obligations, but it improves how those obligations can be evidenced and reviewed. In regulated environments, evidence quality is often as important as policy intent.

To reduce ambiguity, CLUE separates three questions that are often incorrectly merged in Web3 discussions. First, what the protocol contracts do as code-level mechanics. Second, who delivers access as a service and under what legal basis. Third, which policy controls an operator applies for its own jurisdictional obligations.

This boundary helps avoid a common mistake: assuming that because protocol contracts are globally accessible, every interface distribution model is automatically compliant everywhere.

For multi-region products, this distinction is critical. Teams may share one protocol backend while maintaining jurisdiction-specific controls, disclosures, and access policies at the operator layer.

KYC/AML and sanctions perimeter​

CLUE documentation treats KYC/AML/sanctions controls as context-dependent service controls, not as automatic protocol-layer assumptions.

At the protocol layer, contract logic does not imply a universal centralized onboarding gate by default. At the operator layer, local regulatory requirements may require risk-based controls such as customer due diligence, sanctions checks, restrictions for prohibited jurisdictions, recordkeeping, and reporting workflows.

For integrators, the implication is straightforward: frontend and API operators should publish and maintain a clear compliance policy stack, including eligibility rules, control scope, and escalation channels.

Clear user-facing policy language reduces legal ambiguity and support friction. It also helps align user expectations with actual service constraints in each market.

Compliance obligations are legal-jurisdiction specific. Always validate implementation with qualified local counsel.

CLUE applies a layered responsibility model:

The protocol layer defines execution and settlement mechanics through code and on-chain state transitions. The interface layer delivers user access through UI and infrastructure services and may vary significantly by provider. The operator layer carries legal-entity obligations in specific jurisdictions, including policy enforcement and service-level compliance controls. The governance layer handles protocol-level parameter updates through auditable DAO procedures with execution timing constraints.

These layers should be treated as complementary rather than interchangeable. Legal and operational ownership should be mapped explicitly to the layer where real control is exercised.

Where ownership is shared across multiple entities, responsibilities should be documented in an explicit control matrix. This avoids overlap gaps and improves incident accountability.

Why this split matters​

This split clarifies liability boundaries, improves incident communication with users and stakeholders, and strengthens integration architecture by making legal assumptions explicit instead of implicit. It also reduces the risk of policy drift between technical design and real-world service operation.

Over time, explicit layer separation also improves governance quality, because protocol proposals can be evaluated with clearer understanding of downstream operator and compliance impact.

Compliance operations baseline​

For production services built on CLUE, operators should maintain a structured baseline with documented controls.

  • Jurisdictional eligibility matrix

    • Defines where services are available and under which restrictions.

  • Public legal disclosures and service terms

    • Aligns user communication with the operator’s control model and restrictions.

  • KYC/AML/sanctions controls (where required)

    • Establishes onboarding, screening, and escalation workflows.

  • Monitoring and escalation procedures

    • Sets incident ownership, communication paths, and response timelines.

  • Governance-watch process

    • Tracks protocol updates that may affect service obligations.

The baseline should be versioned and periodically reviewed. Version control is essential for accountability: teams need to show which policy was active, why it changed, and which governance or regulatory trigger initiated the update.

Change management and periodic review​

Regulatory conditions evolve, and so should compliance posture. Review cycles should account for new legal guidance in target markets, governance-level protocol changes, new integrations that alter risk profile, and incident-driven operational learning.

A periodic review model is especially important in fast-moving Web3 environments where legal expectations and technical design can change on different timelines.

A common cadence is quarterly baseline review plus ad-hoc review triggered by major governance upgrades, new market entries, or material incident findings.

Jurisdiction and change notice​

Requirements can change over time. Compliance posture should be reviewed periodically and validated with qualified counsel for target jurisdictions.

Teams should treat this notice as an active operating requirement, not as a passive disclaimer. Compliance readiness is sustained by routine maintenance, documentation quality, and timely cross-functional coordination.

See also​