Hanko exit_liquidity

hanko

Hanko は、暗号資産市場の話題を、根拠を添えた適切なサイズのポジション、あるいは誠実な見送り判断へと変換します。そして、その同じ判断を何年後でもバイト単位で証明できます。

トークンと、X、Telegram、Bluesky 上で信頼する発信者を指定してください。それぞれが実際に何を発言したかを読み、独立した声なのか、それとも同じ見解が三度繰り返されているだけなのかを確認して、判断を下します。

ENTER TOKENA  size 3.28%  confidence 0.66
  + independent_voices: 2 independent voice(s): voice_alpha, voice_gamma
  ~ echo voice_beta: marked as a repost or quote by the source
  ! wrong if price_usd < 1.0625 at any point within 72.0h (thesis fails if price falls 15% from entry)
  review at 2026-08-30T12:00:00Z

_{出力例：実際のエンジンによるものです。入力は合成データです。voice_alpha／voice_beta／voice_gamma と TOKENA は架空のテスト用フィクスチャであり、実在のアカウントやトークンではありません。}

同じ入力を1年後にもう一度実行しても、同じ判断 ID が生成されます。判断処理ではネットワーク、時計、モデルに一切触れないためです。実際に保存されたデータだけを読み取ります。これがこのプロジェクトのすべてです。「証明して」という要求を、README 上の約束ではなく、実行できるコマンドにするアーキテクチャです。

審査に参加しますか？ /judges から始めてください：公開されている評価基準の各項目が、自分で確認できるページまたはコマンドに対応しています。 tryhanko.vercel.app には、概要とサンプルレシート（合成データを使用し、その旨を明記）があります。/try では、インストール不要で、ブラウザーからその一部をライブ実行できます。技術的な詳細はすべて /docs にあります。

---

RYO-CHAN Hackathon 2026 への3トラック応募作品です。 **トラック1（自律エージェント）**は上記のエージェントで、Multi-KOL Narrative Agent のスポットライトに合わせて構築されています。 **トラック3（新しいスキル）**は exit_liquidity です。利用可能な場合に実行可能な取引所の見積もりを基に、ポジションから「退出」するためにかかるコストを、RYO 独自のレスポンスエンベロープで提示します。これは、エージェントがポジション確定前に実行するサイズ判定ゲートでもあります。**トラック2（ダッシュボードとインターフェース）**は3つの画面です：ワークベンチ、障害訓練、Echo Index。

ライブで示してきたこと

• 鍵不要で、3時間ごとに増える台帳。 定期ワークフローが、BTC、ETH、SOL、BONKに関する公開Telegram、Bluesky、ニュースの発信を読み取り、判断を下し、リプレイ用バンドルで実行を封印してOpenTimestampsに記録し、live/にコミットします。各判断は、最初に書き留めた条件に照らして72時間後に評価されます。 /ledgerでは、前回の実行からの変更点を重要度順に確認できます（D-20）。
• 誤りだった場合も含め、自ら定めた条件に照らして評価。 最初の32件の定期判断は2026-10-27と28に評価時期を迎えました。ENTERはすべて維持され（7件中7件、実現リターンは-0.9%から+1.1%）、不参加の判断25件のうち7件は、判断を覆すとした発信が実際に届いたため、誤りだったと判定されました。これらのレビューで評価処理のバグも2件見つかり、D-21で修正されました。
• 誰でも再導出できる、封印済みのライブENTER。 BTC、2026-10-23、runs/run_836b976720f63dc0.json。マニフェストには、PASSと2件のABSTAINを含むウォッチリストの全エントリーが記載されています。Bitcoinのブロック972,817にアンカーされており、封印から35分後にマイニングされました。hanko verify-runを使えば、ネットワークも鍵も使わず、コミット済みバンドルから4件すべての判断を再現できます。（2026-10-24までは、このバンドルは実際にはリポジトリに含まれていませんでした。D-19）
• モデル上の推定ではなく、実測した退出コスト。 BONK、$50,000の場合、Jupiterの見積もりは2.3%です。このスキル独自の定積商品モデルでは7.2%となり、レポートではその3.1倍の差を隠さず表示します。
• エージェントを監査した調査。 Echo Indexでは、15の暗号資産チャンネルから収集した実際の投稿2,094件にHankoのエコーチェックを実施しました。エコーの膨張率は1.005倍で、確認できたとおりに公開しました。ただし、まずHanko自体の検出器が、広告やフッターを付け加えた逐語的なコピーを見逃すことが判明しました（D-14で修正）。
• 意図的に注入した9件の障害。 RYOの下落、全ソースの停止、レート制限された見積もり先、モデルの停止、モデルが実際に従ってしまったプロンプトインジェクション、証拠の改ざん、封印済み実行の編集、スイープ中のソース停止、再起動。9件すべてに耐えることを、/drillでライブに計算します。再起動のシナリオは最初の実行時に失敗し、D-18で修正されました。

判子とは、文書への確約を示すために人が押す封印です。結果が分かる前に印を押し、後から取り消すことはできません。このエージェントが判断を下すたびに行うことも、まさにそれです。判断の規模を定め、確約し、何がその判断を誤りだと証明するのかをあらかじめ明示します。

提出

• プロジェクト提出フォーム（PDF、このリポジトリ内）
• デモ動画
• Xでの告知投稿

目次

• 60秒で自分で検証
• 対象者
• 何も実行せずに見る
• 唯一のルール
• 構成
• このように構築した理由
• 使い方
• ステータス
• exit_liquidity、新しいTrack 3スキル
• 判断記録
• レビューループ
• スイープ
• アーキテクチャ、判断、制約

60秒で自分で検証

ライブ認証情報も、アカウントも、ネットワークも不要です。以下の数値はすべて、このリポジトリにコミットされた合成フィクスチャから再生成できます（テスト用に作成した架空の発信者と架空のトークンであり、実際のアカウントから取得したものではありません）。

git clone https://github.com/IamHarrie-Labs/hanko && cd hanko
pip install -e ".[dev]"

pytest                                          # 349 tests, offline, ~20s

# make a decision, then prove it replays from stored bytes
hanko decide x --token TOKENA --subject voice_alpha --subject voice_beta \
  --subject voice_gamma --market fixtures/market_tokena.json \
  --as-of 2026-08-27T12:00:00Z --fixture fixtures/x_three_voices.json
hanko audit                                     # re-derives it, insists it reproduces

# the Track 3 skill, against the same fixture, no network
hanko exit-liquidity TOKENA --size 50000 --market fixtures/market_tokena.json

# the first live ENTER, re-derived from its committed bundle
hanko verify-run runs/run_836b976720f63dc0.json

# break it on purpose: nine failure scenarios, offline
python -c "from hanko.drill import run; print([r['held'] for r in run()])"

# re-derive every number in the Echo Index
hanko echo-index publish

このプロジェクトの対象者

エージェントの推論を鵜呑みにするのではなく、監査可能にしたい開発者やトレーダーが対象です。根拠もないのに「強い買いシグナル」と告げるボットに痛い目に遭い、代わりに根拠や反証材料、そして率直に認められた不足を確認したい人です。また、この README に書かれた主張を信頼するのではなく、保存された正確なバイト列からあらゆる判断を再現できる、今回の提出物を審査する審査員も対象です。

エージェントに取引を実行させたい人向けではありません。エージェントは取引を実行しません。また、ハッカソン独自のルールにより、これが基盤としている RYO ツールはどれも取引を実行できません。ここで行うのはすべて調査とポジションのサイズ決定であり、資金を動かすことはありません。

実行せずに内容を見る

開く	表示内容
tryhanko.vercel.app	概要と、判断レシートのサンプル（実際のエンジン、合成フィクスチャ入力。その旨を明記）
/try	ライブの exit_liquidity：RYO のファクト、DexScreener の深度、Jupiter の見積もりを、RYO のエンベロープ内で表示
/judges	すべての評価基準と、その確認場所
/workbench	サンプル判断（合成入力、その旨を明記）から発言者を除外したり、しきい値を厳しくしたりして、実際の decide() の判定がどう変わるか、どのルールが原因かを確認
/drill	実際のコードに注入した9つの実際の障害。それぞれの防御策をライブで計算
/echo	Echo Index：2,094件の実際の投稿をもとに、暗号資産に関するコンセンサスがどれほど一つの声の繰り返しなのかを表示
/docs#track1-live	実際の判断2件と、ライブの X 証拠およびライブの RYO ファクト。どちらも恣意的に選んだものではありません
/docs#mcp-transport	ライブの MCP ハンドシェイクとライブの x_search 呼び出しで、実際に何が返されるか

/try、実際のプラットフォームに対するライブ表示	/docs

唯一のルール

fetch()  touches the network, is allowed to fail, and is never deterministic
parse()  touches nothing, and is a pure function of its payload

エージェントが見るのは、常に parse() の出力だけです。parse() は純粋関数であり、ペイロードはコンテンツアドレス方式で識別されるため、過去の判断は保存されたバイト列から再導出でき、必ず同じ判定に到達します。parse() 内にネットワーク呼び出しを入れると、推論の追跡可能性が再現できなくなります。提出物全体は、この性質を基盤としています。

構成

hanko/provenance.py      canonical JSON, sha256 addressing, Status, Coverage
hanko/evidence.py        Evidence + Provenance: the source-agnostic unit
hanko/sources/base.py    the adapter contract
hanko/sources/xsearch.py X, via the xAI Responses API and its x_search tool
hanko/sources/rss.py     RSS/Atom: free, and the only source with trustworthy timestamps
hanko/sources/fixture.py local JSON: free development, and every failure mode in CI
hanko/snapshot/store.py  append-only content-addressed store, replay, integrity
hanko/ryotools/          the six RYO tools over MCP and REST; structural fact extraction
hanko/skills/exit_liquidity/  Track 3: what it costs to exit a position, not just enter one
hanko/review/outcome.py     grading a decision against its own commitment
hanko/review/reliability.py calibration, per-voice and per-rule track records
hanko/review/ledger.py      append-only reviews, one per decision
hanko/cli.py             collect / decide / review / scorecard / audit / verify

全体のツリー：

hanko/
  sources/       X, RSS, fixtures -- fetch() impure, parse() pure
  snapshot/       append-only content-addressed store
  ryotools/       the six RYO tools, MCP + REST
  decision/       evidence quality, verdicts, falsifiers, the ledger
  review/         falsifier checking, calibration, reliability
  skills/exit_liquidity/   Track 3: exit cost, capacity, drift, turnover
  sweep.py, cli.py, config.py, provenance.py, evidence.py
site/            static landing page, /docs, /try -- the live web demo
  api/exit_liquidity.py    the /try endpoint, real assess() call, no fixture
tests/           349 tests, one file per hanko/ package
fixtures/        evidence and market fixtures used offline and in CI
.github/workflows/ci.yml       pytest on every push, Python 3.11 and 3.12
.claude/skills/hanko-exit-liquidity/SKILL.md   packages exit_liquidity as a Claude Skill
ARCHITECTURE.md  the one rule, the pipeline, the layers
DECISIONS.md     engineering decisions and the bugs that shaped them
LIMITATIONS.md   what hasn't been shown yet, and why
LICENSE          MIT

このように設計した理由

情報源は差し替え可能です。 エージェントは、証拠の出所を知る必要がありません。X を Telegram に、あるいは Grok を直接 API に切り替えても、変更が必要なのは 1 つのアダプターだけで、後続の処理には何も影響しません。9 日目に x_search が非推奨になったり、費用が高くなりすぎたりしても、ほかには何も影響しません。

この切り替えは仮定上のものではなく、実際に検討済みの選択肢です。X 独自の API は、間にモデルが文章による要約を言い換えることなく、構造化された投稿を直接返します。ただし、別の有料プランと、このビルドですでに使用しているものとは異なる認証情報が必要です。後で対応する価値はありますが、提出が迫ったこの段階では、アダプターの境界によっていつでも低コストで切り替えられるため、書き換えのリスクを冒すほどではありません。

失敗は例外ではなくデータです。 問い合わせても応答がなかった情報源は、理由を添えた FAILED スナップショットを生成します。アダプターがエラーを発生させた場合も同様です。このストアで表現できない唯一の結果は無応答です。これにより、データがあるかのように気付かれないまま処理を進めるのではなく、証拠の欠落に正直に対応したポジションサイズの調整が可能になります。

3 種類の「何もない」は区別したままにします。 FAILED（情報源から応答がなかった）、項目数が 0 の OK（投稿がなかった）、PayloadShapeError（読み取れないバイト列が届いた）は、それぞれ別の事実です。これらをひとまとめにすると、スキーマの変更が市場の静けさに見えてしまいます。

カバレッジを過大に主張することはありません。 x_search は検索ツールであり、タイムラインフィードではないため、そのカバレッジは仕様上 UNKNOWN です。COMPLETE と主張するのは、KOL 間の収束数を水増しすることにほかなりません。

一度収集すれば、以降の開発は無料です。 実際のスナップショットは一度だけ取得し、それ以降の処理はすべて保存済みのバイト列に対して実行します。開発と CI は費用がかからず、レート制限にも達しません。20 個のハンドルを 1 時間ごとにスイープする場合、ライブ収集は 1 回あたり約 $0.005 で、ビルド全体ではおよそ $25 から $35 です。

使い方

pip install -e ".[dev]"
pytest

hanko collect x --subject voice_alpha --subject voice_beta
hanko collect rss --subject https://example.com/feed.xml
hanko ls
hanko replay snap_7723f3520b7dfa2efa6856e3
hanko verify

フィクスチャを使ってオフラインで実行する場合：

hanko collect x --subject voice_alpha --fixture fixtures/x_three_voices.json

ライブで X を収集するには、XAI_API_KEY を設定する必要があります。設定されていない場合、アダプターはエラーをスローするのではなく、その旨を示す FAILED スナップショットを記録します。

ステータス

テストは349件で、すべてオフラインで実行でき、所要時間は約20秒です。エビデンス層では、正規形とアドレスの安定性、ペイロードの重複排除、改ざん検出、リプレイ時のアダプターバージョン不一致、リプレイの決定性、バイト列と位置に固定されたエビデンスの識別情報、各種の失敗モード（レート制限、部分ウィンドウ、空の結果、例外を発生させるアダプター、不正なフィード、読み取り不能なペイロード）を網羅しています。判断層では、エコーの格下げ、PASS と ABSTAIN の分離、安全性データの欠落／ソースの失敗／古いエビデンスがある場合の機械的なサイズ縮小、エントリーと拒否の両方に対する反証条件の生成、台帳の改ざん検出、保存されたバイト列から保存済み判断をエンドツーエンドで再現するテストを網羅しています。レビュー層では、反証条件の確認、利益が反証された主張を救済しないこと、確認不能な指標が未解決のまま残ること、結論が出ないレビューがすべての比率から除外されること、エコーが功績にも非難にも値しないこと、キャリブレーション、判断の再レビュー拒否を網羅しています。

MCP 層では、JSON-RPC ハンドシェイク、セッション処理、SSE のデコード、すべてのトランスポート失敗モードに加え、MCP ペイロードから抽出した事実と REST ペイロードから抽出した事実が同一であることを検証するテストを含みます。

2026年8月28日、稼働中の API で確認済みです。 x_search は構造化された投稿オブジェクトを返しません。投稿をモデルが文章で表現したものと、URL 引用の配列を返します。文章だけでは特定の投稿に帰属させられないため、アダプターは JSON スキーマを要求したうえで、返されたすべての投稿 ID をツール独自の引用と照合します。引用されている投稿は保持し、引用されていない投稿は破棄します。この確認で証明できるのは、投稿が存在し、ツールがそれを参照したことまでです。モデルがテキストやタイムスタンプを忠実に書き起こしたことまでは証明できないため、すべての項目でこれらのフィールドにモデルが書き起こしたことを示すフラグを付けています。

2026年9月5日、稼働中の RYO MCP サーバーで確認済みです。 hanko tools、hanko facts SOL、hanko decide はすべて、フィクスチャではなく実際のエンドポイントに対して実行しました。推測をやめたことで変わった点は3つあります。

カタログは6つのツールで、ハッカソンの公開ツール一覧に記載されている7つではありません。認証済みカタログには check_safety と supported_tokens はなく、monitor_market_sentiment_shift は含まれていますが、まったく予想していませんでした。6つのツールのどこにも数値の安全性スコアはないため、MarketFacts の safety_score は、時折値が入るのではなく、常に正直に None のままです。

引数キーは analyze_token と deep_analysis では symbol、compare_tokens ではカンマ区切りの文字列1つとしての symbols であり、token ではありません。どちらのトランスポートも後者を推測して実装されていましたが、現在は実際の仕様に合わせて修正済みです。

REST での応答は {"tool": ..., "result": {envelope}, "latency_ms": ...} であり、_degraded() が参照するのは、エンベロープ自身の status（ok／partial／unavailable）と data_mode（live／mixed／simulated／unknown）です。simulated と明示された応答は、部分的な応答とまったく同じように扱います。シミュレーションデータをライブデータとして提示することは、プラットフォームが決して行わないとしている唯一の捏造だからです。

訂正、2026年9月22日。 定期的な hanko audit が PayloadShapeError: no message item in the response output で突然クラッシュしました。原因はラベル付けのバグでした。ローカルのフィクスチャデータから作成した判断に、フィクスチャであることを示すものではなく、ライブの X ソース自体の ID が付けられていたため、リプレイが実際のアダプターに、その読み取りを想定していないバイト列を渡していました。既存のリプレイテストはすべて、各テストが hanko audit と同じ検索処理を経由するのではなく、フィクスチャを無条件で返す独自のリゾルバーを用意していたため、この問題を見逃していました。詳細な説明、修正内容、および修正を証明する回帰テストは、DECISIONS.md の D-07 に記載しています。

まだ示せていないもの：実際の結果に基づくキャリブレーション曲線、ライブの ENTER、実際に価格が付いたプールです。その理由とともに、LIMITATIONS.md で明記しています。

新しい Track 3 スキル、exit_liquidity

6 つの実ツールはいずれも、ある形で「エントリーする価値はあるか？」に答えます。 「このポジションをクローズできるか、またクローズにはどれだけのコストがかかるか？」に答えるものはありません。 この数値によって、調査が取引へと変わります。トークンが測定されたすべてのシグナルをクリアしていても、ポジションを手仕舞うことで価格が 2 桁動くなら、罠になり得ます。

hanko exit-liquidity BONK --size 50000

OK  BONK  confidence high
  price $0.00000331 · 24h volume $1,395,538  (dexscreener)
  quoted: selling ~$50,000 on jupiter returns $48,886, 2.34% under its own near-mid rate (price impact plus fees, 5-hop route)
  model said 7.15% from $1,299,172 of on-chain depth
  the model overstates this exit's cost 3.1x: the route reaches concentrated liquidity a constant-product curve cannot see
  depth: 29 pools on solana, deepest $327,472, 1 rejected
  or exit over 8.6h at 10% of volume
  verdict from an executable jupiter quote; quotes move with the market

RYO 独自のマーケットツールが失敗していた、2026-10-23 時点のライブ出力です。RYO はプールの深さを公開したことがないため、バージョン 2.0 では認証キー不要の 2 つの取引所に問い合わせます。DexScreener はトークンの正規コントラクトに対応するプールを提供します。偽のプールが返されるため、シンボルで検索することはありません。Jupiter は指定された正確なサイズで執行可能な見積もりを提供します。測定された見積もりはモデルより優先され、モデルの誤差もその横に表示されます。どちらの取引所からも回答がない場合、コスト欄はゼロではなく null になります。すべての回答は RYO の公開レスポンスエンベロープで、RYO 独自の REST ルート形式（POST /api/tools/exit_liquidity/call）および MCP サーバー（/api/mcp）でも提供されます。

完全なモデル、誠実性に関する規約、テストカバレッジについては hanko/skills/exit_liquidity/README.mdをご覧ください。 実際のプラットフォームを相手にライブ実行できるのは **tryhanko.vercel.app/try**です。ただし、公開ページがライブ認証情報に無制限のリクエストを送ることがないよう、対象トークンを少数に限定し、サイズにも上限を設けています。

Claude Skill

.claude/skills/hanko-exit-liquidity/SKILL.md では、このコマンドをそのまま Claude Skill としてパッケージ化しています。このリポジトリを Claude Code に指定すると、「このポジションを手仕舞うにはいくらかかるか」に直接回答できます。その際は、回答内のすべての数値をコマンド自体の出力から取得し、モデルが決して捏造したり丸めたりしないという明示的なルールが適用されます。これは、ツールが自身に課しているものと同じ誠実性に関する規約を、実行する側にも適用するものです。

意思決定記録

記録には、意思決定の時点での結論、根拠となる証拠、判断に用いた推論、欠けていた情報、そして何がその判断を覆す証拠になるかを記します。

hanko/decision/reading.py      interpretation, recorded once and frozen
hanko/decision/convergence.py  independence: is this many voices, or one echoed?
hanko/decision/quality.py      gaps, and the evidence-quality score that sets size
hanko/decision/policy.py       risk limits, hashed into every record
hanko/decision/engine.py       the verdict function -- pure by contract
hanko/decision/record.py       the record, and the commitment that names it
hanko/decision/ledger.py       append-only ledger, and the replay proof

エンジンは純粋です。 decide() が読み取るのは引数だけです。時計、ネットワーク、モデル呼び出し、乱数には依存しません。解釈は唯一の主観的なステップであるため、上流で行い、記録に固定します。意思決定経路に LLM を入れても、リプレイから何も証明できません。

判定は 2 つではなく 3 つです。 ENTER、PASS（証拠は十分で、エントリーに反対する根拠がある）、ABSTAIN（どちらの立場を支持するにも証拠が不十分）の 3 つです。最後の 2 つをまとめてしまうと、エージェントは実際には持っていなかった市場見解を主張できてしまいます。

データの欠落は、機械的にポジションサイズを縮小します。「安全性を確認できない場合は半分にする」というルールはありません。欠落があると完全性が下がり、完全性が下がると証拠の品質が低下し、品質によってサイズが決まります。4 つの品質要素は加重幾何平均で統合されるため、1 つの要素がゼロならスコア全体がゼロになります。熱意があっても、安全性チェックの欠如を平均で埋め合わせることはできません。

見解の一致は、独立性を確認します。 3 つのアカウントが 1 つの主張を引用しても、実質的には 1 つの観測です。それを 3 つとして数えることは、複数の KOL を追うエージェントが自信満々に誤る最も簡単な方法です。繰り返されたすべての情報について、引用元の投稿と、評価を下げた理由を記録します。

すべての意思決定で、その反証条件を事前登録します。 反証条件は結果が判明する前に記述され、機械的に評価され、decision_id にハッシュ化されます。事後にしきい値、サイズ、レビュー日を変更すると、別の ID が生成されます。これは編集済みの意思決定ではなく、新しい意思決定です。見送りにも記録上の確約があります。PASS には、どのような条件なら判断が覆るかが記録されます。

それを見る

hanko decide x --token TOKENA --subject voice_alpha --subject voice_beta --subject voice_gamma --market fixtures/market_tokena.json --as-of 2026-08-27T12:00:00Z --fixture fixtures/x_three_voices.json

ENTER TOKENA  size 3.28%  confidence 0.66
  dec_1c1fb9e7ae2020cb260d6f32
  evidence quality 0.82  (completeness 1.0, freshness 0.75, corroboration 1.0, independence 0.67)
  + independent_voices: 2 independent voice(s): voice_alpha, voice_gamma
  + safety: safety score 0.82
  ~ echo voice_beta: marked as a repost or quote by the source
  ! wrong if price_usd < 1.0625 at any point within 72.0h (thesis fails if price falls 15% from entry)
  ! wrong if independent_voices < 2.0 at review, within 72.0h (entry rested on convergence that no longer holds)
  review at 2026-08-30T12:00:00Z

  replayed from stored bytes: same decision id

3 人の投稿者がそのトークンに言及し、そのうち 2 人は独立していました。安全性スコアがなく、同じ証拠サイズで、3.28% ではなく 3.08% の市場フィクスチャに差し替えてください。ルールは何も変わらず、分かっていることだけが変わりました。

hanko audit は、記録されたすべての判断を保存されたバイト列から再導出し、同じ結果が再現されることを求めます。これが、「再現可能な推論の記録を保持する」という README の主張を、ビルド失敗につながる要件に変える CI ゲートです。

レビューループ

review_at では、各反証条件を観測された事実に照らして評価し、判断がどれだけ利益を上げたかではなく、何を約束していたかに基づいて採点します。

この 2 つは、受け入れがたいほど頻繁に食い違います。エントリーが利益を上げていても、反証されることがあります。ポジションサイズの根拠となった流動性が失われる一方で価格が上昇した場合、推論は誤っており、結果は運にすぎなかったということです。どちらの事実も記録され、別々に報告されます。利益だけで採点すると、エージェントは運のよかった失敗を繰り返すようになります。

3 つ目の結果が重要です。 反証条件が指定した指標をレビュー時に利用できない場合、チェックは UNCHECKABLE となり、合格として黙って扱われることはありません。確認できなかった判断は、正しかった判断ではありません。結論が出ないレビューは、すべての率から除外し、独立した数値として報告します。検証できなかったものを黙って除外するエージェントは、事後に自ら選んだサンプルで自己採点することになるからです。

拒否も採点対象です。 PASS は、どのような条件なら判断が覆ったかを明示するため、実行した取引だけに印を付けるエージェントは、自らの慎重さがどんな代償をもたらしたのかを学べません。

判断ごとにレビューは 1 回のみで、それを徹底します。 答えが改善するまで再レビューすることは、事前登録が防ぐためにあるまさにその失敗です。そのため、台帳は最新のレビューだけを残すのではなく、2 回目のレビューを拒否します。

hanko review --observations fixtures/observations_day3.json --now 2026-08-30T12:00:00Z

FALSIFIED  TOKENA  (enter at confidence 0.66)
  dec_1c1fb9e7ae2020cb260d6f32 -> rev_24903844c6020591a568451b
  x price_usd observed at 1.02 at 2026-08-30T12:00:00Z; committed to being wrong if < 1.0625 at any point in the window -- thesis fails if price falls 15% from entry
  + liquidity_usd held against < 630000.0 across 1 sample at 2026-08-30T12:00:00Z -- no intermediate readings; last observed 880000.0
  + independent_voices observed at 2.0; holds against < 2.0
  realised return -18.4%  (recorded, not used to grade)

liquidity_usd の行は、確認した内容を正確に示しています。読み取りは 1 回で、中間の読み取りはありません。price_usd と liquidity_usd は、判断からレビューまでの間に hanko sweep --samples が記録したすべてのサンプルを対象に採点されます（D-13）。違反がレビュー時刻より前に解消されても、その違反によって崩れた仮説は反証されます。また、期間末の読み取り 1 回だけで行ったレビューは、期間全体を監視していたかのように示すのではなく、その事実を明らかにします。

スコアカード

hanko scorecard

reviewed 2   scored 2   unverifiable 0
held 1   falsified 1   hit rate 50.0%   brier 0.2461

calibration        said     actual    n
  0.6-0.8         0.7       50.0%    2

voices
  voice_gamma               0.0%   1 scored
  voice_alpha              50.0%   2 scored

rules satisfied on decisions that later
  independent_voices       0.0% held
  conviction              50.0% held

0.7 と述べ、50% の確率で正解でした。エージェントは自信過剰であり、そのことも自ら示しています。

発言者ごとの信頼性は、フォロワー数を根拠に主張するのではなく、エージェント自身の監査済み履歴から積み上げて得られるものであり、オウム返しには加点も減点もありません。採点済みの判断がない発言者の値は 0% ではなく None です。0 と報告すれば中傷になり、100% と報告すれば過大評価になります。ルールごとの信頼性は、答えにくい問いに答えます。負けた取引で常に満たされるルールは、フィルターではなく飾りです。

スイープ

hanko decide は、1つのソースから1つのトークンを手動で処理します。実際のウォッチリストでは、複数のソースにわたる20個のトークンについて、どれか1つのソースの停止や不正なトークンによって残りの実行まで失敗させることなく、スケジュールに従って同じ処理を行う必要があります。hanko/sweep.py がそのオーケストレーションを担います。

hanko sweep --watchlist watchlist.json --as-of 2026-08-27T12:00:00Z

1回のパスで、ウォッチリストのすべてのエントリについて判断し、続いて台帳上で期限を迎えたすべての判断を評価します。処理に失敗したトークンはレポートに記録され、例外を発生させる代わりにスイープはその先へ進みます。ウォッチリストから削除されたトークンについても、未処理の判断を放置せず、引き続きレビューします。

1回のスイープにおけるすべてのスナップショットには、実際の時計時刻ではなく、スイープ自体の as_of が記録されます。 1回のパス内で複数のソースを呼び出すには実時間で数秒かかりますが、それらはすべて同じ論理的な時点に属します。変更されていないソースに対してスイープを再実行した場合、リトライが1秒遅れただけで新しい ID になるのではなく、同じ decision_id に到達する必要があります。

レビューでは、固定された情報ではなく、新たに取得した情報を使います。 fresh_observations() は、元の判断の数値を再利用するのではなく、レビュー時点で証拠を再収集し、independent_voices を再導出します。レビューの目的は、今何が真実かを確認することです。「そのとき真実だった」内容の古いコピーを使えば、判断をその判断自身に照らして評価することになります。

--samples samples.jsonl を指定すると、ウィンドウで実際に確認できるデータが記録されます。 各パスでは、すでに取得済みの情報を再利用して、ウォッチ対象の各トークンについて市場の読み取り値を1つずつ追記します。後日、期限を迎えた判断は、レビュー時点の読み取り値だけでなく、その判断が行われてから記録されたすべての読み取り値に照らして評価されます。これにより、ANY_POINT_IN_WINDOW の反証条件（D-13：「72時間以内」と述べておきながら、最後の時点だけを確認していた反証条件）が、価格や流動性の違反が期限までに回復してしまう場合でも検出できます。これを省略すると、hanko sweep は従来どおり、ウィンドウ終了時の読み取り値だけを保持します。レビューでは、どちらの方式を使ったかが示されます。

これは、cron、スケジュールされた GitHub Action、Windows タスク スケジューラなど、すでにスケジュール管理の方法を備えているものから実行することを想定しています。1回実行して終了するものであり、プロセス内でスリープを繰り返すループではありません。実行に失敗した場合は呼び出し自体が失敗するのであり、終了させるプロセスを探しに行く必要はありません。

このリポジトリでは、1つの実行を行っています。.github/workflows/sealed-sweep.yml はキーを一切使わず、3時間ごとに watchlist.live.json を封印し、コミット済みファイルから実行を検証して、保留中の Bitcoin プルーフをアップグレードし、/ledger 用に live/summary.json を書き出します。

hanko seal --watchlist watchlist.live.json --ledger live/decisions.jsonl   --reviews live/reviews.jsonl --samples live/samples.jsonl   --manifest-dir live/runs --interpreter lexicon --lookback-hours 24 --ots
hanko live-summary --dir live

--interpreter lexicon は、単語全体を照合し、「$BTC」だけでなく「Bitcoin」も認識するように学習したキーワードリーダーです。--lookback-hours 24 はフィードの直近1日分だけを読み取ります。Telegram ページや RSS フィードには数日分の履歴が残っており、それらを含めると古い情報としてスコアが付いてしまうためです（D-20）。

hanko sweep --watchlist fixtures/sweep_demo/watchlist.json \
  --fixture-dir fixtures/sweep_demo --as-of 2026-08-27T12:00:00Z

sweep at 2026-08-27T12:00:00+00:00
  ENTER   TOKENA  dec_5b2eadbf21bc8c073927b4ac

すべてオフラインで実行する16件のテストです。既存の証拠フィクスチャに加え、RYO ツールの応答を模したフィクスチャ（ライブのツールソースに似た形で、証拠形式の FixtureSource とは異なる FixtureFactsSource）を使います。対象範囲：証拠ソースや事実ツールの失敗が例外ではなく欠落として扱われること、不正なトークンが1つあってもスイープの残りがキャンセルされないこと、台帳にすでにある判断が重複せずスキップされること、ウォッチリストから削除されたトークンも引き続きレビューされること、レビュー時に元の判断に固定された情報ではなく新しい観測結果が取得されること。

アーキテクチャ、意思決定、制限事項

• ARCHITECTURE.md：唯一のルール、図で示したパイプライン、各パッケージの責務、そして exit_liquidity が decide() 内部で実行されるものと同じサイズゲートをどのように算出するかを説明します。
• DECISIONS.md：実際に発生した順に13件のエンジニアリング上の意思決定を記載しています。このビルド中に発見・修正した実際のバグと、それぞれが何を壊したのかも含まれています。
• LIMITATIONS.md：実際の結果に基づくキャリブレーション曲線、ライブの ENTER、実際に価格が付いたプールなど、まだ実証されていない事項を記載しています。ステータスの段落にまとめず、率直に示しています。
• SEALING.md：hanko seal -- ウォッチリスト実行全体の番号付きマニフェストです（エラーも含め、一切省略しません）。公開のOpenTimestampsカレンダーにアンカーされ、結果が判明する前に公開されます。

次のステップ

sweep、audit、scorecardをCIまたはスケジュール実行に組み込み、音声ごとの信頼性をエビデンスの重み付けに反映します。これにより、エージェント自身の実績が、何を信じるかに反映され始めます。

エビデンスの更新、2026年10月30日

Hanko 2.0.0が、公式MCPレジストリにio.github.IamHarrie-Labs/hankoとして公開されました。

• 振り返りによるベースライン比較：レビュー済みの対象機会76件では、Hankoと単純なルールによるエントリーの選択結果が一致しました。このサンプルから選択上の優位性は確認できません。python scripts/compare_baseline.pyで再現できます。
• 誤りだと判明した、SOLに関する署名済みの拒否：当初のコミットメント、レビュー時点で後から得られた観測結果、追加の音声によって何が確認でき、何が確認できないかを説明しています。

最初に成功したモデル読み取りのワークフローでは、10月30日にrun_547a6eaf6c69d992を署名しました。モデル呼び出しは21回、フォールバックはなく、名前のないトークンの読み取り3件を却下し、4件すべての判断を独立して再現しました。Bitcoinのタイムスタンプは確認待ちです。