Polymarket Intel

Polymarket Wallet Intelligence

Polymarket のウォレットを人間またはボットに分類し、取引エッジを 0～10 でスコアリングして、現在のオープンポジションを配信する MCP サーバーおよび REST API です。 コピー取引やシグナル追従のスタックで利用する AI エージェント向けに構築されています。

# Use it from any MCP client (Claude Desktop, Cursor, etc.)
pip install polymarket-intel-mcp
polymarket-intel-mcp

# Or call the hosted REST API directly
curl https://polymarket-intel-production.up.railway.app/wallet/0xf1528f12e645462c344799b62b1b421a6a4c64aa

他の Polymarket MCP サーバーとの使い分け

ステータス

最新: v1.2（2026 年 5 月）— 分類器を改良し、活発に取引する人間のトレーダーと HFT ボットを区別できるようになりました。今後の予定については、リリースノートとv1.3 のバックログ課題をご覧ください。

毎日 08:00 UTC にスナップショットジョブを実行し、リーダーボード上位 50 件のウォレットを再スコアリングして、時間経過に伴う分類の安定性に関する履歴データセットを構築します。

Polymarket を対象とする MCP サーバーはいくつかあり、それぞれ異なるレイヤーをカバーしています。

サーバー	機能	利用する場面
polymarket-intel（本サーバー）	ウォレットインテリジェンス — 人間かボットかを分類し、取引エッジをスコアリングして、オープンポジションを読み取ります	どのトレーダーのシグナルを追従するかを決めるとき
graph-polymarket-mcp	The Graph のサブグラフを介した市場データ（20 個のツール、8 個のサブグラフ）	オンチェーンの生の市場データを読み取るとき
whitmorelabs/polymarket-mcp	スリッページ、流動性、裁定取引、価格フィード	独自の取引価格を算出するとき
joinQuantish/polymarket	セルフホスト可能な取引エージェント	自律型ボットを運用するとき

これらは互いに補完し合います。コピー取引エージェントは、まず polymarket-intel を使って追従する価値のあるウォレットを絞り込み、次に graph-polymarket-mcp を使ってそれらのウォレットが賭けている市場を読み取り、その後 whitmorelabs/polymarket-mcp を使って自らのエントリーサイズを決められます。

このサーバーで分かること

• 「このトレーダーは人間ですか、それともボットですか？」 — score_polymarket_wallet(wallet_address) → classification ∈ {human, bot, insufficient_data} に加え、信頼度スコアと理由コードを返します。
• 「実際に取引エッジがありますか？」 — edge_score は 0～10 のスコアです。実現純 PnL を条件とし、分散していても損失を出しているウォレットが誤って高評価されないようにします。
• 「現在、何に賭けていますか？」 — get_open_positions(wallet_address) は、サイズ順に並べたライブポジションを返します。30 秒ごとに更新されます。
• 「取引エッジは時間とともにどう変化しましたか？」 — /wallet/{address}/history は、毎日のスナップショットからスコアの時系列を返します。

このサービスが存在する理由

Polymarket のリーダーボードは実態を正確に反映していません。現在価格で評価した未実現 PnL が含まれるため、上位には構造的な裁定取引を行うボットや、ポジションが有利な形で決着するとは限らない大規模なオープンポジションを抱えたウォレットが並んでいます。リーダーボードをそのまま頼りにコピー取引するエージェントは、痛い目に遭います。

このサービスでは、すべてのリーダーボード上のウォレットについて、行動の指紋分析（注目度比率、保有期間、タイミングの規則性、カテゴリーの集中度）と、生のアクティビティからの PnL 再構築を実施します。そのうえで、実際のエッジを持つ本物の人間のトレーダーらしいウォレットのみを表示します。

データセットは時間とともに価値が高まります — スナップショットジョブが実行されるたびに、過去のシグナルが蓄積されます。90 日間にわたり一貫してエッジ 7 を上回るウォレットは、ある時点での単一スコアよりも強いシグナルとなります。

REST API と MCP サーバーの両方で提供

提供形態	用途	セットアップ
MCP サーバー	ツール形式のアクセスを必要とするエージェント	pip install polymarket-intel-mcp
REST API	カスタム HTTP 連携、ダッシュボード	curl https://polymarket-intel-production.up.railway.app/...
ホスト型 MCP	MCP 対応クライアント上のエージェント	クライアントの設定に https://polymarket-intel-production.up.railway.app/mcp を追加

アーキテクチャ

┌──────────────────────────────────────────────┐
│  core/                                       │
│    client.py    — Polymarket data API client │
│    signals.py   — pure signal calculators    │
│    scorer.py    — classifier + edge score    │
│    models.py    — Pydantic response schemas  │
├──────────────────────────────────────────────┤
│  db/                                         │
│    schema.sql   — Postgres tables + indexes  │
│    repository.py — Repository protocol +     │
│                    InMemoryRepository        │
│    supabase_repo.py — Supabase impl          │
│    converters.py — ScoreResult ↔ records     │
├──────────────────────────────────────────────┤
│  api/main.py    — FastAPI HTTP server        │
│  mcp_server/    — MCP server (stdio)         │
│  scripts/                                    │
│    analyze_wallet.py — CLI                   │
│    snapshot_job.py   — daily cron entry      │
│  tests/                                      │
└──────────────────────────────────────────────┘

Core は永続化の存在を一切認識しません。API とスナップショットジョブは Repository プロトコルに依存します。本番環境では Supabase、テスト時や環境変数が設定されていない場合はメモリ内リポジトリを使用します。これにより、データベースなしでテストスイートを実行でき、後からファイルを 1 つ追加するだけで Supabase を Neon、RDS、その他のものに置き換えられます。

クイックスタート

git clone <repo> && cd polymarket-intel
python -m venv .venv && source .venv/bin/activate
pip install -r requirements-dev.txt
pytest                             # 19 tests, all green

CLI

python scripts/analyze_wallet.py phonesculptor
python scripts/analyze_wallet.py 0xf1528f12e645462c344799b62b1b421a6a4c64aa --json

REST API

uvicorn api.main:app --reload --port 8000
open http://localhost:8000/docs

API は低速ティア（積極的にキャッシュされ、低コストで、単発の探索に最適）と高速ティア（キャッシュ期間が短く、リアルタイムのコピー取引エージェントに最適）に分かれています。この分割は、基盤となるデータの鮮度要件が異なるためです。ウォレットの分類は分単位では変わりませんが、オープンポジションは変化します。

ティア	メソッド	パス	TTL	備考
低速	GET	/wallet/{address}	1h	スコア情報 — 分類、edge_score、シグナル。ポジションは含みません。履歴に保存されます（デバウンスあり）。
高速	GET	/wallet/{address}/positions	30s	オープンポジションのみ。呼び出しごとの DB 書き込みはありません。
—	GET	/wallet/{address}/history	DB	スコアの時系列
—	GET	/wallet/{address}/positions/history	DB	時間の経過に伴うポジションの変化
—	GET	/wallet/by-username/{username}	1h	便利な検索
—	GET	/leaderboard?limit=50	30m	Polymarket の上位トレーダー一覧（未加工）
—	GET	/leaderboard/verified?min_edge=5	1h	スコア評価済みの人間に絞り込み
—	GET	/leaderboard/historical?date=…	DB	過去の任意の日付時点のリーダーボード
—	GET	/snapshots/latest	DB	cron が最後に実行された日時

ポジションの更新間隔が 30 秒なのはなぜですか？ Polygon のブロック時間は約 2 秒で、Polymarket のアクティビティインデックスには数秒の遅延があります。10 秒未満の間隔でポーリングしてもデータは新しくならず、レート制限エラーが増えるだけです。コスト、鮮度、上流への負荷のバランスが最適なのは 30 秒です。

DB 書き込みをデバウンスするのはなぜですか？ 取引エージェントは 1 時間に何千回も /wallet/{address} を呼び出す可能性があります。呼び出しごとに行を書き込むと、ほぼ重複したスナップショットで履歴が膨れ上がります。スコアエンドポイントがウォレットごとに保存するのは、1 時間あたり最大 1 回です。日次スナップショットジョブにより、API トラフィックに関係なく上位 50 件が必ず記録されます。

MCP サーバー（Claude Desktop、Cursor、Continue）

python mcp_server/server.py

次に、mcp_server/claude_desktop_config.example.json を Claude Desktop の設定に配置し、絶対パスを編集してください。

サーバーは 4 つのツールを公開します。

• score_polymarket_wallet(wallet_address) — 詳細なスコア
• score_polymarket_user(username) — 表示名で検索
• get_polymarket_leaderboard(limit) — 未加工のリーダーボード
• get_open_positions(wallet_address) — ライブベットの高速スナップショット

スコアリング方法

ボット判定トリガー（いずれか 1 つに該当 → ボット）

シグナル	しきい値	出典
集中度比率	> 12	Hubble Research、実証的に検証済み
保有時間の中央値	< 60s	HFT / MEV パターン
タイミング CV	< 0.3 (n≥100)	スケジュール取引

ソフトシグナルは累積します。暗号資産マーケットメーカーのパターン、1 日 200 件超の取引などがあります。

人間向けエッジスコア（0～10）

Hard gate: net realised PnL ≤ 0  →  capped at 2.0
Hard gate: < 10 winning markets  →  capped at 3.0

35%  PnL magnitude (log-scaled)
25%  win rate (capped at 70%)
15%  PnL distribution (penalises top-1 concentration)
15%  sample size (winning markets, capped at 50)
10%  win/loss ratio (capped at 3x)

実現損益が厳格な判定基準となるため、分散した小さな利益の陰に 37 万 5 千ドルの損失を隠している neutralwave23 のようなウォレットも、適切に低評価と判定できます。

PnL の再構築

money_in   = sum(BUY usdcSize per conditionId)
money_out  = sum(SELL usdcSize) + sum(REDEEM usdcSize)
pnl        = money_out - money_in

status:
  REDEEM exists                                    → won
  SELL exists, no REDEEM                           → exited
  no SELL, no REDEEM, last trade > 7 days old      → lost
  no SELL, no REDEEM, last trade within 7 days     → open

positions エンドポイントではなく activity を使う理由：redeem 後、ポジションは API から消えるため、/positions を使った単純な分析では勝ちが過少にカウントされます。必ず /activity?type=TRADE と /activity?type=REDEEM から再構築してください（個別に呼び出します。タイプをカンマで連結すると 400 が返されます）。

永続化（Supabase）

履歴データセットは他社に対する優位性です。毎日、スナップショットジョブがリーダーボードを取得し、上位 N 個のウォレットをスコアリングして、3 つのデータを保存します。スコアそのもの（wallet_scores）、その時点でのウォレットのオープンポジション（open_position_snapshots）、その時点のリーダーボード（leaderboard_snapshots）です。90 日後には、他では答えられない質問に回答できます。「過去 1 四半期にわたり、エッジ 7 を一貫して上回っていたのは誰か？」「上位 50 位に入ったばかりのウォレットはどれか？」「解決の 3 日前にこのマーケットで YES を保有していた全員を表示して。」

セットアップ

# 1. Create a Supabase project, get the URL and service_role key
cp .env.example .env  # fill in SUPABASE_URL and SUPABASE_KEY

# 2. Apply the schema (Supabase dashboard → SQL editor → paste db/schema.sql → run)
#    Or via psql:
#    psql "$DATABASE_URL" -f db/schema.sql

# 3. Run the snapshot job once to verify it writes:
python scripts/snapshot_job.py --top 10

SUPABASE_URL と SUPABASE_KEY が未設定の場合、API とスナップショットジョブはいずれもインメモリリポジトリにフォールバックします。テストスイートは引き続きパスし、API ではライブスコアリングを引き続き提供しますが、Supabase を接続するまでは履歴エンドポイントは空になります。

日次スナップショットジョブ

毎日 python scripts/snapshot_job.py --top 50 をスケジュールしてください（Railway cron、GitHub Actions、またはエッジ関数を起動する Supabase pg_cron など、方法は自由です）。ジョブはべき等ではありません。2 回実行するとスナップショットが 2 つ作成されますが、問題ありません。履歴クエリは最も近いものを選択します。

python scripts/snapshot_job.py --top 50              # production
python scripts/snapshot_job.py --top 5  --dry-run    # local testing, no writes

実行のたびに、開始時刻／終了時刻、スコアリングされたウォレット数、エラー数を含む監査行が snapshot_runs に記録されます。

スキーマの概要

テーブル	目的
wallets	これまでに確認されたウォレットごとに 1 行
wallet_scores	追記専用のスコア時系列
open_position_snapshots	各時点で各ウォレットが保有していたもの
leaderboard_snapshots	日次で保存されるリーダーボード全体
snapshot_runs	cron ジョブの監査証跡

2 つのビュー（latest_wallet_scores、latest_leaderboard）により、一般的な「現在の状態は？」というクエリを低コストで実行できます。

リポジトリパターン

db/repository.py では Repository プロトコルを定義しています。実装は 2 つあります。

• InMemoryRepository — スレッドセーフですが、再起動するとデータが失われます。テストと開発モードのフォールバックに使用します。
• SupabaseRepository — 本番環境向けです。supabase-py クライアントをラップします。

API とスナップショットジョブはプロトコルのみに依存します。Supabase を Neon またはセルフホスト可能な Postgres に切り替えるには、同じ 6 つのメソッドシグネチャを実装するクラスを 1 つ新たに作成してください。

料金設定の区分

エンドポイントの分割は、各ティアが課金モデルに明確に対応するよう設計されています。推奨価格帯は次のとおりです。

ティア	エンドポイント	推奨価格	理由
ディスカバリー	/wallet/{address}、/leaderboard/*	$0.001–$0.01 / 呼び出し	キャッシュの有効期間が長く、主に DB 読み取り
モニタリング	/wallet/{address}/positions	$0.01–$0.05 / 呼び出し	最新データを取得。毎回 Polymarket にアクセス
ストリーミング（v2）	ポジション変更の SSE フィード	$20–$100 / 月額固定	こちら側で継続的にデータを取得
履歴	/wallet/{address}/history など	$0.005 / 呼び出し	DB の読み取りのみ。時間とともに価値が高まる

ストリーミングエンドポイントは、本格的なコピートレードボットが実際に料金を支払うものですが、こちら側で継続的にデータを取得するワーカーが必要です。呼び出し単位のビジネスが成立する兆候を確認してから、v2 に向けて対応します。

デプロイ

Railway

リポジトリをプッシュして、そこを指定してください。残りは railway.toml が処理します。

Render / Heroku 形式

Procfile は用意されています。

キャッシュ

api/cache.py は、Redis クライアントと同じインターフェースを持つスレッドセーフなインメモリ TTL キャッシュです。複数ワーカーの本番環境では、1 つのファイルでシングルトンを redis.Redis() に置き換えてください。TTL は次のとおりです。

• ウォレットスコア：1 時間
• オープンポジションのみ：5 分
• リーダーボード：30 分
• 認証済みリーダーボード：1 時間

テスト

pytest -v

tests/fixtures.py の合成フィクスチャは、調査段階で確認した 3 つの実際のウォレットパターン（MLB に特化した人間のトレーダーである phonesculptor、HFT ボットの gabigol、ティルト状態で損失を出す neutralwave23）に加え、データの少ない初心者を模しています。テストはフィクスチャのみを対象に実行され、ライブ API 呼び出しは行わないため、テストスイートは決定論的で CI に安全です。

配布ロードマップ

1. 現在 — Railway 上の REST API、日次スナップショットの永続化に Supabase を使用
2. 次に — MCP Hub、Replit Agent Market、awesome-mcp-servers で公開
3. その後 — 呼び出しごとの x402 マイクロペイメント（USDC）、過去データのクエリーエンドポイント（強み：実行する日ごとにデータセットが拡大）

認証済みウォレットの例

以下は、テストフィクスチャの対象となるペルソナです。活動状況に応じて、実際の数値は異なります。

ウォレット	スコア	備考
phonesculptor	~9/10	MLB に特化した人間のトレーダー、分散した勝ち、実際の優位性
gabigol	ボット	5 分足の Up/Down 仮想通貨アービトラージ（2026 年 2 月以降、優位性はほぼ消失）
neutralwave23	~1/10	分散した小さな勝ちで大きな純損失を覆い隠している