今日、Kiteの開発者向けドキュメントを最初から最後まで読みました。心に残ったのは、速度でも手数料でもありません。権限が3つの層に分かれている点です。ユーザーがルート権限を持ち、各エージェントにはBIP-32を使ってユーザーのウォレットから派生した独自のアドレスが割り当てられ、各セッションでは使用後に失効するランダムなキーが使われます。セッションが侵害されても、失われるのは1つの委任権限だけです。エージェントが侵害されても、被害はユーザーが設定した制限の範囲内にとどまります。無制限の損失につながるのはルートキーだけで、そのためドキュメントではルートキーをローカルのエンクレーブに保管しています。
決済設計も同じ考え方に基づいています。リクエストのたびにオンチェーンで決済するのではなく、2者がチャネルを開き、何千もの署名付き更新をオフチェーンでやり取りし、2回目のトランザクションでチャネルを閉じます。
ドキュメントによると、レイテンシは100ms未満、リクエスト100万件あたり約1ドルです。
ここで、自分の期待にあえて異を唱えてみます。ドキュメントでは、ボラティリティが急上昇したときにエージェントの上限を引き下げるといった条件付きルールについても説明されています。こうしたルールには外部データが必要ですが、そのデータを誰が提供するのか、あるいはフィードに誤りがあった場合にどうなるのかは見つけられませんでした。また、テストネットの大きな数値(数億件のトランザクション)はテスト環境でのものなので、2026年4月30日にローンチしたメインネットで継続的な需要があるかどうかについては、ほとんど何も示していません。
今後注目するのは、KiteScan上のアクティブなAgent Passportの数、エージェントのトランザクションのうちテストではなく実際のサービス決済が占める割合、そして条件付き支出上限の根拠となるデータソースがドキュメントに明記されるかどうかです。
人が安心してウォレットを預け、夜ぐっすり眠れるのでなければ、エージェント経済は成り立ちません。それを左右するのは、エージェントがどれだけ速く支払うかよりも、入力データに問題が起きたときにルールがどう機能するかです。
#KiteBBW $KITE @KITE AI 中文 #KiteBBW
決済設計も同じ考え方に基づいています。リクエストのたびにオンチェーンで決済するのではなく、2者がチャネルを開き、何千もの署名付き更新をオフチェーンでやり取りし、2回目のトランザクションでチャネルを閉じます。
ドキュメントによると、レイテンシは100ms未満、リクエスト100万件あたり約1ドルです。
ここで、自分の期待にあえて異を唱えてみます。ドキュメントでは、ボラティリティが急上昇したときにエージェントの上限を引き下げるといった条件付きルールについても説明されています。こうしたルールには外部データが必要ですが、そのデータを誰が提供するのか、あるいはフィードに誤りがあった場合にどうなるのかは見つけられませんでした。また、テストネットの大きな数値(数億件のトランザクション)はテスト環境でのものなので、2026年4月30日にローンチしたメインネットで継続的な需要があるかどうかについては、ほとんど何も示していません。
今後注目するのは、KiteScan上のアクティブなAgent Passportの数、エージェントのトランザクションのうちテストではなく実際のサービス決済が占める割合、そして条件付き支出上限の根拠となるデータソースがドキュメントに明記されるかどうかです。
人が安心してウォレットを預け、夜ぐっすり眠れるのでなければ、エージェント経済は成り立ちません。それを左右するのは、エージェントがどれだけ速く支払うかよりも、入力データに問題が起きたときにルールがどう機能するかです。
#KiteBBW $KITE @KITE AI 中文 #KiteBBW
