Original CryptoSignalsReview dataset research
Crypto Signal Provider Route Reuse and Dedupe Gap Analysis
This crosswalk separates raw stored routes, platform-specific endpoint comparison, and explicit source-key coverage so one metadata layer is not mistaken for entity proof.
Open the route and dedupe analysisNo signup, payment, wallet connection, or credentials are required.
39.5% of the inventory.
25 records occur in those groups.
38.3% of records.
Direct answer
1,264 of 3,200 records have a direct Telegram, Discord, WhatsApp, or website route. The 1,265 stored assignments contain 9 exact shared-route groups covering 23 records. Platform-specific canonicalization produces 10 groups covering 25 records. Separately, 1,224 records have no explicit dedupeKey field, but the Provider Atlas generator can still fall back to handle, slug, or name when constructing its internal record key. Shared stored routes and explicit source-key missingness create review work; neither is a duplicate-provider rate or ownership conclusion.
Route comparison sensitivity
| Comparison profile | Unique routes | Shared groups | Provider records | Excess assignments | Boundary |
|---|---|---|---|---|---|
| Exact stored string | 1,251 | 9 | 23 | 14 | No host, path, case, or scheme transformation. |
| Platform-specific canonical | 1,250 | 10 | 25 | 15 | Primary comparison profile used by this report. |
| Telegram scheme sensitivity | 1,249 | 10 | 26 | 16 | Additional sensitivity only; HTTP and HTTPS Telegram routes are folded. |
The primary profile, platform-route-v2, changes the queue from 23 to 25 records. A more aggressive Telegram-only scheme fold would add one more record. Publishing all three profiles prevents a normalization choice from being presented as an objective duplicate count.
Platform-specific route rules
For Telegram only, the canonical profile maps known Telegram hosts to t.me, removes the public-view /s/ wrapper, lowercases a single public username, removes presentation-only single and embed parameters, and discards the fragment. It preserves the HTTP or HTTPS scheme, bot start parameters, and case-sensitive private-invite tokens. For Discord invite paths only, it maps discord.com/invite/ to discord.gg/. Generic website and WhatsApp query strings, fragments, www hosts, and paths are preserved. Invalid stored URLs fail generation rather than entering a lossy fallback.
| Route field | Assignments | Canonical shared groups | Inventory boundary |
|---|---|---|---|
| Telegram URL | 1,257 | 10 | Dominant direct-route field in this source mix. |
| Discord URL | 6 | 0 | Small seeded source family; no shared route group. |
| WhatsApp URL | 1 | 0 | One assignment; no market-level inference. |
| Website URL | 1 | 0 | One assignment; generic URL details remain intact. |
The shared-route queue is entirely Cornix-sourced
| Canonical shared-route measure | Count | Interpretation |
|---|---|---|
| Shared route groups | 10 | Every group involves the Telegram URL field. |
| Provider records | 25 | All come from Cornix supported group marketplace. |
| Records with explicit keys | 25 | Every record in the canonical shared-route queue has a populated explicit key. |
| Groups spanning multiple explicit keys | 9 | Route equality and source-key equality disagree in most groups. |
This concentration is more informative than a site-wide route-reuse percentage. It suggests the queue is a property of one marketplace import and its supported-group relationships, not a pattern demonstrated across all seven source families. A Cornix route can represent a product relationship, supported automation endpoint, tier, or imported listing. The aggregate does not decide which explanation applies.
Explicit dedupe-key field coverage
| Field measure | Records or groups | Interpretation |
|---|---|---|
| Explicit key populated | 1,976 | An opaque import or comparison identifier is stored. |
| Explicit key absent | 1,224 | The field is blank; generator fallback logic may still use handle, slug, or name. |
| Unique lowercase comparison keys | 1,974 | Opaque keys are trimmed and lowercased only; name normalization is not applied. |
| Repeated key groups | 2 | Exact source-key repetitions after lowercase comparison. |
| Records in repeated key groups | 4 | Records affected by those repetitions. |
| Source family with explicit keys | Records |
|---|---|
| RealTelegram channel category | 1,870 |
| Cornix supported group marketplace | 85 |
| TGStat crypto category | 21 |
The 1,224 blanks are explicit-field missingness, not dedupe failures. Keys are not identity certificates: different keys can still describe related products, while a repeated key can reflect source construction rather than one operator.
Route and dedupe cross-tab
| Direct route | Dedupe key | Records | Safest interpretation |
|---|---|---|---|
| Present | Present | 106 | Two join clues exist, but route ownership and time still need checking. |
| Present | Missing | 1,158 | The route can seed review; create a documented comparison key only after reconciliation. |
| Missing | Present | 1,870 | The key likely comes from source identity, while current endpoint evidence remains absent. |
| Missing | Missing | 66 | Name, aliases, source, and fresh route research must carry the resolution task. |
The four cells sum to 3,200 records. The largest contains 1,870 records with an explicit key but no direct route; 1,158 have a route but no explicit key. That asymmetry is why route presence and explicit key presence remain separate dimensions instead of becoming one completeness score.
What this crosswalk can support
The report can identify records that share an exact stored route, records added by a declared platform-specific comparison profile, the source family responsible for the current shared-route queue, and the intersection between route and explicit-key fields. It cannot determine route ownership, current control, product equivalence, authorization, or whether a record should merge. Those outcomes require the dated joins in the entity-resolution checklist.
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.
Public verification vocabulary: CSR Verified or CSR Unverified only. In this frozen snapshot, 0 records were CSR Verified and 3,200 were CSR Unverified. “Listed for review” and “quarantined” are retained only as historical internal workflow fields from 2026-07-05; neither is a third public verification status.
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 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 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, 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.