openttt-pot

@helm-protocol/ttt-mcp

draft-helmprotocol-tttps のリファレンス実装（IETF 実験仕様）

Proof-of-Time 証明 — Ed25519 署名付きタイムスタンプと複数ソースによる裏付け、明示的な誤差範囲。IETF draft-helmprotocol-tttps

---

EU AI Act 第 50 条 — AI 生成コンテンツの透明性

TTTPS は、AI 生成コンテンツの作成時に暗号学的な時刻由来情報を提供します。pot_generate の呼び出しにより、コンテンツレコードの暗号学的ハッシュに改ざんを検知できるタイムスタンプを結び付けます。埋め込みメタデータには依存しません。

C2PA との相補性：C2PA メタデータは、再撮影、トランスコード、形式変換の際に削除されます。TTTPS は外部アンカーとして残り、メタデータチェーンの継続性に依存せず独立して検証できます。埋め込みマーカーがない場合でも、コンテンツの由来をフォレンジックに再構成できます。

設計上 GDPR に準拠：PoT レコードにはコンテンツも個人識別情報も含まれません。各レコードは、暗号学的ハッシュ（SHA-256 + HMAC-SHA256）を複数ソースによる時刻証明に結び付けます。平文コンテンツが Helm サーバーを経由したり、保存されたりすることはありません。

IETF 仕様： draft-helmprotocol-tttps （ISE トラック）。お問い合わせ：[email protected]。

---

問題：ワークフローの記憶喪失

Claude Code の長期ワークフローは、どれも同じ壁に突き当たります。コンテキスト圧縮によってアクション履歴が消去されます。

エージェント B は、エージェント A が何を決定したかを記憶していません。エージェント A は、過去の手順の記録がないまま圧縮後に再開します。作業が重複し、決定が失われ、状態が破損します。

ttt-mcp は、コンテキスト圧縮後も残る外部の因果チェーンです。

ワークフローのすべてのステップは、外部サーバー上の暗号学的タイムスタンプに結び付けられます。このサーバーは Claude のコンテキストウィンドウから物理的に分離されています。圧縮が発生したとき、エージェントは pot_query(eventId) を呼び出して O(1) で該当ステップを正確に取得し、因果関係の全コンテキストを保ったまま再開します。

Claude workflow → [context compressed] → agents call pot_query(eventId)
                                         → external server returns full timeline
                                         → workflow resumes, zero lost state

---

数学的保証

レイヤー	仕組み	保証
ID	SHA-3 eventId（256 ビット）	衝突確率 2⁻²⁵⁶ — 実質ゼロ
検索	O(1) の正確な取得	履歴再構築でコンテキストを消費しません
順序	TTTPS 因果タイムスタンプ	イベントの全順序 — 改ざん不可能な順序証明
因果チェーン	prevEventId DAG	O(深さ) の走査 — 10 億トークンのワークフローで深さは約 100
否認防止	Ed25519 署名	誰がいつ操作したかを示す暗号学的証明
耐障害性	消失訂正符号化された暗号学的シャード	BER=0.05 で ≥97% の復旧率、BER=0.02 で 99.88%（理論値）
永続性	Redis AOF + 90 日の TTL	サーバーはコンテキスト圧縮や再起動後も稼働します

---

クイックスタート

Claude Code

claude mcp add ttt -- npx -y @helm-protocol/[email protected]

API キーを使用する場合（無料枠がご利用プランの月間上限まで引き上げられます）：

claude mcp add ttt -e TTT_API_KEY=your-key -- npx -y @helm-protocol/[email protected]

Claude Desktop

claude_desktop_config.json に追加します：

{
  "mcpServers": {
    "ttt": {
      "command": "npx",
      "args": ["-y", "@helm-protocol/[email protected]"],
      "env": { "TTT_API_KEY": "your-key" }
    }
  }
}

Cursor

ワンクリックでインストールするか、上記と同じ mcpServers ブロックを .cursor/mcp.json に追加します。

無料枠：IP あたり 1 日 100 回 — 登録は不要です。

---

5 分間テスト

接続したら、Claude で次の手順を実行します。

ステップ 1 — ワークフローのステップを記録する：

Claude に自然な言葉で伝えます。

「このステップを my-first-step として記録して」 「今行ったことを refactor-auth-step1 として記録して」

Claude は自動的に pot_generate を呼び出します。直接呼び出すこともできます。

pot_generate(eventId: "my-first-step")

ステップ 2 — コンテキスト圧縮をシミュレートする： 新しい Claude セッションを開始します

ステップ 3 — 新しいセッションで復元する：

Claude に伝えます。

「my-first-step で何をしましたか？」 「最後のワークフロー状態を復元して」

または直接呼び出します。

pot_query(eventId: "my-first-step")

→ 正確な記録が返されます。記憶喪失は解消です。

ステップ 4 — 因果関係の連鎖を構築する：

pot_generate(eventId: "step-2", prevEventId: "my-first-step")
pot_graph(eventId: "step-2", depth: 5)

→ 完全な遡及チェーンが返されます。暗号技術で順序が保証されます。

---

10 個のツール

ツール	目的
pot_generate	暗号技術によるタイムスタンプでワークフローのステップを記録します
pot_verify	PoT 署名を検証します
pot_generate_v2	draft-11 の 180 オクテット PoT Record v2 コア（標準ワイヤープロファイル）を生成します
pot_verify_v2	v2 レコードを検証します。オプションで TLS 1.3 エクスポーターのバインディング証明を検証します（TLS がない場合はフェイルクローズします）
pot_verify_v08	draft-08 §3 Payload Digest レコードを検証します
pot_query	eventId による O(1) の完全一致検索 — 記憶喪失からの復元の中核です
pot_graph	因果関係 DAG をたどります（前後のチェーン）
pot_checkpoint	イベントを圧縮サマリーにまとめます — 約 100 件のイベントごと、または長いタスクの前に使用してください
pot_stats	サーバーの統計情報とモードの状態を表示します
pot_health	ヘルスチェックを実行します

---

ツールのパラメーター

pot_generate

暗号技術によるタイムスタンプでワークフローのステップを記録します。Claude Code では、eventId と prevEventId を使用します。DeFi では、txHash、chainId、poolAddress を使用します。アテステーションを特定のコンテンツに紐付けるには（draft-08 §3 Payload Digest）、contentDigest も指定します。eventId、txHash、contentDigest のいずれかが必須です。

パラメーター	型	必須	説明
eventId	string	いずれか	ワークフローステップの識別子。例："refactor_auth_step1"
prevEventId	string	いいえ	前のステップの eventId — ステップを因果関係の連鎖につなげます
txHash	string	いずれか	トランザクションハッシュ（DeFi、0x プレフィックス付きの 16 進数）
chainId	number	いいえ	EVM チェーン ID（DeFi）
poolAddress	string	いいえ	DEX プールのコントラクトアドレス（DeFi）
contentDigest	string	いずれか	このレコードがアテステーションするコンテンツの SHA-256 ダイジェスト（小文字の 16 進数、64 文字）。呼び出し元が計算します。サーバーがコンテンツを参照することはありません。ローカル時刻の合成が draft-08 独自の要件（3 つ以上の独立したソース、表現可能な誤差範囲）を満たす場合、応答には仕様準拠の potRecordV08 バイナリレコード（16 進数）が含まれます。満たさない場合は、理由を potRecordV08Error で説明します。
ctxId	string	いいえ	draft-08 §3.3 のコンテキスト識別子（Commitment ドメインセパレーター、最大 255 オクテット）。既定値は固定のサーバー値です。公開してもかまいません。

pot_verify_v08

pot_generate の potRecordV08 フィールドで生成された draft-08 §3 レコードを検証します。Commitment を再計算し、Ed25519 署名を確認します。また、content が指定されている場合は、レコードの Payload Digest と照合します。

Parameter	Type	Required	Description
potRecordV08	string	Yes	16 進数でエンコードされた 184 または 216 オクテットのレコード
ctxId	string	No	pot_generate で使用した値と一致する必要があります。一致しない場合、検証は失敗します
issuerPubKey	string	No	16 進数でエンコードされた 32 バイトの Ed25519 生公開鍵。デフォルトでは、このサーバー自身の鍵が使われます
content	string	No	レコードの Payload Digest フィールドと照合するペイロード
clientId	string	TTTPS_REQUIRE_REPLAY_LEDGER=1 の場合は必須	リプレイキーに使用する、呼び出し元の安定した識別子
sessionId	string	TTTPS_REQUIRE_REPLAY_LEDGER=1 の場合は必須	リプレイキーに使用する、有効なトランスポート／セッション識別子

TTTPS_REQUIRE_V08_FRESHNESS=1 の場合、TTTPS_V08_MAX_SKEW_NS に非負の整数を設定する必要があります。検証器は、maxSkewNs + errorBoundUs の範囲外にあるレコードを拒否します。TTTPS_REQUIRE_REPLAY_LEDGER=1 の場合、検証が成功すると Redis で clientId/sessionId/nonce が 90 日間の TTL でアトミックに確保されます。Redis の障害または 2 回目の確保は拒否されます。これらのフラグはフェイルクローズ制御です。

現在の MCP 正規ワイヤープロファイルは draft-11 PoT Record v2（180 オクテット）です。pot_generate_v2 と pot_verify_v2 は、オクテット 0〜79 の SHA-256 整合性検証と、オクテット 0〜115 に対する Ed25519 発行者認証を含む、固定コアレコードを実装しています。draft-08 は、レガシー環境との相互運用専用として pot_verify_v08 で引き続き利用できます。TLS バインディング証明は別個の 64／32 オクテット値です。TTTPS_V2_REQUIRE_BINDING=1 の場合、サーバーが直接 TLS 1.3 上で実行されていない限りフェイルクローズします。stdio とプレーン HTTP には TLS エクスポーターがありません。HTTPS モードでは MCP_TLS_CERT_FILE と MCP_TLS_KEY_FILE を設定してください。リプレイの確保では、TTTPS_REPLAY_TTL_SECONDS（デフォルトは 86400）を使用し、(ctx_id, nonce) をキーとします。

pot_query

Proof of Time レコードを検索します。コンテキスト圧縮後に O(1) で正確に検索するには、eventId を使用してください。

Parameter	Type	Required	Description
eventId	string	No	ステップの完全一致検索 — 衝突確率は 2⁻²⁵⁶
startTime	number	No	開始時刻（unix ms）。デフォルト：24 時間前
endTime	number	No	終了時刻（unix ms）。デフォルト：現在
limit	number	No	返すエントリの最大数。デフォルト：100、最大：1000

pot_graph

任意のステップから因果チェーンをたどります。後方チェーン（祖先）と前方チェーン（子孫）を返します。

Parameter	Type	Required	Description
eventId	string	Yes	たどり始めるステップ
depth	number	No	後方にたどる最大深度。デフォルト：10、最大：100

返される値：

• backwardChain — 時系列順の祖先（大規模なチェーンでは深度圧縮されます）
• forwardChain — 指定した eventId の後に続くステップ
• chainBroken — ギャップが検出された場合は true（祖先がリングバッファから削除された、またはチェーンのルートが不明なエントリを参照している場合）
• brokenAt — ギャップの原因がサーバー再起動によるインメモリ状態の消去の場合は "server_restart"、それ以外の場合はチェーンが途切れた eventId。チェーンが完全な場合は null
• reachableDepth — ギャップ（またはチェーンのルート）に達する前に正常にたどれた祖先の数

因果チェーンにギャップが生じる原因：

• server_restart：サーバーが再起動し、インメモリ DAG が消去されました。Redis が利用可能で、REDIS_URL が設定されている場合は、起動時に Redis から DAG が再構築され、再起動によるギャップが減少します。
• リングバッファからの削除：リングバッファは、直近の 10,000 件のイベントをメモリに保持します。この期間より前の祖先は chainBroken: true として表示され、brokenAt には到達可能な最古の eventId が設定されます。

ギャップからの復旧：長時間のタスクを始める前に pot_checkpoint を呼び出して、トークン予算内でチェーンを圧縮・保持するか、Redis 永続化を使用して再起動後も状態を維持してください。

pot_verify

パラメーター	型	必須	説明
potHash	string	はい	検証する PoT ハッシュ（0x プレフィックス付きの 16 進数）
grgShards	string[]	はい	16 進数でエンコードされた暗号学的整合性シャードの配列
chainId	number	はい	EVM チェーン ID
poolAddress	string	はい	Uniswap V4 プールアドレス

pot_stats

パラメーター	型	必須	説明
period	"day" | "week" | "month"	はい	統計の対象期間

pot_health

パラメーターはありません。

pot_checkpoint

ワークフロー履歴の圧縮ロールアップチェックポイントを作成します。

次の場合に使用します： コンテキストの上限に近づいたとき、長時間のタスクの前、または約100イベントごと。

パラメーター	型	必須	説明
fromEventId	string	いいえ	範囲の開始 — 因果チェーンに含める最初の eventId
toEventId	string	いいえ	範囲の終了 — 因果チェーンに含める最後の eventId
startTime	number	いいえ	Unix ms。デフォルト：1時間前
endTime	number	いいえ	Unix ms。デフォルト：現在
maxTokens	number	いいえ	ロールアップ出力のおおよその最大トークン数。デフォルト：2000

戻り値：

• checkpointId — 一意のチェックポイント識別子
• rollup — 圧縮されたイベント履歴（深度に応じて適応：full／compact／minimal／rollup）
• summary — チェックポイントの、人が読める1行の要約
• chainIntact — 因果チェーンが途切れていないかどうか
• nextCheckpointHint — 次のチェックポイントまでに推奨されるイベント数

深度に応じた適応型圧縮：

深度	形式	約トークン数
1–5	完全なエントリー	約200／イベント
6–20	コンパクト（id+hash+ts）	約80／イベント
21–50	最小（id+ts）	約30／イベント
51+	ロールアップ文字列	約10／イベント

---

ユースケース

1. Claude Code ワークフロー — 記憶喪失の防止

問題：20個のエージェントが動的ワークフローを使って、500K行のコードベースを数時間かけてリファクタリングします。コンテキストが圧縮されるたびに、エージェントはすでに処理した内容を記憶していません。作業が重複し、状態が破損します。

解決策：各エージェントは pot_generate(eventId, prevEventId) で各ステップにスタンプを付けます。圧縮後、pot_query(eventId) を呼び出すと、外部サーバーから正確なアクション履歴（何を、いつ、どの順番で実行したか）を復元できます。サーバーは Claude のコンテキストウィンドウの外部にあるため、圧縮による影響を受けません。

// Agent starts a workflow step
const pot = await client.callTool({
  name: "pot_generate",
  arguments: {
    eventId: "refactor_auth_module_step3",
    prevEventId: "refactor_auth_module_step2"
  }
});
// pot.potHash — cryptographic proof this step happened at this time

// After context compression, agent recovers its history:
const history = await client.callTool({
  name: "pot_query",
  arguments: { eventId: "refactor_auth_module_step3" }
});
// history.local[0] — exact record: timestamp, prevEventId, potHash
// history.found: true — O(1) lookup, collision probability 2⁻²⁵⁶

// Traverse full causal chain:
const chain = await client.callTool({
  name: "pot_graph",
  arguments: { eventId: "refactor_auth_module_step3", depth: 20 }
});
// chain.backwardChain — all ancestor steps in chronological order
// chain.forwardChain — steps that follow this one
// chain.chainBroken — true if a gap was detected in the ancestor chain
// chain.brokenAt    — "server_restart" if the server restarted and cleared
//                     the in-memory DAG; otherwise the eventId of the oldest
//                     reachable ancestor before the gap; null if chain intact
// chain.reachableDepth — how many ancestors were recovered before the gap

// Handle a server-restart gap:
if (chain.chainBroken && chain.brokenAt === "server_restart") {
  // Server cleared in-memory state; ancestors before the gap are gone unless
  // Redis was configured (REDIS_URL) — in that case the DAG was rebuilt on
  // restart and chainBroken will be false.
  // Recover by querying the most recent checkpoint or restarting from a known step.
}

長時間のタスクの前、または約100イベントごとに、チェックポイントを作成します：

// Compress workflow history before context fills up — by causal range:
const checkpoint = await client.callTool({
  name: "pot_checkpoint",
  arguments: {
    fromEventId: "refactor_auth_module_step1",
    toEventId: "refactor_auth_module_step3"
  }
});
// checkpoint.checkpointId — store this; resume from it after compression
// checkpoint.rollup — depth-adaptive compressed history (10–200 tokens/event)
// checkpoint.chainIntact: true — causal chain verified unbroken
// checkpoint.nextCheckpointHint: 87 — suggested events before next checkpoint

// Or compress by time window with a token budget:
const checkpoint = await client.callTool({
  name: "pot_checkpoint",
  arguments: {
    startTime: Date.now() - 3_600_000,  // last 1 hour
    maxTokens: 1500
  }
});

// After context compression, restore from checkpoint instead of re-querying all events:
const history = await client.callTool({
  name: "pot_query",
  arguments: { eventId: checkpoint.checkpointId }
});
// Full causal context restored in a single call

結果：作業の重複はゼロです。コンテキストが完全にリセットされた後でも、ワークフロー全体のタイムラインを復元できます。

---

2. MEV ボット — トランザクション順序の証明

問題：フロントランされました。それを証明できません。メンプールのタイムスタンプはノードごとに異なり、署名されておらず、信頼できるものではありません。

解決策：送信の前に毎回 pot_generate を呼び出します。PoT レシートは、互いに独立した3つの時刻ソース（NIST、Google、Cloudflare）を使用して暗号学的に署名されます。オンチェーンハッシュは、別途用意された Base Sepolia TTT ERC-1155 コントラクトを介してアンカーできます。フロントランが発生した場合、攻撃者のブロックへの取り込みより前のタイムスタンプ付き記録が残ります。

const pot = await client.callTool({
  name: "pot_generate",
  arguments: { txHash: pendingTxHash, chainId: 8453, poolAddress: "0x..." }
});
// pot.potHash — your evidence, timestamped by NIST+Google+Cloudflare

注： DeFi パス（txHash + chainId + poolAddress）を使用するには、整合性シャードのパイプラインを有効にしたサーバーサイドビルドが必要です。公開版の openttt npm パッケージでは利用できません。これがない状態で呼び出すと、エラーが発生します。Claude Code パス（eventId）はそのまま使用できます。

---

3. DEX プロトコル — サンドイッチ攻撃の抑止

解決策：TTTHookSimple（Uniswap V4 フック、Base Sepolia：0x8C633b05b833a476925F7d9818da6E215760F2c7）を統合します。誠実なビルダーには turbo モードが適用されます。改ざんされたシーケンスには full モード（ペナルティ遅延）が適用されます。ガバナンスではなく、経済的な仕組みで実現します。

注： シャードベースの検証（grgShards を使用する pot_verify）には、整合性シャードのパイプラインを有効にしたサーバーサイドビルドが必要です。公開版の openttt npm パッケージでは利用できません。

---

4. ヘッジファンド／プロップデスク — MiFIR 第22c条への準拠

問題：MiFIR 第22c条／RTS 25では、マイクロ秒精度でUTC同期されたタイムスタンプが必要です。ハードウェアPTPアプライアンスの費用は5万～50万ドルです。

解決策：pot_generateは、不確実性の上限と複数ソースによる証明を伴うEd25519署名付きタイムスタンプを生成します。RTS 25の監査記録形式と構造的に互換性があります。取引ごとにAPIを1回呼び出します。

const audit = await client.callTool({
  name: "pot_generate",
  arguments: { txHash: tradeHash, chainId: 8453 }
});
// audit.timestamp: high-resolution timestamp
// audit.uncertainty: ± bound (RTS 25 uncertainty field)
// audit.confidence: fraction of sources that agreed

精度に関する注意： デフォルトのネットワーク時刻ソース（Roughtime／NTP）が提供する不確実性の上限は数ミリ秒です。MiFIR 第22c条／RTS 25の±1ミリ秒（およびそれより厳しい）要件を満たすには、GEO時刻ソース（KTSat）の追加が必要です。これはロードマップ上の構成であり、デフォルトのデプロイではありません。

成果：構造的に互換性のある監査証跡。IETF仕様：draft-helmprotocol-tttps。

---

5. マルチエージェント連携 — 因果順序の証明

問題：複数のAIエージェントがパイプライン内でやり取りする場合、デバッグと監査では因果順序が重要です。エージェントのログは検証できません。

解決策：各エージェントはpot_generateを使って自身のアクションにタイムスタンプを付与します。potHashチェーンは独立して検証できます。pot_graphは、誰が何をどの順番で実行したかを再構築します。

---

違い —「優れている」のではなく、役割が異なります

ツール	統合方法	想起する内容	完全性	ホットパスのコスト
Letta (MemGPT)	エージェントループを所有	自己編集型のセマンティックメモリ	なし	メモリ操作ごとに埋め込み＋ベクトル検索
LangGraph / LangMem	LangGraphのみ	グラフ状態／セマンティック情報	なし	チェックポイントI/O（＋埋め込み）
RAG / vector DB	後付け	あいまいな類似性	なし	アイテムごとに埋め込み＋ベクトル検索
ttt-mcp	2分でMCPに後付け統合	正確な因果ステップ（eventIdによる）	Ed25519＋TTTPSタイムスタンプ	署名＋ハッシュ＋書き込み — 埋め込み呼び出し0回

コストの違いは構造的なものであり、偶然ではありません。

LettaとMem0はエージェントメモリをセマンティック検索の問題として扱います。想起のたびにLLMの埋め込み呼び出しとベクトル検索が必要です。ttt-mcpはLLM／埋め込みレイヤーを完全に迂回します。状態の復元はO(1)の暗号学的ハッシュ検索です。追加コストは汎用CPUとストレージであり、APIトークンではありません。

対象範囲：エージェントはチェックポイントとして記録する価値のあるステップにタイムスタンプを付与します。すべてのトークンやクエリが対象ではありません。処理量はチャット全体のトラフィックではなく、意思決定の数に応じて増加します。

過去の会話に対するあいまいなセマンティック検索が必要な場合は、LettaまたはベクトルDBを使用してください。コンテキストの圧縮後も機能する、長期ワークフロー向けの埋め込み不要で決定論的な状態復元レイヤーが必要な場合は、ttt-mcpを使用してください。

---

料金

プラン	価格	月間呼び出し数
Free	$0	1日あたりIPごとに100回 — 登録不要
Dev	$29/mo	100K
Pro	$99/mo	1M
Team	$299/mo	10M ＋超過分は1K回あたり$0.01
Enterprise	$999+/mo	月間1億回 · 超過分は1K回あたり$0.001 · SLA 99.9%
Platform License	要相談（年額$2M以上）	上限数は要相談 · ネイティブ統合

購読：

Dev $29/mo · Pro $99/mo · Team $299/mo — 購読するには、[email protected]までメールでお問い合わせください。

EnterpriseおよびPlatform License：[email protected]

お問い合わせ：[email protected]

クォータの仕組み — stdioとHTTP：

• HTTPモード（Glama／Smitheryコンテナ、PORTが設定されている場合）：IPごとの無料プランの上限（1日あたり100回）は、サーバープロセス内でローカルに適用されます。
• stdioモード（Claude Code npx、Claude Desktop）：IPごとのカウンターはありません。ツールの呼び出しはX-TTT-API-Key経由でapi.kenosian.comに委任され、クォータはプランの月間利用枠に基づいてサーバー側で適用されます。TTT_API_KEYがない場合、ローカルのフォールバックは1日あたりの上限なしで実行されますが、プランの機能（サーバー側のDAG永続化、複数セッション間の因果チェーン）は利用できません。

---

要件

• Node.js >= 18
• 時刻合成のためのネットワークアクセス（time.nist.gov、time.google.com、time.cloudflare.com への HTTPS）

時刻ソースの優先順位（自動フォールバック）：

優先順位	ソース	ストラタム	備考
1（優先）	PTP / ハードウェアクロック	0–1	ローカルの PTP デーモンが必要です
2	Roughtime / NTP（NIST、Google、Cloudflare）	2–4	ほとんどのデプロイ環境でのデフォルトです
3（オフライン時のフォールバック）	ローカルシステムクロック	16	RFC 5905 における未同期のストラタムです。ネットワークソースにすべて到達できない場合に使用されます

サーバーは自動的にストラタム 16 にフォールバックするため、手動設定は不要です。各 pot_generate レスポンスの stratum フィールドで、使用された優先順位を確認できます。

Redis による永続化（任意）：

Redis は必須ではありません。実行時にはインメモリ DAG が正となります。REDIS_URL が設定されている場合、イベントは 90 日間の TTL を設定して Redis に書き込まれ、サーバーの再起動時に Redis から DAG が再構築されるため、server_restart によるチェーンの欠落を減らせます。Redis がない場合、再起動時にインメモリ DAG は消去されます。

---

本番環境でのヒント

コールドスタート時のウォームアップ — 初回起動時、BatchSigner の初期化には 1 件のリクエストが必要です。ロードバランサーのヘルスチェックを有効にする前に、pot_health を呼び出すか、ダミーの pot_generate を 1 回送信してください。これを行わない場合、初回のリクエストは p99 が約 500ms になる可能性がありますが、以降のリクエストは 10ms 未満で安定します。

# Kubernetes / Docker: add to your startup script
curl -s http://your-server/pot/health > /dev/null

---

詳細情報

• OpenTTT SDK — 基盤となる SDK
• IETF Draft: draft-helmprotocol-tttps — TTTPS プロトコル仕様
• Helm Protocol — GitHub

ライセンス

BSL-1.1 — 非商用利用は無料です。

商用利用（本番環境のボット、ヘッジファンド、プロップデスク）にはライセンスが必要です。

変更日：2029-05-28 → Apache 2.0