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 completed, independently verified timestamp can support a bound on the existence of the exact covered bytes. The documented VR2 preimage is VR2|salt|family|ticker|direction|grade|entry|signal_time. Stop and target are outside that digest. Preserve encoding, separators and original formatting. Pending submission is not completed Bitcoin attestation; a bound after the outcome does not establish pre-outcome publication. A proof is not an exchange fill, subscriber delivery record, full-population audit or custody guarantee.

Walk one call through it

For a hypothetical VR2 test, first obtain the actual salt, family, ticker, direction, grade, entry and signal_time strings exactly as published. Preserve separators, case, decimal formatting and encoding. Hash those exact bytes, then verify the associated completed .ots proof. An omitted stop or target is not protected by that digest; save its original instruction separately.

In this hypothetical walkthrough, the relevant comparison is between an independently verified bound and the declared outcome event. That earlier bound is assumed for the teaching case, not observed for a real call here. Retain proof state and event definitions; do not infer a completed trade from the comparison.

What failing this test looks like

When an original publication sequence cannot be reconstructed, timing remains unresolved. Obtain the first versions, amendments, expected population and independent receipt evidence. Lack of one timestamp technology is not itself proof of fraud.

• Crypto evidence request: Preserve the complete message sequence, first versions, revisions and missing-message policy.
• Crypto evidence request: Reconcile one named source account to follower orders, rejected entries, sizing differences and costs.
• Crypto evidence request: Keep a consecutive sample of first-version posts and disclose any referral incentives.
• Crypto evidence request: Compare forwarded instructions with the original source and retain delays and changes.

The comparison therefore records source-specific evidence requests rather than awarding a universal pass to one product format. Missing records limit the conclusion; they do not prove a whole category is dishonest. A compatible task and complete source population matter more than an attractive badge.

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.