原文

ERC-XXXX: NFT-Bound Prediction Markets (LMSR pricing, on-chain state) — OFTRH (2026-07-21)

ERC-XXXX: NFTに紐付けられた予測市場（LMSR価格設定、オンチェーン状態）

概要

この提案は、NFTに1対1で紐付けられた予測市場の標準を提案します。各ERC-721トークンは、他の場所で開催される市場のレシートではなく、単一のバイナリ（YES/NO）市場そのものです。市場の状態（質問テキスト、現在のオッズ、プール残高、解決ステータス）はオンチェーンに存在し、トークンのtokenURI SVGとしてレンダリングされるため、NFTは自己完結型で、どのウォレットでも判読可能です。

価格設定には、固定流動性パラメータbを持つオンチェーンのLMSR（対数マーケットスコアリングルール）が使用され、ネイティブチェーン通貨で決済されます。トークンホルダーは市場の質問を設定し、そのトークンの寿命にわたって取引ごとの手数料を獲得し、解決後に市場を新しい質問にリセットできます。解決は、オプティミスティックな紛争期間を持つオラクル駆動型です。

この設計の意図は、今日の予測市場よりも広範です。許可不要なトークンローンチャー（Pump.fun）を爆発的に普及させたローンチメカニズムを、予測市場（Polymarket）の決済の明確さに統合します。その結果、ローンチ可能で、所有可能で、取引可能な市場プリミティブが生まれます。これは、トークンをミントするのと同じ方法でミントし、手数料を伴うポジションを保有するのと同じ方法で保有する市場です。

動機

テーゼ：次のローンチプリミティブはコインではなく市場である

許可不要なトークンローンチャーは、ローンチに対する莫大な潜在需要を示しました。何百万ものユーザーが、既存のものを取引するだけでなく、他者が取引するものを創造したいと考えています。しかし、ローンチされたミームコインは不透明な金融商品です。その価格は、実際の質問から抽象化されたローソク足チャートであり、新規ユーザーはそれが「安い」のか、「高い」のか、「天井に達した」のかを推論できず、ローンチャーは自身が作り出した継続的な取引量を一切捕捉しません。

バイナリ市場は判読性の問題を解決します。平易な言葉の質問（「XはY日までに起こるか？」）に紐付けられた市場は、トークンチャートよりも非専門家が推論するのに劇的に簡単です。

• YESは買い。NOは売り。 この両面のアクションは、すべての新規参入者がすでに持っている直感にマッピングされます。
• 総取引量は依然として総取引量 — トレーダーがすでに追跡しているソーシャル/アテンション指標は、翻訳後も存続します。
• ローソク足も、時価総額計算も、「これが天井か」もありません — 全体のメンタルモデルは1つの質問と2つのボタンです。

この標準は、市場がローンチプリミティブとなることを提案します。クリエイターはトークンをミントするのと同じ方法で市場をミントし、質問を設定し、そして — 決定的に — その市場がその全寿命にわたって生成する手数料ストリームを所有します。 ローンチャーは最終的に、自身が作り出す取引量と一致します。

なぜ市場をERC-721トークンに紐付けるのか

既存の予測市場設計では、市場を(a)プロトコルが所有するシングルトン（Augur、Polymarket）または(b)オンチェーンペイアウトを持つ一時的なデータベース行として扱っています。どちらも、トークンを面白くする構成可能性を放棄しています。

• 市場を転送したり、NFTマーケットプレイスで販売したりすることはできません。
• オフチェーンメタデータなしでは、ウォレットのNFTビューで市場のライブ状態を表示することはできません。
• 市場の経済的メリット（手数料）は、市場自体とは別に販売または委任することはできません。

市場をERC-721トークンに紐付けることで、これら3つすべてが解決されます。市場は所有者（トークンホルダー）を持ち、取引可能であり、自己完結型の状態をあらゆるERC-721対応インターフェースにレンダリングします。質問の所有権は、スマートコントラクトのパーミッションエントリではなく、譲渡可能でキャッシュフローを生む権利となります。 NFTを売却すると、市場とその将来の手数料ストリームが一緒に売却されます。ホルダーは実質的に、生産的な資産を売却していることになります。

反断片化：1つのNFT、1つの市場

ローンチャーの失敗モードはコピー＆ペースト戦争です。人気のあるローンチは、その注目と取引量を吸い上げるために即座にクローンされます（「バンピング」）。ここでの各トークンは、独自の流動性、価格履歴、および発生した手数料を持つ単一の異なる市場であるため、オリジナルの状態を捕捉するクローンは存在しません。 トークンを複製しても市場は複製されません。市場の流動性、実績、手数料ストリームは正確に1つのトークンに紐付けられており、アドレスをコピーしてもフォークできません。これにより、ファンジブルなローンチを悩ませる敵対的なプレイヤー対プレイヤーのダイナミクスが排除され、各市場に永続的なアイデンティティが与えられます。

仕様

準拠するコントラクトはERC-721を実装し、以下のインターフェースを公開しなければなりません。価格計算、解決フロー、レンダリングは以下に指定します。

interface IOFT /* is IERC721 */ {
  // ----- Market lifecycle -----
  function setQuestion(uint256 tokenId, string calldata question, uint64 lockTime) external;
  function resetMarket(uint256 tokenId, string calldata newQuestion, uint64 lockTime) external;
 
  // ----- Trading -----
  function buy(uint256 tokenId, bool outcome, uint256 minShares) external payable returns (uint256 shares);
  function sell(uint256 tokenId, bool outcome, uint256 shares, uint256 minReturn) external returns (uint256 payout);
  function redeem(uint256 tokenId) external returns (uint256 payout);
  function refund(uint256 tokenId) external returns (uint256 refunded);
 
  // ----- Resolution -----
  function resolve(uint256 tokenId, bool outcome) external;
  function dispute(uint256 tokenId, bool proposedOutcome) external payable;
 
  // ----- Views -----
  function marketState(uint256 tokenId) external view returns (MarketState memory);
  function priceOf(uint256 tokenId, bool outcome) external view returns (uint256 priceWad);
  function costToBuy(uint256 tokenId, bool outcome, uint256 shares) external view returns (uint256 cost);
}

LMSR価格設定。 コスト関数 C(q_yes, q_no) = b · ln(exp(q_yes/b) + exp(q_no/b))。取引コストは C(q_new) − C(q_current) です。結果の価格は exp(q_i/b) / (exp(q_yes/b) + exp(q_no/b)) です。実装は、少なくとも18桁の精度を持つ固定小数点演算（PRBMath、ABDK、または同等品）を使用しなければなりません。bは市場作成時に設定され、サイクルごとに不変です。

手数料。 準拠する実装は以下をサポートしなければなりません。

• ownerFeeBps — NFTホルダーに発生し、すべてのbuyおよびsellで支払われます。
• protocolFeeBps — デプロイ時に設定されたトレジャリーアドレスに発生します。

どちらもベーシスポイント値です。手数料の発生は市場ごとであるため、市場の転送は手数料ストリームをトークンとともに転送します。これが、トークンを生産的で売却可能な資産にするメカニズムです。ホルダーは市場の寿命にわたるすべての取引で収益を得て、その権利はNFTとともに移動します。

解決。 二段階です。

1. 提案。 lockTime後、オラクルまたは許可されたリゾルバーがresolve(tokenId, outcome)を呼び出し、紛争期間（例：24時間）を開始します。
2. 紛争。 期間中、誰でも結合されたチャレンジでdispute(tokenId, proposedOutcome)を呼び出すことができます。紛争中の市場は、より遅い解決パス（例：UMA、2番目のオラクル、または所有者署名）にフォールバックします。

レンダリング。 tokenURIは、質問テキスト、現在のYES/NO価格、プール残高、および解決状態をレンダリングするSVGを含むデータURIを返します。これは自己完結型でなければなりません（外部画像URLなし、IPFS依存なし）。これにより、フロントエンドがオフラインでも市場がウォレットで判読可能になります。判読性はこの標準の第一級の目標です。オンチェーンレンダリングにより、非専門家が一目で市場を読み取ることができます。

理論的根拠

なぜERC-1155や市場レジストリではなく、市場ごとに1つのNFTなのか？ ERC-721は、既存のマーケットプレイス流動性、ウォレット表示、ロイヤリティ強制機能を備えた、広くサポートされている唯一の「1つのものに1人の所有者」プリミティブです。単一のコントラクト内の市場レジストリは転送セマンティクスを失い、転送セマンティクスこそが、手数料ストリームを売却可能な資産にするものです。

なぜCPMM（Uniswapスタイル）ではなくLMSRなのか？ LMSRはマーケットメーカーに限定された損失（bによって限定される）を与え、流動性に関わらず常に価格が提示可能であることを保証し、LPからの初期流動性提供を必要としません。未知の取引量を持つバイナリ結果の場合、これはよく研究されており、CPMMよりも厳密に優れています。また、新しくミントされた市場は、一貫した価格で即座に取引可能であることを意味します。これは、設計目標が「ミントすればライブ」である場合に不可欠です。

なぜラップされたステーブルコインではなくネイティブ通貨なのか？ 1つの依存関係と1つの承認ステップを削除します。これは、設計がターゲットとする新規参入者のフローにとって重要です。実装はERC-20バリアントを提供してもよいですが、基本仕様はネイティブです。

なぜプロトコル設定ではなく所有者設定の質問なのか？ それはトークンを生産的にします。ホルダーは、各サイクルで自分のNFTがどの市場を表すかを決定します。リセットセマンティクスと組み合わせることで、1つのNFTはその寿命にわたって多くの市場にサービスを提供でき、所有者はそれらすべてで収益を得続けることができます。

後方互換性

ERC-721、ERC-2981（二次販売のロイヤリティ）、およびERC-165（インターフェース検出）と完全に互換性があります。既存のNFTマーケットプレイスは、これらのトークンを修正なしで表示および取引します。

セキュリティに関する考慮事項

• LMSRの精度。 素朴な固定小数点exp/lnはドリフトする可能性があります。参照実装には、qの全範囲にわたって許容範囲内でprice_yes + price_no ≈ 1を主張する不変条件テストを含めるべきです。
• ペイアウト時のリエントランシー。 sell、redeem、refundはネイティブ通貨を転送します。標準的なチェック・エフェクト・インタラクションとリエントランシーガードが適用されます。
• 転送時の手数料会計。 所有者手数料の発生はNFT転送時に決済されなければなりません。これにより、購入者が未請求の手数料を継承せず、販売者がそれを失わないようにします。
• オラクル捕捉。 提案 → 紛争フローは、ほとんどの場合、正直なオラクルを前提としています。実装は、フォールバックリゾルバーと紛争ボンドのサイズ設定を文書化すべきです。
• 返金パス。 市場が解決されない場合（タイムアウトを超えてオラクルが沈黙した場合）、許可不要な返金パスはすべてのトレーダーの担保を按分して返還しなければなりません。

未解決の質問

特に以下の点についてフィードバックを歓迎します。

1. インターフェースの表面。 resetMarketはsetQuestionと十分に異なり、別の関数を正当化するか、それとも解決済み市場での質問設定は暗黙的にリセットすべきか？
2. 多結果拡張。 仕様はインターフェースレベルでN項の結果に対応すべきか、それともバイナリが基本でN項は別のERCとすべきか？（「YESは買い / NOは売り」という判読性の議論はバイナリで最も強力であり、表現力と比較検討する価値があります。）
3. 紛争ボンド通貨。 ネイティブかERC-20か？ネイティブは依存関係を低く保ちますが、ボンドを変動性の高い資産で表示します。
4. SVGレンダリング予算。 完全なオンチェーンSVGはガスコストがかかります。base64データURIは許容されるか、それとも軽量なサムネイル + 別途marketMetadataURIが規範的であるべきか？
5. b（流動性深度）の可変性。 サイクルごとに固定するのが最も単純で安全です。一部の実装は資本効率のために動的なbを望んでいますが、標準で対応するか、拡張機能に任せるか？

参照実装は進行中であり、議論がインターフェースを凍結するのに十分落ち着いたらリンクされます。LMSRの精度、オラクルエスカレーション、またはオンチェーンSVGレンダリングに取り組んだ経験のある方からのフィードバックを特に歓迎します。

お読みいただきありがとうございます。

twitter: oftrobinhood · site: oftrh.xyz

1 post - 1 participant

Read full topic