OKX Growth Competition — トレーディング競争

Agenticウォレット限定トレーディング競争。完全なライフサイクル：リスト → 詳細 → 参加 → トレード → ランク → 請求。

CLI リファレンス：references/cli-reference.md

すべてのAgenticウォレット競争に関する事実（バックエンドが別途確認しない限り常に正確）

<MUST> ユーザーが競争の仕組みについて質問する場合、以下を**事実の根拠真実**として扱う。`competition_detail`内の単一チェーン `chainName` から推論しないこと — そのフィールドは現在のところ、プライマリEVMチェーンのみを含みます。2番目のチェーンは、バックエンドがまだ別フィールドに分割していないハードコードされた製品の不変量です。 </MUST>

1. すべてのアクティブな競争はSolanaおよびバックエンドが返すチェーン上で同時に実行されます（例：chainName=X Layer → アクティビティはX LayerおよびSolana の両方で実行）。Solanaはすべてのアクティビティのハードコードされた2番目のチェーンです。
2. いずれかのチェーン上でのトレードは同じ競争スタンディングにカウントされます。 SolanaでX Layer対象の競争をトレードするユーザーは傍観者ではなく参加者です。同様にEVMトレードはSolana対象競争でカウントされます。（バックエンドが後でサポートされるすべてのチェーンをリストする複数チェーンフィールドを返す場合は、このハードコーディングを削除します。）
3. myRankInfo.userTotal = 0 は、ユーザーがまだ適格閾値に達していないか、バックエンドメトリクスパイプラインがまだトレードを取得していないことを意味します — ユーザーのチェーンがサポートされていないことを意味しません**。**userTotal=0観測に基づいて「あなたのチェーンはカウントされない」とユーザーに決して言わないでください。
4. competition_rank は単一のオプション wallet を受け取ります。自分のランクではそれを省略してください — ツールは competition_detail.chainId に基づいてアクティブアカウントからチェーン適切なアドレスを自動解決します。他人のランクをクエリする場合のみ明示的なアドレスを渡してください。アドレスチェーン（EVM 0x... またはSolana）はアクティビティチェーンと一致する必要があり、そうでない場合ツールは呼び出しを拒否します（チェーン間違いの無音クエリなし）。クエリするチェーンは単なるレンズです — 他のチェーン上のトレードは依然として同じランキングにカウントされます。
5. ポイント1～4の形状は、バックエンドがサポートされている完全なチェーンリストを公開するときに将来変更される可能性があります。それまでは、「このチェーン上でのSolanaのトレードはカウントされますか？」という質問に「はい」以外の答えで応じてください。

ユーザーが「このチェーン上でのSolanaのトレードはカウントされますか？」または「どのチェーンでトレードすべきですか？」のような質問をする場合、chainName だけではなく、このセクションに基づいて答えてください。

アドレス解決の不変量（決定論的 — 常に応答可能）

<MUST> 3つの単一アドレス競争ツール — `competition_rank`、`competition_user_status`、`competition_claim` — は**1つ**のアドレス解決アルゴリズムを共有します。バックエンド `walletAddress` パラメータは**常に正確に1つ**のアドレスです（両方ではなく、欠落もなし）。ユーザーが「どのアドレスを使いましたか？」と聞く場合、答えはアクティビティの chainId から**決定論的です** — 「両方」、「不明」、または「わかりません」で応じないでください。 </MUST>

アルゴリズム（常に内部で実行される。AIはバイパスできない）:

1. アクティビティの competition_detail.chainId を取得
2. chain_family() を介してマッピング：
   • "501" → Solanafamily → SOLアドレスを使用
   • その他（"1" Ethereum、"196" X Layer、"8453" Base、"42161" Arbitrum、…） → EVM family → EVM アドレスを使用
3. その1つのアドレスをAPIの walletAddress パラメータとして渡す
4. 他のチェーンのアドレスは同じ呼び出しで送信されません

「どのアドレスを使いましたか？」に答える方法：

アクティビティチェーン	送信されたアドレス	答え方（ユーザーの言語に翻訳）
X Layer / Ethereum / Base / BSC / Arbitrum / … (EVM family)	EVM	「あなたのEVMアドレス 0x... — アクティビティのプライマリチェーンが {chainName} (EVM family) だから」
Solana (chainId=501)	SOL	「あなたのSolanaアドレス ... — アクティビティのプライマリチェーンがSolanaだから」

禁止された回答（観察されたパターンを言い換え、間違っている）:

• ❌ 「competition_user_status はEVMとSolanaアドレスを区別しない」 — 間違い。アクティビティごとに選択します。
• ❌ 「両方のアドレスが自動的に渡されます」 — 間違い。APIは正確に1つ受け取ります。
• ❌ 「ツールが最終的にどちらを送ったかはわかりません」 — 間違い。これはアクティビティ chainId から決定論的です。常に応答可能です。

複数アクティビティクエリ（例：activity_name のない competition_user_status）の場合、アルゴリズムはアクティビティごとに実行されます。結果の各アクティビティは独立してチェーン適切なアドレスを選択します。したがって、答えはリストになります。「X Layer アクティビティはEVMアドレスを使用しました。SolanaアクティビティはSOLアドレスを使用しました」。

⚠️ 必読順序

<MUST> **競争に関するユーザー向けメッセージを作成する前に（リスト/詳細/参加/請求/ランク/ステータス/ウォレットエクスポートガード）、最初に以下の対応する `Step N` セクションを探し、その固定テンプレート構造に従う必要があります。** 形式を即興で作成しないでください。テンプレートを短くしないでください。セクションをドロップまたはマージしないでください。

テンプレート構造は固定です。言語はユーザーに従う — 上記の ## Output Language ルールを参照。ユーザーが中国語で書く場合、テンプレート文字列を自然な中国語に翻訳します。ユーザーが英語で書く場合は、書かれたとおりに英語を使用します。プレースホルダーと Solana リテラルはそのままです。

クイックルーター（ユーザー意図 → テンプレートセクション）:

• 「list competitions / show available competitions」 → Step 1（テーブル、オプションでActive / Endedに分割）
• 「show details / show rules / show prize pool」 → Step 2（基本情報ブロック + 4つの報酬セクション、ハードコードされた Solana, {chainName} と必須参加/Skillコピー付き）
• 「register / join」 → Step 3（登録成功固定テンプレート + 免責事項）
• 「trade for me」 → Step 4（okx-dex-swapに委譲）
• 「leaderboard / ranking」 → Step 5
• 「claim reward」 → Step 6（competition_claim MCP を使用、アトミック）
• 「show registered wallet」 → 追加フロー / 登録済みウォレットクエリ
• 「export wallet」 → 追加フロー / ウォレットエクスポートガード

ユーザーの意図が上記のいずれかに明確にマップされない場合、応答する前にどちらを意図したか尋ねてください — フリーフォーム形式を発明しないでください。 </MUST>

プリフライト

../okx-agentic-wallet/_shared/preflight.md を読んでください。見つからない場合は、_shared/preflight.md を読んでください。

コマンドインデックス

#	コマンド	認証	説明
1	onchainos competition list [--status 0|1|2] [--page-size N] [--page-num N]	なし	Agenticウォレット限定競争をリスト（デフォルト status=0、アクティブのみ）
2	onchainos competition detail --activity-id <id>	なし	ルール、賞金プール、チェーン、タイムラインを取得
3	onchainos competition rank --activity-id <id> [--wallet <addr>] --sort-type <type> [--limit N]	なし	リーダーボード + ユーザーランク。アクティブアカウントから自動解決するため --wallet を省略します。コマンドは competition_detail.chainId を取得し、チェーン適切なアドレスを選択します。他人のランクをクエリする場合のみ --wallet を渡してください — アドレスチェーンはアクティビティチェーンと一致する必要があり、そうでない場合は呼び出しが拒否されます。MCP ツール competition_rank はこれを反映します（単一オプション wallet）。competition_detail → tabConfigs[].rankFieldConfig[].sortValueMap.descend から利用可能な sort-type 値を発見してください（ハードコードしないでください）。
4	onchainos competition user-status [--activity-id <id>] --evm-wallet <evm_addr> --sol-wallet <sol_addr>	なし	参加と報酬ステータスをチェック。チェーン適切なアドレスを使用します（--activity-id を省略してすべてのアクティビティをチェック）。MCP ツール competition_user_status は両方のウォレット引数を可選にします — アクティブアカウントから自動解決。
5	onchainos competition join --activity-id <id> --evm-wallet <addr> --sol-wallet <addr> --chain-index <chain_id>	ウォレットログイン	競争に登録します。MCP ツール competition_join は両方のウォレット引数を可選にします。
6	onchainos competition claim --activity-id <id> --evm-wallet <addr> --sol-wallet <addr>	ウォレットログイン	CLI は署名されていないコールデータを返します。MCP ツール competition_claim はアトミック — ウォレットはオプション。署名 + ブロードキャストはツール内で実行され、txHashの配列を返します。

--status（リクエストフィルタ）: 0=アクティブ、1=終了、2=すべて
activityStatus（レスポンスフィールド）: 3=アクティブ、4=終了 — これらはリクエストフィルタからの異なる値です
sort-type：動的 — competition_detail → tabConfigs[].rankFieldConfig[].sortValueMap.descend から読み取ります。現在観察されている値：1=PnL% （実現ROI）、7=PnL（実現利益）。将来のアクティビティはさらに追加される可能性があります — ハードコーディングよりも常に tabConfigs を信頼してください。

出力ルール

内部専用IDと、ユーザー向けの表示。 内部数値ID（activityId、chainIndex、accountId）は目的上ツール応答で返されます — ツール間の呼び出しをチェーンするために必要です（例：competition_join の後、成功テンプレートを入力するため、アクティビティ id で competition_detail を呼び出す必要があります）。それらをデータレイヤーに保つ。ユーザー向けメッセージでレンダリングしないでください。

<NEVER> **どのような状況でも、どのような形式でも、ユーザーのために作成されたメッセージに内部 id を含めないでください。** アクティビティを識別する際はユーザーに **`activityName` (または名前が利用できない場合は `shortName`) のみ**で識別してください。 </NEVER>

禁止されているユーザー向けパターン（このような出力を生成しないでください）:

• ❌ Agentic Trading Contest (#107)
• ❌ #106 (agenticwallettest1)
• ❌ 「ID」または「#」というタイトルの列
• ❌ 「competition 107」または「id 107」のような参照

正しいユーザー向けパターン:

• ✅ Agentic Trading Contest
• ✅ 同じ名前の2つのアクティビティを区別する場合、chainName を追加します（例：Agentic Trading Contest (Solana)）、IDは使用しません。

背後でのハンドリング（許可され、期待されている）:

• ✅ competition_user_status / competition_join レスポンスから activityId を読み取り、固定テンプレートを入力するために必要なデータを取得するため competition_detail に渡す。
• ✅ 数値 id を介したツール間のチェーニング — 最終的なユーザー向けメッセージがそれらを省略する限り。

ユーザーが特定のアクティビティに対してアクションを実行するよう要求する場合（例：「claim Agentic Trading Contest」）、MCP ツール competition_claim / competition_join は activity_name を受け入れ、サーバー側で id を解決するため、独自のルックアップを行わずに名前を直接使用することもできます。

時間フォーマット（必須）

<MUST> 競争API からのすべてのタイムスタンプは、これらの正確なルールを使用してレンダリングする必要があります。時間変換を自由にスタイル化しないでください。 </MUST>

フィールドタイプ — これらは相互交換可能ではありません:

フィールド	形式	例（生値）	メモ
startTime、endTime、joinTime、claimTime	10桁Unix秒	1778148000	ランタイムが ms を期待する場合のみ 1000 を乗算
rankUpdateTime	13桁Unix ミリ秒	1774359000638	最初に1000で除算して秒に変換

ドキュメント化された場所に13桁の値が表示される場合（またはその逆）、静かに強制しないでください — バックエンド異常として報告してください。

表示形式 — 正確、即興は厳禁:

• 日時フィールド（startTime、endTime）: YYYY-MM-DD HH:mm (UTC+8) — 例：2026-05-07 18:00 (UTC+8)
• 日付のみコンテキスト（例：コンパクトリストテーブル）: YYYY-MM-DD ~ YYYY-MM-DD (UTC+8 日の境界) — 例：2026-05-07 ~ 2026-05-21
• joinTime / claimTime ユーザー向けコンテキストで表示：YYYY-MM-DD HH:mm (UTC+8)
• rankUpdateTime （最後の更新マーカー）: YYYY-MM-DD HH:mm:ss (UTC+8)

タイムゾーンルール： すべての競争時間がユーザーに表示される場合、UTC+8 （中国標準時）に変換されます。競争製品はUTC+8で運営されています。生のUTCを表示しないでください、ユーザーのローカルタイムゾーンを使用しないでください。

ステップバイステップ変換:

1. フィールドのドキュメント化された単位を特定（秒またはミリ秒 — 上記の表を参照）。
2. 正しい単位を使用してDate オブジェクトに変換。
3. 上記の形式に従ってUTC+8ウォールクロック文字列として形式化。
4. 常に日時表示に (UTC+8) 接尾辞を追加して、ユーザーが検証できるようにします。

<NEVER> - ❌ タイムスタンプから「現在の日付」のあなたのトレーニングデータセンスを使用して日付を精神的に計算しないでください — 常に明示的な数値変換を実行します。 - ❌ 秒とミリ秒を混在させないでください — 13桁の値を秒として扱うと年～58000 にランディングします。10桁の値を ms として扱うと1970にランディングします。 - ❌ `(UTC+8)` 接尾辞を日時文字列でドロップしないでください。 - ❌ ユーザーのローカルタイムゾーンを使用しないでください — ユーザーが海外にいても、競争時間はUTC+8で運営されています。 </NEVER>

出力言語

<MUST> **ユーザーの会話言語で固定テンプレートをすべてレンダリングしてください。** テンプレート構造（セクション、順序付け、番号付きリスト、テーブル列数、プレースホルダー位置、`Solana, {chainName}` や `[Disclaimer: ...]` ブロックのようなハードコードされたリテラルフレーズ）は固定であり、変更してはいけません。内部の自然言語テキストのみをユーザーの言語に自然に翻訳します。

プレースホルダーは翻訳されません。 {chainName}、{rewardUnit}、{txHash}、{accountName} など は API値を逐語的に入力されます — ローカライズしないでください。Solana（ハードコードされた2番目のチェーン名）も、すべての言語でそのままです。 </MUST>

実行フロー

Step 1 — 競争を発見

ステータスフィルタの選択

ユーザーの意図に基づいて、渡す status を決定します：

ユーザー意図	status を渡す	返された activityStatus 値
一般的なリスティング（「競争を表示」）	2 （すべて）	3（アクティブ）と4（終了）の混在
アクティブのみ（「今参加できるのは」）	0 （アクティブフィルタ）	3のみ
終了のみ（「優勝者リスト」）	1 （終了フィルタ）	4のみ

確実でない場合は、status=2 を選択して、ユーザーが全体像を見て選択できるようにしてください。

<MUST> **結果をmarkdownテーブルとして表示 — アクティビティごとに1行。番号付きプロサリストを使用しないでください、フィールドを単一の文に折りたたまないでください。**

結果にアクティブ（activityStatus=3）と終了（activityStatus=4）の両方のエントリが含まれる場合、太字サブ見出し（**Active** / **Ended**、ユーザーの言語に翻訳）の下に2つの別々のテーブルに分割し、その順序で。ステータスが1つだけ存在する場合、サブ見出しなしで単一テーブルをレンダリングします。 </MUST>

固定テーブルテンプレート（英語正典。非英語ユーザーのセルを翻訳）

**Active**

| Name | Chain | Time | Total Prize Pool | Details |
|------|-------|------|------------------|---------|
| {name} | Solana, {chainName} | {startTime} ~ {endTime} | {rewards} | [View](https://web3.okx.com/boost/trading-competition/{shortName}) |
| ... | ... | ... | ... | ... |

**Ended**

| Name | Chain | Time | Total Prize Pool | Details |
|------|-------|------|------------------|---------|
| {name} | Solana, {chainName} | {startTime} ~ {endTime} | {rewards} | [View](https://web3.okx.com/boost/trading-competition/{shortName}) |
| ... | ... | ... | ... | ... |

非英語ユーザーの場合、列ヘッダー、セクションヘッダー、リンクテキストを自然に翻訳してください。構造（列数、順序、Solana, {chainName} リテラル）は変わりません。

フィールドマッピングルール

• 行を availableCompetitions[].status でグループ化：3 → アクティブテーブル、4 → 終了テーブル。
• 名前列 ← name
• チェーン列 ← Step 2と同じハードコーディング：常にSolana と バックエンド chainName を含めます。
  • chainName がSolanaの場合 → 「Solana」と書く
  • それ以外の場合 → 「Solana, {chainName}」と書く（例：Solana, XLayer）
  • バックエンドが完全なサポートチェーンリストを返すまで一時的。
• 時間列 ← startTime ~ endTime を上記の時間フォーマットルールに従ってフォーマット。リストテーブルコンパクト形式：UTC+8 のYYYY-MM-DD ~ YYYY-MM-DD （例：2026-05-07 ~ 2026-05-21）。列を狭く保つためにコンパクトリストに時刻を含めないでください — 完全な時刻はStep 2詳細ビューにのみ表示されます。
• 総賞金プール列 ← rewards フィールド（既に形式化された文字列、例：50,000 USDC）
• 詳細列 ← https://web3.okx.com/boost/trading-competition/<shortName> をmarkdownリンク

テーブルの後、ユーザーに尋ねてください（ユーザーの言語で）:

• アクティブのみにエントリがある場合：「詳細で表示したい競争、または直接登録したい競争はどれですか？」
• 終了のみにエントリがある場合：「これらのいずれかのランキングまたは請求ステータスを確認したいですか？」
• 両方の場合：結合 — 「登録または表示したいアクティブな競争、またはランキング/請求を確認したい終了した競争はどれですか？」

空の結果処理（英語正典。ユーザーの言語に翻訳）

• すべてのフィルタが0エントリを返した → 現在利用可能なトレーディング競争はありません。
• status=0 フィルタが0エントリを返した → 現在アクティブなトレーディング競争はありません。
• status=1 フィルタが0エントリを返した → 終了したトレーディング競争はまだありません。

CLI 同等

onchainos competition list --status 2   # all
onchainos competition list --status 0   # active only
onchainos competition list --status 1   # ended only

Step 2 — 詳細を表示（リクエストされた場合）

onchainos competition detail --activity-id <id>

<MUST> **固定英語テンプレート下を使用して競争/報酬情報を表示します。** 構造（セクション、順序、番号付きリスト、プレースホルダー位置、ハードコードされた `Solana, {chainName}` チェーンプレフィックス）は固定です。テンプレートを文字単位でコピー。プレースホルダーを入力するだけです。言い換えたり、短縮したり、同義語を置換したりしないでください。

ユーザーの言語が英語でない場合は、構造、プレースホルダー、下記にリストされているすべての必須コンテンツ不変量を保持しながら、自然言語文字列をユーザーの言語に翻訳してください。セクションを並び替えたり、省略したり、マージしたりしないでください。 </MUST>

固定表示テンプレート

基本情報
対応チェーン：Solana, {chainName}
期間：{startTime} ~ {endTime}
総賞金プール：{totalPrizePool}

賞金カテゴリ：
実現PNL%賞金プール ({roiPoolAmount})
実現PNL%で高いものから低いものへランク付けします。
{roiRankTable}

実現PnL賞金プール ({pnlPoolAmount})
実現PnL額で高いものから低いものへランク付けします。
{pnlRankTable}

参加賞 ({participationPoolAmount})
Agenticウォレット経由で総取引量$100以上を蓄積し、競争期間中$100以上のウォレット残高を維持した登録ユーザーは、{participationPoolAmount}参加賞金プールを均等に共有します。競争期間中、ランダム資産スナップショットを取得して適格性を確認します。

スキル品質賞 ({skillPoolAmount})
スキル品質賞は独立して判定される賞です。競争期間中、参加者はイベントランディングページを通じてAgent Skillsを送信する場合があります。適格な提出物には、オンチェーン自律利回り戦略、取引分析、取引シグナル監視が含まれますが、これに限定されません。提出されたすべてのAgent Skillsは、AI事前スクリーニングと手動判定を組み合わせた二重レビュープロセスを通じて評価されます。スコアで上位 {skillTopN} のSkillクリエーターは、それぞれ {skillPerCreatorReward} の報酬を受け取ります。

フィールドマッピングルール

• チェーン行 ← Solana が最初、次にバックエンド chainName。具体的には：

  • chainName が既にSolanaの場合 → 「Solana」と書く
  • それ以外の場合 → 「Solana, {chainName}」と書く（例：Solana, XLayer）
  • これは一時的なハードコーディングです。バックエンドは現在のところプライマリチェーンのみを返すためです。将来のバックエンドリリースは、完全なサポート対象チェーンリストを別フィールドとして返します。その場合、このハードコーディングを削除してください。

• {startTime} / {endTime} ← 上記の時間フォーマットルールに従ってフォーマット。詳細ビューは完全な形式 YYYY-MM-DD HH:mm (UTC+8) を使用します（例：2026-05-07 18:00 (UTC+8)） — 常に (UTC+8) を追加してください。

• {totalPrizePool} ← すべての prizePoolDistribution[].totalReward の合計 + rewardUnit （例：50,000 USDC）。

• {roiPoolAmount} ← 実現ROIタブの totalReward。

• {pnlPoolAmount} ← 実現PnLタブの totalReward。

• {participationPoolAmount} ← 参加賞タブの totalReward。

• {skillPoolAmount} ← スキル品質賞タブの totalReward。

• {skillTopN} ← スキルタブの rules[].interval の上限（例："1-10" → 10）。

• {skillPerCreatorReward} ← そのルールエントリの reward + rewardUnit （例：500 USDC）。

• {roiRankTable} / {pnlRankTable} ← 対応するタブの rules[] から構築されたmarkdownテーブル。形式（英語正典。ユーザーの言語にローカライズ）:

  | Rank | Reward |
  |------|--------|
  | <interval-formatted> | <reward-formatted> |
  | ...                  | ...                |
  | Total | <totalReward> {rewardUnit} |
  

  行ごとの間隔/報酬フォーマット:

  • 単一ランク（interval = "1"） → ランクセル Rank 1、報酬セル <reward> <rewardUnit> （each プレフィックスなし）
  • 範囲（interval = "2-6"） → ランクセル Ranks 2-6、報酬セル <reward> <rewardUnit> each
  • 常にタブの totalReward + rewardUnit である報酬セルの総計行で終わります。

特定のアクティビティの4つのプールのいずれかが欠落している場合、そのセクションのみを省略します（他は保持）。

必須コンテンツ不変量（セクションごと）

セクション1 — 実現PNL%賞金プール

• タイトルは正確に実現PNL%賞金プール（またはユーザーの言語での忠実な翻訳）である必要があります。「PnL%ランキング賞」/「実現ROIランキング賞」/「実現ROIプール」で置換しないでください。
• 説明は以下を含む必要があります：実現PNL%によるランキング、高いものから低いものへ。
• ランクテーブルは Rank / Reward ヘッダーを持ち、Total 行で終わる必要があります。

セクション2 — 実現PnL賞金プール

• タイトルは正確に実現PnL賞金プールである必要があります。「PnLランキング賞」/「実現PnLプール」で置換しないでください。
• 説明は以下を含む必要があります：実現PnL額によるランキング、高いものから低いものへ。
• ランクテーブルはセクション1と同じ形式に従う必要があります。

セクション3 — 参加賞（製品から指定されたコピー）

• タイトルは正確に参加賞である必要があります。
• 説明本体は以下の特定の用語をすべて含める必要があります：
  • Agenticウォレット
  • 総取引量$100以上を蓄積
  • 競争期間中$100以上のウォレット残高を維持
  • 参加賞金プールを均等に共有
  • 適格性を確認するためのランダム資産スナップショット

セクション4 — スキル品質賞（製品から指定されたコピー）

• タイトルは正確にスキル品質賞である必要があります。
• 説明本体は以下の特定の用語をすべて含める必要があります：
  • 独立して判定される賞
  • イベントランディングページを通じたAgent Skillsの提出
  • 適格な提出物の例（オンチェーン自律利回り戦略、取引分析、取引シグナル監視）
  • AI事前スクリーニングと手動判定を組み合わせた二重レビュープロセス
  • 上位 {skillTopN} のSkillクリエーターが、それぞれ {skillPerCreatorReward} の報酬を受け取ります

<NEVER> - ❌ バックエンドの `chainName` が既にEVMチェーン（XLayer / Arbitrumなど）の場合でも、チェーン行から後続の `, Solana` をドロップしないでください。 - ❌ 4つの報酬セクションを並び替えたり、マージしたりしないでください — 1 → 2 → 3 → 4の順序で表示される必要があります。 - ❌ IDカラムを追加したり、ユーザー向けの出力の任意の場所で内部数値id（`activityId` など）を公開しないでください。 - ❌ セクション3と4で言い換え、短縮、または同義語を置換しないでください。これらは製品から指定されたコピーです。 - ❌ プール額からランク配分ルールを発明しないでください。実際のルールは `prizePoolDistribution[].rules[]` から来ます — それらを読んでください。除算しないでください。 - ❌ 4つの番号付きセクション内でマーカー（`-`）を使用しないでください — 構造は `1. タイトル (額)\n説明テキスト` その後ランクテーブル。箇条書きリストではありません。 </NEVER>

テンプレートの印刷後、尋ねてください：「この競争に登録していただきたいですか？」

Step 3 — 参加（ウォレットログイン必須）

MCP: activity_name と chain_index のみで competition_join を呼び出します — evm_wallet と sol_wallet はアクティブアカウントから自動解決されます。

CLI: アドレスを明示的に渡す：

onchainos competition join --activity-id <id> --evm-wallet <evm_addr> --sol-wallet <sol_addr> --chain-index <chain_id>

competition_detail → chainIndex フィールドから chainIndex を取得します。

ユーザーがログインしていない場合、ツールは not logged in — please run: onchainos wallet login を返します。ユーザーに逐語的に伝えてください：

この会話の内側からは実行できないため、ターミナルで onchainos wallet login <your_email> を実行してログインしてください。その後、再度登録するよう依頼してください。

必須プリフライト：重複登録シナリオを区別

<MUST> **`competition_join` を呼び出す前に、最初にアクティビティの `competition_user_status` を呼び出して、現在のアカウントの `joinStatus` を読む必要があります。** これにより、異なるユーザー向けメッセージを持つ2つの重複登録ケースを分離します。 </MUST>

シナリオ	user_status.joinStatus （現在のアカウント）	アクション	テンプレート
A — 現在のアカウントは既に参加済み	1	competition_join を呼び出さないでください	シナリオAテンプレート（下記）
B — 現在のアカウントは参加していない	0	competition_join を呼び出す	成功の場合 → 成功テンプレート。code=11016 の場合 → シナリオBテンプレート

シナリオA — 現在のウォレットが既に登録されている

テンプレート:

あなたの現在のウォレットアカウント [accountName] は [activityName] に既に登録されています。再度登録する必要はありません。ルールを詳しく説明してもらいたいですか、または直接トレードを開始しますか？

フィールドマッピング:

• [accountName] ← 現在選択されているアカウントの accountName （wallet_store / wallet status から読み取ります、例：Account 1）
• [activityName] ← 前の competition_user_status / competition_list レスポンスの activityName

シナリオB — 同じログイン、別のアカウントが既に登録されている

competition_join が code=11016 Participation limit reached を返すときにトリガー。

テンプレート:

登録に失敗しました。ウォレットアカウント [registeredAccountName] は既に登録されています。再度登録することはできません。登録済みアカウントに切り替えてトレードしてください。

フィールドマッピング:

• [registeredAccountName] ← 登録を保持している同じログイン内の別のアカウント。それを見つけるために、現在のアカウント以外の wallet_store のすべてのアカウントを反復し、アクティビティの competition_user_status を呼び出し、joinStatus=1 であるものを選択してください。アカウントが見つからない場合（稀なレース）、「あなたのウォレットアカウントの別のアカウントが既に登録されています」のような一般的なフレーズにフォールバックし、ユーザーに onchainos wallet status を自分で確認するよう要求してください。

登録成功

<MUST> **成功した `competition_join` 呼び出しのたび（ツールが `joined: true` を返す）、以下の固定テンプレートを出力します。** 構造（リードフレーズ + デュアルチェーン文 + 終了質問 + 自身の行にある括弧付き免責事項）は固定です。Solanaリテラルはハードコードされている。`{chainName}` と `{totalPrizePool}` は `competition_detail` から入力されます（テンプレートをフォーマットするときに必要に応じてそれを呼び出します）。自然言語文字列をユーザーの言語に翻訳しながら、構造、プレースホルダー、`Solana` リテラルを保持します。 </MUST>

テンプレート:

登録完了！この競争は {chainName} とSolanaで同時に実行され、総賞金プール {totalPrizePool} があります。取引コンテストは参加者をPnL%と実現PnLの両方でランク付けし、追加の参加賞とスキル品質賞があります。詳細なルールを説明してもらいたいですか、または {chainName} またはSolanaでトレードを開始するのをお手伝いしましょうか？

[免責事項：デジタル資産の取引にはリスクが伴います。価格は非常に変動しやすい場合があります。トレードする前に、リスクを完全に理解し、独自の調査を実施してください。]

フィールドマッピングルール

• {chainName} ← competition_detail からのバックエンド chainName （例：XLayer）。特殊なケース：バックエンド chainName が既にSolanaの場合、アクティビティは単一チェーンです — 文を「この競争はSolanaで実行されます」に折りたたみ、終了質問を「詳細なルールを説明してもらいたいですか、またはSolanaでトレードを開始するのをお手伝いしましょうか？」に折りたたみます。免責事項行は依然として最後に表示されます。
• {totalPrizePool} ← 総報酬プール（すべての prizePoolDistribution[].totalReward + rewardUnit の合計、例：500 DJT）。

<NEVER> - ❌ バックエンドのプライマリチェーンが既にEVMチェーンの場合でも、ハードコードされた `Solana` 言及をドロップしないでください — アクティビティは実際に両方のチェーンで実行されます。 - ❌ リード文の4つのキーフレーズをドロップしたり、マージしたりしないでください：(1)どの2つのチェーンで実行されるか、(2)総賞金プール、(3)デュアル軸PnL%/実現PnLランキング、(4)参加賞とスキル品質賞の存在。これらは必須コンテンツです。言い方はローカライズできますが、4つのピースすべてが表示される必要があります。 - ❌ 括弧付きの免責事項行をドロップしたりマージしたりしないでください — メッセージの最後に独立した行に表示される必要があります。ユーザーの言語で。 </NEVER>

その他のエラー

「地域」/「お客様の地域では利用できません」を含むエラー時：

登録失敗：サービスはお客様の地域では利用できません。サポート対象の地域に切り替えて、もう一度お試しください。

その他のエラーで：

操作に失敗しました。カスタマーサポートにお問い合わせください。

Step 4 — トレード（okx-dex-swapに委譲）

ユーザーが競争ルールに従ってトレードするよう要求する場合：

ケースA — ユーザーがCA を提供しない（トークン名/シンボルのみ）:

1. token_search MCP ツール経由でCAを解決します（CLI：onchainos token search）。
2. 進める前にユーザーに確認してください：

   確認ですが、トークン「{tokenSymbol}」のCAは「{contractAddress}」です。正しいですか？

3. ユーザーが確認するまで待ちます。明示的な「はい」の後のみ進めます。
4. その後、下記のケースB に従います。

ケースB — ユーザーがCAを直接提供：

1. スワップ実行 swap_swap MCP ツール経由（CLI：onchainos swap swap）。okx-dex-swap スキルでパラメータを参照してください。
2. レポート：「完了 — トレードが送信されました。」+ tx ハッシュ。

注：スワップを追加の「トークン価格は変動していますが、リスクを受け入れますか？」プロンプトで先制しないでください。ユーザーは既にトレードを要求しました — 追加の摩擦は不要です。トークンごとのリスクメタデータ（蜂蜜壺/極端なボラティリティフラグなど）は okx-security に属し、実際にフラグが立てられた場合のみ発火します。

トレードごとの競争制約:

• 単一トレード最小 $1（$1未満の注文はカウントされません）
• トークンペアは detail レスポンスの競争ルールと一致する必要があります

Step 5 — ステータスとランクを確認

参加ステータスを確認

onchainos competition user-status --evm-wallet <evm_addr> --sol-wallet <sol_addr>                       # all activities
onchainos competition user-status --activity-id <id> --evm-wallet <evm_addr> --sol-wallet <sol_addr>   # single

表示：参加ステータス、参加時間、報酬ステータス、報酬額。

• rewardStatus=1 （勝利、未請求）の場合：積極的に「報酬を獲得しました。請求するのを手伝いましょうか？」と尋ねてください。
• rewardStatus=3 （期限切れ）の場合：「報酬の有効期限が切れており、もう請求できません。」

リーダーボードを確認（フルボード）

<MUST> ユーザーが特定のリーダーボードを指定せずに「リーダーボードを表示」と言う場合、以下を実行する必要があります：

1. アクティビティの competition_detail を呼び出し、tabConfigs[].rankFieldConfig[].sortValueMap.descend を列挙します — これがアクティビティが公開するリーダーボードの完全なセットです。
2. sort_type ごとに1回 competition_rank を呼び出します（リーダーボードごとに1つのHTTP呼び出し）。すべてのリーダーボードのデータがあります。 3.応答内のすべてを表示 — リーダーボードごとに1つのセクション。アクティビティが複数のリーダーボードを持つ場合、1つだけのリーダーボードを静かにデフォルトにしないでください（例：sort_type=1 のみ）。

クリアに多すぎる場合（単一競争で≥3リーダーボード）のみ、ユーザーに1つを選択するよう求めます。1～2リーダーボード の場合、常にすべてをデフォルトで表示します。 </MUST>

tabConfigs[].rankFieldConfig[] フィールド:

• title — 表示名（例：PnL%、PnL）
• key — 内部ソートフィールド（例：pnl、realizedProfit）
• sortValueMap.descend — --sort-type として渡す数値

リーダーボードごとの取得:

onchainos competition rank --activity-id <id> [--wallet <addr>] --sort-type <descend> --limit 20

表示ルール： リーダーボードごとに、その title でラベル付けされた別々のセクションをレンダリング。各セクションは上位Nエントリを表示します：ランク、ニックネーム（マスク）、スコア（format フィールドでフォーマットされた userTotal）、推定報酬。

レスポンス例（2つのリーダーボードを持つアクティビティ）:

PnL%リーダーボード — プール 200 DJT ランク 1、Agentic....sMWP、PnL% +0.17%、推定報酬 100 DJT ランク 2、Agentic....gweD、PnL% +0.03%、推定報酬 20 DJT

PnLリーダーボード — プール 200 DJT ランク 1、Agentic....sMWP、PnL $0.1885、推定報酬 100 DJT ランク 2、Agentic....gweD、PnL $0.0006、推定報酬 20 DJT

リーダーボードの後、下記のセクションから「あなたのランク」セクションを使用して追加 — あなたは既にすべてのデータを持っているため、ケース1 / 2 / 3テンプレートを使用してください。

ユーザー自身のランクをチェック（すべてのリーダーボード全体）

ユーザーは複数のリーダーボードに同時に表示できます（例：PnL%とPnL）。ユーザーが「ランクは？」と聞く場合、アクティビティが公開するすべてのリーダーボードをクエリし、以下の3つの固定テンプレートのいずれかをレンダリングする必要があります。

必須フロー:

1. competition_detail を呼び出す → tabConfigs[].rankFieldConfig[].sortValueMap.descend を列挙して、このアクティビティの sort_type 値の完全なセットを取得します。
2. 各 sort_type に対して、competition_rank --sort-type <descend> を呼び出し、myRankInfo とリーダーボードの閾値（allRankInfos の最低 userTotal）を取得します。
3. 結果を分類：
   • ケース1 — ユーザーはすべてのリーダーボード上に currentRank > 0 を持つ
   • ケース2 — ユーザーはすべてではなく、少なくとも1つのリーダーボード上に currentRank > 0 を持つ
   • ケース3 — ユーザーはどのリーダーボード上にも currentRank > 0 を持たない
4. 一致するテンプレートを出力し、ユーザーの言語でレンダリングします（英語正典以下。中国語/その他言語ユーザーはローカライズ）。

<MUST> **以下の一致するテンプレート構造を正確に出力してください — データフィールドを言い換えない。2つのリーダーボードセクションを1つに折りたたまないでください。自然言語文字列をユーザーの言語にローカライズ。プレースホルダー、数値、ユニットは逐語的に保つ。** </MUST>

ケース1 — PnLとPnL%の両方でランク付けされている

テンプレート:

実現PnLランキング:
あなたは現在ランク #{pnlRank}、推定報酬 {pnlReward} {rewardUnit}！

実現ROIランキング:
あなたは現在ランク #{roiRank}、推定報酬 {roiReward} {rewardUnit}！

| リーダーボード | マイランク | 推定報酬 |
|-------------|---------|------------------|
| 実現PnL | #{pnlRank} | {pnlReward} {rewardUnit} |
| 実現ROI | #{roiRank} | {roiReward} {rewardUnit} |

両方のランキング全体の総推定報酬：{totalReward} {rewardUnit} （2つの合計）

ケース2 — 1つのリーダーボードでランク付けされた。もう1つのリーダーボードではランク外

2つの対称的なサブケースがあります。構造は同一です：ランク付けされたリーダーボードが最初に行き（「ランク#N、推定報酬X」）、次にランク外（「リーダーボードに未掲載、現在の値Y、閾値Z」）。各サブケースは独自の固定テンプレートを持つ — ランク外セクション単位を即興で作成しないでください（PnL% には %、PnL には通貨 $）。

ケース2-A — PnLに乗せる、PnL%から外す(sort_type=7のcurrentRank > 0; sort_type=1 == 0)

テンプレート:

実現PnLランキング:
あなたは現在ランク #{pnlRank}、推定報酬 {pnlReward} {rewardUnit}！

実現ROIランキング:
まだリーダーボードに掲載されていません。あなたの現在の実現ROIは {currentRoi}%です。適格となるには、少なくとも {minRoi}%（現在のリーダーボード最小値）が必要です。

ケース2-B — PnL%に乗せる