Written to a chain first

A screenshot proves only that an image exists. It says nothing reliable about when a call was made, or whether the entry was nudged after the candle went the wrong way. The audience this guide serves already rejects that kind of proof everywhere else — you would not accept a screenshot of a transaction in place of the transaction on-chain, so there is no reason to accept one in place of a trade.

A SHA-256 hash committed to Bitcoin at publication closes the gap. A hash is a one-way digest: change any field afterward — entry, target, stop or grade — and you get an entirely different digest that no longer matches the on-chain receipt. So a confirmed receipt proves the exact call existed in that exact form before the trade resolved. The hashed shape used by the pick is a SHA-256 of the call's entry, target, stop, grade and signal time, and because the grade is folded into that digest, a call cannot be quietly upgraded from a C to an A after it wins.

Walk one call through it

Picture an illustrative call (this is a made-up example for the walkthrough, not a specific real trade): a long on a liquid asset, entry 1.2840, target 1.2990, stop 1.2780, grade B, signal time 09:14:30 UTC. At publication the desk runs those exact fields through the hash and writes the digest to a Bitcoin block via OpenTimestamps. The position resolves over the following sessions. Weeks later you take the published call, re-derive the digest from those same five fields, and confirm it matches the receipt recorded against a block that was mined before the trade closed. Had the stop been shifted from 1.2780 to 1.2810 after the fact, the digest would no longer match — and you would know at a glance. None of this relies on trusting the desk: the receipt format is the open OpenTimestamps standard, and the block it points to is readable by anyone on a public explorer such as mempool.space.

The point is not the specific numbers; it is the order of events. The receipt is dated by the Bitcoin block, and that date sits before the outcome. That is what “written to a chain first” means, and no amount of polished marketing substitutes for it. It is a statement about the verification method only — never about which instruments the models trade.

What failing this test looks like

Most providers fail this test not through outright fraud but through architecture: where the call lives, nobody can pin down when it was made.

• Messaging-app channels (Telegram, Discord). The operator owns the post history. A call can be added after the move, edited in place, or deleted with no trace, so it fails anchored on-chain outright — and usually the denominator too, because the losing posts simply never appear.
• Copy-trading rooms. More checkable than a chat, since a platform tracks participant results — but the calls are rarely anchored per signal and rarely graded, so they fail anchored on-chain and a measured grade even where a rough denominator exists.
• Social-media callers. Posts can be quietly deleted or selectively boosted, and revenue often comes from exchange referral links, so a caller tends to fail almost every test together — anchored on-chain, a real denominator and clean incentives all at once.
• Signal-aggregator sites. They republish other people's calls without verifying them, so every gap in the original is carried forward unfixed. They fail a re-runnable record by inheritance.

This is why the guide frames itself as ranking a field rather than reviewing a single product: writing the call to a public chain before its outcome is exactly the test most of the field cannot clear, which is what makes clearing it worth paying for.

This is the one mechanism that turns a record from something you can merely be shown into something you can re-derive yourself on a ledger nobody owns, which is why it leads the five tests rather than trailing them. To run the check yourself, see the verification playbook; for what a full record must also contain, see a re-runnable record.