YESとNOのトークンはどこから来るのか：分割・結合・償還

YESとNOは、一組分の担保で裏付けられた二つの権利として生まれます。 分割はその権利を作り、結合は再びまとめ、償還は記録された結果に従って支払います。別のトレーダーからトークンを買うことは、これとは別の操作です。

「PolymarketとKuestの仕組み」の第三回では、画面、取引、コントラクトの下にある資産を追います。支払額と価格の違いがまだ曖昧なら、予測市場の価格の意味からお読みください。

価格ではなく担保から考える

「観測所Aは、日付Cの12:00 UTCに都市Bの気温が30.0°C以上だったと公表するか」という仮定の問いを使います。情報源、丸め方、代替処理、取消ルールは定義済みとします。標準的な二択のConditional Tokens Framework（CTF）の条件を、YESが先、NOが後の順でモデル化します。

担保 は、ポジションを裏付けるために預ける資産です。この例では、勝ったトークン一つにつき担保一単位が支払われますが、一単位が必ず一ドルとは限りません。画面にドル記号があっても、ステーブルコインには発行体、移転、価値に関するリスクがあります。

以下の残高はすべて、手数料、ガス、資金調達費用を除きます。一つの条件と一種類の担保資産を使い、親ポジションは使いません。この前提により、別市場の資産を混ぜず、すべての単位を照合できます。

CTFは通常、担保にERC-20トークン、結果にERC-1155の残高を使います。ERC-1155では一つのコントラクトで多くのトークンIDを管理できます。気温の問いのYESと選挙の問いのYESは、同じ銘柄記号で表示されても別の資産です。

完全な組には正確な識別情報がある

条件の準備では、オラクル、質問ID、結果の数を登録します。担保を入金したり、誰かの結果トークン残高を作ったりはしません。確認対象のKuest CTFコードでも、条件の準備と分割は別の関数です。

CTFの条件IDはkeccak256(abi.encodePacked(oracle, questionId, outcomeSlotCount))です。オラクルのアドレスも識別情報の一部なので、同じ質問IDを別のオラクルに割り当てると、別の条件になります。

コレクション は、親コレクションがある場合はそれも含めた結果の集合を識別します。担保アドレスとコレクションIDが、ポジションを特定します。コレクションの導出には専用のアルゴリズムがあるため、ラベルを独自にハッシュせず、コントラクトのgetCollectionIdを使います。CTF開発者ガイドがこの構成を説明しています。

この二択の例で使う分割指定は[1, 2]です。最初と次の結果スロットを個別に選ぶビットマスクで、両方を合わせると重複なく全結果を覆います。親コレクションはすべてゼロの32バイトで、すでに条件付きの親ポジションではなく、担保から分割することを意味します。

したがって、タイトルの一致だけでは結合できません。ネットワーク、トークンコントラクト、条件、担保、コレクション経路を確認します。PolymarketのYESとKuestのNOは、問いが同じように見えるだけでは、ローカルの完全な組になりません。

分割：100を預けて、各結果を100ずつ受け取る

担保100単位から始めます。分割に成功すると、それをCTFコントラクトへ移し、呼出元に100 YESと100 NOを発行します。分割の実装は分割指定を検証し、一つのトランザクションでこれらの資産変更を行います。失敗すれば操作は取り消されます。

ウォレットには結果トークンが200ありますが、完全なペアは100組だけです。YESとNOの各ペアは担保一単位で裏付けられています。通常のYESという結果なら、そのYESに一単位、NOにゼロが支払われ、通常のNOなら逆になります。分割は在庫を作る操作で、資産を二倍にする操作ではありません。

両方を持つだけでは、方向性のある予測も表しません。マーケットメイカーは両側に売り注文を出す在庫を作るために分割することがあります。その後YESの一部を売ると、対応するNOが残るため、リスクの向きが変わります。分割だけで買い手が生まれたり、売買収入が確保されたりはしません。

通常の購入では、既存トークンをアカウント間で移転することもできます。他のトレーダーが既存のYESを10売れば、その人のYES残高が減り、自分の残高が増えます。その転送でYESやNOを新規発行する必要はありません。在庫の出所と、その取得価格は別の問いです。

結合：40組を焼却し、担保40を戻す

結果確定前に、対応する結果を同じ数量ずつ結合できます。100 YESと100 NOから40組を結合すると、コントラクトは各40を焼却し、担保40を返します。残るのは60 YES、60 NO、使用可能な担保40です。

この台帳が追うのは、自分のウォレットと、その完全な組に対応する裏付けだけです。コントラクト全体の残高ではありません。手数料、ガス、資金調達費用も引き続き除きます。

ウォレット残高は担保 / YES / NOの順で示します。

最終行は次に取り得る操作の一例であり、以下の償還例の前に実行する手順ではありません。費用控除前の初期残高へ戻ることで、利益ではなく数量の保存を示します。

60 YESに対し、対応するNOが20しかなければ、結合できるのは最大20組です。残りの40 YESには結果に応じたリスクが残ります。YES一つだけではNOの結果をカバーしないため、結果確定前に担保一単位を取り出せません。

結合の実装には支払結果が不要です。完全な組の再結合は結果確定前にもでき、関数の利用がその期間だけに限定されているわけでもありません。注文板の買い手を探すのではなく、ペアの裏付けを使います。

償還：最新価格ではなく結果を使う

先ほどの担保40、各結果60の状態に戻ります。記録された結果がYESなら、選択した残高の償還でYESには担保60、NOにはゼロが支払われます。ウォレットは費用控除前で担保100となり、償還したトークンは焼却されます。

60 YESだけを持つウォレットも、同じくYESの支払60単位を受け取ります。償還時に、所有者がNOも用意する必要はありません。これが結果確定前の結合との主な違いで、どの個別の権利に支払うかを記録済みの結果が決めます。

確認対象の償還関数では、選択した各ポジションの残高に対応する支払分子を掛け、分母で割ったものが支払額です。分母は記録された分子の合計です。このCTF関数は、選んだポジションの全残高を償還し、一部の数量を指定する引数はありません。

各トークン100について、[1, 0]はYESに100 / NOに0、[0, 1]はYESに0 / NOに100を支払います。通常のCTFで対応する[1, 1]の支払は分母が2で、各側に50を支払います。これは担保の受取額であって純利益ではなく、取得費用も考慮する必要があります。

この割合による支払機能は、取消時の返金を一律に約束するものではありません。市場のルールと結果確定の仕組みが、その結果を認める必要があります。連動したNegRiskイベントには、それ自体が対応する支払と復旧のルールが必要で、通常の二択の代替処理が使えるとは限りません。

コントラクトは最小単位の整数で計算し、割り算は切り捨てます。担保トークンの小数桁が六桁なら、100単位は最小単位で100000000です。最小単位一つに半額支払を適用するとゼロに切り捨てられます。画面の小数値を、そのままコントラクトの整数引数に渡してはいけません。

市場の終了時刻に達しただけでは、支払は確定しません。償還には、ゼロではない支払分母が記録されている必要があり、先にオラクルと設定された手続きが結果を提供しなければなりません。取引終了後も待ち時間が生じることがあります。

売却と償還は別の出口

売却には、執行できる買い注文が必要です。利用できる数量、実行費用、決済の成功を条件に、合意した価格で結果トークンを買い手へ渡します。結果が出る前にポジションを閉じられますが、表示された中間値は、利用できる買い気配ではありません。

償還は結果確定後に、記録された支払額と適切なコントラクト経路を使います。注文板に新しい買い手は不要です。0.60で取得し、勝った結果として一単位を受け取れば、一トークンの粗利益は0.40です。負けた結果なら損失は0.60で、どちらも費用控除前の値です。

両結果を結合価値より安く買う取引で費用控除前の差額を得るには、同じ完全な組の各側が、同量ずつ実際に約定する必要があります。未約定の片側、誤ったID、手数料、承認、トランザクションの失敗、担保リスクにより、差額が消えたり方向性リスクが残ったりします。気配値だけでは戦略を完了したことになりません。

Kuestの特徴：作成者の情報がポジションに結び付く

KuestはこのCTFの資産の仕組みを保ちつつ、条件の準備に作成者アドレスと外部メタデータ参照を追加しています。メタデータ更新関数は更新を作成者または管理者に限定し、旧参照、新参照、更新者を記録します。

運営者は、このコード上の仕組みで条件を作成者に関連付け、メタデータ参照の変更を追跡できます。ただし、市場文書の全文をCTF台帳に保存したり、表示中の全ルールを固定したり、支払額を決めたりはしません。アクセスできる文書と、明確に特定した結果確定経路は別途必要です。

CTFの公開ガイドは、ポジション台帳の分割・結合・償還を区別しています。NegRiskアダプターは別のコントラクト経路なので、同じ在庫操作を試す前に、公開インターフェースと担保を確認してください。

必要な権限も経路によって変わります。分割には、対象CTFまたはアダプターへの担保の支出許可が必要です。ネガティブリスクの結合・償還では、アダプターがCTFポジションを扱う権限も必要になります。取引用の承認で、これらの在庫操作も自動的に許可されるわけではありません。

2026年10月30日時点のバージョン確認： Polymarketの現在のポジション管理ドキュメントは、CTFの担保アダプターとProtocol V2のRouterおよびPositionManagerを区別しています。バージョン番号や似たメソッド名だけでは、別プラットフォームとの互換性は分かりません。実際のポジションに対応する、文書化された経路を使います。

上記のKuest CTFの説明は、Polygon上の公開・検証済みコントラクトで確認できます。ただし、各掲載市場で実際に使われる担保、権限、結果確定者を証明するものではありません。在庫操作を有効にする前にそれらを確認し、分割・結合・償還を別々の資産移動として示してください。

自分の読者やコミュニティ向けに準備していますか。Kuestで独自の予測市場を作成し、市場ルール、対象者の法域、必要な流動性を整理して、適切な運営構成を選びましょう。