Provider status widget

Put the current CSR evidence status on another website.

Choose a provider file, preview its live CSR Verified or CSR Unverified status, then copy one embed tag. The provider cannot rewrite the status, supporting-evidence coverage, missing-proof note, or destination link.

1. Choose the record

Enter the provider slug.

Use the final path segment from a CSR provider file. For example, the slug in /reviews/mycryptoparadise-review/ is mycryptoparadise.

Provider slug

Widget view The result-sheet panel is populated only when CSR has published checked documents for that provider.

Widget theme Match your site background. Dark keeps the widget native on dark pages; the evidence content is identical in every theme.

<script src="https://cryptosignalsreview.com/csr-provider-widget.js" data-csr-provider="mycryptoparadise" defer></script>

2. Check the live state

Preview before publishing.

Loading the CSR-controlled widget…

The widget opens the canonical CSR provider file in a new tab. Its status can change when the evidence changes, expires, is corrected, or becomes unavailable.

Inspect the current machine-readable widget record

Installation

Add one live record without copying its conclusion.

The script and status API are hosted by CryptoSignalsReview. Do not cache, alter, cover, or restyle the evidence conclusion.

Confirm the slug and preview. Open the linked CSR record and confirm the intended provider identity and supporting evidence.
Copy the generated script tag. Paste it where the widget should appear in the page body. Use one provider slug per widget.
Allow the required CSR origins. If the site has Content Security Policy headers, add only the directives required for the script, status request, logo and widget styles.
Recheck the published page. Confirm the full widget remains visible on desktop and mobile and that the link opens the same canonical CSR record.
Optional: keep a crawler-visible static copy. Paste a plain-HTML evidence snippet next to the embed and mark it data-csr-widget-static="<slug>". Readers without JavaScript and crawlers see the static copy; when the live record renders, the widget hides it, and if the live fetch fails the static copy stays visible instead of an unavailable card.

Content Security Policy

Merge these sources into an existing policy rather than adding a second CSP header. Widget styles load from the CSR origin; the production embed does not require 'unsafe-inline'.

script-src https://cryptosignalsreview.com; connect-src https://cryptosignalsreview.com; img-src https://cryptosignalsreview.com; style-src https://cryptosignalsreview.com;

Evidence boundary

What the widget means—and what it never means.

Binary CSR status

The widget displays exactly one status: CSR Verified or CSR Unverified. Supporting evidence coverage and exclusions appear separately.

Visible freshness

Treat the canonical CSR file as controlling. Recheck it before relying on the widget because evidence coverage, gaps, status, and availability can change.

No endorsement

A widget is not a safety badge, recommendation, profitability claim, ranking award or promise of future performance. Provider-funded work cannot buy its conclusion.

Compliance built in

Every link the widget renders carries rel="nofollow noopener noreferrer", so an embed never passes search authority back to CSR. The widget renders the exact binary status plus supporting-evidence coverage and exclusions, so the context travels with the status.

Do not use screenshots as the authoritative status

A copied image can remain online after a record changes. Keep the live script and canonical CSR destination intact, or link directly to the provider file instead.

Missing or incorrect record?

Apply with the source, period and correction contact.

An application can request evidence review or a correction. It cannot buy verified status, a rating, ranking or favorable conclusion.

Open provider application