KYC and Compliance Identity for Prediction Market Agents

KYC (Know Your Customer) compliance for prediction market agents means meeting the identity verification requirements of regulated platforms like Kalshi, where both the human operator and the automated trading agent must be properly identified and authorized under CFTC regulations.

The identity layer for prediction market agents is not just about cryptographic proofs and social reputation. For any agent that touches regulated markets, there is a compliance dimension that is non-negotiable: KYC.

KYC requirements vary dramatically across prediction market platforms. On one end, Kalshi requires full government-issued identity verification before you can place a single trade. On the other end, Polymarket requires nothing beyond a wallet address. Understanding these differences — and structuring your agent’s identity accordingly — is the foundation of compliant operation.

This guide is not legal advice. It is a technical and operational overview of how KYC and compliance requirements affect prediction market agent builders. For specific legal questions about your situation, consult a qualified attorney.

Regulated vs. Unregulated Markets

The prediction market landscape splits cleanly into regulated and unregulated platforms, each with fundamentally different identity requirements.

Three patterns emerge from this comparison:

CFTC-regulated platforms (Kalshi) treat prediction markets as derivatives and apply the same KYC standards as a brokerage account. This is the heaviest identity requirement — government-issued identification, tax identification numbers, and in some cases proof of funds.

Offshore platforms (Polymarket) operate outside US regulatory frameworks and implement minimal identity requirements. Wallet-based identity is sufficient, which makes agent deployment simpler but raises questions about long-term regulatory risk.

State-regulated platforms (DraftKings) fall under gaming commissions rather than financial regulators. KYC requirements vary by state and are focused on age verification and geographic eligibility rather than financial compliance. Agent API access is typically limited or unavailable.

For agent builders, the practical question is: which platforms does your agent need to access, and what identity infrastructure do you need for each?

Kalshi KYC Requirements

Kalshi is the most regulated prediction market platform and has the most comprehensive KYC process. Understanding it in detail is essential for any agent targeting Kalshi markets.

What Kalshi Requires

The Kalshi KYC process collects the following information from the human operator:

• Full legal name — must match government-issued ID exactly
• Date of birth — must be 18 or older
• Social Security number (SSN) or Individual Taxpayer Identification Number (ITIN)
• Residential address — must be a US address (Kalshi is US-only)
• Government-issued photo ID — driver’s license, state ID, or passport
• Selfie verification — live photo matched against the ID document

For accounts exceeding certain trading thresholds, additional requirements may apply:

• Source of funds documentation — bank statements, pay stubs, or other proof
• Enhanced due diligence — additional questions about trading experience and financial background

The Application Process

1. Account creation. Register on kalshi.com with email and password.
2. Identity submission. Upload government ID and complete selfie verification through Kalshi’s identity provider (currently Persona).
3. SSN verification. Enter your Social Security number for tax reporting purposes.
4. Address verification. Confirm your residential address. Kalshi may verify this against public records.
5. Review period. Kalshi reviews the application. Typical approval time is 1-3 business days, though it can take longer for enhanced due diligence cases.
6. Approval and API access. Once approved, you can trade through the web interface. To enable API access for your agent, generate API keys from the Kalshi dashboard under account settings.

API Key Generation After KYC

Once your account is verified, API access is straightforward:

import requests

# Kalshi API authentication
KALSHI_API_BASE = "https://trading-api.kalshi.com/trade-api/v2"

def get_kalshi_session(email: str, password: str) -> str:
    """
    Authenticate with Kalshi and receive a session token.
    The account must have completed KYC before this will work.
    """
    response = requests.post(
        f"{KALSHI_API_BASE}/login",
        json={
            "email": email,
            "password": password,
        }
    )
    response.raise_for_status()
    return response.json()["token"]

# Use the session token for subsequent API calls
session_token = get_kalshi_session("[email protected]", "password")
headers = {"Authorization": f"Bearer {session_token}"}

# Example: get account balance
balance = requests.get(
    f"{KALSHI_API_BASE}/portfolio/balance",
    headers=headers
).json()
print(f"Available balance: ${balance['balance'] / 100:.2f}")

The key point: the API credentials are tied to the KYC-verified account. Your agent trades through the human operator’s verified identity. See the Kalshi API guide for the full API reference.

Operator vs. Agent Identity

This is the most important conceptual distinction in compliance identity for agents, and getting it wrong can create serious legal problems.

The operator is the human being who:

• Creates the account on the platform
• Completes KYC verification with their personal identity
• Funds the account with their money
• Bears legal responsibility for all trading activity
• Reports income and pays taxes on gains
• Is liable for compliance violations

The agent is the software that:

• Authenticates using API keys or wallet permissions issued to the operator’s account
• Places trades based on its strategy logic
• Has no independent legal identity
• Cannot complete KYC (it is not a person)
• Operates within the permissions granted by the operator

This maps to a clear hierarchy:

┌──────────────────────────────────────────────┐
│  HUMAN OPERATOR                               │
│  ├── Legal identity (KYC verified)            │
│  ├── Financial responsibility                  │
│  ├── Tax liability                             │
│  └── Account ownership                         │
│                                                │
│  ┌──────────────────────────────────────────┐ │
│  │  AGENT (Bot Software)                     │ │
│  │  ├── Trades via operator's API keys       │ │
│  │  ├── No independent legal identity        │ │
│  │  ├── Constrained by operator's permissions│ │
│  │  └── Activity attributed to operator      │ │
│  └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────┘

The critical implication: every trade your agent makes is legally your trade. If your agent violates platform terms of service, executes wash trades, or triggers market manipulation alerts, you — the operator — are responsible. The “my bot did it” defense has no legal standing.

This is why agent guardrails matter so much. Coinbase Agentic Wallets with spending limits, position size caps, and allowlisted contracts are not just good engineering practice — they are compliance infrastructure. An agent that can spend unlimited funds or trade on unauthorized markets is a compliance liability.

Coinbase CDP Verification

Coinbase Developer Platform (CDP) provides an identity layer that connects traditional KYC verification to on-chain wallets. For agents using Coinbase Agentic Wallets, this creates a bridge between regulatory compliance and cryptographic identity.

When a human operator creates a Coinbase account, they complete Coinbase’s KYC process. Coinbase then issues a verification attestation via EAS on Base, certifying that the wallet owner has been KYC-verified without revealing any personal information on-chain.

This matters for agents because services can check whether an agent’s wallet is controlled by a KYC-verified human without knowing who that human is. The verification pattern looks like this:

from eas_sdk import EAS, SchemaEncoder
from web3 import Web3

w3 = Web3(Web3.HTTPProvider("https://mainnet.base.org"))

# Coinbase Verifications schema on Base
COINBASE_VERIFICATION_SCHEMA = "0x..."  # Coinbase's published schema UID
EAS_ADDRESS = "0x4200000000000000000000000000000000000021"

def check_coinbase_verification(wallet_address: str) -> dict:
    """
    Check if a wallet has a Coinbase KYC verification attestation.
    Returns verification status without revealing personal details.
    """
    eas = EAS(w3, EAS_ADDRESS)

    attestations = eas.get_attestations(
        schema=COINBASE_VERIFICATION_SCHEMA,
        recipient=wallet_address,
    )

    # Filter for active (non-revoked) Coinbase attestations
    active = [a for a in attestations if not a.revoked]

    if active:
        latest = max(active, key=lambda a: a.time)
        return {
            "verified": True,
            "attester": latest.attester,
            "timestamp": latest.time,
            "note": "Wallet holder has completed Coinbase KYC"
        }
    return {
        "verified": False,
        "note": "No active Coinbase verification found"
    }

This is a privacy-preserving model. The attestation says “this wallet belongs to a KYC-verified person” without saying who that person is. It is particularly useful for services that need to ensure they are dealing with verified humans (for regulatory reasons) but do not need to know the human’s specific identity.

Polymarket’s Wallet-Based Identity

Polymarket operates at the opposite end of the identity spectrum from Kalshi. There is no KYC process, no identity verification, and no account registration in the traditional sense. Identity is purely wallet-based.

To trade on Polymarket, an agent needs:

1. An Ethereum-compatible wallet with a private key
2. USDC on Polygon (for funding trades)
3. API credentials from the Polymarket CLOB

Authentication happens through Sign-In with Ethereum (SIWE) — the agent signs a message with its private key to prove it controls a specific wallet address. That is the entirety of the identity requirement.

from py_clob_client.client import ClobClient

# Polymarket requires no KYC — just a wallet
client = ClobClient(
    host="https://clob.polymarket.com",
    key="0xYOUR_PRIVATE_KEY",  # Agent's wallet private key
    chain_id=137,  # Polygon
)

# Derive API credentials from the wallet
client.set_api_creds(client.create_or_derive_api_creds())

# The agent can now trade — no identity verification needed
markets = client.get_markets()

This simplicity is a major advantage for agent builders. There is no approval process, no waiting period, and no documentation requirements. An agent can go from zero to live trading in minutes.

However, the lack of KYC creates different considerations:

US access restrictions. Polymarket’s terms of service prohibit US-based users from trading. This restriction is enforced through IP-based geoblocking, not KYC verification. The practical implications for agent builders depend on your jurisdiction and legal advice.

No regulatory protection. KYC-verified platforms like Kalshi are regulated by the CFTC, which provides certain protections (segregated funds, dispute resolution). Polymarket operates offshore with no equivalent regulatory oversight.

Wallet address as identity. Without KYC, the agent’s wallet address is its entire identity. If the wallet’s private key is compromised, the agent’s identity and funds are both lost. There is no “forgot password” or identity recovery process. See the agent betting security guide for best practices.

The Operator Identity Pattern

Most serious agent operators run multiple agents across multiple platforms. The operator identity pattern formalizes this structure.

┌─────────────────────────────────────────────────────────┐
│  HUMAN OPERATOR                                          │
│  ├── Kalshi Account (KYC verified)                       │
│  │   ├── Agent A — Political event arbitrage bot         │
│  │   │   └── API Key: kalshi_key_a                       │
│  │   └── Agent B — Weather market sentiment bot          │
│  │       └── API Key: kalshi_key_b                       │
│  │                                                       │
│  ├── Polymarket Wallet 1 (Coinbase Agentic Wallet)       │
│  │   └── Agent C — Crypto market maker                   │
│  │       └── Wallet: 0xABC...                            │
│  │                                                       │
│  ├── Polymarket Wallet 2 (Separate EOA)                  │
│  │   └── Agent D — Cross-market arb bot                  │
│  │       └── Wallet: 0xDEF...                            │
│  │                                                       │
│  └── Moltbook Identity                                   │
│      └── Operator profile linking all agents              │
└─────────────────────────────────────────────────────────┘

Key principles for structuring this:

Separate API keys per agent on Kalshi. If Kalshi supports multiple API keys per account, use separate keys for each agent. This allows you to revoke one agent’s access without affecting others, and makes it easier to attribute trading activity to specific agents.

Separate wallets per agent on Polymarket. Each agent should have its own wallet address. This provides natural isolation — if one agent’s wallet is compromised, others are unaffected. It also makes on-chain track records cleaner, since each wallet’s trade history corresponds to a single agent.

Single Moltbook identity for the operator. Your Moltbook profile should link to all your agents, providing a unified reputation layer. Buyers want to know that the person behind Agent A is the same person behind Agent B, especially if they are evaluating your track record across multiple strategies.

Shared compliance infrastructure. KYC verification on Kalshi applies to the operator’s account, not to individual agents. Tax reporting, record-keeping, and compliance obligations are at the operator level.

Compliance Considerations for Agent Builders

This section is not legal advice. Compliance requirements depend on your jurisdiction, trading volume, and specific circumstances. Consult a qualified attorney for guidance specific to your situation.

That said, here are the key compliance areas that prediction market agent builders should be aware of.

Tax Reporting

Kalshi issues 1099 forms to US-based traders who meet IRS reporting thresholds. Your agent’s trading gains are taxable income attributed to you (the operator), regardless of whether a human or a bot made the trades.

Key considerations:

• Kalshi reports gross proceeds and may issue 1099-B or 1099-MISC forms
• Polymarket does not issue tax forms (it has no KYC and no knowledge of your identity), but you are still obligated to report taxable gains
• Trading across multiple platforms requires aggregating P&L across all accounts for accurate reporting
• Agent operational costs (API subscriptions, compute, data feeds) may be deductible as business expenses — consult a tax professional

Record-Keeping

Regardless of platform, maintain detailed records of all agent trading activity:

• Every trade with timestamp, market, position, size, and price
• Daily portfolio snapshots
• Agent configuration changes (strategy parameters, risk limits)
• API key creation and revocation events
• Deposits and withdrawals

These records serve multiple purposes: tax reporting, performance auditing, dispute resolution, and building verifiable track records through EAS attestations.

import json
from datetime import datetime

def log_trade(trade_data: dict, log_file: str = "trade_log.jsonl"):
    """
    Append a trade record to the compliance log.
    Every trade should be logged regardless of platform.
    """
    record = {
        "timestamp": datetime.utcnow().isoformat(),
        "platform": trade_data["platform"],
        "market_id": trade_data["market_id"],
        "market_question": trade_data.get("question", ""),
        "side": trade_data["side"],  # "buy" or "sell"
        "outcome": trade_data["outcome"],  # "yes" or "no"
        "size": trade_data["size"],
        "price": trade_data["price"],
        "order_id": trade_data.get("order_id", ""),
        "agent_id": trade_data.get("agent_id", ""),
        "wallet_or_account": trade_data.get("account_id", ""),
    }

    with open(log_file, "a") as f:
        f.write(json.dumps(record) + "\n")

Anti-Money Laundering (AML)

Regulated platforms like Kalshi have their own AML programs. As an operator, you are subject to their terms of service, which prohibit using the platform for money laundering. For unregulated platforms, the legal obligations depend on your jurisdiction.

Practical implications for agents:

• Do not use agents to move funds between accounts in patterns designed to obscure the source
• Do not run agents on behalf of sanctioned individuals or entities
• If you are selling agents to others, understand that your buyers are responsible for their own compliance — but be aware of your obligations if you have reason to believe the agent will be used for illicit purposes

Sanctions Screening

US-based operators are subject to OFAC sanctions. This primarily affects agents trading on Polymarket and other crypto-based platforms, where wallet addresses associated with sanctioned entities are blacklisted. Ensure that your agent’s wallet interactions do not involve sanctioned addresses.

How KYC Identity Intersects with On-Chain Identity

KYC and on-chain identity serve different purposes but can be linked in privacy-preserving ways.

The pattern is straightforward: a human completes KYC with a centralized service (Coinbase, Kalshi), and that service creates an on-chain attestation confirming the verification without revealing personal details.

Coinbase Verifications on EAS (Base) are the primary mechanism today. When you create a Coinbase Agentic Wallet, the associated wallet address can receive a verification attestation that says “this wallet is controlled by a KYC-verified individual” — nothing more.

This creates a useful layering:

A service that wants to restrict access to KYC-verified agents can check the Coinbase Verification attestation on Base without knowing the operator’s name, address, or SSN. The verification is binary — verified or not verified — and the personal details stay with Coinbase.

For agents operating across both Kalshi and Polymarket, this creates a bridge. The operator completes KYC once (with Kalshi and/or Coinbase), and the resulting on-chain attestation extends that verification to their Polymarket agent wallets. Services interacting with those wallets can verify KYC status without the agent re-proving its identity to every counterparty.

This is the intersection of regulatory compliance and cryptographic identity, and it points toward a future where KYC verification is completed once and carried as a portable credential across the agent ecosystem. For more on combining multiple identity systems, see the multi-identity strategy guide.

Further Reading

• Agent Identity Comparison — How KYC fits alongside SIWE, ENS, EAS, and Moltbook
• Legal Guide to Selling AI Agents — Licensing, liability, and regulatory considerations for agent sellers
• Multi-Identity Strategy for Agents — Combining KYC with social and cryptographic identity layers
• Kalshi Agents — Platform-specific guide for building and deploying agents on Kalshi
• On-Chain Reputation for Agents — Building verifiable track records with EAS attestations