> ## Documentation Index
> Fetch the complete documentation index at: https://docs.clypt.ai/llms.txt
> Use this file to discover all available pages before exploring further.
# 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
```mermaid theme={null}
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#1e293b', 'primaryTextColor': '#e2e8f0', 'primaryBorderColor': '#94F1E8', 'lineColor': '#5bb8b0', 'clusterBkg': '#0f172a', 'clusterBorder': '#1e3a3a', 'titleColor': '#94F1E8', 'edgeLabelBackground': 'transparent' }}}%%
flowchart TB
classDef highlight fill:#134e4a,stroke:#94F1E8,stroke-width:2.5px,color:#94F1E8
classDef action fill:#172554,stroke:#60a5fa,stroke-width:1.5px,color:#bfdbfe
subgraph Builder
A["Submit TradingSpec"]
end
subgraph Platform["Platform Validation"]
direction TB
B["Reproduce backtest"] --> C["Cross-exchange validation"]
C --> D["Compute verified metrics"]
D --> E["Publish with Verified badge"]
end
subgraph Trader
F["Deploy: paper → live"]
end
A --> B
E --> F
class E highlight
class F action
```
## 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:
```python theme={null}
# 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:
```mermaid theme={null}
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#1e293b', 'primaryTextColor': '#e2e8f0', 'primaryBorderColor': '#94F1E8', 'lineColor': '#5bb8b0', 'clusterBkg': '#0f172a', 'clusterBorder': '#1e3a3a', 'titleColor': '#94F1E8', 'edgeLabelBackground': 'transparent' }}}%%
flowchart LR
classDef highlight fill:#134e4a,stroke:#94F1E8,stroke-width:2.5px,color:#94F1E8
classDef success fill:#0f2d2b,stroke:#2dd4bf,stroke-width:1.5px,color:#ccfbf1
subgraph BS["Builder Claims"]
direction TB
B1["Sharpe 2.0"]
B2["Works everywhere"]
B3["Low cost impact"]
end
subgraph PV["Platform Validates"]
direction TB
P1["Reproduce backtest"]
P2["Unseen exchanges"]
P3["Real venue fees"]
end
subgraph BY["Trader Sees"]
direction TB
Y1["Sharpe 1.98 ✓"]
Y2["Consistency 0.85"]
Y3["Fee impact -12%"]
end
B1 --> P1 --> Y1
B2 --> P2 --> Y2
B3 --> P3 --> Y3
class P1,P2,P3 highlight
class Y1,Y2,Y3 success
```
**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 `TaggedArray`s (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
How to develop and submit strategies
How to evaluate and deploy strategies
Why backtest = live makes marketplace trust possible
How backtests are verified with real-world costs