Skip to main content

Compliance Flow

This page describes the end-to-end compliance enforcement flow within the CRYMBO Oracle — from transaction initiation to attestation publication.

Overview​

CRYMBO enforces compliance before execution, not after. Every transaction that triggers a compliance rule passes through the Oracle before it can settle on-chain. This is fundamentally different from post-trade analytics or surveillance tools.

The Flow​

Step 1: Transaction Initiation​

A user or system initiates a transaction through a registered wallet. The transaction is detected by the CRYMBO Oracle (via on-chain monitoring or API call).

Step 2: Rule Matching​

The Oracle determines which compliance rules apply based on:

  • Transaction amount (KYC/AML thresholds)
  • Sender and receiver jurisdictions
  • Asset type (regulated securities, stablecoins, etc.)
  • Transaction type (transfer, swap, issuance, redemption)
  • Applicable regulations (Travel Rule, MiCA, local requirements)

Step 3: Identity Request​

If identity exchange is required, the Oracle generates an encrypted request to the originating institution. The request specifies which fields are needed based on the applicable regulation.

Step 4: Validator Verification​

Staked validators receive the verification task:

  • Perform encrypted compliance checks
  • Verify identity data against regulatory requirements
  • Confirm counterparty status (sanctioned, verified, unknown)
  • Sign their validation result

Step 5: Consensus & Attestation​

The Oracle aggregates validator responses. If consensus is reached:

  • A cryptographic attestation is published on-chain
  • The attestation confirms compliance status (COMPLIANT / NON_COMPLIANT)
  • Smart contracts can read the attestation and proceed or halt

Step 6: Execution or Halt​

Based on the attestation:

  • COMPLIANT — Transaction proceeds. Fees distributed to validators and Treasury.
  • NON_COMPLIANT — Transaction is flagged. Depending on configuration: halted, delayed, or reported.
  • PENDING — Awaiting counterparty response. Transaction held until resolution or timeout.

Step 7: Logging & Audit Trail​

Every compliance event is logged:

  • Attestation ID and on-chain reference
  • Rule(s) that were evaluated
  • Timestamp and participants
  • Validator consensus details

All logs are accessible via the CRYMBO Platform and API for audit and reporting purposes.

Key Principles​

  • Pre-execution — Compliance is enforced before value moves, not monitored after
  • Deterministic — Binary compliant/non-compliant outcomes, not probabilistic scores
  • Privacy-preserving — Only attestations are on-chain; PII stays encrypted and off-chain
  • Auditable — Every decision has a verifiable trail accessible to authorized parties