The Agent Betting Glossary

This glossary defines every term you’ll encounter while building, deploying, or researching autonomous prediction market agents. 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

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.

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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. Only available on 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.

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