全36章中の第36章

要約版

2026年4月28日、PolymarketはPolygon上の決済担保をUSDC.e(ブリッジされたUSDCトークン、コントラクト 0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174)からpUSDへ移行しました。pUSDはPolymarket発行のステーブルコインで、ネイティブUSDCと1:1で償還できます。Webアプリのトレーダー側で行うことは何もありません - 残高とポジションはスナップショットブロックで自動変換されました。APIおよびボット運用者は更新が必要です: すべてのCLOB注文署名内の担保資産アドレスが変更され、USDC.eに対して署名された古い注文はキャンセルされ、py-clob-client 0.40以降が必要です。このガイドでは、ボットを切り替え時およびその後も動かし続けるために必要な、正確なコード、コントラクト、承認の変更を説明します。

学べること: PolymarketがUSDC.eから移行した理由、コントラクトレベルで何が変わったのか、py-clob-clientの正確なアップグレード手順、新しい担保に対する許可を再承認する方法、交換後に残高を確認する方法、そして今ではほとんどのアカウントが保有しているレガシーなUSDC.eの端数をどう扱うかです。
前提条件: すでに動作するPolymarketアカウント、Polygonコントラクトの基本的な知識、そして2026年4月28日より前から存在するボットまたは手動APIワークフローが必要です。今日これから始めるなら、最新のSDKをインストールして第4章へ進んでください - USDC.eに触れる必要は一切ありません。
01
第1章

パート1: 3つのステーブルコイン、1つのPolygon

移行前、PolymarketのPolygon上のエコシステムには3つのUSDステーブルコインが存在していました。その違いを知ることが、Polymarketがなぜ場所を移したのかを理解するための最初の一歩です。

トークン発行者Polygon上のコントラクト準備金の種類
USDC.ePolygon PoS bridge0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174Ethereumメインネットからブリッジ
USDC (native)Circle0x3c499c542cEF5E3811e1192ce70d8cC03d5c3359ネイティブ、Polygon上で直接発行
pUSDPolymarket TreasurySee docs.polymarket.com/pusdネイティブUSDCに1:1で裏付け、毎月アテステーション

Polymarketは当初、2020年のローンチ時点でPolygon上のUSDCの主流バージョンだったため、USDC.eを選びました。その後CircleはPolygon上でネイティブUSDCを直接発行し、ブリッジ版が最終的に廃止されることを示しました。すべての市場をUSDC.eで決済し続けることは、ブリッジが突然停止するという長期尾部リスクにPolymarketをさらすことになります。Polymarketが管理するステーブルコインへ移行することで、その問題を解消し、同じ記帳単位を共有する将来の製品機能 - たとえば永久先物の証拠金、vaultへの入金、クロスチェーン受取 - を実現できます。

02
第2章

パート2: pUSDとは何か、そして何ではないか

pUSDは、標準的なPolygon上のERC-20トークン(chain id 137)で、6桁の小数を持ち、USDCと同じ精度です。Polymarket Treasuryコントラクトのみが発行でき、いつでも手数料なしでネイティブUSDCと1:1で償還できます(ネットワークのガス代は別途必要です)。pUSDを裏付ける準備金は分離管理された口座で保有され、第三者による保証付きで毎月報告されます。

pUSDはアルゴリズム型ステーブルコインではなく、暗号資産による過剰担保でもなく、利回りも生みません。Polymarket外でpUSDを保有している場合は、ネイティブUSDCに対するPolymarket発行のIOUだと考えてください - プラットフォーム内では便利ですが、必要に応じて償還可能であり、外部ウォレットで長期保有するメリットはありません。

監査と準備金: pUSDのスマートコントラクトはPolymarketの常任監査人による監査を受けています。準備金の保証レポートは毎月の頻度でdocs.polymarket.com/pusd-auditに公開されています。大きな残高を長期保有する前に、必ず両方を確認してください。
03
第3章

パート3: Webアプリのトレーダーが見たもの

polymarket.com だけで取引している場合、移行は見えませんでした。2026年4月28日のスナップショットブロック時点で:

  • Polymarketのプロキシウォレットに保有されていたすべてのUSDC.e残高は、1:1でpUSDに原子的に変換されました。
  • 保有中のポジションは、同じドル価値、同じアウトカムのオッズ、同じ満期を維持しました。条件付きトークンIDは変わりませんでした。
  • USDC.e建ての残存注文はスナップショット時点でキャンセルされました。移行後の新規注文は自動的にpUSDで署名されます。
  • 外部ウォレットへの出金は、USDC.eの送付からネイティブUSDCの送付に切り替わりました(または、要求に応じて、生のpUSD - ほとんどのユーザーには必要ありません)。

署名、トランザクション、設定の変更は不要でした。あなたにとって重要な残存指値注文は、移行後に手動で再度出し直す必要があります。キャンセルは一度限りの出来事でした。

04
第4章

パート4: APIとボット運用者 - 重要な変更

これは、対応しないとボットが動かなくなる部分です。

オーダー署名で何が変わったか: CLOB注文はEIP-712で署名され、型付きデータの一部として担保資産のアドレスを参照します。移行前、そのアドレスはUSDC.e(0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174)でした。移行後はpUSDです。古いアドレスに対して署名された注文は、CLOBで署名検証に失敗し、"invalid メイカー (maker) asset" または "signature mismatch" のエラーを返します。

py-clob-clientをアップグレードする

Polymarketは切り替えの2週間前に、pUSDを完全サポートしたpy-clob-client 0.40.0を公開しました。0.34.x系は移行翌日に廃止されました。

# pUSD対応版に更新
pip install --upgrade "py-clob-client>=0.40.0"

# 組み込まれている担保資産を確認
python -c "from py_clob_client.constants import POLYGON; \
print('pUSD address:', POLYGON.get('collateral'))"

新しいSDKは起動時にチェーン設定から担保資産アドレスを取得するため、何もハードコードする必要はありません。古いバージョンをforkしたり固定していた場合は、ロックファイルを削除し、最新のconstantsモジュールで再インストールしてから、テストスイートを再実行するのが最も安全です。

許可を再承認する

あなたのPolymarketプロキシウォレットには、あなたの取引アカウント → CTF ExchangeコントラクトからpUSDトークンへのERC-20許可が必要です。USDC.eに対する古い許可はチェーン上には残っていますが、完全に無意味です。CLOBはそれを消費しません。新しいpUSD許可がなければ、すべての注文は"INSUFFICIENT_ALLOWANCE"を返します。

from py_clob_client.client import ClobClient

client = ClobClient(
    host="https://clob.polymarket.com",
    chain_id=137,
    key=os.environ["POLY_PRIVATE_KEY"],
    funder=os.environ["POLY_FUNDER"],
    signature_type=1,  # Magic-linkアカウント向けのPOLY_PROXY
)
client.set_api_creds(client.create_or_derive_api_creds())

# 一度だけ: CTF ExchangeコントラクトのpUSDを承認
# (ヘルパーはpy-clob-client 0.40で追加)
client.update_balance_allowance(asset_type="COLLATERAL")

API認証情報を更新する

既存のAPIキーは引き続き動作しますが、4月1日以前に認証情報を生成した場合は、予防措置としてローテーションするべきです。L1のECDSA署名は、現在、新しい担保資産アドレスを含むドメインに結び付けられています。最も簡単な手順は次のとおりです:

creds = client.create_or_derive_api_creds()  # 冪等な再生成
client.set_api_creds(creds)

# .envに保存
print(creds.api_key, creds.api_secret, creds.api_passphrase)
05
第5章

第5部: 移行後のボットの検証

実際の資金でサイズ調整ロジックを動かす前に、この最小限のスモークテストを実行してください:

# 1. プロキシウォレット上のpUSD残高を確認
from py_clob_client.client import ClobClient
client = ClobClient(...)  # 上記のとおり
balance = client.get_balance_allowance(params={"asset_type": "COLLATERAL"})
print("pUSD残高 (生):", balance["balance"])
print("取引所への許可額:", balance["allowance"])

# 2. ティックから十分離れた場所に$1の指値注文を出す
from py_clob_client.clob_types import OrderArgs
order = client.create_order(OrderArgs(
    token_id=test_token_id,
    price=0.05,        # 市場からまったく離れている
    size=20,           # $0.05での$1建玉
    side="BUY",
))
resp = client.post_order(order)
print(resp)

# 3. キャンセルして確認
client.cancel(order_id=resp["orderID"])

3つの呼び出しがすべて成功すれば、接続は問題ありません。SDKはpUSDに対して署名し、許可額は認識され、注文台帳も整合しています。徐々に元の規模まで戻してください。

アップグレードのタイミングには十分注意してください: スナップショットのブロックをまたいでボットを連続稼働させていた場合、ローカルのオーダーブック状態はおそらく乖離しています。サイズを提示する前に、大きな取引所変更の後は常にRESTスナップショットと照合してください。
06
第6章

Part 6: よくあるエラーと修正

エラーまたは症状原因修正
signature verification failedUSDC.e EIP-712 ドメインに対して署名された注文py-clob-client を 0.40+ にアップグレードし、constants モジュールを再読み込みする
すべての注文で INSUFFICIENT_ALLOWANCEproxy から CTF Exchange への pUSD の allowance がないupdate_balance_allowance(asset_type="COLLATERAL") を 1 回実行する
invalid maker assetハードコードされた USDC.e アドレスが設定にまだ残っているハードコードされた担保アドレスをすべて SDK 定数に置き換える
ウォレットに移行後の USDC.e 残高が > 0 と表示される第三者による送金の残りとして "dust" トークンが残っているUSDC.e を Circle の CCTP でネイティブ USDC に戻すか、そのままにしておく
WebSocket の再接続で空のオーダーブックが表示される古いサブスクリプションが snapshot 前の古い market state を使用していたローカルキャッシュを削除し、REST のオーダーブックを再取得してから再購読する
外部ウォレットへの出金で USDC ではなく pUSD が表示される出金モーダルで "USDC" ではなく "pUSD" を選択した"USDC" を選ぶ - ブリッジが pUSD → ネイティブ USDC を 1:1 で変換する
07
第7章

パート7: Conditional Tokens、Order ID、そして変わらなかった他のもの

リファクタリングの範囲を誠実に保つために、移行を通じて変わらない識別子の一覧を示します:

  • Conditional Token contract (CTF): アドレスは同一です。YES / NO の ERC-1155 ポジションはそのままです。
  • condition_id and question_id: 市場パラメータから決定論的に生成され、担保の切り替えの影響を受けません。
  • token_id (outcome): condition_id + outcome index から導出され、変更されません。
  • Polymarket proxy wallet address: 同じアドレス、同じ Gnosis Safe スタイルのコードです。
  • API key, API secret, API passphrase: 引き続き有効です(ローテーションを推奨しますが、必須ではありません)。
  • WebSocket schemas: 同一です。新しい asset フィールドは、fill イベントでは "USDC.e" ではなく "pUSD" と読み取られます。
  • Gamma and Data APIs: 認証不要で、変更ありません。これらは担保トークンを直接参照していませんでした。
小さなUI変更が1つあります: Polymarket の proxy wallet 表示では、残高が pUSD で表示され、USD ラベルは 1:1 です。ブロックエクスプローラー(PolygonScan、Polygonscan API)では、proxy wallet の取引履歴に pUSD の ERC-20 転送が表示されます。以前の USDC.e 転送も履歴には引き続き表示されます。しばらくの間、あなたのアドレスには ERC-20 トークンの行が2つ並びます。
08
第8章

パート8: 税務と帳簿への影響

ほとんどの法域では、USDC.eからpUSDへの自動変換はUSDペッグのステーブルコイン同士の1:1の同種交換であり、課税イベントは発生しません。取得原価と保有期間は引き継がれます。

とはいえ、帳簿上で注意すべき項目が2つあります。

  1. 元帳スキーマを更新する。 Polygon取引をUSDC.eのコントラクトでフィルタリングする税務ツール、SQLite元帳、または会計士向けエクスポートは、移行後のすべての取引を静かに見落とします。pUSDのコントラクトアドレスを別名として追加してください。
  2. スナップショット変換に注記する。 ほとんどの制度では非課税でも、記録には変換を明示的に残してください-金額、ブロック、タイムスタンプ、そして1:1のステーブルコイン移行である旨の注記です。後であなたの法域から確認が入った場合に備え、明確な監査証跡を残しておきたいからです。

イスラエルのトレーダーは、ITA固有の報告についてTax Guideを参照してください。移行自体は標準的な取り扱いを変えませんが、コントラクトアドレスの変更は自動報告ツールにとって重要です。

09
第9章

第9部: 変更を経験した運用者からのプロのヒント

  1. requirements.txt で py-clob-client を >=0.40,<0.50 に固定する。 0.40系は pUSD 注文を正しく署名できる最小バージョンです。上限を固定しておけば、将来の破壊的変更を防げます。
  2. 低出来高の時間帯に再承認を行う。 update_balance_allowance の呼び出しは Polygon のトランザクション1回です。急な相場変動時に実行すると、ガス代の急騰を招きます。
  3. 4月28日より前に USDC.e 残高をスナップショットする。 変換は自動ですが、検証可能な移行前スナップショット残高があれば、照合の問題が起きた場合に異議申し立てする際に最も明確です。
  4. スナップショット前に未約定注文を手動でキャンセルする。 どうせ取引所側でキャンセルされますが、自分で行えば "system cancel" の行ではなく、きれいな台帳記録になります。
  5. 古いダッシュボードに注意する。 サードパーティの Polymarket ダッシュボード (PolymarketAnalytics、Polynance など) は、pUSD イベントを再解析するのに2日から3日かかりました。あなたのボットのローカルDBは、数日間は公開ダッシュボードより進んでいるかもしれません。
  6. USDC.e の端数は自分の都合のよいタイミングでブリッジする。 ほとんどのアカウントには、古い手数料還元や個人間送金による数セント分の USDC.e が残っています。Circle の CCTP か、標準の Polygon Portal ブリッジを使ってください - 急ぐ必要はありません。
  7. ブロックエクスプローラーのアラートには古い USDC.e アドレスを残しておく。 移行後にあなたのプロキシから USDC.e が何かしら引き出されることがあれば、それはすぐに調査すべき警告サインです。

次は何をしますか?

重要なポイント

PolymarketのpUSD移行は、すでにPolymarketボットを運用しているオペレーターにとって、低リスクの一度きりのリファクタリングです。py-clob-clientを0.40以上に更新し、pUSDの許可を再承認し、1ドルのスモークテストを実行して、再開してください。基盤となるインフラストラクチャー(CTF、condition IDs、token IDs、API keys)は変更されていないため、影響範囲は小さく、ロールバックの見通しも明確です。