Crypto Signal Provider Entity Resolution Checklist

Why this check comes before performance review

A result sheet is meaningful only when the reviewer knows which service produced the alerts, which route followers used, which product or tier was sold, and whether the archive belongs to the same operator and time period. The frozen inventory contains 77 normalized-name collision groups, 13 shared-alias groups, and 10 canonical shared-route groups. None establishes wrongdoing or common control. Together they show why identity is a separate evidence gate rather than a footnote under performance.

If similarly named records are merged too early, evidence may be assigned to the wrong service. If one evolving service is split without a continuity record, results can be separated across names or dates. The checklist avoids both errors by requiring explicit, dated joins.

Beginner five-minute identity check

A pass signal permits deeper review; it does not establish provider quality, profitability, regulatory status, or safety. Use the separate provider due-diligence checklist for performance, fees, permissions, payment safety, and trading-risk review.

Advanced seven-lane evidence graph

1. Record node: CSR slug, exact display name, source family, source URL, and capture date.
2. Name node: original script, punctuation, normalization version and key, translation notes, and generic terms.
3. Alias node: each alternate label with its own source, first-seen date, last-seen date, and relationship claimed.
4. Route node: original URL, comparison profile, endpoint, object type, public or private state, and archive evidence.
5. Source node: upstream origin, whether another source copied it, and the basis for treating sources as independent.
6. Identity node: operator, company or project claim, support identity, payment recipient, product tier, affiliate, or reseller relationship.
7. Timeline node: renames, migrations, admin changes, route changes, product changes, and corrections.

Join nodes with bounded statements such as “this archived site linked this public handle on this date.” Avoid timeless claims when the source covers one period. Record conflicts and missing fields as edges too; disagreement is an evidence output, not a reason to force a merge.

Decision matrix

The matrix is deliberately asymmetric: agreement creates a review candidate, while disagreement identifies the next question. No row converts metadata into endorsement or a misconduct finding.

Evidence request template

Provider record or CSR slug:
Exact displayed name and original script:
Aliases and source for each:
Independent public route:
Route object type:
Operator or entity claimed:
Support identity:
Product or tier:
Payment recipient as an identity join:
First-seen and last-seen dates:
Rename, migration, or ownership-change evidence:
Conflicting routes or claims:
Fields still missing:
Merge, retain separately, or revisit:
Reviewer and review date:

Redact personal contact, payment, credential, and account data before publishing. Keep an internal evidence reference that allows a correction without exposing private information.

Six stopping rules

1. Do not merge because names look similar after fuzzy matching.
2. Do not merge because two directories repeat the same claim; trace whether they are independent.
3. Do not treat a route as official when it was reached only through the payment request.
4. Do not bridge a historical and current route without dated continuity evidence.
5. Do not let subscriber count, testimonials, disclaimers, or page position resolve identity.
6. Do not delete an ambiguous record merely to improve a uniqueness metric; retain it with the missing proof visible or place it in an explicitly historical internal quality workflow.

Resolution outputs

Paid profile or production work may help a provider supply a clearer evidence packet, but it cannot buy a merge decision, verified status, ranking position, removal of a valid risk note, or a favorable conclusion.

Official context sources

These sources explain why identity, disclosure, complete performance evidence, and resistance to urgency matter. They do not validate any record in the CSR dataset.

• FCA: cryptoasset firms marketing to UK consumers

  Current social-media promotion, risk-warning, and fair-clear-not-misleading context.

• ESMA: finfluencer factsheet

  Transparency, accuracy, paid-promotion disclosure, and recommendation boundaries.

• Investor.gov: social media and investment fraud

  Identity verification, impersonation, testimonials, urgency, and social-media limitations.

Continue the transparency research

• Crypto Signal Provider Name Collision Report 2026

  First-party analysis of repeated provider names across 3,200 records, with exact and Unicode-normalized counts, source context, and identity limits.

• Crypto Signal Provider Alias Coverage and Entity Resolution

  Audit alias-field coverage across 3,200 provider records, including importer patterns, shared values, source-family gaps, and display-name matches.

• Crypto Signal Provider Route Reuse and Dedupe Gap Analysis

  Analyze exact and canonical route reuse plus explicit dedupe-key field coverage across 3,200 provider records, with source and method sensitivity.

• Crypto Signal Provider Transparency Report 2026

  Original analysis of 3,200 crypto signal provider candidate records: platform concentration, binary verification, historical workflow, sources, and missing evidence.

• Why 98.4% of the Provider Dataset Is Telegram-Labeled

  Analyze why 3,150 of 3,200 CryptoSignalsReview candidate records mention Telegram, what that concentration means, and what it cannot prove.