On-Chain Reputation for Prediction Market Agents: EAS Attestations and Verifiable Track Records

On-chain reputation for prediction market agents means storing verifiable performance data — win rates, Sharpe ratios, platform history — as cryptographic attestations on a blockchain, allowing anyone to independently verify an agent’s track record without trusting the agent’s self-reported claims.

Every prediction market agent seller will tell you their bot has a 68% win rate and a Sharpe above 2. The question is whether you can verify that claim without taking their word for it.

Self-reported metrics are the default in agent marketplaces today. A developer posts a screenshot of their equity curve, maybe a backtest report, and buyers are left to trust or walk away. This is the same trust model that existed before credit scores, before financial audits, before any system where independent verification replaced handshake agreements.

On-chain reputation changes this dynamic entirely. By recording verifiable performance data as cryptographic attestations on a blockchain, agent builders can create track records that anyone can inspect, that cannot be altered after the fact, and that compose with other identity systems to build a comprehensive trust profile. This guide covers how to build that system using the Ethereum Attestation Service (EAS) on Base, and how it integrates with the broader identity layer for prediction market agents.

The Trust Gap in Agent Marketplaces

The prediction market agent ecosystem has a trust problem that grows worse as the market grows larger.

On the supply side, developers are building agents and listing them for sale across multiple channels — GitHub, Discord, purpose-built marketplaces. The technical barriers to creating agents have dropped dramatically with tools like the Polymarket CLI and Coinbase Agentic Wallets. More agents mean more competition, and more competition means stronger incentives to exaggerate performance.

On the demand side, buyers are trying to evaluate agents without the tools to verify claims independently. The current verification guide lays out the hierarchy of trust evidence — from backtests (weakest) to on-chain verified live trading (strongest). But even the best verification processes today are manual, one-off exercises. There is no persistent, composable record that follows an agent across platforms and marketplaces.

This gap creates three specific problems:

1. Adverse selection. Without reliable verification, buyers cannot distinguish good agents from bad ones, so they discount all agents equally. Good agents are underpriced, bad agents are overpriced, and the market settles at a mediocre equilibrium.

2. Reputation portability. An agent that builds a strong track record on Polymarket has no way to carry that reputation to a different marketplace, a data provider evaluating API access requests, or a fund looking for agents to allocate capital to.

3. Accountability decay. Without persistent records, a developer whose agent blew up last month can launch a new agent this month with a clean slate. There is no equivalent of a credit history for agents.

On-chain reputation addresses all three problems by making performance claims verifiable, portable, and persistent.

What On-Chain Reputation Means for Agents

On-chain reputation is fundamentally different from social reputation systems like Moltbook karma. Both are valuable, but they prove different things.

Moltbook karma is a social signal. It tells you that other users in the community have interacted with an agent, found it useful, and endorsed it through upvotes and engagement. This is genuine information — community consensus is a real filter. But karma does not tell you what the agent’s actual trading performance was. A highly upvoted agent could be popular for its documentation quality, its developer’s responsiveness, or its entertaining market commentary, while its actual trading returns are mediocre.

On-chain attestations are cryptographic claims. They state specific, verifiable facts: this agent had a 1.87 Sharpe ratio over a 6-month period, as computed by this specific attester, using this specific methodology, at this specific time. The claim is signed by the attester’s private key, stored immutably on a blockchain, and verifiable by anyone with a block explorer.

Three properties make on-chain attestations uniquely valuable for agent reputation:

Immutability. Once an attestation is recorded on-chain, it cannot be edited or deleted. An agent cannot retroactively improve a bad quarter. The attester can revoke the attestation (marking it as no longer valid), but the original record remains visible. This creates an honest historical record.

Composability. Attestations follow a standard schema and live at a known address. Any service — a marketplace, a data provider, a fund — can query the same attestation data and make its own trust decisions. The agent does not need to re-prove its track record for every new counterparty.

Verifier independence. The person verifying an attestation does not need to trust the agent, the marketplace, or any intermediary. They verify the attestation against the blockchain directly. The only trust assumption is in the attester’s identity and methodology, which is itself verifiable through the attester’s on-chain history.

EAS Attestation Schemas for Agents

The Ethereum Attestation Service (EAS) is the standard infrastructure for creating on-chain attestations. It is deployed on Base (Coinbase’s L2), which makes it the natural choice for agents already using Coinbase Agentic Wallets.

EAS works through schemas — predefined data structures that describe what an attestation contains. Before you can create an attestation, you register a schema. Then anyone can create attestations that conform to that schema.

Schema 1: Agent Performance

This schema records an agent’s trading performance over a specific time period.

from eas_sdk import SchemaRegistry, EAS, SchemaEncoder
from web3 import Web3

# Connect to Base
w3 = Web3(Web3.HTTPProvider("https://mainnet.base.org"))

# EAS contract addresses on Base
SCHEMA_REGISTRY_ADDRESS = "0x4200000000000000000000000000000000000020"
EAS_ADDRESS = "0x4200000000000000000000000000000000000021"

schema_registry = SchemaRegistry(w3, SCHEMA_REGISTRY_ADDRESS)

# Define the performance schema
performance_schema = (
    "address agentWallet,"      # Agent's wallet address
    "uint64 periodStart,"       # Unix timestamp - period start
    "uint64 periodEnd,"         # Unix timestamp - period end
    "string platform,"          # e.g., "polymarket", "kalshi"
    "int32 sharpeRatio100x,"    # Sharpe ratio * 100 (187 = 1.87)
    "uint16 winRateBps,"        # Win rate in basis points (6800 = 68%)
    "uint16 maxDrawdownBps,"    # Max drawdown in basis points
    "uint32 totalTrades,"       # Number of trades in period
    "int64 pnlUsdCents,"       # P&L in USD cents (signed)
    "string methodology"        # How metrics were computed
)

# Register the schema
tx = schema_registry.register(
    schema=performance_schema,
    resolver_address="0x0000000000000000000000000000000000000000",
    revocable=True
)
schema_uid = tx.wait()
print(f"Performance schema registered: {schema_uid}")

Key design decisions in this schema:

• Fixed-point integers for ratios. Solidity has no native floating point. Sharpe ratio is stored as an integer multiplied by 100, win rate and drawdown as basis points (1/100th of a percent). This avoids precision loss.
• Signed P&L. The pnlUsdCents field is signed because agents can lose money. An honest reputation system must record losses, not just wins.
• Methodology string. Different attesters may compute Sharpe ratio differently (annualized vs. rolling, risk-free rate assumptions). The methodology field makes the computation transparent.
• Revocable. The schema allows revocation so attesters can mark outdated or incorrect attestations. Revocation does not delete the attestation — it adds a revocation flag.

Schema 2: Strategy Type Certification

This schema classifies what kind of strategy an agent runs.

strategy_schema = (
    "address agentWallet,"
    "string strategyType,"        # "arbitrage", "sentiment", "market-making", etc.
    "string strategyDescription," # Human-readable description
    "string[] markets,"           # Market categories: ["politics", "crypto", "sports"]
    "bool usesLeverage,"
    "uint16 maxPositionSizeBps,"  # Max position as % of bankroll (bps)
    "uint64 attestedAt"           # Timestamp of certification
)

tx = schema_registry.register(
    schema=strategy_schema,
    resolver_address="0x0000000000000000000000000000000000000000",
    revocable=True
)
strategy_schema_uid = tx.wait()
print(f"Strategy schema registered: {strategy_schema_uid}")

Strategy certification matters because buyers want to know what they are getting before they examine performance numbers. An arbitrage bot with a 1.2 Sharpe is a very different product from a sentiment bot with a 1.2 Sharpe — the risk profiles, capital requirements, and failure modes are completely different.

Schema 3: Audit Results

This schema records the results of a third-party audit of an agent’s code or performance claims.

audit_schema = (
    "address agentWallet,"
    "address auditorAddress,"     # The auditor's wallet
    "string auditorName,"         # Human-readable auditor identity
    "uint64 auditDate,"
    "string auditScope,"          # What was audited
    "string findings,"            # Summary of findings
    "uint8 riskRating,"           # 1-5 scale (1 = lowest risk)
    "bool codeReviewed,"
    "bool livePerformanceVerified,"
    "bool backtestReproduced,"
    "string reportHash"           # IPFS hash of full audit report
)

tx = schema_registry.register(
    schema=audit_schema,
    resolver_address="0x0000000000000000000000000000000000000000",
    revocable=True
)
audit_schema_uid = tx.wait()
print(f"Audit schema registered: {audit_schema_uid}")

The audit schema is designed around the verification hierarchy — it explicitly records whether the auditor reviewed code, verified live performance, and reproduced backtest results. A buyer can immediately see the depth of the audit.

Verifiable Track Records on Base

With schemas registered, here is the end-to-end flow for creating and verifying an agent’s track record.

Step 1: Agent Trades on Polymarket

The agent trades normally through the Polymarket CLOB API. All trades settle on Polygon, creating an immutable on-chain record.

Step 2: Performance Data Is Computed

At the end of a reporting period (monthly, quarterly), the agent or a third-party service computes performance metrics from the on-chain trade history.

import requests
from datetime import datetime, timedelta

def compute_performance(wallet_address: str, period_days: int = 90):
    """
    Compute agent performance from Polymarket subgraph data.
    """
    end_time = int(datetime.now().timestamp())
    start_time = int((datetime.now() - timedelta(days=period_days)).timestamp())

    # Query Polymarket subgraph for trade history
    query = """
    {
        trades(
            where: {
                trader: "%s",
                timestamp_gte: %d,
                timestamp_lte: %d
            },
            orderBy: timestamp,
            orderDirection: asc
        ) {
            id
            market { question }
            side
            size
            price
            timestamp
            outcome
        }
    }
    """ % (wallet_address.lower(), start_time, end_time)

    response = requests.post(
        "https://api.thegraph.com/subgraphs/name/polymarket/activity",
        json={"query": query}
    )
    trades = response.json()["data"]["trades"]

    # Compute metrics
    returns = compute_daily_returns(trades)
    sharpe = compute_sharpe_ratio(returns)
    win_rate = compute_win_rate(trades)
    max_dd = compute_max_drawdown(returns)
    total_pnl = compute_total_pnl(trades)

    return {
        "period_start": start_time,
        "period_end": end_time,
        "sharpe_ratio": sharpe,
        "win_rate": win_rate,
        "max_drawdown": max_dd,
        "total_trades": len(trades),
        "pnl_usd": total_pnl,
    }

Step 3: Attestation Is Created on Base

The computed performance data is written as an EAS attestation on Base.

from eas_sdk import EAS, SchemaEncoder

eas = EAS(w3, EAS_ADDRESS)

# Encode the attestation data
encoder = SchemaEncoder(performance_schema)
encoded_data = encoder.encode_data([
    {"name": "agentWallet", "value": "0xAGENT_WALLET_ADDRESS", "type": "address"},
    {"name": "periodStart", "value": perf["period_start"], "type": "uint64"},
    {"name": "periodEnd", "value": perf["period_end"], "type": "uint64"},
    {"name": "platform", "value": "polymarket", "type": "string"},
    {"name": "sharpeRatio100x", "value": int(perf["sharpe_ratio"] * 100), "type": "int32"},
    {"name": "winRateBps", "value": int(perf["win_rate"] * 10000), "type": "uint16"},
    {"name": "maxDrawdownBps", "value": int(perf["max_drawdown"] * 10000), "type": "uint16"},
    {"name": "totalTrades", "value": perf["total_trades"], "type": "uint32"},
    {"name": "pnlUsdCents", "value": int(perf["pnl_usd"] * 100), "type": "int64"},
    {"name": "methodology", "value": "polymarket-subgraph-v1-annualized-sharpe", "type": "string"},
])

# Create the attestation
tx = eas.attest({
    "schema": performance_schema_uid,
    "data": {
        "recipient": "0xAGENT_WALLET_ADDRESS",
        "expirationTime": 0,  # No expiration
        "revocable": True,
        "data": encoded_data,
    }
})
attestation_uid = tx.wait()
print(f"Attestation created: {attestation_uid}")
print(f"View: https://base.easscan.org/attestation/view/{attestation_uid}")

Step 4: Buyer Verifies On-Chain

A potential buyer can verify the attestation directly on Base without trusting any intermediary.

def verify_agent_reputation(agent_wallet: str, schema_uid: str):
    """
    Look up all attestations for an agent under a given schema.
    Returns a list of verified performance records.
    """
    eas = EAS(w3, EAS_ADDRESS)

    # Query attestations for this recipient under this schema
    attestations = eas.get_attestations(
        schema=schema_uid,
        recipient=agent_wallet,
    )

    verified_records = []
    for att in attestations:
        if att.revoked:
            continue  # Skip revoked attestations

        decoder = SchemaEncoder(performance_schema)
        data = decoder.decode_data(att.data)

        verified_records.append({
            "attester": att.attester,
            "timestamp": att.time,
            "sharpe_ratio": data["sharpeRatio100x"] / 100,
            "win_rate": data["winRateBps"] / 10000,
            "max_drawdown": data["maxDrawdownBps"] / 10000,
            "total_trades": data["totalTrades"],
            "pnl_usd": data["pnlUsdCents"] / 100,
            "platform": data["platform"],
            "methodology": data["methodology"],
        })

    return verified_records

# Verify an agent
records = verify_agent_reputation(
    agent_wallet="0xAGENT_WALLET_ADDRESS",
    schema_uid=performance_schema_uid
)

for r in records:
    print(f"Period: {r['platform']}")
    print(f"  Attested by: {r['attester']}")
    print(f"  Sharpe: {r['sharpe_ratio']}")
    print(f"  Win rate: {r['win_rate']:.1%}")
    print(f"  Max drawdown: {r['max_drawdown']:.1%}")
    print(f"  Trades: {r['total_trades']}")
    print(f"  P&L: ${r['pnl_usd']:,.2f}")

The buyer does not need to trust the agent, the marketplace, or any intermediary. They read the attestation from Base, check who attested it, evaluate the attester’s credibility, and make their own trust decision.

Soulbound Tokens (SBTs) as Credentials

Soulbound Tokens are non-transferable NFTs bound permanently to a wallet address. They were proposed as a mechanism for on-chain identity credentials and have some overlap with EAS attestations.

For agent reputation, SBTs are best understood as visible badges rather than detailed records. An SBT might represent “Verified Prediction Market Agent — Q1 2026” or “Audited by XYZ Firm.” It shows up in the agent’s wallet on NFT explorers and can serve as a quick visual trust signal.

Key differences from EAS attestations:

Recommendation: Use EAS attestations as the primary reputation mechanism for detailed, queryable performance data. Use SBTs selectively for high-visibility credentials — for example, a “Top 10% Agent — 2026” badge issued by a trusted authority. Most agents should start with EAS and add SBTs only if they need the visual credentialing.

Building a Reputation Profile

The strongest agent reputation combines social trust from Moltbook with cryptographic proof from EAS attestations. Each system covers what the other cannot.

The combined profile looks like this:

AGENT: PolyTraderBot

  SOCIAL IDENTITY (Moltbook)
  ├── Verified human operator: @devname on X
  ├── Karma: 847
  ├── Member since: January 2026
  ├── Active in: #prediction-markets, #arbitrage
  └── Endorsements: 12 community members

  CRYPTOGRAPHIC IDENTITY (EAS on Base)
  ├── Performance Attestation (Q4 2025)
  │   ├── Sharpe: 1.87 | Win Rate: 64.2% | Max DD: 8.3%
  │   ├── Attested by: 0xAUDITOR (AgentAudit.xyz)
  │   └── Methodology: polymarket-subgraph-v1-annualized
  ├── Performance Attestation (Q1 2026)
  │   ├── Sharpe: 2.14 | Win Rate: 67.1% | Max DD: 6.1%
  │   ├── Attested by: 0xAUDITOR (AgentAudit.xyz)
  │   └── Methodology: polymarket-subgraph-v1-annualized
  ├── Strategy Certification
  │   ├── Type: Cross-market arbitrage
  │   └── Attested by: 0xCERTIFIER (StrategyReview.io)
  └── Audit Result
      ├── Risk Rating: 2/5 (low-moderate)
      ├── Code reviewed: Yes | Live verified: Yes
      └── Attested by: 0xAUDITOR (AgentAudit.xyz)

A buyer evaluating this agent can see both the social context (active community member, verified human operator) and the hard numbers (consistent Sharpe above 1.5, low drawdown, third-party audited). Neither layer alone provides this complete picture.

Marketplace Trust Pattern

Here is the step-by-step workflow a buyer follows to verify an agent’s claims before purchase, combining the identity layers covered in this guide with the buyer’s guide.

Step 1: Discover the agent. The buyer finds the agent on a marketplace listing or through a Moltbook profile.

Step 2: Check social reputation. Query the Moltbook API for the agent’s karma score, verification status, and community endorsements. A verified agent with substantial karma is a stronger starting signal than an anonymous listing.

Step 3: Resolve the wallet address. The agent’s marketplace listing includes its wallet address (or ENS name). This is the address used to look up on-chain data.

Step 4: Query EAS attestations. Using the wallet address, query EAS on Base for all attestations under the performance, strategy, and audit schemas. Check which attestations are active (not revoked) and who created them.

Step 5: Evaluate attester credibility. An attestation is only as trustworthy as its attester. Check the attester’s own reputation — are they a known audit firm? A platform-verified data feed? Another agent self-attesting? The weight given to each attestation should scale with the attester’s credibility.

Step 6: Cross-reference with on-chain trades. For Polymarket agents, compare the attested performance with the actual on-chain trade history on Polygon. The trades should exist, the timestamps should match the attested period, and the computed metrics should be consistent with the attestation.

Step 7: Make a trust decision. With social reputation, attested performance, attester credibility, and on-chain trade verification all checked, the buyer has enough information to make an informed decision.

This workflow moves verification from “trust the seller” to “trust the math.” The seller does not need to convince the buyer. The data speaks for itself.

Tiered Access Based on Attested Reputation

On-chain reputation enables a pattern that is impossible with self-reported metrics: automated tiered access.

Data providers, premium API services, and capital allocators can gate access based on attested reputation scores. The logic is simple and verifiable: query the agent’s attestations, check the relevant metric, grant or deny access.

def check_tiered_access(agent_wallet: str, min_sharpe: float = 1.5):
    """
    Gate access to a premium data feed based on attested Sharpe ratio.
    Only agents with a verified Sharpe >= threshold from a trusted attester
    are granted access.
    """
    TRUSTED_ATTESTERS = [
        "0xAgentAuditXyz...",
        "0xStrategyReviewIo...",
        "0xPlatformVerified...",
    ]

    records = verify_agent_reputation(agent_wallet, performance_schema_uid)

    # Filter to trusted attesters only
    trusted_records = [
        r for r in records
        if r["attester"] in TRUSTED_ATTESTERS
    ]

    if not trusted_records:
        return {
            "access": "denied",
            "reason": "No attestations from trusted attesters found"
        }

    # Use the most recent trusted attestation
    latest = max(trusted_records, key=lambda r: r["timestamp"])

    if latest["sharpe_ratio"] >= min_sharpe:
        return {
            "access": "premium",
            "sharpe": latest["sharpe_ratio"],
            "attester": latest["attester"],
            "tier": "gold" if latest["sharpe_ratio"] >= 2.0 else "silver"
        }
    else:
        return {
            "access": "basic",
            "sharpe": latest["sharpe_ratio"],
            "reason": f"Sharpe {latest['sharpe_ratio']} below premium threshold {min_sharpe}"
        }

Example tier structure:

This creates a virtuous cycle: agents that perform well earn better access to data and infrastructure, which helps them perform even better, which strengthens their attestations. The reputation system becomes a competitive advantage that compounds over time.

Security Considerations

On-chain reputation is only as trustworthy as the system’s security model. Here are the critical considerations.

Attestation Integrity

The fundamental question is: who can create attestations, and how do you trust them?

Self-attestation is the weakest form. Any agent can attest to its own performance. Self-attestations should be treated as claims, not evidence. They are useful for discoverability (an agent saying “I am an arbitrage bot”) but not for verification (an agent saying “my Sharpe is 2.1”).

Third-party attestation is the standard for trust. A separate entity — an audit firm, a platform data feed, an escrow service — creates the attestation. The buyer’s trust transfers from the agent to the attester. This is the same model as traditional financial audits: you trust the auditor, not the company being audited.

Platform-verified attestation is the gold standard. If Polymarket itself (or a service with direct access to Polymarket’s data) creates the attestation, the data is authoritative. The attester has no incentive to inflate or deflate the metrics.

Trusted Attesters vs. Self-Attestation

A registry of trusted attesters is essential for the system to work. Without it, self-attestation pollution makes the data useless. Trusted attester registries can be maintained on-chain (a smart contract with an allowlist) or off-chain (a curated list maintained by a marketplace or industry body).

# On-chain trusted attester registry (simplified)
TRUSTED_ATTESTER_REGISTRY = "0xTrustedAttesterRegistry..."

def is_trusted_attester(attester_address: str) -> bool:
    """Check if an attester is in the trusted registry."""
    registry = w3.eth.contract(
        address=TRUSTED_ATTESTER_REGISTRY,
        abi=attester_registry_abi
    )
    return registry.functions.isTrusted(attester_address).call()

Revocation

EAS supports attestation revocation, which is critical for honest reputation systems. Revocation use cases:

• Error correction. The attester made a computational error and needs to revoke the incorrect attestation and create a corrected one.
• Time expiration. A performance attestation from 18 months ago may no longer be relevant. The attester revokes stale data.
• Fraud discovery. The attester discovers that the agent’s on-chain trades were manipulated (wash trading, self-dealing). The attestation is revoked.

Revocation does not delete the attestation from the chain. It adds a revocation flag, creating a transparent record that the claim was made and then withdrawn. This is by design — a revoked attestation can itself be informative.

Gaming Risks

Several attack vectors exist against on-chain reputation systems:

Wash trading. An agent trades with itself to inflate volume and win rate metrics. Defense: attesters should verify that trades were against genuine counterparties, not the agent’s own wallets.

Cherry-picked periods. An agent seeks attestation only during its best-performing periods. Defense: attesters should require continuous reporting (every quarter, not when the agent chooses) or flag gaps in the attestation history.

Collusive attestation. An attester and agent collude to create fraudulent attestations. Defense: use multiple independent attesters, and weight attestations from well-known entities higher than those from unknown ones.

Sybil attestation. An agent creates multiple attester identities to attest to itself. Defense: trusted attester registries with real-world identity verification.

None of these attacks are unique to on-chain reputation — they exist in traditional finance too. The advantage of the on-chain model is that attacks leave a permanent, auditable trail. A wallet that wash-traded can be identified retroactively. An attester that colluded with agents will have a pattern of suspicious attestations visible to anyone.

Further Reading

• EAS (Ethereum Attestation Service) — Tool overview and setup guide
• Agent Identity Comparison — How on-chain reputation fits with other identity systems
• Prediction Market Bot Verification — The broader verification framework that EAS attestations plug into
• Sell Your Prediction Market Bot — Using on-chain reputation to strengthen your marketplace listing
• Multi-Identity Strategy for Agents — Combining EAS with Moltbook, SIWE, ENS, and KYC for a complete identity stack