2026年10月15日のWIREDの調査記事は、二つの選挙市場を取り上げました。MSR Decodeの分析を引用し、エチオピア市場の約2億8400万ドルの取引が、ペアになった口座間での反復売買によるものだと報じています。Polymarketは調査を行い、該当口座の取引を停止したと回答しています。

調べる価値のある指摘です。その根拠は取引相手間の循環であって、単に「落選候補の出来高が大きい」という話ではありません。ただ、自分でAPIを開いて検証するときにも、最初の集計で間違えがちです。候補者名の下にある金額は、すべてその候補者の勝利への賭けなのでしょうか。一つのハッシュが三回出たら、三件の重複取引なのでしょうか。

私は二つのイベントの累計金額、二つの小さな取引期間、Polygon上の三件のマッチング取引を確認しました。大きな出来高は調査先を示しますが、分解すべきなのは取引構造です。この二つの小さな期間では、名目取引金額の98%超が Noトークンの買いと売りの合計でした。「資金の98%が負ける側を買っていた」という意味ではありません。1ドル近辺のNoも繰り返し売買でき、通常の取引でも人為的な循環でも同じ分布になり得ます。区別には取引相手と資金フローが必要です。

疑惑と数値の定義を知りたい場合は金額比較から、収集ツールやインデクサーを作る場合はPython例とログの判定規則まで読んでください。

event、condition、tokenと累計金額

Polymarketでは、一つの選挙eventが複数の候補者市場を含みます。それぞれにconditionとYes/Noの二つの結果トークンがあり、どちらのトークンも買うことも売ることもできます。

event: 選挙イベント全体
  └─ condition: 特定の候補者が勝つか
       ├─ Yes token → BUY / SELL
       └─ No token  → BUY / SELL

保存したGamma APIのスナップショットでは、次のようになっていました。各イベントの子市場のvolumeを合計すると、イベント全体の値と一致します。

ここでの約6億5800万ドルは、APIスナップショットの全期間累計です。WIREDの見出しが扱うのは選挙結果が決まった後の取引ですが、この累計額を、各選挙の結果が明確になった時刻で分割してはいません。ここでは規模の比較にとどめ、「結果判明後の出来高」を再現した表とは扱いません。

MSRの2億8400万ドルは、何を分母にするのか

報道で丸められた$284,000,000をGammaの$286,138,162.70で割ると、約**99.25%**です。計算自体に問題はなくても、分子と分母の対象範囲が異なります。

MSRの公開研究とJSONデータ表には、研究自身の分母があります。対象期間は2026-04-28から09-09、Polygonのブロック範囲は86107336–93524955です。event_id=411239に属するエチオピアの七つの子市場行には、それぞれturnover_usdと、研究が検出したrecycled_usdが記載されています。七行を合計すると次の値になります。

**同じ表の比率は$283,964,639.89 / $285,027,224.40 ≈ 99.63%**で、MSRが小数第1位まで示した99.6%と一致します。この高い割合は、その七市場、その研究期間の結果です。

Gammaと同じ勘定にするには、七つのcondition_id、開始・終了ブロック、経済的な約定の数え方を合わせる必要があります。MSRの公開ルールでは、直接の持分取引は現金価格、ペアの作成・統合は1ペアあたり1ドルとし、経済的なfillを一度ずつ数えます。経路ごとに金額の定義が違うため、すべてをAPI片側のsize × priceに置き換えることはできません。

今回再計算したのは公開表の合計です。MSRは循環のエピソードを判定する具体的なしきい値を公開しておらず、公開censusとWIRED向け受託分析が同一の固定データ版かどうかも確認できていません。分類を独立再現するにはこの情報が不足していますが、「約2億8400万ドル」の公開出典と分母は確認できます。

二つの小さな期間でのNo取引

Adanech Abiebie市場は累計約8346万ドル、Nicolae Ciucă市場は約3億2650万ドルで、後者はルーマニアイベント全体の約87.8%です。候補者名は目立ちますが、実際に何が取引されたかはYes/Noまで分ける必要があります。

各市場の最新250件のtaker記録を取得し、その最初と最後の時刻が両端をまたぐUTC期間を選びました。

outcome=No, side=BUYはNoの購入、outcome=No, side=SELLはNoの売却です。この表は両方を取引金額に含めています。純買い越しやポジション変化は、口座、持分数量、売買方向を使って別途計算します。

二期間の合計は約9.89万ドル、二つの子市場の累計に対してわずか**0.0241%**で、無作為抽出でもありません。選んだ理由は、一ページで期間全体を覆えて、フィールドと計算を点検しやすかったからです。集計定義の例であり、両市場の全履歴を表すサンプルではありません。

Data API v2：現在の一ページは過去のスナップショットではない

公式OpenAPI契約では、GET /v2/tradesの絞り込みにconditionを使い、一覧はトップレベルのdata、各Tradeにはcondition_idがあります。ページ送りはpagination.next_cursor、taker_only=trueはtaker側の記録です。condition検索ではstart/endが無視されるため、時間のフィルタリングは取得後に行います。

カーソルなしのlimit=250は現在の最新ページを取得するだけで、保存した歴史スナップショットを固定しません。 記録の追加や訂正によって、ページが覆う時間は変わります。以下のスクリプトは現在のページが両方の時間境界をまたぐ場合だけ集計します。83件と対応額は保存時の結果であり、いつ実行しても同じ出力になる保証ではありません。

import json
from datetime import datetime, timezone
from decimal import Decimal
from urllib.error import HTTPError, URLError
from urllib.parse import urlencode
from urllib.request import Request, urlopen

CONDITION = '0x7d0aaf81bbd3fd73b6a1651cce08a452c0cbf9c0cbb4520ce0f981065b639d88'
START = int(datetime(2026, 9, 1, tzinfo=timezone.utc).timestamp())
END = int(datetime(2026, 9, 30, tzinfo=timezone.utc).timestamp())

def summarize(payload):
    rows = payload.get('data')
    if not isinstance(rows, list) or not rows:
        raise ValueError('Missing or empty v2 data list')
    if any(r['condition_id'] != CONDITION for r in rows):
        raise ValueError('Unexpected condition_id')
    times = [int(r['timestamp']) for r in rows]
    if times != sorted(times, reverse=True):
        raise ValueError('Unexpected trade ordering')
    if times[0] < END:
        raise ValueError('Upper bound unproven: older pages cannot fix this')
    if times[-1] >= START:
        raise ValueError('Window not bracketed: follow pagination.next_cursor')
    sample = [r for r in rows if START <= int(r['timestamp']) < END]
    amounts = {'Yes': Decimal('0'), 'No': Decimal('0')}
    for r in sample:
        size, price = Decimal(str(r['size'])), Decimal(str(r['price']))
        if not size.is_finite() or not price.is_finite() or size < 0 or not 0 <= price <= 1:
            raise ValueError('Invalid size or price')
        if r['outcome'] not in amounts:
            raise ValueError('Unlabelled outcome: inspect before aggregation')
        amounts[r['outcome']] += size * price
    return len(sample), sum(amounts.values()), amounts['No']

def build_request():
    params = urlencode({'condition': CONDITION, 'limit': 250, 'taker_only': 'true'})
    return Request('https://data-api.polymarket.com/v2/trades?' + params,
                   headers={'Accept': 'application/json',
                            'User-Agent': 'PolymarketVolumeCheck/1.0'})

if __name__ == '__main__':
    try:
        with urlopen(build_request(), timeout=20) as response:
            payload = json.load(response, parse_float=Decimal)
    except HTTPError as error:
        raise SystemExit(f'HTTP {error.code}: stop; check API access or Retry-After')
    except URLError as error:
        raise SystemExit(f'Network error: {error.reason}')
    count, total, no_total = summarize(payload)
    print('rows:', count)
    print('all:', total.quantize(Decimal('0.01')))
    print('No:', no_total.quantize(Decimal('0.01')))

CTF Exchange V2：ログを識別してから金額を定義する

Adanechについて別に取得したtaker_only=falseの100行は、49個の異なる取引ハッシュに対応していました。48ハッシュが複数回現れ、一つにつき最大3行です。100 - 49 = 51を計算して残りを水増し取引と呼べば、レスポンス行とオンチェーン取引を混同します。ハッシュごとに最初の行だけ残す方法も、一取引内の異なる記録を消してしまいます。

固定バージョンのCTF Exchange V2ソースはイベントの階層を示しています。一回のmatchOrdersが一つのtaker orderと複数のmaker ordersを処理し、makerの約定ごとにOrderFilledを出します。takerの処理後には別の集約OrderFilledが出て、その直後にOrdersMatchedが続きます。最後の二イベントを出すのが_emitTakerFilledEventsです。

確認した三取引の件数は以下のとおりです。これはイベント数の確認であり、両側の金額が等しいことの証明ではありません。

これは注文記録数であり、一ウォレットが複数注文を持つこともあります。taker集約イベントのOrderFilled.makerにも、積極側注文の作成者であるtakerOrder.makerが入ります。フィールド名makerだけでは受動側の明細かどうか判断できません。

同一トークンの直接売買とYes/Noのペア処理は別の勘定

まず同じ結果トークンのBUY対SELLという構成例で、集約の二重計上を考えます。1口$0.60で10口を購入し、4口と6口の売り注文を約定させたとします。maker明細は$2.40と$3.60、taker側の総額は$6です。三つを独立の経済的金額として足すと$12になります。これはA/B/Cの実際の金額の復元ではありません。

Yes/NoをまたぐMINT/MERGEは別の計算です。手数料も残余もないMINTの構成例なら、一方がYes10口に$4、もう一方がNo10口に$6を払い、合計$10の担保を作ります。異なる結果トークンへの支払いなので、taker集約イベントだからといって$6を$4の重複とみなせません。

直接売買の例: maker明細 2.40 + 3.60 = taker総額 6.00
MINTの例:    Yes支払 4.00 + No支払 6.00 = 担保 10.00

後者の純粋なMINTで単位がそろい、手数料や残余がない簡略関係では、takerの担保支払いは「ペアの担保総額－maker側の支払い」です。受け取る結果持分はもう一方の側で集約します。実際の実装ではside、tokenId、担保の桁数、手数料、残余も識別します。固定ソースの列挙値COMPLEMENTARYは同一トークンのBUY/SELL直接マッチを意味し、互補結果トークンをまたぐ買い同士・売り同士はMINT・MERGEです。名前に引っ張られないようにします。

maker明細とtaker集約は別テーブルで保持します。 ログ分類は記録の役割を決める作業で、経済的な出来高の定義はマッチタイプを識別した後です。イベント数が正しくても金額集計は間違い得ます。

集約イベントの識別

原始イベントの重複取得は(chain_id, transaction_hash, log_index)で除きます。ここでのlog_indexはRPCの**ブロック単位のlogIndex**です。この値をキーとするマップを作り、receipt.logsの配列添字に直接使わないでください。取引内インデックスを使う実装なら、全体をその方式に統一し、元の順序と隣接関係を保ちます。

次は擬似コードです。完全で成功した同一レシートと、上記V2経路と確認済みの発行コントラクトに限定します。ABIをデコードし、アドレスと整数表現を統一してから処理します。requireが一つでも不成立なら、そのレシートの自動集計を停止します。

for m in events_of(receipt, 'OrdersMatched'):
    f = log_at(receipt, m.log_index - 1)
    require(f.event == 'OrderFilled' and f.address == m.address)
    require((f.orderHash, f.maker, f.side, f.tokenId,
             f.makerAmountFilled, f.takerAmountFilled) ==
            (m.takerOrderHash, m.takerOrderMaker, m.side, m.tokenId,
             m.makerAmountFilled, m.takerAmountFilled))
    taker_summary_ids.add(raw_id(f))
maker_fills = [f for f in order_fills if raw_id(f) not in taker_summary_ids]

events_ofとorder_fillsに含めるのは確認済みコントラクトだけです。最後の行の前に、関連するすべてのOrderFilledが完全で説明可能なマッチ群に属することを確認します。ログ欠損、フィールド不一致、閉じていない群は調査用に保留します。一取引内で複数回マッチすることもあるので、群ごとに対応付けます。将来の版で隣接関係が変わったら、そのレシートの集計を止めて版を確認します。注文は複数呼び出しで部分約定し得るため、取引全体で同じorderHashの最後の行を拾う代替処理にはしません。両テーブルの金額を保持し、直接売買・MINT・MERGEごとの定義で計算します。

短時間の反転売買は、しきい値で見え方が変わる

二期間に同じルールを適用しました。同一代理ウォレット識別子・同一結果トークンでまとめ、数量差2%以内の逆方向売買を探します。一記録を使えるのは一組だけです。許容時間差だけを変えても、結果は大きく変わります。

15分ルールで選ばれた記録の金額は、各期間総額の**8.39%と2.50%**です。調査候補であって、確定した仮装売買ではありません。

構成した反例で違いが分かります。マーケットメイカーがNo100口を$0.985で買い、9秒後に同量を$0.986で売ると、手数料前の差額は$0.10です。通常の在庫調整でも、意図的な出来高循環でも、短時間・近い数量・逆方向という条件を満たし得ます。

追加で必要なのは取引相手の関係、ウォレット間の資金移動、手数料、在庫変化です。この同一ウォレットの反転検出は、WIREDが引用した「ペア口座が繰り返し相互に取引する」分析とは異なる条件です。

五分足のデータで最初の判断が変わった

AdanechのYesは2026年9月22日、隣り合う十二時間観測点のいくつかがすべて0.0030でした。最初は「取引は続いているが、粗い観測点の価格は変わらない」としか見えませんでした。五分間隔にすると、それでは不十分だと分かります。

全系列は通常の五分区間288個です。隣接点を比較すると価格変化は三回。次の表は変化直前の基準と三つの変化開始点だけを示し、変化しなかった区間を省いているため、連続する四サンプルではありません。

五分データには粗いサンプリングで消えていた下落と回復が現れます。ただし区間価格であり、価格インパクトの因果分析には当時の気配値、深度、情報発生時刻が必要です。

決済済み合約の履歴には末尾にresolution_seconds=0, price=0の償還端点も追加されていました。APIの規定に従い通常の五分点と分離し、決済状態はresolutionsで確認します。価格系列に混ぜれば、存在しなかったゼロへの暴落を描いてしまいます。

価格曲線やシグナル分析だけなら、まず履歴価格を使い、すべてのOrderFilledをオンチェーンから復元する必要はありません。しかし償還端点の除去はクリーニングの一段階です。期間カバレッジ、欠損区間、決済を確認し、戦略の実現可能収益まで推定するなら約定仮定、手数料、スリッページも検証します。履歴区間価格は、その価格で取引できる気配値ではありません。

再利用できる確認順序は、合約・時間・分母をそろえ、Yes/NoとBUY/SELLを分け、ログを識別してからマッチタイプ別に金額を定義することです。外部研究でも、公開表の再計算と分類器の再構築は別作業です。先に割合で議論するより、各層の根拠を残す方が有用です。株式バックテストにも似た分母問題があります。同じ銘柄が繰り返し選ばれると、量化戦略の勝率は信頼できるか？では、完全なPythonとSQLで三つの集計定義を比較しています。

本稿はデータ定義と実装の議論であり、取引助言ではありません。Gamma金額と局所期間は2026-10-20 UTCのスナップショット、MSR公開表・API契約・固定ソースは2026-10-21 UTCに確認したものです。