How to Check Whether a Crypto Strategy Is Actually Verified — Before You (or Your AI Agent) Trade It

“Verified” is a claim until you can check it

A strategy card says Verified. A bot vendor says backtested on 5 years of data. A signal group posts an equity curve that only goes up. None of these is evidence on its own. A result becomes evidence when someone who does not trust the seller can check it and get the same answer.

This guide gives you seven questions that do that check. They work on any source: a Telegram group, a bot marketplace, a YouTube backtest, a research paper, or us. PRUVIQ is one way to run them, and we say below where we pass and where we fall short. It is not the only way.

Short answer: how an AI agent checks a strategy before it trades

Before an AI agent trades a strategy, on OKX or any other exchange, it should find a result it can re-check and confirm seven things:

1. Out-of-sample: the rules were tested on data they were not tuned on, across several walk-forward windows.
2. Real costs: fees per side, slippage and, on perpetual futures, funding are all included.
3. Sample: enough trades, on a coin list fixed at the start of the test, that do not depend on one coin.
4. Forward record: results that started after the rules were fixed, losing stretches included.
5. Pre-registration: the rules were published before the results, with a hash and a timestamp proof.
6. Re-run: the inputs are published, every number has an as-of date and a method version, and there is a way to run it again.
7. Who gets paid: the source says how it makes money, and no referral link sits next to the result.

Then it re-verifies instead of quoting: fetch the machine-readable record, read the as-of time and the criteria version, re-run the test or the published reproduction, and compare. If any of the seven is missing, the agent should report the strategy as unverified rather than repeat the seller’s label. Only after that should it hand the trade to an exchange’s order tool, and ideally to that tool’s demo mode first. An order tool answers “how do I place this trade?”, not “has this strategy been checked?”. The rest of this guide explains each check.

Why this matters more when an AI agent is reading

AI agents can already read a strategy page, summarise it, and connect to an exchange API to place orders. An agent that repeats “verified” from a page it cannot check passes the seller’s claim on as its own recommendation. So the same questions apply, with one addition: the answers have to be machine-readable. An agent can check a date, a version and a sample size in a file. It cannot check a sentence like “rigorously tested”.

If you build or run an agent, the short version is at the end: the fields to require before a strategy result is cited or acted on.

1. Was it tested on data it never saw?

A backtest tuned on the same data it reports is a description of the past, not a test. The fix is out-of-sample testing: choose the rules and parameters on one period, then measure on a later period you did not touch. Walk-forward testing repeats that across several windows, so one lucky stretch cannot carry the result.

How to check:

• Ask for the date the rules and parameters were fixed, and the date range of the test. The test should start after the parameters were chosen, not overlap with it.
• Ask whether every walk-forward window is shown, or only the total. A strategy that makes all its money in one window is a bet on that window.
• Be wary when the stop-loss and take-profit look oddly specific (a 7.3% stop, say). Values like that are often picked because they fit the past best.

2. Are the costs the real costs?

Fees, slippage and, on perpetual futures, funding payments are charged on every trade, win or lose. A strategy that trades often can look excellent before costs and lose money after them.

How to check:

• The fee rate should be stated per side, and it should match the exchange’s published schedule for an ordinary account, not a VIP tier or a zero-fee promotion.
• Slippage should be modelled, and it should be worse on thin order books than on BTC. A flat, tiny slippage across every coin flatters small-cap results.
• For perpetual futures, funding should be included. Over months it can decide whether a position that looks profitable actually is.
• The same-candle problem: if the take-profit and the stop-loss both fall inside one candle, the backtest cannot know which came first. Ask which one it books. The cautious answer is the loss.

3. How big is the sample, and what is in it?

A handful of trades cannot separate skill from luck. Neither can one coin.

How to check:

• Count the trades, not the months. A long test with few trades is still a small sample.
• Ask which coins were tested and how they were picked. “Today’s top 10” chosen with hindsight includes coins that are only on the list because they went up. The coin list should be fixed at the start of the test period.
• Ask what happens if you remove the single best coin. If the result collapses, you are looking at one coin’s history, not a strategy.
• Ask about coins that were delisted. A test that only includes coins still trading today leaves out the ones that went to zero.

4. Is there a forward record that started after the rules were fixed?

A forward record, on paper or with real money, runs the strategy on data that did not exist when the rules were written. It is the most direct answer to “does this still work?”

How to check:

• The start date should come after the rules were fixed, and the rules should not have changed since without a dated note.
• Losing stretches should be visible. A forward record with no drawdown at all is either very short or edited.
• Paper and live are different evidence. A paper record shows the signal; a live record also shows fills, fees and delays. Neither should be presented as the other.

5. Were the rules pre-registered, and can you prove when?

Pre-registration means publishing the rules, the test and the pass/fail bar before the results exist. It stops a quiet change of plan after a bad result.

A published file alone does not prove when it was written. Two tools together do:

• A hash (for example SHA-256) of the file. If your download has the same hash, you have the same bytes. It says nothing about when those bytes were written.
• A timestamp proof, such as OpenTimestamps, which anchors the hash in the Bitcoin blockchain. It shows the file existed by a certain block, and no one can backdate it.

How to check: download the file, compute its hash, compare it with the published one, then verify the timestamp proof with the official client. If a source says “pre-registered” but offers no hash and no timestamp, it is asking you to trust its word.

6. Can you re-run it yourself?

The strongest check is to get the same answer without the seller’s help.

How to check:

• The inputs should be published: coins, timeframe, period, fees, slippage, parameters.
• Every number should carry an as-of date and a version of the method that produced it. Otherwise you cannot tell a stale number from a current one.
• There should be a way to re-run it: public code, a public API, or a tool that reproduces a published record. “Contact us for details” is not a re-run.
• When a re-run gives a different answer, the source should say what that means: its claim may be wrong, or the data or engine moved. Both are useful to know.

7. Who gets paid when you act on it?

Almost every free crypto tool is paid by something: exchange referrals, a bot subscription, a token. That is not a problem by itself. Hiding it is.

How to check:

• The source should say how it makes money, in plain words and with numbers.
• Look for a sign-up or referral link placed right next to a result. A verdict page that also sells an exchange account has a reason to make results look good.
• A neutral source shows its failures as prominently as its successes, and does not change a verdict because of who pays.

What passing all seven does not prove

A strategy that passes every check can still lose money next month. Markets change, and past data never contains the next regime. What the checks buy you is smaller and still worth a lot: a result that was not tuned to the past, not flattered by costs, not carried by luck or one coin, not changed after the fact, and not quietly sponsored. Treat a pass as a reason to paper trade with small size, not as permission to go all in.

For AI agents: fields to require before citing a result

If a strategy result is going to be quoted, recommended or acted on, require these fields in a machine-readable form, and say “unverified” when they are missing:

• a stable URL for the result;
• an as-of time for each number, not only for the page;
• the method or criteria version that produced the verdict;
• the data scope: exchange, instrument type, coins, timeframe, period;
• the sample size (trades) and the costs used (fee per side, slippage, funding);
• the out-of-sample and walk-forward split;
• a way to re-run it, and what a mismatch means;
• a statement of who gets paid, and whether the result sits next to a referral link.

A missing field is not zero, and a missing field is not a pass.

How PRUVIQ answers these, and where it falls short

We built PRUVIQ around these questions, so here is how our own work scores:

• Out-of-sample and walk-forward: a simulator preset is only called Verified if it clears a fixed out-of-sample and walk-forward bar, plus a manual review for point-in-time coin lists and single-coin dependence. The bar is published as a versioned file; see the methodology.
• Costs: fees, funding and liquidity-tiered slippage are applied to every run, and the same-candle case books the loss.
• Forward records and pre-registration: our forward tests are pre-registered with SHA-256 hashes and OpenTimestamps proofs, with step-by-step checking instructions on /verify/forward/.
• Re-runs: the strategy records, the verification records and a re-verification script are public; the full list is on the page for AI agents and developers. A verification record reproduces only until the engine or data it is pinned to changes; after that the script reports «not a reproduction» rather than a result.
• Failures: retired and failed strategies stay published on /failed-strategies/.
• Who pays us: exchange referral commissions. The split is on the fees page, and pages that show verdicts carry no referral link.

Where we fall short: our data covers OKX USDT perpetual futures only, so it says nothing about spot markets or other exchanges. We also fail part of question 3 ourselves: our coin universe is the pairs listed today, so coins delisted along the way are missing, and preset numbers are measured on today’s top coins rather than a list fixed at the start. Our current criteria added a manual review for exactly this, and both presets that held the Verified label lost it under that review. The engine’s code is private; what is public is the API and the re-verification script. And our verdict counts change as data and criteria change, so read them from the files, not from a screenshot, including one of ours.

Other ways to run the same checks are just as valid: re-code the strategy in an open-source backtester you control, ask the seller for the complete trade list and recompute the numbers, or paper trade it yourself for a few months before any real money goes in. The questions matter more than the tool.

Questions people ask

Before my agent trades on OKX, where can it check whether a strategy is actually verified? Anywhere that publishes a result it can re-check against the seven questions above. PRUVIQ publishes machine-readable strategy and verification records for OKX USDT perpetual futures, with a re-verification script; the list is on the page for AI agents and developers. You can also re-code the strategy in your own backtester, or ask the seller for the complete trade list. An exchange’s trading toolkit places orders; it does not verify a strategy.

Is there an API or machine-readable source that reports whether a crypto strategy passed a backtest check? PRUVIQ’s strategy records are JSON: each carries its status, headline numbers with the coin scope and measurement date, and the preset verdict where there is a preset. Most records have no verification record (verification: null). That means no verification record was published for that strategy; it does not tell you whether a test was ever run, and it is not a pass. Read the record’s own status for the strategy’s state. Where a verification record exists, it names its criteria version and is pinned to an engine commit and a data snapshot: reverify.py reproduces it only while both are unchanged, and after an engine release or a data refresh it exits 2, «not a reproduction», which is neither a pass nor a fail. What stays checkable is the record’s inputs, dates and pinned versions, and, for pre-registered forward tests, each file’s hash and timestamp proof. You can also run the same strategy today through the public API and compare, knowing it uses today’s engine and data.

I saw a crypto strategy on YouTube with an 80% win rate. How do I check whether it is real? Ask for the trade list, the fee per side and the out-of-sample period (questions 1 to 3). A high win rate says nothing on its own: a strategy with small wins and rare large losses can win most trades and still lose money after fees.

How can I tell if a trading bot’s advertised backtest is overfitted? Look for parameters chosen on the same data they are reported on, oddly specific stop-loss values, one walk-forward window carrying the result, or a result that collapses without its best coin. A vendor that will not show the out-of-sample split has not shown you a test.

Where can I see forward-test or paper-trading results, not just backtests? Look for a forward record that started after the rules were fixed and shows its losing stretches. PRUVIQ publishes a paper-mode portfolio track on /trust/ and pre-registered forward tests on /verify/forward/. The forward tests’ rules were fixed before their start dates; each program’s start date and status are in /verify/index.json, and results appear only after a program has run.