Strategy Marketplace

How the Clypt strategy marketplace works for builders and traders

Trading Commerce

The Clypt marketplace is not a typical app store. It’s a Trading Commerce platform where backtests are independently verified, strategies are validated across exchanges the builder never had access to, and performance metrics are computed by the platform — not self-reported.

How It Works

Submission Flow

What Builders Submit

Builders submit a TradingSpec — not source code. The TradingSpec defines the complete strategy (graph, operators, connections, parameters) in a serializable format:

# Builder develops in Jupyter
spec = TradingSpec(
    data=data_config,
    strategy=TradingStrategySpec(graph=graph),
    execution=TradingExecutionSpec(accounts=[account]),
    mode="backtest",
)

# Submit to marketplace
# Platform receives the spec, not the .py files

What is included: Graph structure, operator types, parameters, input connections, execution configuration.

What is NOT included: Source code of custom operators (if any). Custom operators are packaged as compiled modules.

Current limitation: The submission pipeline currently supports strategy code only — model weight files (.pkl, .joblib, .pt, .onnx), trained artifacts, and external data files cannot be uploaded alongside the strategy. This means ML/DL strategies that depend on pre-trained model files are currently limited to the research environment (Jupyter notebooks). They cannot yet be deployed to paper/live trading or listed on the marketplace.

Planned: A workspace file explorer feature will allow builders to upload and manage model artifacts alongside their strategy code, enabling full ML/DL pipeline support for marketplace submission and live deployment.

Validation Steps

1. Reproducibility check: Platform runs the submitted spec on the builder’s declared exchange data. Results must match the builder’s reported metrics within tolerance.

2. Cross-exchange validation: Platform runs the same spec on data from exchanges the builder didn’t use. This catches strategies that are overfit to a single venue’s price feed.

3. Cost model verification: Platform applies exchange-specific fees, funding rates, and liquidation logic. Strategies that are only profitable without costs are flagged.

Why Validation Matters: Builder → Platform → Trader Trust Chain

The validation pipeline exists because the trader’s capital is at stake. Every validation step directly addresses a specific risk that the trader faces:

Without this chain: Traders would have to trust self-reported metrics — the same broken trust model that plagues every existing copy-trading platform.

With this chain: Every number the trader sees was computed by the platform, on data the builder didn’t choose.

Cross-Exchange Validation (Venue Sampling)

Why it’s necessary

A strategy that only works on Binance might be exploiting:

• Venue-specific microstructure — Binance’s matching engine quirks, fee rebates, or liquidity patterns
• Data artifacts — Gaps, misquotes, or feed-specific anomalies in one exchange’s data
• Overfit to price feed — The “alpha” is just noise that happened to be profitable on one venue’s price history

Cross-exchange validation catches all three by running the exact same graph on data the builder never saw.

How it works

Because all operators process TaggedArrays (not exchange-specific data), the same strategy runs on any exchange:

Builder submits: Tested on Binance futures

Platform runs validation across venue samples:
  ✓ Binance futures  → Sharpe 1.8, MDD -12%  (builder's data — reproduced)
  ✓ Bybit futures    → Sharpe 1.5, MDD -15%  (builder never saw this data)
  ✓ Gateio futures   → Sharpe 1.3, MDD -18%  (builder never saw this data)
  ✗ Coinbase futures → Sharpe 0.4, MDD -35%  (poor — flagged in listing)

What it catches

Problem	How Venue Validation Detects It	Impact on Trader
Venue-specific overfitting	Sharpe drops 50%+ on other venues	Trader avoids deploying on other exchanges
Microstructure exploitation	Works on Binance, fails on Bybit	Trader knows the alpha source is fragile
Data artifact trading	Profits only from one feed’s anomalies	Trader avoids strategies that can’t generalize
Robust alpha	Consistent Sharpe across 4+ venues	Trader has high confidence in deploying

What the trader sees

The marketplace listing displays:

• Primary exchange results (builder’s declared venue)
• Cross-exchange results (independently validated on each sampled venue)
• Consistency score — how stable performance is across venues (0 = unstable, 1 = perfectly consistent)
• Recommended venues — which exchanges are suitable for deployment

Trader Experience

Strategy Evaluation

Traders see independently verified metrics for each strategy:

Metric	Source	Standardization	Builder Can Manipulate?
Sharpe Ratio	Platform-computed	Annualized (requires periods_per_year or timeframe)	No
Max Drawdown (MDD)	Platform-computed	Peak-to-trough, percentage	No
Total Return	Platform-computed	Cumulative return (V_current - V_first) / V_first	No
Win Rate	Platform-computed	Percentage of positive returns	No

Required metrics for every marketplace listing: Sharpe Ratio (AccumSharpe), Maximum Drawdown (AccumMaxDrawdown), and Total Return (AccumTotalReturn). Sharpe requires explicit periods_per_year or timeframe parameter. Total Return is cumulative (not CAGR). MDD is reported as the maximum peak-to-trough drawdown percentage.

Deployment

Traders deploy strategies from the dashboard:

1. Paper trading — Strategy runs on live data with simulated fills.
2. Live trading — Trader allocates capital. Strategy trades real money.

The trader’s TradingSpec uses the same graph as the builder’s — ensuring verified performance matches deployed performance.

Revenue Model

The platform generates revenue from two primary streams:

1. Platform Subscription

Builders and traders pay a monthly subscription for access to infrastructure. The subscription tier determines the number of strategies you can run concurrently on the dashboard:

Plan	Price	Live Trading Bots	LLM Credits	Backtest Data
Starter	Free	1	5 / month	Limited
Pro	$30/month	1	85 / month	Broad + Early Access Beta Data (on-chain, news, etc.)
Premium	$200/month	5	730 / month	Full Data Access

2. Marketplace Transaction Fee

Strategies are sold as one-time purchases. The platform takes a commission on each sale:

Trader pays one-time price → Platform takes commission → Builder receives remainder

The builder sets the strategy price. The platform commission varies by seller tier:

Seller Tier	Max Listing Price	Builder Revenue Share	Platform Commission
Free	$99	20%	80%
Bronze	$299	40%	60%
Silver	$599	60%	40%
Gold	$999	70%	30%

Builder Monetization

Builders earn revenue without revealing their strategy logic:

• Source code is never shared — traders receive a deployed strategy, not source files
• Cross-exchange validation proves the strategy works without revealing how
• Performance metrics are independently computed — no self-reporting
• Multiple traders can deploy the same strategy simultaneously

Trust Guarantees

Guarantee	How It’s Enforced
Backtest accuracy	Platform runs backtests with exchange-specific costs, funding, and liquidation
No lookahead	ClyptQ’s RollingBuffer architecture makes it structurally impossible
Independent metrics	Platform computes all metrics — builders cannot override
Cross-venue robustness	Validated on data the builder never saw
Real-time verification	Paper trading results are tracked and compared to backtest expectations
Malicious code protection	Multi-layer validation pipeline detects and blocks abusive patterns before and during execution
Metric integrity	Required metric operators (AccumSharpe, AccumMaxDrawdown, AccumTotalReturn) are computed by platform code — cannot be faked

Related Pages

Builder Guide

How to develop and submit strategies

Trader Guide

How to evaluate and deploy strategies

Code Parity

Why backtest = live makes marketplace trust possible

Backtesting Accuracy

How backtests are verified with real-world costs