システムは、独立して見える5つのフィードを参照しても、なお1組の目を通して市場を見ている可能性があります。
複数の承認済み価格ソースが一致したときだけリバランスする自動化された金庫を想像してください。
方針は保守的に見えます。
単一のフィードでは結果を制御できません。
最新の値は新鮮です。
中央値は許容範囲の内側にとどまっています。
VaultKitは決済前にアクションを評価し、必要なすべての条件が満たされ、認可プロセスによって署名された結果が生成されます。
すると金庫は、5つのすべてのフィードが、直接または間接に同じ薄い市場に依存していたことを発見します。
それらは別々に失敗しませんでした。
彼らは同じ弱点を5回繰り返しました。
捏造する必要はありませんでした。
データは最新である可能性があります。
値は一致し得ます。
政策は、設計どおりにまさに実行され得ます。
隠れた失敗は、合意を独立性とみなすことでした。
そして、私には、自律的な金融が、ますます複雑な証拠に依存するようになるほど、そのデータの問題は重要になっていくように思えます。
政策エンジンは、どれだけの情報源が意思決定を支持しているかを数えることができます。
それらの情報源が、異なるインターフェース経由で到達しているだけだという理由で、本当に異なる情報を表していると決めつけるべきではありません。
最終的には3つのプロバイダが、同じ取引所を参照することになるかもしれません。
複数のフィードが、同じ上流の集約器を使うことがあります。
異なる市場データサービスは、1つの会場に集中した流動性に依存しているかもしれません。
たとえ独立して運用されているシステムでも、同じ狭い部分の市場を観測することで相関を持つようになることがあります。
アプリケーションの観点では、証拠は多様に見えます。
リスクの観点では、それでも1点の故障箇所（単一障害点）が残るかもしれません。
ここで私は、Newton Mainnet Beta が興味深いと感じます。
VaultKit を通じて、アプリケーションは、エージェント・マネージャ・自動化された戦略が実行してよいことの範囲に関する条件を定義できます。 @NewtonProtocol can は、決済の前にその評価を行わせ、価値が動く前の段階でアクションを拒否できるポイントを作れます。署名付きの証明（アテステーション）によって、事後に認可イベントをより確認しやすくすることもできます。
それは、取引が最終確定した後に意思決定を見直すだけよりも、より強い立場です。
しかし、署名付きの結果は、必要なチェックが行われたことは証明できますが、それらのチェックの背後にある証拠が意味のある形で独立していたことまでは証明できません。
アテステーションは、承認された5つの入力が一致したことを示し得ます。
それは、5つの入力が現実の別々の見方を表していたことを自動的に示すものではありません。
私にとって、この区別は決定的に重要です。
情報源間のコンセンサスは、意見の相違が本当に起こり得る場合に限って、信頼度を高められます。
すべてのフィードが同じ上流の依存関係を共有しているなら、依存関係そのものが間違っている場合でも、一致がデフォルトの結果になり得ます。
その場合、情報源の数は誤解を招くセキュリティ指標になります。
より強い問いは、こうではありません。
何本のフィードがチェックされましたか？
それは：
どれだけの異なる故障経路（failure paths）が表現されていましたか？
新たなエクスポージャーを開く前に、いくつかの価格入力を使う金庫（ボールト）を考えてください。
1つのフィードはオラクルサービスから来ています。
別のものはデータ集約器（アグリゲータ）経由で来ます。
3つ目は、アナリティクス提供者から供給されます。
表面上、情報源は独立しているように見えます。
しかし、3つすべてが、流動性が弱い期間に同じ取引所から参照価格を計算しているのなら、アプリケーションは見かけほど証拠を分散していません。
インターフェースは異なります。
前提となる市場の仮定は同じです。
これは微妙な失敗を生みます。政策が、より依存度を高めたにもかかわらず、より頑健に見えてしまう可能性があるからです。
フィードが増えるほど、確認（コンファーム）が増えます。
確認が増えるほど、信頼度は高まります。
信頼度が高まれば、エージェントはより速く行動できます。
しかし、その一連の流れ全体は、いったん広範な価値を表さなくなった1つの市場に左右される可能性もあります。
したがって、自動化によって、参加者がだれも不正を働かなくても、誤った信頼感を拡大（スケール）できます。
それは古いデータとは異なります。
古い入力は、より前の市場を表します。
相関のある証拠は現在の市場を正確に描写できるかもしれませんが、それは狭く、しかも潜在的に歪んだ視点からである場合に限られます。
どちらも誤った行動を認可してしまえます。
それらは別々の理由で失敗します。
Newton を活用した真面目なアプリケーションには、その区別を維持してほしいです。
政策は、「新鮮（fresh）」と「独立（independent）」を互換的な性質として扱うべきではありません。
また、各ソースが承認されているというだけで、すべてのソースを同等だとみなすことも避けるべきです。
いくつかの意思決定では、取引所（会場）間で多様性が必要になる場合があります。
別のものは、プロバイダ間での多様性を必要とするかもしれません。
高リスクの行動には、価格と利用可能な流動性の両方を反映する証拠が必要かもしれません。
低リスクの返済は、より単純な基準でも安全なままかもしれません。
証拠の要件は、行動の結果に見合うものにすべきです。
レバレッジをかけたエクスポージャーを開くことは、リスクをクローズする場合と同じソース前提に必ずしも依存すべきではありません。
担保（コラテラル）を引き出すことは、負債を返済することと同じように評価されるべきではありません。
行動を取り消すのが難しいほど、支える証拠がどこから来たのかを理解する重要性は高まります。
私もまた、この問題をすべての取引で最大数の情報源を要求することで解決しようとはしません。
入力が増えるほどコストも増えます。
それらは認可を遅くできます。
それらは、政策が解決しなければならない不一致を生み出し得ます。
それらはアプリケーションの運用や監査を難しくし得ます。
同じ上流の依存関係を繰り返すだけなら、別のフィードを追加してもほとんど価値がありません。
目的は最大限の冗長性ではありません。
それは有用な独立性です。
つまり、開発者は各政策条件の背後にある証拠の連鎖を理解する必要があります。
どの市場がその価値を生み出したのですか？
それを変換したのはどのプロバイダですか？
共有された前提は何でしたか？
観測を裏づけた流動性はどれくらいでしたか？
情報源が数値的には一致しているが、独立性の要件を満たしていない場合はどうなるべきでしょうか？
これらの問いによって、データの出所（プロヴナンス）が、見えないインフラの細部ではなく、認可設計の一部になります。
すると、有意義な署名付きの認可記録が、レビュアーに対して、その政策が通過したことだけでなく、その決定を支えた証拠クラス（種類）が何であったかを理解する手がかりになります。
記録は、すべての機密の実装詳細を公開する必要はありません。
しかし、開発者・利用者・認可済みのレビュアーは、複数の同一依存関係のコピーによって支えられた決定ではなく、本当に多様な入力によって支えられた決定を区別できるはずです。
特に、AIエージェントが認可結果を自動的に消費する場合に、これは重要です。
人間のアナリストなら、5つのフィードがすべて1つの不安定な場に依存していることに気づくかもしれません。
ソフトウェアは5回の確認を受け取り、信頼度を高めることがあります。
承認がどれだけ機械可読になるかに応じて、それを裏づける証拠はどれだけ慎重に分類される必要があります。
そうでなければ、誤った種類の合意を信頼することについて、システムが完全に一貫した状態になってしまうことがあります。
それは、Newton Mainnet Beta を判断するときに私が使う標準です。
単に、アプリケーションが決済前にマルチソースのルールを強制できるかどうか、という話ではありません。
その政策が、複数の情報源がなお1つの根本的なリスクを表し得ることを認識できるかどうか。
信頼できる認可システムは、インターフェースを数に入れるべきではありません。
証拠が間違っていた可能性のある独立した方法を数えるべきです。
5つの一致するフィードが、すべて同じ場所から答えを学んだのであれば、5つの真実を作るわけではありません。
$NEWT @NewtonProtocol #Newt $LAB $VANRY #Velvet #xau #VANRY #Labs
