Original CryptoSignalsReview dataset research
Crypto Signal Provider Alias Coverage and Entity Resolution
The stored alias field is mainly an importer and retrieval feature. This report separates copied handles from additional values before any alias is treated as evidence of a relationship.
Inspect the alias evidenceNo signup, payment, wallet connection, or credentials are required.
41.3% of the inventory.
1,502 unique after normalization.
Records with at least one additional normalized value.
Direct answer
1,322 of 3,200 provider records contain at least one stored alias, but 1,241 of the 1,522 entries are equivalent to the record’s stored handle after comparison normalization. 1,152 records contain nothing beyond their name or handle, leaving only 170 records with another normalized value. This is alias-field coverage, not a count of evidenced rebrands. A stored alias can improve retrieval, but it does not by itself prove common ownership, authorization, continuity, or affiliation.
Alias coverage is source-dependent
| Discovery source family | Records | Records with aliases | Alias entries | Coverage implication |
|---|---|---|---|---|
| RealTelegram channel category | 1,870 | 0 | 0 | This source contributes no stored aliases; absence cannot be read as no alternate name exists. |
| TGStat crypto group rating | 598 | 598 | 598 | Every record from this source has at least one stored alias, reflecting the source transformation. |
| TGStat crypto category | 555 | 555 | 558 | Every record from this source has at least one stored alias, reflecting the source transformation. |
| Cornix supported group marketplace | 85 | 85 | 173 | Every record from this source has at least one stored alias, reflecting the source transformation. |
| Manual provider seed | 74 | 66 | 152 | Alias coverage is partial and should be checked record by record. |
| Public WhatsApp source family | 12 | 12 | 24 | Every record from this source has at least one stored alias, reflecting the source transformation. |
| Public Discord source family | 6 | 6 | 17 | Every record from this source has at least one stored alias, reflecting the source transformation. |
The largest source family contributes 1,870 records and no alias entries, while both TGStat families populate aliases for every record. Cornix, manual seeds, and the small Discord and WhatsApp source families also retain aliases. This pattern shows that alias presence is partly a feature of import design. Comparing providers by alias count would therefore compare source pipelines as much as provider identity.
How much of the field adds another value?
| Alias-field measure | Count | Unit | Interpretation |
|---|---|---|---|
| Records with at least one entry | 1,322 | Provider records | Field presence; heavily determined by source import. |
| All stored entries | 1,522 | Alias assignments | Raw strings before comparison grouping. |
| Equivalent to stored handle | 1,241 | Alias assignments | The value repeats the handle after normalization; not evidence of a rename. |
| Equivalent to stored name | 55 | Alias assignments | The value repeats the display name after normalization; this can overlap the handle count. |
| Name-or-handle-only records | 1,152 | Provider records | Every stored alias reduces to that record’s own name or handle. |
| Records with another value | 170 | Provider records | At least one normalized entry differs from both stored name and handle. |
The assignment counts overlap because an alias can equal both a record’s name and handle. The record-level measure avoids that overlap: 1,152 of 1,322 alias-bearing records add no normalized value beyond their own name or handle. That leaves 170, or 5.3% of the full inventory, for deeper provenance review.
Exact and normalized sharing
| Comparison | Unique values | Shared groups | Provider records | Assignments |
|---|---|---|---|---|
| Exact stored alias | 1,506 | 11 | 23 | 27 |
| Versioned normalized alias | 1,502 | 13 | 28 | 32 |
Exact comparison finds 11 values shared across 23 records and 27 assignments. Mark, case, and separator folding expands the queue to 13 groups, 28 records, and 32 assignments. The difference is a method-sensitivity result, not evidence that the newly joined strings are official equivalents.
8 entries, representing 8 normalized values, match another record’s display name. That supports cross-record retrieval. It does not establish which record is canonical or whether either operator authorized the relationship.
The manifest lacks per-alias provenance
The current record stores an alias array, a record-level source URL, and a source-family label. It does not attach an individual source URL, first-seen date, last-seen date, relationship type, or operator confirmation to each alias entry. A value may therefore come from a directory transformation, handle preservation, manual seed, category label, or another source-specific rule without exposing that lineage at alias level.
This limitation is why the report does not classify entries as former names, translations, abbreviations, product names, or unauthorized labels. Those categories require provider-level evidence and dates. The aggregate can state where alias fields are populated and how values compare; it cannot reconstruct the history of each string.
What the alias field is safe to do
| Use | Supported input | Output boundary |
|---|---|---|
| Search retrieval | Exact and normalized stored values | Return candidate records without choosing one as canonical. |
| Importer audit | Source-family coverage and handle-equivalent counts | Explain field construction without scoring provider quality. |
| Relationship queue | Shared values or alias-to-display-name matches | Request route, source, and continuity evidence before linking entities. |
| Correction intake | Original string, source, capture date, and replacement evidence | Preserve the old observation while documenting why the record changed. |
The entity-resolution checklist owns the record-level workflow. This page remains an importer and provenance audit so alias-field statistics are not confused with verified provider history.
What alias metrics cannot prove
The 1,522 entries describe the frozen CSR inventory, not the number of names a provider uses in the wider market. Missing aliases may reflect source design, and populated aliases may repeat a source label rather than an operator-chosen name. Shared aliases do not prove coordination or impersonation. Alias-to-display-name matches do not establish which record is canonical. The next action is to resolve the route and time period, not to award or remove status.
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.
- CFTC: virtual-currency pump-and-dump advisory
Messaging-app tips, anonymity, urgency, thin liquidity, and market-manipulation risk.
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 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.