@NewtonProtocol は社内の取引ボットの形で「AI」を販売しません。代わりに、他者がAI戦略を構築し検証するための基盤（配管）を提供します。Newton Model Registryにより、開発者はAI戦略コード（トリガー・アクションのコントラクト）をオンチェーン上で公開できます。
その後、開発者はモデルのために担保をステークすることでNEWTを獲得でき、戦略が誇大宣伝ではなくパフォーマンスで評価されるマーケットプレイスが生まれます。原則として、ユーザーは（支出上限やコントラクトの許可リストなどの）事前定義されたルールに従って、これらのエージェントに資金を委託します。
システムのRegoポリシーは、ニュートンのドキュメントに示されている通り、これらのガードレールを自動的に強制します。たとえば input.intent.value <= max_agent_spend の上限を設けたり、コントラクトアドレスの許可リスト（allowlist）を適用したりします。このアーキテクチャは実際の課題に対処しています。つまり、AIアルゴリズムは高速に動作できますが、現実世界での説明責任が欠けがちです。ニュートンのアプローチは、すべてのエージェントの行動を監査可能かつ許可制にすることで、その点を担保しようとしています。
セキュリティとリスク：ニュートンのモデルは独自の攻撃ベクトルを導入します。オペレーターノードが共謀すれば、EigenLayerによるスラッシングが行われない限り、不正な証明を作り出せる可能性があります。TEEとZKの活用はオフチェーン実行の強化を意図していますが、集中化の懸念は残ります。実際、一部の分析では、ニュートンのローンチ段階では、ロールアップに財団運営のTEEサーバーを使用し、その後「段階的な分散化」が進むと指摘されています。これは当初、財団がコンセンサスを支配することを意味し、「信頼最小化」の論調と衝突します。
関連するリスクとしてアップグレード管理があります。中核となるアップグレードはバリデータの合意を必要とするため、財団が支配するノードの少数が、変更を拒否したり、チェーンのフォークを強制したりする可能性があります。オンチェーンでは、ニュートンは新しい暗号（BLS署名、場合によってはzkSNARKやTEEによる証明）に依存しており、そのため幅広く新規性のある攻撃対象面を持ちます。
監査とピアレビューは不可欠です。（ニュートンのGitHubはセキュリティ監査プロセスを示していますが、ホワイトペーパーは、ライブ後はポリシーパックが「監査では検証不能」だと認めており、ランタイムでのチェックに委ねています。）トークノミクスも権力を集中させています。初期段階では78.4%のトークンがインサイダーによってロックまたは管理されています。分析としては、ユーザーは本当に権限を信頼できるのか、それともその信頼は実質的に財団に置かれているのか、を精査すべきです。これらはいずれも未解決の問いです。