Strateva

Scope

Spot markets, and nothing built on derivatives.

The scope is narrow on purpose. A validation is only credible where the execution can be modelled honestly, and that is where this one stops.

What is covered

The engine boundary is wider than the automated acquisition path. The difference is stated here so a supported schema is never mistaken for a service available today.

  • Equities and ETFs, spot

    One listed share or exchange-traded fund bought and sold outright, on daily data in the current automated path.

  • Crypto, spot — supported Binance pairs

    Supported spot pairs are acquired from Binance on daily 24×7 bars. Perpetual swaps, leveraged tokens and every other derivative remain excluded.

  • Currency pairs, spot

    One spot FX pair on daily data. The exposure is the currency itself, not a derivative wrapper.

What is not covered

These are out of scope today. It is a limit of what can be validated properly, not a judgement on the instruments.

  • Options
  • Futures
  • Perpetual swaps
  • CFDs
  • Leveraged tokens
  • Structured products

And, as a general rule: any strategy whose main exposure depends on derivatives, whatever the wrapper is called.

Derivative strategies live or die on things a returns series does not contain — the funding, the margin mechanics, the roll, the exercise assumptions, the path to a margin call. Validating them without modelling all of that would produce a confident number that means nothing, which is worse than no number.

What decides whether a specific strategy is accepted

Being in a covered market is necessary, not sufficient. Six things decide the rest, and they are checked before execution.

  • Data availability

    Whether the history the strategy needs exists, and whether it can be obtained in a form good enough to reason about.

  • Frequency

    The current automated data connector is daily only. Other intervals exist in the engine protocol but are not promised as an end-to-end service.

  • Universe

    How the instrument set is defined, and whether it can be rebuilt as it stood at the time rather than as it stands today.

  • Benchmark

    Whether a fair like-for-like comparison exists. Without one, an improvement cannot be attributed to the strategy.

  • Execution complexity

    Whether the fills the strategy assumes are plausible at its size and speed, and whether the costs can be modelled with a real source.

  • Reproducible rules

    Whether the rules can be restated precisely enough that the same inputs produce the same decisions, every time.

What to send, and in what shape

Start by describing the rules in your own words. You do not need to convert anything, reformat anything or prepare a package before getting in touch.

Claude or ChatGPT can normalize code, Pine Script, AI-generated code or precise natural-language rules through the MCP. The original source is preserved and hashed.

Normalization does not make an unsupported asset, interval or data source executable. Contract and data checks stop those cases before execution.

Is your strategy a fit?

Compatibility is checked before anything is charged. Most of it you can judge yourself from this list.

What you can send for assessment

You can send code, Pine Script, a trade list or written systematic rules. First we check whether the material can be turned into a reproducible specification. If it is not compatible with the engine or with the current scope, you are not charged.

  • Python
  • Pine Script
  • AI-generated code
  • Trade logs
  • Written systematic rules

Being accepted for assessment is not the same as being compatible. The assessment is what establishes that, and it happens before any money changes hands.

A strategy is usually a fit if

  • The rules are systematic.
  • You can name the assets and the timeframe.
  • There is code, Pine Script, a trade list, or rules written precisely enough to be reproduced.
  • There is a backtest, or material that can be reproduced.
  • It is close to a shadow-trading decision.
  • Its main exposure is spot.

What gets caught before you are charged

  • Derivatives.
  • Discretionary rules that cannot be formalised.
  • Incompatible data.
  • Unsupported frequencies.
  • Multi-asset strategies that cannot be separated.
  • Insufficient material.

If the material is not compatible with the engine or with the current scope, you are not charged.

Compatibility is enforced automatically by closed contracts and executable-data checks. Unsupported requests stop before Checkout; routine analyst review is not included.

Have something that needs an independent check?

Describe the strategy, the backtest or the model through the MCP. You confirm the exact scope before anything runs.

Connect the MCP

Validation is sponsored. Optional support is separate and never affects the result.