Original CryptoSignalsReview dataset research
Crypto Signal Provider Name Collision Report 2026
A repeated display name is a queue for entity resolution, not proof that records describe one operator. This report measures exact and normalized collisions while keeping that boundary explicit.
Review the collision findingsNo signup, payment, wallet connection, or credentials are required.
124 records share an exact display name.
172 records collide after conservative text normalization.
Maximum records sharing one normalized name.
Direct answer
The frozen inventory contains 57 exact-name collision groups covering 124 records, or 3.9% of the inventory. The versioned Unicode comparison key produces 77 groups covering 172 records, or 5.4%. 2 records contain no letter or number after normalization and remain unkeyable rather than being grouped together. A repeated name is not proof of a duplicate record, common ownership, impersonation, misconduct, or even the same service. It means the display name cannot serve as the identity key by itself.
Exact names and normalized names answer different questions
| Measure | Exact display name | Unicode-normalized name | Interpretation |
|---|---|---|---|
| Unique names | 3,133 | 3,103 | The normalized method merges cosmetic variants, so it is deliberately more sensitive. |
| Collision groups | 57 | 77 | Groups with at least two provider slugs. |
| Records in groups | 124 | 172 | Records requiring another identity key before consolidation. |
| Excess records | 67 | 95 | Records beyond the first record in each collision group; not a duplicate count. |
| Largest group | 6 | 6 | Maximum group size in this snapshot. |
Exact matching preserves every visible character after trimming outer whitespace. Comparison version nfkd-mark-lower-separator-v2 applies Unicode NFKD decomposition, removes combining marks, lowercases without choosing a national locale, and folds non-letter and non-number runs into separators. It is not full Unicode case-folding, homoglyph or confusable detection, transliteration, fuzzy spelling, or semantic similarity. Original names remain the evidence; the key exists only to find records that need another join field.
Collision group sizes
| Records sharing a name | Exact groups | Normalized groups | Review implication |
|---|---|---|---|
| 2 | 51 | 67 | Pairwise ambiguity; compare route, source, operator, and capture date. |
| 3 | 4 | 4 | Multi-record ambiguity; build an evidence graph before deciding whether records should merge. |
| 4 | 1 | 5 | Multi-record ambiguity; build an evidence graph before deciding whether records should merge. |
| 6 | 1 | 1 | Multi-record ambiguity; build an evidence graph before deciding whether records should merge. |
Most collisions are pairs: 51 of the exact groups and 67 of the normalized groups. The largest normalized group contains 6 records. CSR publishes these aggregates instead of listing ambiguous names as allegations. Provider-level resolution belongs in a sourced evidence file where corrections and changing routes can be recorded.
What changed after separator folding
| Sensitivity measure | Groups or records | Meaning |
|---|---|---|
| Cross-spelling normalized groups | 27 | Groups that contain more than one exact stored display string. |
| Records in cross-spelling groups | 64 | 2% of the inventory; these are the records added to a broader comparison queue. |
| Normalized groups with one exact spelling | 50 | The exact spelling already repeated; normalization did not create the ambiguity. |
| Unkeyable records | 2 | No letters or numbers remain, so the records are kept out of collision groups. |
27 of the 77 normalized groups contain multiple exact strings, covering 64 records. That is the measurable sensitivity added by case, mark, and separator folding. It is not evidence that the spellings are interchangeable in branding, law, language, or operator identity.
Source context does not settle identity
| Context | Exact groups | Normalized groups | What it can show |
|---|---|---|---|
| One source family | 44 | 56 | The records entered through the same kind of catalog or seed workflow. |
| Multiple source families | 13 | 21 | The label appeared across different discovery methods; independence still must be checked. |
| One source URL | 44 | 56 | Records may share a category page, so repetition can originate in one list. |
| Multiple source URLs | 13 | 21 | More than one source route exists, but those routes may copy each other. |
Among exact collision groups, 44 share one source URL and 13 span multiple source URLs. A shared category route can explain a repeated label without proving duplication. Multiple directories can also repeat the same underlying listing, so source count must not be promoted into independent corroboration without tracing provenance.
Direct-route context narrows only part of the queue
| Route context within exact collision group | Groups | What remains unresolved |
|---|---|---|
| No direct route captured | 40 | Name and discovery source are insufficient to compare destinations. |
| One route for every record | 2 | The shared route is a strong join clue, but ownership and service continuity still need proof. |
| One route with missing records | 9 | Some records can be linked to a route; blank routes must not be silently imputed. |
| Multiple direct routes | 6 | The group may contain separate operators, tiers, migrated handles, resellers, or stale records. |
40 of the 57 exact-name groups have no direct route stored. Only 2 groups have one normalized route populated across every record. The collision queue therefore cannot be solved by a bulk name merge.
Why the name page stops at a queue
This report deliberately does not choose a canonical record or publish a bulk merge list. A name key lacks route ownership, operator identity, product tier, source independence, and continuity over time. The separate entity-resolution checklist defines the record-level evidence needed to move from a collision group to a dated resolution status. Keeping that workflow separate preserves this page’s job: quantify name-key sensitivity and expose its limits.
What the collision count can and cannot support
The count supports a narrow factual claim: display-name uniqueness is weaker than slug uniqueness in this inventory, and 172 records need additional keys after conservative normalization. It cannot identify the current owner of a route, prove that one provider copied another, establish which record came first, or determine whether a similarly named service is legitimate. Those conclusions require provider-level evidence beyond this aggregate dataset.
140 records in normalized collision groups remain listed for review and 32 are quarantined. Workflow status does not resolve the collision; it only describes how CSR currently frames the record.
Dataset boundary
This is a census of records in the CryptoSignalsReview candidate inventory at snapshot 2026-07-05, not a representative survey of every crypto signal provider or every messaging channel. Directory inclusion is discovery evidence only. Missing fields stay missing, platform labels can overlap, and no count proves provider quality, legality, profitability, or safety.
Frozen source: 5dcd30b2b1a0da9bacbaeec08244190dae19a49f. Unit: one unique CSR provider slug. Position: coverage is not endorsement.
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.
- 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 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 Entity Resolution Checklist
A practical beginner and advanced workflow for resolving provider names, aliases, routes, operators, payments, and continuity without unsupported merges.
- Crypto Signal Provider Transparency Report 2026
Original analysis of 3,200 crypto signal provider candidate records: platform concentration, verification gaps, quarantine rates, 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.