Dan Trapp

Workflow solution / Prediction markets

Polybot

A heavily iterated prediction-market automation system that treats execution discipline as the product.

A Python automation system for market monitoring, execution, sizing, and operational guardrails across fast-moving prediction markets, originally built around 15-minute markets and iterated hundreds of times.

Status

Prototype

Timeline

Hundreds of execution iterations

Domain

Prediction markets

Why

Workflow solution

Ask about this build

Execution guard

15m+ market automation

Prototype

Cap

$20

Iterations

100s

Mode

Guarded

Freshness, edge, bankroll cap, no-trade reasons, and hundreds of strategy iterations.

Stack

Languages, services, data sources, and operating pieces behind the build.

PythonWebSocketsCLI toolsExecution engineMarket data

Code Proof

What The Build Actually Contains

LOC

60k+

Source files

116

Runtime

Python

Guard

Risk caps

Product proof

Execution guard

15m+ market automation

Prototype

Cap

$20

Iterations

100s

Mode

Guarded

Freshness, edge, bankroll cap, no-trade reasons, and hundreds of strategy iterations.

Implementation

Code Behind The Surface

Guard before execution

py

The core move behind the product surface.

if not ws_snapshot.is_fresh(max_age_seconds=2):
    return skip("stale market data")

stake = min(bankroll_fraction(edge), DIRECTIONAL_CAP_USD)
if stake < MIN_TRADE_USD:
    return skip("edge too small")

executor.place_order(market_id, side, stake)

Product Model

ts

The useful answer has to be modeled before the UI can make it obvious.

type ProductSurface = {
  input: "Prediction markets";
  signal: "Can an automated prediction-market system stay disciplined when the market window is";
  proof: string[];
};

const surface: ProductSurface = {
  input: "Prediction markets",
  signal: "Freshness, edge, bankroll cap, no-trade reasons, and hundreds of strategy iterations",
  proof: [
  "15-minute and short-window market monitoring",
  "Execution sizing guardrails",
  "WebSocket freshness checks",
  "Manual trade script"
],
};

Hard Part

ts

Every build has a constraint: data quality, workflow shape, trust, speed, or operational risk.

const constraint = {
  project: "Polybot",
  status: "Prototype",
  category: "Workflow solution",
  hardPart: "The product lesson is the structure required to make automation behave under pressure: limits, fallbacks, obse...",
};

shipSurface(constraint);

Project Logic

Why This Exists

The point is not to show another screen. It is to show the gap, the build constraint, and the proof of work.

Mission

Can an automated prediction-market system stay disciplined when the market window is short, noisy, and execution mistakes compound fast?

Prediction markets create a strange workflow: the opportunity is brief, the data moves quickly, and a bad execution rule can do more damage than a bad thesis. Polybot started around 15-minute markets and became a long-running iteration system for edge, freshness, sizing, no-trade rules, and rollback discipline.

Build

What Had To Work

I built a Python system that watches markets, evaluates directional opportunities, sizes bets, routes execution through strict risk caps and timing guards, and keeps evolving as real market behavior exposes new failure modes.

Why It Matters

15m+ market automation

Turns fast crypto-market movement into an inspectable trade/skip decision with guardrails.

Hard Parts

Find An Edge Without Forcing A Trade

The mission was not constant execution. It was finding exploitable movement in Polymarket crypto markets, then having enough discipline to skip when the signal was stale, weak, or structurally unsafe.

Short Windows Punish Bad Assumptions

The system started around 15-minute markets, where timing, WebSocket freshness, price movement, and bankroll caps matter more than a pretty prediction.

Iteration Became The Product

Hundreds of commits hardened the rules: no-trade reasons, rollback points, manual execution paths, cap changes, and strategy variants built from what live markets exposed.

Decisions

Treat stale market data as a hard stop, not a warning.
Keep bankroll caps explicit so a good thesis cannot become a bad execution.
Log no-trade reasons so skipped trades are inspectable, not invisible.
Iterate against real market behavior instead of pretending the first strategy was final.

Next Move

I would separate strategy simulation from execution, add full replay logs, and build a dashboard that makes every automated decision inspectable after the fact.

Tell Me About Your Project

Bring Me The Bottleneck.
I’ll Build The Answer.

Tell me what people are trying to do, where the current path breaks, and what kind of useful answer should exist.

Market Gap

Demand exists, but the answer is missing.

Workflow Drag

The work is still too manual, slow, or scattered.

Product Wedge

A small surface could prove the larger opportunity.

LinkedIn

Quick Note