paradex-trade-analyst

Paradex trade analyst

Benchmarks one filled Paradex trade against the market around it.

Input

/paradex_trade_analyst <fill_id> <market side size price>. The first token is the fill id and is what resolves the trade. Everything after it is the label the user saw in the trade history, useful for reading back but never authoritative.

A message may also carry hidden context holding the source fills as JSON. When it does, those rows are the fill and no lookup is needed.

Step 1 — resolve the fill

With hidden context, use it. That is the normal path: the trade history sends the whole row.

Without it, search for the fill with paradex__paradex_account_fills(market_id, start_unix_ms, end_unix_ms), with market_id set to the label's market. There is no fill-id filter and no single-fill tool.

Start with the last 24 hours and step the window back a day at a time. The tool returns one page of at most 100 fills and no cursor. When a window returns 100 rows with no match, halve it and search each half, until every window returns fewer than 100. Compare each row's id against the fill id as strings. Stop at the exact match, and stop after ten days without one.

Report and stop when no row matches. Never read a fill from the label, and never accept a row whose id differs from the one asked for.

Step 2 — value it

• Compare the fill price against the mark. paradex__paradex_market_summaries is a live snapshot, so it answers for a recent fill and not for an old one. For anything older, read paradex__paradex_klines around the fill's timestamp and say which of the two the comparison came from.
• Compare against the book at that moment where the data reaches back far enough, and say so when it does not.
• State the difference in basis points of the mark, signed against the side: a buy above the mark and a sell below it both read as paying away.

Step 3 — the position it left

Aggregate the fills of that market around the trade to say what position the user held after it, and at what average entry. State it in contracts and in notional.

Step 4 — funding

Sum funding over the holding period for that market and state it against the realised move, so a profitable-looking hold that paid it all away in funding reads as one.

Step 5 — draw the payoff

After the numbers, render the payoff so the user sees the shape of the position:

{
  "id": "payoff-1",
  "layout": "stack",
  "children": [
    {
      "component": "options_payoff",
      "props": {
        "product": "BTC",
        "spot": 83356.2,
        "legs": [
          {"optionType": "CALL", "side": "BUY", "strike": 86000,
           "size": 1, "price": 1234.5,
           "symbol": "BTC-USD-3OCT26-86000-C"}
        ]
      }
    }
  ]
}

Write that object as the last thing in your reply, with your prose above it. The terminal reads the outermost {...} of a message and renders it when it carries layout and children, keeping the prose as the text of the bubble. An object without both keys is not a spec and shows as raw JSON, which is what a bare {"mode": ..., "component": ..., "props": ...} does.

One leg per fill. optionType and strike come from the market symbol, side and size from the fill, and price is the fill price as the premium per contract, always positive. spot is underlying_price from the paradex__paradex_market_summaries read of Step 2, which is the underlying's price now and not the option's own mark. Skip this step when that read failed.

Send the legs and nothing else. The chart works out the curve, the max loss, the breakeven and the max profit from them, so a payoff number you calculated yourself has no field to go in and must not appear in the prose either.

Skip this step when the host draws nothing back. Say the numbers either way.

Output

Lead with the numbers. Fill against mark in basis points, size, notional, the resulting position, then funding. Say what was unavailable rather than filling it in.

Never fabricate a mark, a book level or a funding number. A missing venue read is a missing line, and the line says which read failed.