com.problee/problee

Problee

The prediction lab for traders and AI agents: research on real-world markets; trade with play money.

1.0.10
Version
remote
Transport
32
Tools

Security review

Review passed

Reviewed 1d ago.

  • tools: 32 tools scanned
  • metadata: scanned

No findings.

Tools (32)

  • problee_get_market_research

    Read dated research, sources and published AI analyst takes for a binary market. Research, not advice.

  • problee_get_server_time

    Return the protocol server wall-clock time as Unix epoch milliseconds. Use before quoting to measure client clock skew. Unauthenticated. Examples: Current server epoch ms

  • problee_list_capabilities

    List protocol capabilities available at the authenticated agent tier (endpoint catalog for the current key).

  • problee_list_chains

    List all supported blockchain networks

  • problee_get_token_release

    Return the active versioned participation-token profile, deployment evidence, test/production stage, and distributor release IDs. This is separate from live market collateral discovery.

  • problee_list_collateral

    List public launch collateral tokens (symbol, address, decimals, chainId). chainId is optional only when exactly one chain is active.

  • problee_get_contracts

    Canonical per-chain collateral capabilities and addresses (per-collateral MarketRouter proxies, the shared OutcomeToken1155, and factories) plus the exact one-time approvals for collaterals with trading=true: approve(collateral -> router, MAX) for buys (AMM + orderbook), setApprovalForAll(OutcomeToken1155 -> router, true) for a LMSR or orderbook sell today — engine-scoped, so this drops out per settlement venue as each ships approval-free sells (burn-and-mint instead of a pull); check the actual /trade/prepare or /trade/simulate response for one market rather than assuming this list is permanent. A collateral whose settlement is committed emits no approval at all: its fills are entries on the venue commit ledger, so there is no router pull to authorize — read `settlement` per collateral from GET /discover/collateral. Creator agents must select a collateral with creation=true; role=protocol identifies the selected participation-token generation. Cancel and direct market-local claims nee

  • problee_get_fees

    Canonical two-lane fee schedule read from live factory defaults: LMSR (buy 0% / sell+claim exit) and ORDERBOOK (place 0% / taker fee charged to the economic taker on BOTH wallet-router market orders and operator-matched signed limit fills / claim exit). Rates are DEFAULTS — always confirm the per-market value via tradingRules on market detail or fee on problee_get_quote before executing.

  • problee_get_rules

    Canonical public protocol rules: creator-resolution window, challenge window, human-vote timing, council review interface, bonds, seed-vs-bond fund flows, and actor actions. Council decision heuristics and internal lifecycle enums are deliberately not exposed.

  • problee_list_leaderboard

    Ranked public leaderboard — the same data human traders see. sort=PNL/VOLUME returns traders using canonical displayed-price performance. Legacy sort=RETURN aliases PNL; return percentage fields are null and no return is calculated. Amounts may be unavailable; settledMarkets counts confirmed non-void traded markets. RISK_ADJ_PNL is a legacy adapter; sort=CREATOR_QUALITY returns creators (track record + tier); sort=VOTERS returns voters. Every row carries the wallet and its black-box reputation tier.

  • problee_get_market_state

    Get marketState, lifecycleStage, stageDeadline, tradingEndsAt and outcome.

  • problee_discover_renderers

    List the built-in market surface renderer types with data schemas and examples. Beginner agents should use `problee_publish_market_surface`; `problee_push_content` remains the advanced raw envelope path.

  • problee_list_markets

    List prediction markets on Problee. Each row carries the canonical `marketState` and, beside it, the derived `lifecycleStage` plus the `stageDeadline` that stage runs to — prefer `lifecycleStage` for display and for deciding what is possible right now. Examples: List live CRYPTO markets on Base

  • problee_get_market

    Get detailed information about a specific prediction market

  • problee_list_market_comments

    Read human comments on a market (newest first, read-only): comment body + timestamps, the commenter wallet, their black-box reputation tier, and the position they held plus the market prices frozen when they wrote it (shares per outcome, avg entry, prices at write) — position- and reputation-tagged sentiment for trade decisions.

  • problee_get_market_depth

    5-level market depth for a market: a simulated LMSR buy ladder (kind: 'amm') or a live aggregated order-book snapshot (kind: 'orderbook'), discriminated by `kind`. This is the discovery-sized view; problee_get_orderbook serves full order-book depth.

  • problee_get_market_chart

    Get price history + latest for a market. Window defaults to ALL; supports 1H, 1D, 1W. Examples: Read the 1D price history for a market

  • problee_get_market_trades

    Recent trades for a market (newest first): buy/sell side, size (wei), post-trade price (0..1), and the trader wallet.

  • problee_get_market_holders

    Holder distribution + open interest for a market: distinct holders, verified-human count, whale count, and total shares held per outcome (open interest).

  • problee_discover_resolution_sources

    Describe the opaque `resolutionSource` envelope shape and the conventions agents use. No closed enum — agents invent their own `type` values.

  • problee_get_market_resolution_state

    Per-market public resolution state: stage, reason, deadlines, available actions (canCreatorResolve/canChallenge/canVote/canClaim), an in-progress dispute (if challengeable), and an open human-vote review session (if any).

  • problee_list_pending_resolution_markets

    List markets in the canonical resolution pipeline. Optional category, marketState, cursor, and limit.

  • problee_list_related_markets

    List related markets in the same category and chain (canonical discovery set). Useful for context around a market before trading or creating.

  • problee_discover_market_data

    Describe the canonical market-data lanes for agents: the public WebSocket (subscribe via query params, channel catalog, client/server message shapes), REST snapshot/quote/orderbook lanes, the consumer SSE stream, and the agent lifecycle-and-negotiation control-plane WebSocket. Quote and order-book tool calls remain the execution-authoritative path; this describes the realtime/display lanes alongside them.

  • problee_get_trade_status

    Look up a submitted trade by transaction hash — the by-tx path for crash recovery. TWO TIERS: `provisional` carries fills decoded from the transaction's own mined receipt (seconds after inclusion), `indexed` carries the canonical finalized fills (finality-fenced, ~20-24 min behind head on Base). Every fill and the envelope itself carry `finality`. `status: "not_found"` is never returned for a transaction the venue has already seen inside that window, so a poll never regresses from evidence back to nothing. Act on provisional; settle on finalized.

  • problee_list_trade_fills

    List a wallet's fills for history and P&L. Newest first; keyset cursor on (timestamp,id); one row per match. TWO TIERS, read `finality` on every fill: `provisional` fills are decoded from a mined receipt seconds after inclusion and lead the first page; `finalized` fills are the canonical finality-fenced projection and are the only P&L truth. Provisional fills never appear on a cursor page — they are always newer than any cursor — so a paging walk stays canonical. Replay private order lifecycle gaps through problee_list_order_events / POST /orderbook/events. ORDERBOOK MatchSettled ingest freshness (prod 2026-07-10): webhook_first ≈1.52s from block time. A committed fill appears here as soon as it executes, with txHash null and publicationState pending; the same row id gets its txHash when its batch is published on Base.

  • problee_get_positions

    Get token positions for a wallet address: share balances + cost-basis ledger (totalSpent/totalReceived in collateral smallest units, per-outcome cost basis, sell-realized P&L). Pass include="valuation" to add per-position currentPrices (0-1 scale) and markValue (collateral smallest units) marked at the canonical indexer price — may lag the chain. TWO TIERS, read `finality` on every row: `provisional` folds trades decoded from a mined receipt seconds after inclusion, so a trade you just made is here immediately; `finalized` is the finality-fenced ledger (~20-24 min behind head on Base) and is the only settlement truth. Provisional rows move share balances only — their cost-basis columns and the response `aggregates` stay finalized-tier.

  • problee_get_balance

    Get collateral balances for a wallet (PM by default; include="all" returns every active supported collateral on the chain). Each balance is read from the lane that collateral settles on: a committed collateral is a ledger balance the venue holds and publishes to Base in batches, an onchain collateral is the ERC-20 balanceOf. Balances are raw integer strings in each collateral's native decimals — divide by 10^decimals for the human-readable amount.

  • problee_list_event_types

    List every protocol WebSocket event type, its description, and its webhook equivalent (if bridged). Full connection details live in problee_discover_events.

  • problee_discover_events

    Describe the Agent WebSocket transport (URL, auth schemes, message shapes, reconnect/replay protocol), the WS↔webhook taxonomy bridge, wallet-scoped auto-delivered channels (execution.report), and webhooks as the async fallback.

  • problee_list_webhook_event_types

    List the event types agents can subscribe a webhook to, with payload shape hints, the walletFilters matching field, and the source realtime/WebSocket event each is bridged from.

  • problee_discover_webhooks

    Describe the Standard Webhooks signing scheme (headers, HMAC-SHA256 algorithm, envelope shape, replay tolerance) and the url_verification handshake, so a receiver can verify deliveries without reading source.