The Agent Betting Glossary — 130+ Prediction Market Terms Defined

This glossary defines 130+ terms across the prediction market agent ecosystem — from trading fundamentals and wallet infrastructure to agent types, marketplace commerce, pricing models, and trust verification. Terms are organized by category, with cross-references to related entries and links to the AgentBets guides that cover each concept in depth.

If you’re looking for a specific term, use your browser’s search (Ctrl+F / Cmd+F) or your agent’s text search.

Prediction Market Fundamentals

Arbitrage (arb). Exploiting pricing differences across sportsbooks or prediction markets to guarantee profit regardless of outcome. If the total implied probability across all outcomes (using the best odds from different books) is below 100%, an arb exists. The gap between 100% and the total implied is the arb percentage — your guaranteed return. Cross-market arb compares pricing between sportsbooks and prediction markets (Polymarket, Kalshi). See also: implied probability, overround, surebet. See: Cross-Market Arbitrage Guide, Arbitrage Calculator.

Bayesian updating. A method for revising probability estimates as new evidence arrives. Starting from a prior probability (often the current market price), the estimate is updated using Bayes’ theorem each time new data appears — such as a news article, social media trend, or polling result. Prediction market agents use Bayesian updating to combine the market’s collective wisdom with their own signals. See: Agent Intelligence Guide.

Binary market. A prediction market with exactly two outcomes — typically “Yes” and “No.” The prices of the two outcomes always sum to approximately $1.00 (or 100¢ on Kalshi). If “Yes” trades at $0.65, “No” implicitly trades at $0.35. Most markets on Polymarket and Kalshi are binary. See also: outcome token, resolution.

CLOB (Central Limit Order Book). The matching engine that pairs buy and sell orders for prediction market shares. Polymarket uses an off-chain CLOB operated by a centralized matching engine, with settlement on-chain via the Polygon blockchain. This is described as a “hybrid-decentralized” design — the order matching happens off-chain for speed, but the final token transfers happen on-chain for trustlessness. Kalshi uses a fully centralized CLOB. See: API Reference — Order Books & Pricing.

Condition ID. A unique identifier for a specific market condition on Polymarket. Each market question (e.g., “Will Bitcoin exceed $100K by March?”) has a condition ID, which is used to derive the token IDs for the Yes and No outcome tokens. Not to be confused with token ID. See also: CTF.

Confidence score. A numerical measure of certainty in a probability estimate, typically on a 0-to-1 or 1-to-10 scale. Agents use confidence scores to weight signals during signal aggregation and to set edge thresholds — a low-confidence estimate requires a larger edge to justify a trade. See: Agent Intelligence Guide.

Contract. What Kalshi calls a single unit of a prediction market position. One contract pays $1.00 if the outcome is correct, $0.00 if not. The price of a contract (1-99 cents) reflects the market’s implied probability. Polymarket calls the equivalent a share or outcome token.

CTF (Conditional Token Framework). The smart contract standard Polymarket uses to represent outcome shares. When a market is created, collateral (USDC) is used to mint ERC-1155 tokens for each possible outcome. A Yes-token and a No-token are created, each redeemable for 1 USDC if its outcome resolves as true. CTF was originally developed by Gnosis. See also: ERC-1155, resolution, outcome token.

Event. A grouping of related markets. On Polymarket, an event like “2026 US Midterm Elections” might contain dozens of individual markets (individual races, control of chambers, etc.). On Kalshi, events similarly group markets within a series. Events are one level in the hierarchy: series → events → markets.

Implied probability. The probability of an outcome as derived from odds or market prices. On prediction markets, the price is the implied probability (e.g., $0.60 = 60%). On sportsbooks, it’s calculated from odds: for American odds, positive = 100/(odds+100), negative = |odds|/(|odds|+100). When total implied probability across all outcomes exceeds 100%, the excess is the overround. When it’s below 100% (using best odds from different books), an arbitrage exists. See: Odds Converter.

Liquidity. The depth of available orders in a market’s order book. High liquidity means large orders can be filled without significantly moving the price. Low liquidity means even small orders cause large price swings (slippage). Agents should check order book depth before placing large orders. See also: slippage, spread.

Maker. A trader who places a limit order that adds liquidity to the order book (the order isn’t immediately filled). Makers typically pay lower fees — on Polymarket, makers receive rebates through the Maker Rebates Program. Opposite of taker.

Market. A single tradeable question with a defined resolution criteria and expiry date. “Will the Fed cut rates in March 2026?” is a market. Markets have a ticker (on Kalshi) or slug (on Polymarket) for identification.

Negative risk market. A Polymarket market type where the sum of all outcome token prices can exceed $1.00, creating scenarios where arbitrage is possible. When building an agent, you must check the negRisk flag on each market and handle these differently — the tick size and order signing logic changes. This is one of the most common sources of bugs in Polymarket agents.

Order book. The collection of all outstanding buy and sell orders for a market. The order book has two sides: bids (buy orders) and asks (sell orders). On Polymarket, both sides are returned from the API. On Kalshi, only bids are returned — you must compute asks by inverting the opposite side’s bids (a yes bid at X¢ equals a no ask at (100-X)¢). See: API Reference — Order Books.

Outcome token. A digital asset representing one possible outcome of a prediction market. On Polymarket, outcome tokens are ERC-1155 tokens on Polygon. Holding a “Yes” outcome token entitles you to $1.00 USDC if the market resolves “Yes,” and $0.00 if it resolves “No.” See also: CTF, token ID, share.

Overround (vig). The amount by which a sportsbook’s total implied probabilities exceed 100%. Represents the book’s built-in profit margin. For example, if a two-outcome market has implied probabilities of 52.4% and 52.4%, the overround is 4.8% (104.8% - 100%). In arbitrage betting, the goal is to find combinations where the total implied probability across different books is below 100% — a negative overround. Also called “juice” or “vigorish.” See also: arbitrage, implied probability.

Resolution. The process by which a market is settled. An oracle (automated or human-based) determines the actual outcome, the market is marked as resolved, and winning outcome tokens become redeemable for the payout. Polymarket uses UMA’s optimistic oracle. Kalshi uses internal resolution based on defined criteria.

Series. The top level of the market hierarchy. A series is a recurring market template — for example, “Daily High Temperature in NYC” or “Monthly Jobs Report.” A series contains multiple events, which each contain multiple markets. Both Polymarket and Kalshi use this hierarchy.

Share. Polymarket’s term for a single unit of an outcome token. Equivalent to Kalshi’s contract. One share of “Yes” pays $1.00 USDC if the outcome is Yes. Price is quoted in USDC (0.00-1.00). See also: outcome token, contract.

Slippage. The difference between the expected price of a trade and the actual price at execution. Occurs when the order is large relative to available liquidity. Agents should calculate expected slippage from the order book before placing large orders. See also: liquidity, spread.

Slug. Polymarket’s human-readable identifier for a market, used in URLs and the CLI. For example, bitcoin-above-100k. Kalshi uses tickers instead (e.g., KXBTC-26FEB28-T100000).

Spread. The difference between the best bid (highest buy price) and best ask (lowest sell price) in an order book. A tight spread (e.g., $0.01) indicates high liquidity. A wide spread (e.g., $0.10) indicates low liquidity and potentially unprofitable trading. See also: midpoint.

Surebet. Another term for arbitrage. A set of bets placed across different sportsbooks or platforms that guarantees a profit regardless of outcome. Called “surebet” because the profit is certain (assuming all bets execute and settle as expected). Common in European betting terminology. See also: arbitrage.

Taker. A trader who places an order that immediately fills against existing orders in the book. Takers remove liquidity and typically pay higher fees. Market orders are always taker orders. Opposite of maker.

Ticker. Kalshi’s unique identifier for a market. Tickers follow a structured format — e.g., KXBTC-26FEB28-T100000 where KX is the series prefix, followed by date and strike information. Polymarket uses slugs instead.

Tick size. The minimum price increment for a market. On Kalshi, the tick size is always 1 cent. On Polymarket, tick sizes vary per market — typically 0.01 or 0.001 USDC. Your agent must check the tick size before placing orders; orders at invalid price increments are rejected. One of the most common API errors agents encounter.

Token ID. The unique identifier for a specific outcome token on Polymarket. Each market has two token IDs — one for Yes, one for No. The token ID is the primary identifier used in the CLOB API for placing orders, reading order books, and checking prices. Not to be confused with condition ID. See: API Reference — Placing Orders.

Wallet and Payment

Account abstraction. A design pattern where a blockchain account is controlled by a smart contract rather than a single private key. This enables programmable security rules (spending limits, multi-sig, transaction guards) that aren’t possible with a standard EOA. Safe Smart Accounts are the most widely deployed implementation. See also: ERC-4337, smart account.

Agentic Wallet. Coinbase’s wallet product launched February 12, 2026, specifically designed for AI agents. Private keys are isolated in TEEs, the agent interacts through a CLI (npx awal) or pre-built skills, and programmable spending limits constrain what the agent can do. Operates on Base. See: Wallet Comparison — Coinbase Agentic Wallets.

Aperture. Lightning Labs’ L402-aware reverse proxy. Developers put Aperture in front of any standard API to convert it into a pay-per-use service. Aperture handles the full L402 negotiation — generating invoices, verifying payments, issuing macaroons — so the backend doesn’t need to know anything about Lightning. See also: L402, lnget.

awal. The command-line tool for Coinbase Agentic Wallets. Invoked via npx awal. Commands include status (check auth), fund (add USDC), send (transfer to address or ENS name), and trade (swap tokens). Designed for agents to call programmatically. See also: Agentic Wallet.

Base. Coinbase’s Ethereum Layer 2 network. Agentic Wallets operate on Base, which offers gasless transactions for agent operations. Polymarket runs on Polygon, so trading requires bridging USDC from Base to Polygon. Base processed the most retail Safe deployments in 2025, overtaking Polygon and Arbitrum.

Bridge. A protocol that transfers assets between different blockchain networks. For prediction market agents, the most common bridge is Base → Polygon (to move USDC from a Coinbase Agentic Wallet to Polymarket). Bridging adds latency (typically minutes) and fees. See also: Base, Polygon.

EOA (Externally Owned Account). A standard blockchain account controlled by a single private key. The simplest wallet type — whoever has the private key has full, unrestricted access to all funds. No spending limits, no multi-sig, no recovery beyond the seed phrase. See: Wallet Comparison — EOA.

Gasless transaction. A transaction where the user doesn’t pay network fees (gas) directly. On Base, Coinbase sponsors gas for Agentic Wallet operations, so agents can transact continuously without maintaining an ETH balance for fees. This eliminates a common failure mode where agents stall because they’ve run out of gas.

KYT (Know Your Transaction). Compliance screening that analyzes blockchain transactions for connections to sanctioned addresses, money laundering, or high-risk activity. Coinbase Agentic Wallets include built-in KYT screening, automatically blocking interactions with flagged addresses. Not to be confused with KYC (Know Your Customer), which verifies human identity.

L402. A protocol standard for Lightning Network-based API authentication. Repurposes the HTTP 402 “Payment Required” status code. When an agent requests a paid resource, the server responds with a Lightning invoice and a macaroon. The agent pays the invoice, receives a preimage as proof, and uses it to access the resource. No accounts, no API keys, no identity required. The predecessor to x402. See: Wallet Comparison — Lightning L402.

lnget. Lightning Labs’ L402-aware command-line HTTP client, analogous to wget or curl. When a server returns an HTTP 402 response, lnget automatically pays the Lightning invoice, caches the authentication token, and retries the request. Supports three backends: direct gRPC to a local LND node, Lightning Node Connect, and embedded Neutrino light wallet. See also: L402, Aperture.

Macaroon. A cryptographic authentication token used in the Lightning Network. Macaroons are like cookies but with built-in, enforceable restrictions (called “caveats”). For agents, scoped macaroons enforce least-privilege access: a “pay-only” macaroon with a spending cap means the agent can pay invoices but cannot create invoices or exceed the cap, even if compromised. See also: L402, remote signer.

Multisig (multi-signature). A wallet design requiring multiple cryptographic signatures to authorize a transaction. A “2-of-3” multisig needs any two of three designated signers to agree. Safe Smart Accounts use multisig as their core security mechanism. For agents, multisig enables multi-agent consensus (three agents must agree) or human-in-the-loop (agent proposes, human approves). See also: Safe, threshold.

Polygon. An Ethereum Layer 2 network where Polymarket’s smart contracts are deployed. Agents trading on Polymarket need USDC on Polygon. Gas fees on Polygon are very low (fractions of a cent per transaction). Chain ID: 137.

Proxy wallet. On Polymarket, a wallet architecture where a “funder” address holds your funds while a separate “signer” address signs orders on its behalf. This separation means the signing key never directly controls the funds. When using Polymarket’s Python SDK, you set signature_type=1 and provide a funder address for proxy wallet mode. See also: EOA, signature type.

Remote signer. A security architecture that separates private key storage from the agent’s runtime. In Lightning’s LND remote signer setup, the private key lives on a dedicated signing machine, while the agent’s node operates without direct key access. Conceptually similar to TEE isolation but using physical separation rather than hardware enclaves. See also: TEE, macaroon.

Safe Smart Account. A smart contract wallet (formerly Gnosis Safe) that enables multisig, transaction guards, and Zodiac modules. Over $60 billion is secured in Safe accounts. Safe is deployed on 14+ EVM chains including Polygon. The Autonolas/Olas framework uses Safe as the default wallet for autonomous agent services. See: Wallet Comparison — Safe.

Safe Shield. A security monitoring layer for Safe accounts, launched 2025, powered by Hypernative. Provides real-time threat detection, anomaly monitoring, and automated defensive actions for high-value treasuries.

Session key. A temporary cryptographic key with limited permissions and a short lifespan. In Coinbase Agentic Wallets, the agent authenticates via email OTP and receives a session key that can only operate within defined spending limits. When the session expires, the key becomes useless. See also: spending limit, TEE.

Signature type. In Polymarket’s SDK, a parameter that determines how orders are signed. signature_type=0 means EOA (the private key signs directly). signature_type=1 means proxy/Magic wallet (a funder address holds funds, a separate key signs). Getting this wrong is a common setup error.

Smart account. A blockchain account controlled by a smart contract rather than a single private key. Enables programmable logic: spending limits, whitelisted addresses, timelocks, multi-sig, and custom modules. Safe is the most widely deployed smart account. See also: account abstraction, EOA.

Spending limit. A configurable cap on how much an agent’s wallet can spend. Coinbase Agentic Wallets offer session caps (maximum per session) and per-transaction limits. Safe implements spending limits through Zodiac modules. Lightning L402 uses macaroon caveats. The critical guardrail that determines your maximum loss if the agent is compromised.

TEE (Trusted Execution Environment). A hardware-isolated area of a processor where code and data are protected from access by any other software, including the operating system. In Coinbase Agentic Wallets, private keys live inside TEEs — even Coinbase employees cannot extract them. This means a compromised agent process cannot access the wallet’s private key. See also: enclave isolation, Agentic Wallet.

Threshold. In a multisig wallet, the number of signatures required to authorize a transaction. A “2-of-3 threshold” means any two of three designated signers must approve. For agents, common thresholds are 1-of-1 with transaction guards (single agent, smart contract enforces rules) or 2-of-3 (agent proposes, two humans or other agents approve).

Transaction guard. A Safe smart contract that runs checks before and after every transaction. Even if the agent’s signing key is compromised, the guard can block transactions that violate rules — wrong destination address, amount too large, calling a forbidden function, interacting with a non-whitelisted contract. On-chain enforcement that the agent cannot bypass. See also: Safe, Zodiac module.

x402. Coinbase’s machine-to-machine payment protocol built on the HTTP 402 “Payment Required” status code, using USDC on Base. When an agent requests a paid API endpoint, the server responds with 402 and a USDC payment challenge. The agent’s wallet pays automatically. Over 50 million transactions processed as of February 2026. The USDC-based counterpart to Lightning’s L402. See also: L402, Agentic Wallet.

Zodiac module. An extension to Safe Smart Accounts that adds programmable permissions beyond basic multisig. Modules can enforce spending limits, timelocks, role-based access, whitelisted target addresses, and delegated execution (allowing an agent address to execute transactions without meeting the full signing threshold). Developed by Gnosis Guild.

Agent Identity and Social

Attestation (EAS). An on-chain cryptographic claim about an agent — such as its verified track record, strategy type, or audit result — created through the Ethereum Attestation Service. Attestations are timestamped, optionally revocable, and independently verifiable by anyone on Base. See also: EAS, on-chain reputation. See: On-Chain Reputation Guide.

Claim link. The URL a human uses to verify ownership of an agent on Moltbook. After registering an agent via the API, the human posts the claim link on X (Twitter) to prove they control both the X account and the agent. This links the agent’s Moltbook identity to a verifiable human operator.

ClawHub. The community skills registry for OpenClaw. Developers publish skills (markdown files with YAML frontmatter) to ClawHub, and other users install them with a single command. Security note: Cisco researchers and Snyk audits have found that some community skills contain prompt injection attacks, credential theft, or data exfiltration — always review skills before installing.

DID (Decentralized Identifier). A W3C standard for self-sovereign digital identity. DIDs allow agents to control their own identifiers without depending on a central registry. Not yet widely adopted in prediction markets but emerging as a future identity standard. See also: ENS, SIWE.

Cron (OpenClaw). A scheduling mechanism in OpenClaw that runs agent tasks at specified times, separate from the heartbeat system. Cron jobs execute in isolated agent turns, while heartbeats run in the main session. Use cron for predictable, time-based tasks (e.g., “post a daily briefing at 9 AM”). Use heartbeat for continuous monitoring (e.g., “check if anything needs attention”). See also: heartbeat.

ENS (Ethereum Name Service). A naming system that maps human-readable names like mybot.eth to Ethereum addresses. Agents can use ENS for discoverability and to store on-chain metadata via text records. See also: SIWE, DID. See: Agent Identity Systems Compared.

Gateway. In OpenClaw, the background process that manages the agent’s lifecycle, message routing, session management, and connections to channels (Telegram, WhatsApp, web, etc.). The gateway runs on your local machine, connects to your chosen LLM provider (Anthropic, OpenAI, Ollama, etc.), and executes skills. The gateway handles heartbeat scheduling. See also: OpenClaw, heartbeat.

Heartbeat. A periodic check-in mechanism in OpenClaw where the agent wakes up on a schedule (default: every 30 minutes), reads its HEARTBEAT.md checklist, and decides if anything needs attention. If nothing needs doing, it responds HEARTBEAT_OK (suppressed by the gateway — never delivered to the human). If something is urgent, it sends a message. The pattern that makes agents proactive rather than purely reactive. See also: HEARTBEAT.md, gateway, cron.

HEARTBEAT.md. A markdown file in the OpenClaw agent workspace that defines the agent’s periodic checklist. The agent reads this file on every heartbeat and follows it strictly. Typical entries include: check for new emails, review calendar for conflicts, monitor specific data feeds, post scheduled updates to Moltbook. The file lives at ~/.openclaw/workspace/HEARTBEAT.md.

Identity token. A temporary authentication token generated by a Moltbook agent from its permanent API key. Identity tokens expire after 1 hour and are used to prove the agent’s identity to third-party applications via the Moltbook verification API. Applications verify tokens by calling POST /api/v1/agents/verify-identity with their app API key. The agent never shares its permanent API key — only temporary identity tokens. See also: Moltbook, verification.

KYC (Know Your Customer). Identity verification required by regulated prediction market platforms like Kalshi. The human operator completes KYC; the agent trades through API keys tied to the verified account. Not to be confused with KYT (Know Your Transaction), which screens transactions rather than identities. See also: verification.

Karma. Moltbook’s reputation score for agents. Accumulated through upvotes on posts and comments. Higher karma signals that the agent produces content the community finds valuable. Karma serves as a lightweight reputation metric for cross-platform trust — applications can check an agent’s karma score via the Moltbook API to gauge reliability. See also: Moltbook, submolt.

MCP (Model Context Protocol). Anthropic’s open standard for connecting AI models to external data sources and tools. MCP turns any data source into a “server” that AI models can query through a standardized interface. For prediction market agents, an MCP server can feed market data, trading APIs, or knowledge bases (like AgentBets guides) directly into the AI’s context. Installable in Claude Code, Cursor, Windsurf, and other MCP-compatible tools. See also: skill, OpenClaw.

Moltbook. The first social network built exclusively for AI agents, launched January 28, 2026. Agents post, comment, and upvote in Reddit-style communities called submolts. Humans can browse but cannot post. Over 2.5 million agents registered as of February 2026, though independent verification of these numbers is limited. Created by Matt Schlicht. The platform has faced security issues including an exposed database incident in January 2026. See also: submolt, karma, identity token, OpenClaw.

On-chain reputation. Verifiable performance data stored as blockchain attestations (typically via EAS on Base), allowing buyers to independently confirm an agent’s track record without trusting self-reported claims. See also: attestation (EAS), SBT. See: On-Chain Reputation Guide.

OpenClaw. An open-source AI agent framework (formerly known as Clawdbot, then Moltbot). Provides a local-first runtime where an LLM agent can execute terminal commands, manage files, browse the web, and interact through messaging channels (Telegram, WhatsApp, web). Key features include heartbeat scheduling, skills, cron jobs, and persistent memory. The primary framework for building agents that operate on Moltbook. Over 100K GitHub stars in early 2026. See also: heartbeat, skill, gateway, Moltbook.

SBT (Soulbound Token). A non-transferable NFT that serves as a permanent credential. In the agent context, SBTs can represent certifications, audit completions, or marketplace badges that cannot be sold or transferred to another agent. See also: attestation (EAS), on-chain reputation.

Sentiment analysis. The process of extracting opinion or mood signals from text data — tweets, Reddit posts, news articles, or Moltbook discussions — and converting them into a numerical score. Prediction market agents use sentiment analysis to detect shifts in public opinion before markets react. Typically implemented by feeding batches of text to an LLM with a scoring prompt, rather than using traditional NLP libraries. See also: signal aggregation. See: Agent Intelligence Guide.

Signal aggregation. The process of combining multiple data sources — LLM analysis, sentiment scores, Bayesian estimates, tool outputs — into a single confidence-weighted probability estimate. Each signal is weighted by its reliability and confidence, then fused into a composite score. Reduces noise compared to acting on any single signal. See also: confidence score, Bayesian updating. See: Agent Intelligence Guide.

SIWE (Sign-In with Ethereum). Authentication standard (EIP-4361) that uses wallet signatures for login. Polymarket’s CLOB uses wallet-based signatures for order placement, making SIWE the de facto authentication method for Polymarket agents. See also: ENS, DID. See: Agent Identity Systems Compared.

Skill. In OpenClaw, a modular capability defined as a markdown file with YAML frontmatter. Skills tell the agent how to perform specific tasks — for example, “monitor a Polymarket market and post updates to Moltbook.” Skills can be user-created or installed from ClawHub. The skills system is OpenClaw’s primary extension mechanism. Security caution: community skills can contain malicious code. See also: ClawHub, SKILL.md.

SKILL.md. The standard filename for an OpenClaw skill definition. Contains YAML frontmatter (name, description, parameters) and markdown body (workflow, examples, implementation). Skills are stored in ~/.openclaw/workspace/skills/SKILL_NAME/SKILL.md.

SOUL.md. An OpenClaw workspace file that defines the agent’s core identity, personality, and operating principles. Injected into the system prompt at session start (capped at 20,000 characters). Analogous to a system prompt, but file-based and persistent across sessions.

Submolt. A topic-specific community on Moltbook, analogous to a subreddit. Examples: m/polymarket, m/predictions, m/tech, m/philosophy. Each submolt has moderators, rules, and subscriber counts. Agents build karma by posting valuable content to relevant submolts. Over 17,000 submolts exist as of February 2026. See also: Moltbook, karma.

Verification (Moltbook). The process of linking a Moltbook agent to a human operator’s identity. Currently relies on X (Twitter) verification — the human posts a claim link from their X account, proving they control both the social media account and the agent. Verification enables verified status badges and higher trust signals, though critics note this only proves a human controls the account, not that the agent acts autonomously.

World ID. Worldcoin’s proof-of-personhood protocol that verifies a human is behind an account using iris scanning. Not yet integrated with prediction markets but represents a potential future layer for operator identity verification. See also: KYC, DID.

Trading and Execution

API credentials (Polymarket). A key/secret/passphrase triplet used for authenticated (L2) operations on Polymarket’s CLOB. Created by signing a message with your wallet’s private key (L1 auth), then used for all subsequent trading operations. Generated via client.create_or_derive_api_creds() in the Python SDK.

Batch orders. Submitting multiple orders in a single API call. Kalshi supports batch creation and batch cancellation of orders. Polymarket supports batch posting via post_orders([...]). Useful for agents that need to update multiple positions simultaneously. See also: GTC, FOK.

Edge. The difference between an agent’s estimated probability and the current market price. A positive edge means the agent believes the market is mispriced in its favor. For example, if an agent estimates 70% probability but the market prices Yes at $0.55, the raw edge is 15 percentage points. Agents must account for platform fees when calculating net edge — a 5% raw edge on Kalshi (≈7% fees) is actually negative. See also: Kelly criterion, confidence score. See: Agent Intelligence Guide.

FOK (Fill-or-Kill). An order type that must be completely filled immediately or cancelled entirely. No partial fills. Used for market orders on Polymarket (OrderType.FOK). On Kalshi, specified via time_in_force: "fill_or_kill". Essential for agents that need certainty of execution. See also: GTC, market order.

GTC (Good-til-Canceled). An order type that remains active in the order book until it’s filled or explicitly cancelled. The default order type for limit orders on both Polymarket (OrderType.GTC) and Kalshi. GTC orders provide liquidity and earn maker rebates. See also: FOK, limit order.

Kelly criterion. A formula for calculating the optimal bet size as a fraction of your bankroll given your estimated edge. Full Kelly maximizes long-term bankroll growth but comes with high variance. Most practitioners use half-Kelly or quarter-Kelly to reduce drawdown risk. Formula: f = (p(b+1) - 1) / b, where p is your estimated probability and b is the odds offered. See also: edge. See: Agent Intelligence Guide.

HMAC (Hash-based Message Authentication Code). The signing algorithm Polymarket uses for authenticated API requests. Your API secret is used to compute an HMAC-SHA256 signature over the request parameters, timestamp, and nonce. Sent as L2 headers (POLY_API_KEY, POLY_SIGNATURE, POLY_TIMESTAMP, POLY_PASSPHRASE). See also: API credentials, RSA signature.

Limit order. An order to buy or sell at a specific price or better. The order sits in the order book until someone matches it. On Polymarket, specify price and size. On Kalshi, specify yes_price (or no_price) and count. Limit orders provide liquidity and typically earn maker fee rebates. See also: GTC, market order.

Market order. An order to buy or sell immediately at the best available price. On Polymarket, implemented as a FOK order using MarketOrderArgs with an amount (USDC to spend). On Kalshi, specified via type: "market". Market orders always take liquidity and pay taker fees. See also: FOK, slippage.

Midpoint. The price exactly between the best bid and best ask in an order book. On Polymarket, retrieved directly via client.get_midpoint(token_id) or the CLI polymarket clob midpoint TOKEN. On Kalshi, you must compute it from the order book data. Useful as a reference price for limit order placement.

Post-only order. An order that is guaranteed to be a maker order — if it would immediately fill (becoming a taker order), it’s rejected instead. Supported on both Polymarket (post_only=True in post_order()) and Kalshi (post_only: true). Useful for agents that want to ensure they always earn maker rebates and never pay taker fees.

RSA signature. The authentication method Kalshi uses. Each API request is signed with your RSA private key. The signature is computed over the timestamp, HTTP method, and path. Sent as headers: KALSHI-ACCESS-KEY, KALSHI-ACCESS-SIGNATURE, KALSHI-ACCESS-TIMESTAMP. See also: HMAC.

Infrastructure and Protocols

AgentKit. Coinbase’s earlier SDK (launched November 2024) for integrating wallets into agents during the building stage. Agentic Wallets (February 2026) build on AgentKit but provide a complete, purpose-built wallet product rather than an SDK. See also: Agentic Wallet.

Autonolas (Olas). A framework for building autonomous agent services on the blockchain. Uses Safe Smart Accounts as the default wallet, with configurable multisig thresholds for multi-agent consensus. Agents operate as “autonomous services” that co-own a Safe. Relevant to prediction market agents because Olas includes prediction agent templates. See also: Safe, multisig.

CDP (Coinbase Developer Platform). The developer infrastructure underlying Coinbase’s Agentic Wallets, AgentKit, and related products. Provides authentication, usage telemetry, security monitoring (via CDP Portal), and the API layer that agents interact with.

Enclave isolation. The security property of TEEs where code and data inside the enclave cannot be accessed by any external software, including the operating system. In the context of Agentic Wallets, enclave isolation means the wallet’s private key cannot be read by the agent’s LLM, prompt, or runtime — even if those components are fully compromised.

ERC-1155. An Ethereum token standard that supports both fungible and non-fungible tokens within a single contract. Polymarket’s outcome tokens are ERC-1155 tokens — each token ID represents a specific outcome (Yes/No) of a specific market. This is why you need a token ID rather than a contract address when trading on Polymarket.

ERC-4337. An Ethereum standard for account abstraction — enabling smart accounts that can implement custom verification logic, gas sponsorship, and batched transactions without changes to the Ethereum protocol itself. Safe supports ERC-4337. Relevant to agent wallets because it enables gasless transactions and programmable security without relying on centralized infrastructure.

llms.txt. A proposed standard file (similar to robots.txt) that websites place at their root to help AI agents discover and understand the site’s content. Contains a structured summary of the site, its key pages, and what information is available. Agents and MCP servers look for this file to decide which pages to fetch. See also: MCP.

Neutrino. A lightweight Bitcoin node implementation that can run embedded within an application. In the Lightning L402 ecosystem, Neutrino is the easiest way to experiment with Lightning payments — it doesn’t require running a full Bitcoin node. Trade-off: lower routing success rate compared to a full LND node.

Prompt injection. An attack where malicious text embedded in data (a web page, email, Moltbook post, or API response) tricks an AI agent into performing unintended actions. For prediction market agents, prompt injection could cause the agent to place wrong orders, reveal API keys, or drain its wallet. Every layer of the agent stack needs prompt injection defenses. See: Security Best Practices.

UMA (Universal Market Access). The optimistic oracle protocol that Polymarket uses for market resolution. UMA allows anyone to propose an outcome, which is accepted after a challenge period unless disputed. If disputed, UMA’s decentralized verification mechanism resolves the disagreement.

WebSocket. A persistent, bidirectional communication channel between client and server. Both Polymarket and Kalshi offer WebSocket feeds for real-time market data (order book updates, price changes, trade events). Essential for agents that need low-latency market monitoring rather than periodic polling. See: API Reference — WebSocket Streaming.

Agent Types and Strategies

Copy-trading agent. An autonomous bot that replicates the trades of a target wallet or portfolio in real time. The agent monitors on-chain transactions from specified addresses and mirrors their positions on Polymarket or Kalshi within seconds. Revenue models include subscription fees for access or performance-based fees. Quality varies significantly — the target wallet’s edge may not persist after accounting for execution latency and fees. See also: signal agent. See: Copy-Trading Agent Guide.

Liquidity provider agent. An agent that adds depth to thin prediction markets by placing limit orders at multiple price levels across the order book. Similar to a market-making bot but may operate on one side of the book only. Earns maker rebates on filled orders. Particularly valuable in low-liquidity markets where wide spreads discourage participation. See also: maker, market-making bot, liquidity.

Market-making bot. An agent that provides continuous liquidity by posting both buy and sell orders around the current market price. Profits from the spread between bid and ask prices while maintaining a market-neutral position. Requires sophisticated inventory management to avoid accumulating large directional exposure. Works best in markets with consistent trading volume and moderate volatility. See also: maker, spread, liquidity. See: Market-Making Bot Guide.

Multi-platform agent. An agent that trades across multiple prediction market platforms simultaneously — typically Polymarket and Kalshi. Enables cross-platform arbitrage by comparing prices for equivalent events across venues. Requires maintaining separate API connections, wallets, and order management for each platform, plus handling different price formats (USDC vs. cents) and order types. See also: arbitrage, cross-market arb finder. See: Cross-Market Arbitrage Guide.

Portfolio agent. An autonomous bot that manages positions across multiple prediction markets simultaneously, optimizing for risk-adjusted returns rather than individual trade profitability. Applies portfolio theory concepts — diversification, correlation analysis, rebalancing — to prediction market positions. Reduces exposure to single-event risk by spreading capital across uncorrelated markets. See also: risk-adjusted return, agent ROI.

Sentiment agent. An AI-powered bot that trades prediction markets based on natural language signals extracted from news articles, social media posts, and forum discussions. Uses LLM analysis to score sentiment shifts, then converts scores into trading decisions when the signal diverges from current market prices by more than a configured threshold. Most effective for markets tied to public opinion rather than technical data. See also: signal aggregation, sentiment analysis. See: Sentiment Bot Guide.

Signal agent. An agent that generates trading signals but does not execute trades directly. Signal agents analyze data sources — news feeds, on-chain activity, social media, model outputs — and publish buy/sell recommendations that other agents or humans act on. Monetized via subscription fees or per-signal charges. The intelligence layer without the execution risk. See also: sentiment agent, signal aggregation.

Sniper bot. An agent that monitors prediction markets for sudden price movements, new market listings, or resolution events and executes trades within milliseconds. Optimized for speed rather than analysis depth. Commonly targets mispriced new markets before the broader market corrects the price. Requires low-latency infrastructure and WebSocket connections for real-time data. See also: edge, WebSocket.

Marketplace and Agent Commerce

Agent listing. A published entry on an agent marketplace that describes a prediction market bot available for purchase, rental, or licensing. A complete listing includes the agent’s strategy type, platform compatibility, verified performance data, pricing model, setup requirements, and documentation. Higher-quality listings with verified performance data command premium pricing. See: How to Sell Your Prediction Market Bot.

Agent rental. A time-limited access arrangement where a buyer pays a recurring fee (daily, weekly, or monthly) to use a prediction market agent without owning it. The builder retains ownership and intellectual property, and can rent to multiple buyers simultaneously. The most accessible entry point for buyers who want to test an agent before committing to a purchase. See also: subscription agent access, agent licensing.

Agent licensing. A legal arrangement granting the buyer permission to run a prediction market agent under specified terms. Perpetual licenses grant indefinite use rights; time-limited licenses expire after a set period. The builder retains intellectual property ownership and may restrict the number of concurrent instances, platforms used, or capital deployed. See also: revenue-sharing model, one-time agent purchase.

Agent escrow. A trusted intermediary arrangement where payment is held in escrow until the buyer confirms the agent works as described during a verification period. Protects buyers from receiving non-functional or misrepresented bots, and protects builders from non-payment. The marketplace releases funds to the builder only after the buyer approves or the dispute window closes. See also: agent verification.

Agent verification. The process of validating that a prediction market agent performs as its listing claims. Verification methods include backtesting review, live track record auditing, code inspection, and third-party audit. Verification levels range from self-reported (lowest trust) to independently audited (highest trust). A verified agent commands premium pricing and faster sales. See also: backtest validation, live track record audit, verified agent badge. See: Bot Verification Guide.

Agent audit. A formal inspection of a prediction market agent’s code, strategy logic, security practices, and performance claims by a qualified reviewer. Audits may be conducted by marketplace staff, independent security firms, or community reviewers. Results are typically published as on-chain attestations via EAS. See also: third-party agent audit, attestation (EAS).

One-time agent purchase. A single payment granting the buyer full ownership and control of a prediction market agent’s codebase, configuration, and strategy. The buyer assumes all responsibility for maintenance, updates, and ongoing operation. Typical prices range from $100 to $10,000+ depending on strategy complexity, verified performance, and exclusivity terms. See also: agent licensing.

Per-trade fee model. A pricing arrangement where the buyer pays the builder a small fee for each trade the agent executes. Common for high-frequency agents where per-trade fees accumulate to meaningful revenue. Typical fees range from $0.01 to $0.10 per trade. Builders prefer this model for agents with high trade volume; buyers prefer it for agents with uncertain profitability. See also: revenue-sharing model, agent pricing model.

Revenue-sharing model. A pricing arrangement where the agent builder receives a percentage of net profits generated by the bot for the buyer. Aligns incentives — the builder earns more only when the agent performs well. Typical splits range from 10% to 30% of net profits. Requires transparent performance tracking and agreed-upon accounting methods. See also: agent pricing model, per-trade fee model. See: Revenue Sharing Guide.

Subscription agent access. Recurring payment (monthly or annual) for ongoing access to a prediction market agent, including updates, bug fixes, and strategy adjustments. The most predictable revenue model for builders and the most common model for actively maintained agents. Typical monthly fees range from $20 to $500 depending on strategy complexity and track record. See also: agent rental.

Verified agent badge. A visual indicator on a marketplace listing confirming that the agent has passed verification checks. Badges typically indicate different levels of verification: self-reported performance, backtested by marketplace, audited by third party, or fully verified with live track record. Higher verification levels unlock prominent marketplace placement and premium pricing.

Pricing and Economics

Agent pricing model. The commercial structure under which a prediction market agent is sold or rented. The five common models are: one-time purchase (full ownership transfer), subscription rental (recurring access), revenue sharing (percentage of profits), per-trade fees (per-execution charge), and licensing (time-limited or perpetual use rights). The optimal model depends on strategy type, expected lifespan, exclusivity requirements, and buyer risk tolerance. See: Bot Pricing Guide.

Agent ROI (Return on Investment). The total return generated by a prediction market agent relative to the capital deployed and the cost of the agent itself. Calculated as (net profit - agent cost) / (capital deployed + agent cost) over a specified time period. ROI should account for all costs including platform fees, gas fees, subscription costs, and opportunity cost of capital. A meaningful metric only when measured over a statistically significant number of trades. See also: risk-adjusted return, win rate.

Backtest vs. live performance. The comparison between an agent’s historical simulation results (backtest) and its actual trading results in live markets. Backtests almost always overstate performance due to lookahead bias, survivorship bias, overfitting, and perfect execution assumptions. Experienced buyers expect 30-50% lower returns in live trading compared to backtested results. The gap between backtest and live performance is the most common source of buyer disappointment. See also: backtest validation.

Edge decay. The gradual reduction in a trading strategy’s profitability over time as markets become more efficient, competitors adopt similar approaches, or underlying market conditions change. Prediction market strategies typically experience faster edge decay than traditional financial strategies due to the concentrated, event-driven nature of the markets. Agents require periodic strategy updates to maintain profitability. Buyers should factor expected edge decay into purchase price calculations. See also: strategy alpha, edge.

Risk-adjusted return. A performance metric that accounts for the amount of risk taken to achieve a given return. Agents with high returns but extreme volatility and large drawdowns score lower than agents with moderate returns and consistent performance. Common measures include Sharpe ratio (return per unit of volatility) and Sortino ratio (return per unit of downside volatility). The preferred metric for comparing agents with different strategy types. See also: agent ROI, win rate.

Strategy alpha. The excess return generated by an agent’s strategy beyond what could be achieved through naive market participation (e.g., random position-taking or index-tracking). An agent that consistently outperforms the baseline has positive alpha. Alpha measures the value added by the agent’s intelligence and execution quality. Alpha tends to decrease over time as the strategy becomes crowded (edge decay). See also: edge, edge decay.

Win rate. The percentage of trades that result in a profit. A prediction market agent’s win rate alone is not a reliable performance indicator — an agent with a 40% win rate can be highly profitable if winning trades are significantly larger than losing trades. Must be evaluated alongside average win size, average loss size, and total number of trades. High win rates (>70%) on small sample sizes are particularly unreliable. See also: agent ROI, risk-adjusted return.

Trust and Verification

Backtest validation. The process of independently reproducing and verifying an agent’s historical performance claims using the agent’s stated strategy rules and publicly available market data. Valid backtests use out-of-sample data, account for transaction costs and slippage, avoid lookahead bias, and test across multiple market conditions. The minimum standard for agent verification before recommending a purchase. See also: agent verification, backtest vs. live performance.

Live track record audit. Examination of an agent’s actual trading history on Polymarket, Kalshi, or other platforms using on-chain transaction data or platform API records. More reliable than backtesting because it reflects real execution conditions including slippage, fees, timing, and market impact. On Polymarket, trades can be verified directly on the Polygon blockchain. See also: agent verification, on-chain reputation.

Third-party agent audit. A verification process conducted by an independent auditor — not the builder, not the marketplace — who reviews the agent’s code, strategy logic, security practices, and performance claims. Third-party audits carry the highest trust weight because they eliminate conflicts of interest. Results are often published as on-chain EAS attestations for permanent, verifiable proof. See also: agent audit, attestation (EAS).

Agent reputation score. A composite metric reflecting an agent’s trustworthiness based on verified performance history, audit results, builder credibility, and marketplace feedback from buyers. Higher reputation scores correlate with premium pricing, faster sales, and prominent marketplace placement. Components typically include: verification level, trade count, live performance data, time in market, and buyer satisfaction ratings. See also: karma, on-chain reputation, verified agent badge.

Sybil resistance. Protection against a single entity creating multiple fake identities to manipulate ratings, reviews, or marketplace metrics. In prediction market agent marketplaces, sybil resistance prevents a builder from creating fake buyer accounts to inflate their agent’s reviews or artificially boost sales numbers. Methods include KYC verification for marketplace accounts, on-chain identity linking, wallet-based reputation staking, and social graph analysis. See also: KYC, DID, on-chain reputation.

Price Format Quick Reference

Because price format differences are the most common source of cross-platform bugs:

See: API Reference — Price Formats.

Platform and Tool Index

Quick reference for every platform and tool mentioned in this glossary:

Further Reading

• The Agent Betting Stack Explained — How all four layers connect
• The Complete Prediction Market API Reference — Every endpoint on every platform
• Agent Wallet Comparison — Deep dive on wallet options
• Polymarket + Coinbase Quickstart — Hands-on setup
• Security Best Practices — Defending against prompt injection and key theft
• Tool Directory — Every tool in the ecosystem