Using BLEEEP

BLEEEP’s unifying category is Verifiable Trading, not Prop Trading alone.

BLEEEP Agent: build your edge. Agent helps users research, structure, test, and operate trading ideas. Its principal artifact is a Strategy Validation Record for one frozen strategy version.

BLEEEP Prop: prove your discipline. Prop tests whether a registered trader or eligible AI agent version can meet a predefined net-performance standard while following the Challenge’s trading, risk, evidence, and operating rules. Its principal artifact is a Prop Challenge Result.

Eligible BLEEEP Agent records serve as verifiable work experience for traders and registered AI agent versions in Prop. They document prior registered validation and operating evidence rather than functioning as admission credentials. An Agent record is treated as attributable work experience only when its association with the relevant trader, creator, or accountable AI operator is established under the applicable rules. Admission, Challenge requirements, and final qualification remain governed by those rules.

BLEEEP Agent helps traders build better trading intelligence. BLEEEP Prop gives eligible traders and AI agents a transparent way to demonstrate how they operate. Together, they express BLEEEP’s broader mission: making trading intelligence verifiable.

BLEEEP keeps the resulting claims separate. A strategy GO does not by itself constitute a Marketplace listing, Prop PASS, execution authorization, or capital entitlement. A Marketplace subscription grants only its stated access entitlement. A Prop PASS is a scoped qualification record, not a guarantee of capital.

BLEEEP Agent

BLEEEP Agent is a strategy-development workbench rather than a performance leaderboard. Users control the strategy submitted for evaluation, while a public, versioned Validation Standard defines the evaluation criteria that equivalent submissions must meet. BLEEEPY is the conversational interface that translates instructions into an inspectable BleeepSpec.

What users do

• Build an inspectable specification. A user can describe an idea in plain language, review the compiled BleeepSpec, edit every field, or write the specification directly. The frozen specification, not the chat transcript, is the evaluation source of truth.
• Validate before deployment. The registered strategy version receives GO, NO_GO, or INSUFFICIENT with the supporting metrics. Revising the logic creates a new version; it does not rewrite the completed run.
• Control the strategy. The user selects markets, conditions, parameters, sizing, and risk limits. The user also remains responsible for securing the rights required to use any incorporated material.
• Create a separate forward paper record. A historical verdict is followed by evidence using outcomes that were unavailable when the verdict was issued.
• Authorize deliberately. Every live order routed by BLEEEP requires current eligibility and a human authorization decision. The account owner or another authorized principal may approve one order or establish a revocable, time-bounded execution mandate for a defined strategy version, mode, account, venue, market, and risk scope. The Safety Vault and venue controls remain binding in either case.
• Protect private logic. A user may keep strategy logic private from the public while disclosing the version, standard, metrics, verdict, and proof material required for the registered evaluation.

The dashboard presents current paper and live-execution status separately, exposes validation metrics and the scoped NO-GO Archive, and shows the actual proof, anchor, forward-stream, and execution-mandate state for each registered version.

Agent venue availability follows its own release path. The product begins with Polymarket prediction markets and may extend to supported onchain perpetual venues such as Lighter. A venue appears in the product only after its execution, evidence, authorization, and availability requirements are met.

Evidence boundaries

BLEEEP does not claim that proof makes a strategy safe. Its objective is to make the evidence behind a deployment decision more inspectable. A registered strategy is evaluated under criteria fixed before the result, unsuccessful registered versions remain in the denominator, and later paper or live evidence is not silently merged with the historical backtest.

The validation gate targets common causes of overstated performance: multiple testing, look-ahead, regime concentration, fragile assumptions, unrealistic fills, omitted costs, and performance that disappears outside the fitting window. A surviving strategy remains uncertain, but its record is more informative than a return screenshot detached from its method and failed variants.

Preset strategies

Presets are editable BleeepSpec templates for approaches such as trend following, mean reversion, momentum, breakout, volatility-based trading, and conservative risk management. They lower the cost of starting without changing the applicable validation bar. A preset can still receive NO_GO or INSUFFICIENT, and that result remains useful evidence.

Discovery module

The discovery module turns unusual volume, funding rates, basis, sentiment, news, or onchain activity into registered hypotheses for testing. It does not publish a bare confidence score as a recommendation. Each eligible hypothesis requires a defined outcome, applicable commitment timing, disclosed scoring rule, and registered result.

Next: System layers shows how validation, execution, proof, and disclosure are separated.