Trade Thesis

Pre-Trade Thesis Builder

A structured framework the agent produces before any live deployment of a new strategy idea. Forces two-sided analysis and a measurable invalidation level so every trade has a thesis that can be killed.

When to produce a thesis

• The user proposes a new trade idea ("I want to long ETH", "thinking about a funding squeeze on SOL")
• The user asks "should I trade X" or "is this a good setup"
• The agent is about to deploy a new strategy to live for the first time
• The user explicitly asks for a bull/bear case, conviction check, or pre-trade analysis

When to skip

• Backtests and parameter sweeps — the thesis is for live capital, not for exploring an idea
• Dry-run / paper deployments — no real money at risk
• Copy-trading — the thesis belongs to the source trader, not the copier
• Re-deploying a previously validated strategy — if the user already ran this setup live and is restarting it, skip unless market conditions changed materially

Thesis format

Produce all six sections below. Each section is 2-4 bullet points max. This is a pre-trade checklist, not a research paper.

1. Thesis statement

One sentence: what is the bet, which direction, what timeframe.

Force clarity. "Long ETH perp on a funding squeeze setup, targeting a 3-5% move over 24-48h" is a thesis. "ETH looks bullish" is not.

2. Bull case

2-3 concrete reasons this trade works. Every reason must reference observable, checkable data:

• Price action the agent can verify via price_check (e.g., "price reclaimed the 4h EMA-50 and is holding above")
• Volume dynamics via volume_momentum_check (e.g., "RVOL is 2.3x on the breakout candle")
• Funding / OI via the alpha scan (e.g., "funding APR is -18%, shorts are paying 0.002% per hour")
• On-chain flows if available (e.g., "exchange outflows spiked 3x over 24h")

No vague claims like "market sentiment is improving" or "BTC looks strong." If it cannot be checked with a tool call, it does not belong in the bull case.

3. Bear case

2-3 concrete reasons this trade fails. Same data-grounding rules as the bull case.

The agent must argue AGAINST the trade honestly. This is adversarial analysis, not a strawman disclaimer. Examples of real bear points:

• "Funding is negative but OI is declining — shorts are closing, not getting squeezed. The fuel is draining."
• "RVOL is elevated but the move happened on a single 15m candle — no follow-through across multiple sessions."
• "BTC is sitting at the 200-day moving average with a bearish divergence on 4h RSI. A rejection here takes alts down 10-15%."

4. Invalidation level

A specific, measurable condition that kills the thesis. This becomes the logical stoploss anchor.

Acceptable invalidation criteria:

• A price level: "Below $3,420 the reclaim is failed — thesis dead."
• A funding flip: "If funding APR crosses above 0% before the move, the squeeze pressure is gone."
• An RVOL collapse: "If RVOL drops below 1.0x within 4 hours of entry, the momentum thesis is invalidated."
• A time deadline: "If price hasn't moved +2% within 24h, the catalyst is stale — cut."

The stoploss in the deployment config should be anchored to this level, not an arbitrary percentage.

5. Data check

Which agent tools to call right now to verify the thesis before proceeding:

Run these checks and update the bull/bear case with the results before proceeding. If the data contradicts the thesis, say so.