METHODOLOGY
Facts first.
Edges second.
CCLR is a historical registry of crypto card programs and the infrastructure beneath them. It records reviewed lifecycle facts, not rankings, recommendations, or inferred safety scores.
What belongs here
CCLR covers consumer crypto card programs, infrastructure providers used by those programs, custody/collateral/settlement infrastructure when material, provider-program relationships, material lifecycle or incident events, and the evidence supporting those claims.
Merchant acceptance directories, generic exchange or wallet records, rewards/APY rankings, and ordinary merchant-side card acceptance are out of scope by default.
Canonical model
The public graph is derived from these five reviewed canonical layers. A provider can carry multiple evidenced operational roles; the registry does not force roles that the evidence does not support.
Relations are time-bounded and evidence-linked. Events describe material lifecycle changes or incidents. Evidence records state the source, publisher, reliability and claim scope behind those claims.
Incident boundary
A provider-side incident does not automatically make every connected card program affected.
Provider-wide facts and program-specific impact are modeled separately. A program is shown as affected or confirmed unaffected only when its own canonical event and evidence support that state. Silence is not converted into an unaffected claim.
What the graph means
Every visible edge is a canonical relation. The interface may arrange records spatially or show chronological arrows for navigation, but layout and chronology do not create new factual relationships or technical causation.
Confidence and source reliability describe evidentiary support. They are not safety ratings.
Corrections
CCLR is intended to be correctable. If a record, relationship, event, or evidence claim is wrong or incomplete, use the public correction path rather than treating the current display as immutable.