Sealed before the outcome was known
In a chat app, the gap between “trust me” and “check it” is a timestamp the sender does not control.
A screenshot proves only that an image exists. A pinned post proves only what the channel wants pinned today. Neither says anything reliable about when a call was made, or whether the entry was nudged — or the whole post deleted — after the trade went the wrong way. In a medium where the sender owns the record, that ambiguity is the entire problem.
An on-chain timestamp removes the ambiguity, because it takes the record out of the sender's hands. The pick takes a SHA-256 of the call's entry, target, stop, grade and signal time and commits the resulting fingerprint to a Bitcoin block via OpenTimestamps — an open, independently run standard — at the moment of publication. A hash is a one-way fingerprint: change any field afterward — entry, target, stop or grade — and you get an entirely different fingerprint that no longer matches the public receipt, and deleting the post leaves the receipt standing. So a confirmed receipt proves the exact call existed in that exact form before the outcome was known. Since the grade is one of the fields feeding that fingerprint, no one can quietly bump a call from a C to an A once it wins.
Walk one call through it
Picture an illustrative Swing call (this is a made-up example for the walkthrough, not a specific real trade): a long, entry 184.20, target 195.30, stop 179.60, grade B, signal time 09:48:12 UTC. At publication the desk runs those exact fields through the hash and anchors the fingerprint to Bitcoin. The position runs for the next few weeks. Long after it closes you can take the published call, recompute the fingerprint from those same five fields, and confirm it matches the receipt recorded against a block that was mined before the trade resolved. If even the stop had been shifted from 179.60 to 181.00 after the move turned, the fingerprint would not match — and you would know.
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 “sealed before the outcome” means, and no amount of pinned-post polish substitutes for it.
What failing this test looks like
Most chat-app channels fail this test not through outright fraud but through architecture: where the call lives, nobody can pin down when it was made.
- Telegram and chat channels. The sender owns the feed and decides what is posted, edited and deleted. A call can be added after the move, re-priced in place, or wiped with no trace, so it fails sealed before the outcome outright — and usually the denominator too, because the losing posts simply never survive in the scroll.
- Copy-trading rooms. More checkable than a chat, because a platform tracks participant results — but the calls are seldom timestamped per signal and seldom graded, so they fail sealed before the outcome and a measured grade even when a rough denominator exists.
- Social-media callers. Posts can be quietly deleted or selectively boosted, and the revenue often comes from broker affiliate links, so a caller tends to fail several tests at once — sealed before the outcome, an honest denominator and clean incentives together.
- Signal-aggregator sites. They republish other people's calls without auditing them, so every verification 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 one product: pre-outcome timestamping 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 chat-app record from something you scroll into something you can audit, which is why it sits at the top of the scorecard rather than the bottom. To run the check yourself, see the verification walkthrough; for what a full record must also contain, see an auditable record.