imokokok

あなたのAIエージェントの取引には「成功」と表示されています。

しかし、本当に承認したとおりに実行されたのでしょうか？

仮に次のようなケースを考えます。あなたは、出力をウォレットAに送る正確な呼び出しを承認します。しかし、エージェントは別のcalldataを送って、ウォレットBに送信します。

承認チェックが失敗していても、取引は正常に（実行成功として）成立することがあります。

私は、エージェントのダッシュボードで次の3つの質問に別々に答えられるようにしたいです。

1. 設定された信頼前提のもとで、証拠は検証を通過しますか？

2. オンチェーンでは何が起きたのか：完了、取り消し（reverted）、保留（pending）、または不確実ですか？

3. 観測された実行は、承認された呼び出しと一致していますか？

有効な署名付きレシートには、「実行が完了した」ことと「承認の不一致」を両方記録できます。これは有用な結果です。何が問題だったのかを記録として保持できるからです。

この違いが、私のInsightとPriorSealの作り方に影響しています。

Insightはオラクルデータとリスク評価を提供します。PriorSealは、明示的な承認を観測された実行に結び付けます。これらは独立して動いても、または組み合わせてもよく、それぞれの結果が独自の意味を保持します。

また、利用可能な情報では一致や違反を立証できない場合の「評価不能（not assessable）」という明確な状態も、証拠レビューには必要です。

あなたのエージェントのダッシュボードは、こうした違いを表示していますか？それとも、緑の「成功」表示だけですか？

#AIAgents #Web3Security

AIエージェントがスワップを送信します。RPC呼び出しがタイムアウトしました。

何をリトライすべきでしょうか？

「応答なし」は「取引なし」を意味しません。スワップはブロードキャスト済み、取り込まれている、またはまだ保留中の可能性があります。何の考えもなく再送すると、意図しない2回目の取引につながるおそれがあります。

私の復旧チェックリスト：

1. 元の試行を観察します。既知の取引ハッシュ、送信者のnonce、そしてチェーン状態を確認します。保留中、リバート、リオーグ（再編成）、不明の結果を区別して保持します。

2. 証拠を回復します。保存したチェックポイントから、レシート受信と検証作業を再開します。このステップでは署名やブロードキャストを行いません。

3. 重複実行のリスクを評価した後にのみ、新しい取引を検討します。まったく同じ呼び出しを再準備し、オラクルとルートの確認を更新し、最新の認可を取得します。確認済み、またはリバートされた取引は、単回使用の認可を消費します。

洞察は、証拠が提案された取引をまだ裏付けているかどうかを評価するのに役立ちます。PriorSealは、認可された呼び出しと、実際に観測された実行を結び付けます。

危険な前提は次のとおりです：「応答がなかったので、何も起きていない」。

エージェントは不確かなブロードキャストをどのように扱いますか？

#AIAgents #Web3Security

AIエージェントが$WETH → $USDCのスワップを準備しています。どの「価格」を見ているのでしょうか？

少なくとも3つの値は別々に確認が必要です：

1. オラクル参照価格：独立した市場ソースが示すもの。
2. シミュレーションされたルート見積：特定のブロックにおけるこの正確な呼び出しの出力。
3. 実際の約定：最終的に取引が実際に提供したもの。

オラクルの評価が良好でも、ルート見積の検討は別途必要です。妥当なシミュレーションは、その後の約定を保証できません。

サポートされている単一プールのUniswap V3 ERC-20ルートについて、Insightはオラクルの証拠と、最小出力、スリッページ上限に加えて、この呼び出しの正確なシミュレーション見積を確認します。そのシミュレーションは、確認済みの1つのブロックを示しています。

チームが、呼び出しを承認したのが誰か、そして観測された実行がそれに一致しているかも確認する必要がある場合、PriorSealは承認と実行の別々の証拠を提供します。

あなたのエージェントは、この3つの値をそれぞれ別に記録しますか？

https://www.oracleinsight.xyz/

#AIAgents #defi #oracles

取引前の確認に合格しました。同じ価格評価を、AIエージェントが数時間後にもそのまま信頼できるでしょうか？

長期間稼働する戦略では、しばらく取引が行われないこともありますが、依存しているオラクルデータは変わり得ます。情報源は分岐したり、遅れたり、十分なカバレッジを失ったりする可能性があります。

私は、Insight Oracle Watchを構築しています。アプリケーションがアクション間でオラクルをまたいだシグナルを確認できるようにします。出力は、NORMAL（通常）、CAUTION（注意）、DANGER（危険）のいずれかで、進行する／注意して進行する／停止する、という推奨が付与されます。

開発者は停止シグナルを戦略に接続し、理由を保持したまま新しいアクションを一時停止できます。

Watchは秒ごとの監視ではなく、サンプリング間隔で動作します。1回の正常なサンプルだけでは、記録された停止を自動的に解除できません。回復には、連続して正常なサンプルと明示的な承認（acknowledgement）が必要です。

あなたのエージェントは、取引と取引の間で何を確認しますか？

https://www.oracleinsight.xyz/

#AIAgents #defi #oracles

署名された取引の受領書をダウンロードしました。何を確認しましたか？

審査者はまだ次を確認する必要があります：

1. 内容と署名が損なわれていないか？
2. 発行者の鍵が独立して確認されたか？
3. 観測された呼び出しは、主たる当事者が承認した内容と一致しているか？
4. 追加のチェーン状態チェックが必要か？

ダウンロードしたバンドル内の公開鍵は、鍵の特定に役立ちます。その公開鍵が同じバンドルに含まれていることは、それ自体ではその鍵への信頼を確立しません。

PriorSealは、有効性、実行状態、および認可順守をそれぞれ別個に示す根拠を報告します。

Insightの評価証拠が添付されている場合、その署名者には、独立して確立された信頼ソースも必要です。証拠をつなぐだけでは、信頼のルーツが統合されるわけではありません。

検証可能な受領書は、特定の主張を裏付けます。しかしそれだけでは、経済的な安全性や、あらゆる外部データソースの正しさをそれ自体で確立するものではありません。

携帯可能な証拠バンドルを確認するとき、署名者の鍵はどこで確認しますか？

https://priorseal.xyz/

#AIAgents #Web3Security

価格は正しくても、取引は間違っていることがあり得る。
2 ETHをUSDCに交換する準備をしているエージェントを想像してみてください。3つの独立した価格ソースが一致し、データは新鮮性チェックを通過します。ですが、ユーザーが許可したのは0.5 ETHの交換だけです。
良い市場の証拠は、より大きな取引を承認しません。
その後、トランザクションハッシュだけでは、取引前に何が承認されていたのか、また観測された実行がそれに一致していたのかをレビュー担当者に伝えることはできません。
私は、エージェントの取引には3つの別々の回答が必要だと考えています。
証拠は意思決定の時点で利用可能だったか？
この具体的な行為は承認されていたか？
観測された実行は、その承認と一致していたか？
これらは私がInsightとPriorSealで取り組んでいる問いです。もしあなたがエージェントの取引を事後レビューしているなら、最初にどの回答を見たいでしょうか？
#AIAgents #defi

AIの取引がタイムアウトしました。「再試行（retry）」は実際には何を再試行すべきでしょうか？

$ETH → $USDC のスワップを行うエージェントを想像してください。ウォレットはトランザクションハッシュを返しますが、クライアントの待機がタイムアウトするまでに実行の観測が完了しません。

これは仮説的な例です。

タイムアウトは「待機が終了した」ことを示します。元のトランザクションはまだ保留中か、あるいはすでに実行済みの可能性があります。そのステータスには追加の調査が必要です。

エージェントには次を保持させたいです：
• 元のトランザクションハッシュ
• その認可（authorization）記録
• 観測ジョブの識別子
• 最後に分かっている状態

そのうえで、保留中・取り消し（reverted）・再編成（reorged）・不明（undetermined）の結果を保持したまま、観測と検証を再開できます。

タイムアウトだけでは、新しい取引を開始してはいけません。

これは、PriorSeal に関する私の取り組みの一部です。再起動や応答の喪失後に、既存の操作を通じて認可と実行の証拠を復旧します。

ウォレットまたは実行者（executor）はトランザクションの送信を引き続き制御します。歴史的な証拠を復旧しても、期限切れの認可が更新されるわけではありません。

再起動後、あなたのエージェントは元のトランザクションの調査を継続できますか？それともワークフロー全体を最初からやり直しますか？

https://priorseal.xyz/

#AIAgents #Web3Security

価格が3つ一致します。それだけでAIエージェントは取引できるだけの十分な根拠を得られるのでしょうか？

$ETH → $USDC スワップを準備するエージェントを想像してください。

それは、3つの類似した見積もり（クオート）を受け取ります。しかし：
• 1つはポリシーの「参照元の経過時間（source-age）上限」を超えています。
• 1つは検証可能な更新日時がありません。
• 1つだけが鮮度要件を満たしています。

これは仮想の例であり、今日の市場に関するレポートではありません。

価格は整合して見えます。それでも、根拠が不十分な可能性があります。

エージェントのリスク記録は区別してほしいです：
1. 検出された市場リスク。
2. 有効な根拠が不十分。
3. データ取得の失敗。

それぞれに異なる対応が必要です。根拠が不十分な場合、エージェントは設定済みのポリシーに従い、必要に応じて停止し、再評価し、理由を保持すべきです。

これは私が Insight と一緒に作っている一部で、価格の不一致に加えて、カバレッジ、参照元の経過時間、評価範囲を確認します。

直近で取得したクオートでも、古い参照元データが含まれていることがあります。また、3つのエンドポイントがあっても、その数だけで3つの独立した参照元が確立されるわけではありません。

エージェントにとって、価格を取得することは出発点にすぎません。

あなたのエージェントは根拠が不十分なときに停止し、欠けているものを正確に記録しますか？

https://www.oracleinsight.xyz/

#AIAgents #defi

AIエージェントはウォレットの支出上限の範囲内に留まっても、誤った判断を下すことができます。
ETH → USDCのスワップを想像してください。100ドルの上限は金額を制限しますが、ユーザーがこの正確な取引を承認したことを証明するものではありません。その承認は、チェーン、対象コントラクト、calldataハッシュ、値、nonce、有効期限などを指定している場合があります。承認後にcalldataが変更されても、$100未満に留まったからといって、新しい呼び出しが承認済みになるわけではありません。
私はこれを2つのタイミングでテストします：
署名前：最終的な呼び出しは、ユーザーが署名した承認と一致しているか？
実行後：観測された取引はそれと一致しており、独立したレビュアーがレシートを確認できるか？
再現可能な合成のBaseスワップテストでは、変更されたcalldataを拒否します。これは取引を送信せず、資金も移動しません。
Insightは、取引前のオラクルとリスクの根拠を別々に提供します。PriorSealは、正確な呼び出しの承認と、観測された実行の証拠を記録します。これらは単独でも、組み合わせても利用できます。
次の公開テストケースで、どの失敗を最も再現してほしいですか：古いリスクデータ、過度に広い権限、承認と異なる実行、または実行後の証拠の欠落？
#AIAgents #Web3Security

支出制限や許可リストは、AIエージェントのウォレットを完全に制御可能にしますか？

バイナンスは最近、Agentic Walletに組み込まれた境界として、ケイパビリティの切り替え、別個の支出割当、トークンの許可リスト、受取人の制限、取引シミュレーション、そしてアクティビティ通知を説明しました。

これは会話が次のように移っていることを示しています：

「AIエージェントは取引できますか？」

から

「正確にどの境界の範囲内で取引してよいのですか？」

そして、もう1つ質問する必要があると思います：

実行後、ユーザー、または独立したレビュアーが、そのエージェントがそれらの境界の範囲内に留まったことを検証できますか？

例として、$ETH → $USDCのスワップを考えます。私は、独立して検証できるエビデンス層を3つ用意したいです：

1. 意思決定の前

市場データは新鮮でしたか？独立したオラクルソースは一致していましたか？その時点で利用可能だったリスク判定は何でしたか？

2. 承認時

誰が、どのチェーン、どのコントラクト、いくら、calldataのハッシュ、nonce、有効期限ウィンドウを承認しましたか？

3. 実行後

オンチェーンの取引は、承認された正確な呼び出しと一致していましたか？失敗した場合、それが再編（reorganized）されたのか、あるいは不確実なままだったのか。その場合でも、元のエビデンスは保持されていましたか？

だからこそ私は2つの別製品を設計しました：

• Insightは、意思決定の背後にあるデータとリスクシグナルを検証します。
• PriorSealは、ユーザーまたは組織の認可を観測されたEVM実行に結び付け、オフラインで検証可能なレシートを生成します。

これらは独立して、または組み合わせて使えます。いずれの製品も、資産を保有せず、ウォレットのためにトランザクションへ署名せず、ウォレットレベルの制限や許可リストを置き換えません。

エージェントウォレット、またはオンチェーンエージェントを構築しているなら、どの失敗を最初に解決しますか？

A. 悪いデータ
B. 権限が広すぎること
C. 承認からの実行逸脱
D. 信頼できる実行後の記録がないこと

最も選ばれたシナリオを、次の公開テストケースにします。

#AIAgents #Web3Security

オンチェーン上での1つのアクション。入力は信頼できたのか、誰がそれを承認したのか、そして実際に何が起きたのか？

私は、InsightとPriorSealを2つの課題に対して構築しています。これらは別々にも、あるいは組み合わせて解決できます。つまり、オンチェーンの意思決定は、その背後にあるデータとリスクシグナルに頼れるのか？またEVMのアクションにおいて、承認された内容と実際に起きたことを検証できるのか？

オラクルデータに依存するアプリケーション、オンチェーンのリスクを監視する取り組み、あるいはオンチェーンアクションの認可・実行・レビューに関わる作業をしているなら、あなたの実運用ワークフローのうち、特に「検証が難しい」部分がどこかを教えてください。私は、最初に一緒に具体的なユースケースをテストしてくれるユーザーまたはチームを探しています。コメント欄で考えを共有するか、詳細が公開されていない場合はBinance Squareでここにメッセージをください。秘密鍵やその他の機微な情報は送らないでください。#AIAgents

市場リスクは、オラクルが示すごくわずかな価格ギャップの中に潜むことがよくあります。
以下は9月19日のオラクル・デイリー・レポートです。21の資産に対して8つのオラクル・プロバイダーを継続的に追跡し、1000件の価格スナップショットを取得して、DeFi基盤の奥深くに隠れた安全性シグナルを掘り起こします。
本日のスキャンで8件のリスクが特定されました。108件の重大な異常、7件の高リスク事象、41件の中リスクアラートが含まれます。WBTCは26.87%という大幅なペッグ差異を示しており、本日の最も深刻なラップド資産のデペッグ警告となっています。XRPはプロバイダー間の最大偏差54.98%を記録しました。ETHおよびBNBにおける価格フィードの乖離は、いつでも連鎖的な清算（リキディエーション）を引き起こし得ます。
ストレステストは明確な警告を発しています。BNBチェーン上のVenus Protocolは、最も薄い清算バッファを保持しています。オラクルの共同偏差73.31%により、ポジションが清算しきい値を超えることになります。稼働中の8プロバイダーのうち6社で異常が記録されました。API3は大きなデータドリフトに見舞われ、Reflectorは成功率40%にとどまりました。
データ収集の全体成功率は99.1%を維持し、平均偏差は1.969%です。前日からわずかに改善しています。156件のクロス・オラクル偏差記録は、価格コンセンサスの亀裂がDeFiリスクの始まりであることを改めて私たちに思い出させます。
市場のノイズと市場の現実を混同しないでください。オラクルの証拠を読み取り、清算とデペッグの“伏流”を前もって見抜きましょう。
#oracles

市場のノイズが本当のリスクシグナルを覆い隠してしまうことが多く、オラクルデータはオンチェーンで起きたことを裏付ける具体的な証拠になります。
こちらは9月17日のオラクル・デイリー・レポートです。10のオラクル提供者にまたがって21のアセットを追跡し、6つの時間帯（6時間ウィンドウ）の中で1000件の価格スナップショットを取得しました。今日特定したリスクカテゴリは8種類で、内訳は重大な異常イベント90件、高リスクイベント21件、中リスクイベント50件です。
WBTCはラップド・アセットのペッグ乖離が最大で22.33%を記録し、TBTCも重大なペッグリスクを引き起こしました。ETHの価格フィードにおける乖離は拡大を続けており、貸出（レンディング）市場の清算リスクを押し上げています。ストレステストでは、BNBチェーン上のVenus Protocolが最も薄い安全バッファを保っていることが示されました。オラクル間の乖離（共同オラクル偏差）71.96%は、ベンチマーク・ポジションを清算の閾値を超える方向へ押し出します。
データ収集の成功率は96.1%で、前日から1.6ポイント低下しました。オラクル間のコンセンサス乖離により161件の重要な事象がフラグされました。今日、10提供者中7社で異常が確認され、API3はXRPの価格乖離で68.26%をピークとして提示しました。監視対象の21アセット中18件で、目立ったボラティリティまたはクロスソースでの価格乖離が見られました。これらの価格ギャップは、連鎖的な清算やペッグの崩壊を引き起こしやすくなります。
短期的な市場の値動きに気を取られないでください。基盤となるオラクルデータを読み取り、攻撃（または発生）する前に隠れたDeFiリスクを見抜きましょう。#oracles

市場は派手な値動きで私たちを魅了します。しかし、あらゆるDeFiポジションを支える“隠れた背骨”は、私たちがめったに確認しないオラクルデータです。
日次のオラクルリスク監視を継続します。9月12日のデータでは、9つのオラクル提供元と21のオンチェーン資産を対象に、1000件の価格スナップショットを取得しました。逸脱イベントは118件記録され、前回セッション比で12.38%上昇しています。加えて、58件の稼働中の重要リスクアラートがあります。
リスクのシグナルは、市場の表面の下でさらに加熱しています。TBTCのペッグ乖離は46.43%まで深まり、最も懸念されるラップド・アセットとして深刻なリスク状態を維持しています。API3のフィードは極端なドリフトに到達し、XRPは最大乖離60.44%を記録。ETHの価格フィードの不整合も継続しており、レンディング市場の参加者は、絶えず清算の脅威にさらされています。
本日、9つのオラクル提供元のうち6つが異常な価格読み取りを提供しました。BNBチェーン上のVenus Protocolは、非常に狭い安全余裕を維持しています。オラクルの合同的な逸脱が72.25%に達すると、大規模な担保の清算を引き起こすのに十分です。
データ収集パイプラインは、完璧な100%の成功率で堅調に推移しています。平均逸脱は日次で高くなりました。市場の見出し上のセンチメントが落ち着いていても、基盤となるオラクルの脆弱性は着実に積み上がっています。
価格チャートは“何が起きているか”を教えてくれます。オラクルの証拠は“次に何が壊れ得るか”を示します。引用された価格への盲目的な信頼は、あなたが気づく前にDeFiエクスポージャーを消し去ってしまうかもしれません。
#oracles

ほとんどのDeFiユーザーはトークン価格だけを見ています。 それらの価格を供給するオラクルを監視する人はほとんどいません。ライブ・オラクル・リスク監視のDay 5です。今日は、9つのオラクル提供元にまたがって21のアセットをスキャンし、リアルタイムの価格スナップショットを1000件収集しました。異常イベントは前日比+18.1%と急増し、偏差スナップショットは124件に達しました。現在、重大アラートが57件アクティブになっています。
危険は表面の下で居座り続けます。TBTCのペッグ偏差は深刻なままで44.43%を維持しており、ダッシュボード上でも最悪のペッグリスクです。API3のフィードでは極端なドリフトが見られ、XRPは最大偏差が57.72%に達しました。ETHの価格フィードの一貫性の欠如が続いており、貸出ユーザーが突然の清算リスクにさらされる状況が露呈しています。
監視対象の9つのオラクル提供元のうち8つが、今日、異常な価格出力を生成しました。BNBチェーン上のVenus Protocolは、極めて薄い安全域の上に位置しています。大規模な担保の清算を引き起こすには、共同オラクル偏差が71.97%に達する必要があります。
データ収集は成功率100%で堅牢に維持しています。平均偏差はわずかに低下しましたが、異常シグナルが急激に急増しました。
市場は価格ノイズをあなたのフィードに流し込みます。しかし、実際のリスクはオラクルデータの中にあります。見えないものは、あなたのDeFiポジションを一掃し得ます。#oracles

占い師（オラクル）リスク監視の3日目。
私たちは9つのオラクル・プロバイダーにまたがる21の資産を追跡し、価格スナップショットを1000件収集しました。今日は117件のクロスフィードの乖離イベントを捉え、68件のクリティカル・アラートが発火しました。平均乖離は前日比で0.073パーセンテージポイントまで上昇し、一方で総異常量はわずかに減少しました。
TBTCの深刻なペッグ（連動）ストレスは悪化し、コンセンサス価格に対する乖離は43.03%に到達しました。API3の極端な価格ドリフトは依然として継続し、XRPの最大乖離はさらに56.22%まで上昇しています。ETHの価格フィードに関する不一致は、DeFiレンディングの利用者にとっての現実的な清算リスクをなおも引き起こしています。
9つのオラクル・プロバイダーのうち5つが、異常な出力を提供しました。BNBチェーン上のVenus Protocolは、観測される限り最も狭い清算バッファを維持し続けています。共同のオラクル乖離が72.53%に達すると、担保ポジションは清算レンジへ直接押し込まれます。
データ収集は100%の成功率を維持しているものの、根本的な市場リスクはなお煮え続けています。市場のノイズが判断を曇らせますが、オンチェーンのオラクル証拠は実際に何が起きているかを明らかにします。危険信号は、連鎖的な障害が発生する前に徐々に積み上がっていきます。ノイズではなく証拠を読み取ってください。
#oracles

オラクル・リスク・ウォッチリストの第2日目です。
本日、9つのオラクル提供者にまたがる21の資産を監視し、1000件の価格スナップショットを収集しました。今日は118件のクロスフィードの乖離イベントを記録し、そのうち68件がクリティカルとしてタグ付けされています。平均乖離は前日比でわずかに低下したものの、総異常件数は6%以上増加しました。
TBTCは依然として厳しいペッグ圧力下にあり、コンセンサスからの乖離は41.60%です。API3は引き続き極端な価格ドリフトを出力しており、XRPの最大乖離は55.07%に達しています。ETHのフィードの不一致は、レンディング市場の参加者に対する清算リスクを継続して生かしています。
9つのオラクル提供者のうち6つが異常な読み取りを生成しました。BNBチェーンでは、Venus Protocolが最も薄い清算バッファを維持しています。共同オラクルの乖離が72.79%に達すると、ポジションは清算領域へ押し込まれるでしょう。
データ収集は100%の成功率で堅牢なままですが、リスクシグナルは積み上がり続けています。市場のノイズがあなたの注意をそらすことはありますが、生のオラクル証拠が本当の物語を語ります。大規模な連鎖的失敗が起きる前に、早期警告のシグナルはここにあります。ノイズではなく、証拠を読み取ってください。
#oracles

クロス・オラクル監視の“もう一日”。そしてリスク信号は増え続けています。
9つのオラクル提供元にわたって21のアセットを追跡し、価格スナップショットを1000件収集しました。今日はクロスフィードの乖離イベント111件を確認し、重大なリスク・アラートは64件がフラグされました。平均価格の乖離は前日からわずかに上昇しました。
TBTCは依然として深刻なペッグ・ストレスにさらされており、市場コンセンサスからの乖離が42.11%に達しています。API3は価格ドリフトの主な発生源であり、XRPの数値は53%超の極端な乖離を示しています。ETHの価格フィードの乖離も、レンディング利用者にとって現実的な清算リスクをもたらします。
DeFiレンディング・システムは引き続き圧迫されています。BNBチェーン上のVenus Protocolは、依然として最も薄い清算バッファを保持しています。オラクル乖離の共同指標が73.35%となれば、担保ポジションは清算ラインを超えることになります。セッション中に9つのオラクル提供元のうち5つが、異常な価格出力を生成しました。
データ収集成功率が100%であっても、警告は変わりません。オラクル・フィード間の乖離は早期警戒サインです。連鎖的な清算やペッグ崩壊が見出しになるずっと前に、これらの数字はすでに物語っています。私たちは市場のノイズではなく、証拠を読み続けます。
#oracles

9つのデータプロバイダーと21の暗号資産にわたる1日 முழのクロスオラクル監視の結果、今日の市場シグナルはランダムなノイズよりもはるかに大きな重みを持っています。
当社のInsightプラットフォームは1000件の独立した価格スナップショットを取得し、104件の乖離イベントを検出しました。そのうち65件は重大なリスクアラートとしてマークされました。
ラップド資産のデペッグ圧力が急激に表面化しました。TBTCはコンセンサス価格から42.70%という深刻な乖離を示し、WBTCとXRPでも不安定な価格レポートが続きました。API3は価格乖離の最大の発生源であり、XRPに対してコンセンサス外のフィードを繰り返し提供し、乖離率は55%を超えました。
レンディング市場も緊張状態にあります。主要なDeFiレンディングプロトコルを対象としたストレステストでは、BNB Chain上のVenus Protocolが大規模清算リスクに最も近いと判定されました。73.36%のオラクル価格乖離が発生すると、担保ポジションは安全閾値を超えてしまいます。
全体のデータ収集信頼性は100%の成功率で安定していましたが、今日の警告が一つの事実を明確に示しています。価格フィードの乖離は、清算やペッグ崩壊が起こる前に、しばしば最初に現れます。私たちは、リスクが市場を不意打ちにする前に、引き続きデータを監視しています。#oracles

前回の投稿では、verify-insight-receipt を簡単に紹介しました。

今回は、それが実際に解決している問題に焦点を当てたいと思います。

システムが「安全」な結果を返したとき、その結果をどうやって独立して検証できるでしょうか？

Insight Oracle Safety Receipt には、署名、リクエストハッシュ、有効期限データ、そして元の検証結果が含まれています。しかし、JSON オブジェクトを受け取ったからといって、それを信頼できるとは限りません。

次のような点を、引き続き判断する必要があります。

• 受領書が発行後に改ざんされていないか
• 署名が主張されている署名者のものか
• UID が再構築された EIP-712 ペイロードと一致しているか
• 再確認が元のリクエストに紐付いているか
• 受領書が期限切れになっていないか
• 署名鍵がまだ信頼できるものと見なされるか

verify-insight-receipt は、まさにそれを行うために設計されています。

インストール:

npm install verify-insight-receipt

使い方:

import { verifyReceipt } from 'verify-insight-receipt';

const result = await verifyReceipt(receipt);

if (result.code !== 'ok') {
throw new Error(`Receipt rejected: ${result.code}`);
}

検証プロセス全体はローカルで完結します。

• Insight の API キー不要
• 受領書のアップロード不要
• Insight がオンラインであることへの依存なし
• 公開されている EIP-712 スキーマと暗号署名から結果を再構築

これにより、受領書はプラットフォーム上で表示されるだけのものから、開発者、AI エージェント、監査担当者、実行システムが自分たちで検証できる証拠へと変わります。

有効な署名は、その取引が正しいことを保証するものではなく、投資の承認でもありません。

それが証明するのは、より限定的で、より有用なことです。

記載された内容は対応する鍵によって署名されており、それ以降改ざんされていないこと。

盲目的に信頼せず、検証してください。

https://www.npmjs.com/package/verify-insight-receipt

#AIAgents