> For the complete documentation index, see [llms.txt](https://newsandwich.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://newsandwich.gitbook.io/docs/new-sandwich-whitepaper/jp.md).

# New\_Sandwich\_Whitepaper\_JP

## New Sandwich

> \*\*プロトコル・コア：\*\*New Sandwichは、サンドイッチ攻撃保護、オンチェーン実行最適化、およびユーザーへの価値還元に特化したプロトコルです。リアルタイムのオンチェーンインテリジェンス、実行前シミュレーション、保護ルーティング、準拠バックラン戦略競争、および検証可能な決済を通じて、情報非対称性と順序付けの優位性によってこれまで捕捉されていた価値を、ユーザー、ウォレット、ストラテジーチーム、エコシステムプロジェクト向けのオープンなプロトコル機能として提供します。

## エグゼクティブサマリー

> New Sandwichは、公開オーダーフロー向けの基盤となるオンチェーン取引保護および戦略実行プロトコルです。体系化された技術基盤を通じてサンドイッチ攻撃と実行価値の漏洩に対処し、独立したエコシステムプロジェクトに対して標準化されたコンポーザブルなプロトコル接続と協力を提供します。

New Sandwichは、ウォレット、取引アプリケーション、オンチェーンユーザー、ストラテジーチーム、独立エコシステムプロジェクト向けのサンドイッチ攻撃保護およびオンチェーン実行保護プロトコルです。プロトコルはユーザー取引実行に対して6段階の保護パイプラインを実装します：リスク識別、保護送信、実行前シミュレーション、制約付き実行、ユーザーへの価値還元、結果検証。

取引意図の露出を減らし、ユーザーが指定した制約条件を厳格に満たし、有害なトランザクション順序を検知・排除することで、New Sandwichはプロトコルルールに従って配分可能な価値を再分配しつつ、プロトコルの持続可能性に貢献します。Flashbots MEV-Shareなどの公開メカニズムは、保護されたオーダーフローが選択的開示とシミュレーション制約の下でバックラン競争を許容し、価値の一部を元の取引当事者に再分配できることを示しています。

New Sandwichの技術的優位性はシステム構成に基づいています：マルチソースのオンチェーン状態ストリーム、サンドイッチリスクスコアリング、フォーク状態シミュレーション、クロスルート純価値比較、プライベート送信とBundle実行、ストラテジーアダプター、コスト帰属、公開データ検証。単一の能力が単独でNew Sandwichを構成するのではなく、統一された実行ループ内でのこれらの能力がシステム全体として統合されることで技術的優位性が生まれます。

エコシステム協力はNew Sandwichの技術能力をスケールさせる主要な経路であり、プロトコル製品自体の代替ではありません。サンドイッチ攻撃保護、ユーザー取引保護、実行最適化を中核とし、New Sandwichはノード引受とオンチェーンプロトコル参加証明書という2つの公式協業モデルを通じて、独立エコシステムプロジェクトに戦略実行、データ、決済能力を公開します。

*図1-1 | New Sandwichサンドイッチ攻撃保護ループ*

| **コア能力**   | **製品機能**                                      | **ユーザー成果**                    |
| ---------- | --------------------------------------------- | ----------------------------- |
| リスク識別      | 公開露出、スリッページ空間、プール深度、Gas競争、順序リスクを識別            | ブロードキャスト前に取引が容易にサンドイッチ可能かを判断  |
| 保護実行       | プライベートルーティング、制御されたオーダーフロー、Bundle、フェイルクローズポリシー | 意図の早期露出と不安全なフォールバックを削減        |
| ユーザーへの価値還元 | ユーザー結果を害さない認可されたバックラン実行のみを許可；あらゆるサンドイッチ攻撃を禁止  | 配分可能なMEVをユーザー、ウォレット、プロトコルに再分配 |
| 実行証跡       | シミュレーション、ルーティング、約定品質、コスト、価値還元、取引ハッシュを記録       | 保護効果を照会可能、監査可能、蓄積可能にする        |
| オープン戦略     | 外部戦略は標準アダプタ、権限、決済ルールを介して接続                    | 安全境界を維持しつつ戦略カバレッジを拡大          |

## オンチェーン取引環境とサンドイッチ攻撃

**MEVとは、ブロックプロデューサーや他の参加者が取引の順序付け、包含、除外によって得る追加的な価値です。アービトラージや清算はDeFiの効率を向上させますが、サンドイッチ取引はユーザーに直接悪い約定価格とスリッページを引き起こします。**

### 2.1 なぜ順序競争がオンチェーンで本質的なのか

オンチェーン取引はユーザーが「確認」をクリックした瞬間に完了するわけではありません。取引はRPC、公開またはプライベートオーダーフロー、Builder、ブロック提案、最終確認を経ます。公開オーダーフローでは、確認前に取引意図が観察される可能性があり、大規模スワップ、浅い流動性、緩いスリッページ、活発な競争が相まってサンドイッチ攻撃の条件を生み出します。

| **構造的位置** | **攻撃者が観察するシグナル**                 | **ユーザーへの影響**                |
| --------- | -------------------------------- | --------------------------- |
| 取引意図      | ペア、サイズ、最小受取額、Gas、対象契約            | 価格影響と許容可能なスリッページ空間を露出       |
| AMM状態     | プール準備金、価格曲線、クロスプールスプレッド、流動性深度    | フロントランニング取引が押し上げ可能な価格範囲を決定  |
| ブロック構築    | 優先手数料、Bundle、Builderカバレッジ、ブロック競争 | フロントラン、ユーザートレード、バックランの順序を決定 |
| 実行結果      | ユーザー約定、攻撃者アンワインド、Gas、純利益         | ユーザーは悪い価格を負担；攻撃者がスプレッドを捕捉   |

*図2-1 | サンドイッチ攻撃の高レベル実行チェーン*

### 2.2 ボットシステムはスクリプトから実行インフラへ進化中

初期のボットは固定パラメータと単一取引プールに依存していました。次世代サーチャーシステムはプール状態、Gas、オラクル、Builder、クロスマーケット状態を同時に読み取り、シミュレーションを使用して候補パスを比較します。公開メムプールはすべてのチェーンとL2で均一な構造ではなく、プライベートシーケンサーとプライベートメムプールが攻撃の実現可能性を変えます。したがってプロトコルはチェーンレベルの適応を採用しなければならず、Ethereum L1の仮定をすべてのネットワークにコピーすることはできません。

*図2-2 | サーチャーとサンドイッチボットの技術進化（MEVサーチャー）*

### 2.3 既存のポイントソリューションの限界

| **一般的なアプローチ** | **対処する問題**          | **残るギャップ**                              |
| ------------- | ------------------- | --------------------------------------- |
| スリッページの引き締め   | 攻撃者の利益空間を圧縮         | 過度の引き締めは失敗を引き起こす可能性；プライバシーやルーティングに対処しない |
| 単一プライベートRPC   | 公開露出を削減             | Builderカバレッジとサービス可用性に依存；実行品質を自動比較しない    |
| 取引シミュレーション    | リバートと価格影響を識別        | 状態、ブロック、Bundleコンテキストが不一致の場合結果が乖離        |
| 単一ボット         | 1つの戦略または1つのチェーンをカバー | 高いメンテナンスコスト；異なる市場構造への継続的適応が困難           |
| データダッシュボード    | 実行結果を表示             | コスト帰属と生の検証がなければ表面的な透明性のみ                |

## New Sandwich製品機能

**New Sandwichは「ユーザー取引実行を保護 — 意図露出を削減 — 有害な順序付けを緩和 — 実行結果を検証」する完全な保護プロトコルです。**

### 3.1 三層保護メカニズム

| **レイヤー**      | **製品アクション**                                             | **コア結果**                                            |
| ------------- | ------------------------------------------------------- | --------------------------------------------------- |
| Shield \| 保護  | 取引はProtected RPC / SDK経由で入り、リスクが識別されプライベートまたは制御パスが選択される | 取引意図の公開露出を削減                                        |
| Guard \| 能動防御 | ユーザー制約が違反されない前提の下、準拠バックラン戦略のみが競争可能                      | ルールにより配分可能なバックラン価値をユーザーに再分配し、ユーザーを害さずにプロトコル持続可能性に貢献 |
| 実行証跡          | 実行証跡、価格影響、Gas、価値還元、戦略帰属記録を生成                            | 検証可能なデータで保護効果を検証                                    |

*図3-1 | Protected Order Flow and ユーザーへの価値還元*

### 3.2 製品形態

| **製品エントリー**       | **対象者**              | **主要機能**                             |
| ----------------- | -------------------- | ------------------------------------ |
| Protected RPC     | 個人ユーザーとウォレット         | 保護送信、ルート選択、取引ステータスと価値還元履歴            |
| Wallet / DApp SDK | ウォレット、DEX、アグリゲータ、アプリ | リスク事前チェック、最小受取保護、ルーティングとフロントエンドステータス |
| Execution API     | 機関とエコシステムプロジェクト      | バッチ実行、制約戦略、プライベートチャネル、決済証跡           |
| ストラテジーアダプター       | サーチャーとストラテジーチーム      | 標準状態入力、候補出力、シミュレーション、権限、パフォーマンス帰属    |
| データダッシュボード        | ユーザー、パートナー、市場        | 取引保護、実行品質、純価値、価値還元、プロトコル運用データ        |

### 3.3 ユーザー取引の完全パス

{% stepper %}
{% step %}

#### ユーザーが取引意図を提出

ユーザーまたはウォレットが取引意図、最小受取額、期限、プライバシー設定を提出。
{% endstep %}

{% step %}

#### リスクをスコアリング

リスクエンジンがプール深度、スリッページ、公開露出、Gas競争、Builder状態を使用してスコアリング。
{% endstep %}

{% step %}

#### 実行パスを比較

ルーティングエンジンが公開パス、プライベートパス、制御オーダーフローの期待実行結果を比較。
{% endstep %}

{% step %}

#### 実行前シミュレーションを実行

シミュレーションエンジンがターゲットブロック状態に対して約定、Gas、リバート、競争影響、最悪ケースシナリオを検証。
{% endstep %}

{% step %}

#### ユーザー制約の下で送信

実行レイヤーがユーザー制約の下で送信；制約を満たせない場合はキャンセル、劣化、または明確な失敗状態を返す。
{% endstep %}

{% step %}

#### 認可バックラン戦略を許可

ユーザー取引が完了しユーザー制約が満たされた後、プロトコルはユーザー結果を害さない認可バックラン戦略の参加を許可し、新たに創出された価値をルールに従って配分可能。
{% endstep %}

{% step %}

#### 検証可能な証跡を生成

決済レイヤーが実際の約定、コスト、価値還元、戦略貢献、オンチェーン検証を示す検証可能な証跡を生成。
{% endstep %}
{% endstepper %}

## 技術的優位性と差別化

**New Sandwichは体系的アーキテクチャ、定量可能な実行メトリクス、監査可能なオンチェーン結果を通じて、オンチェーン取引保護と戦略実行における技術的優位性を継続的に構築します。**

*図4-1 | 技術的優位性の6つのシステム能力*

### 4.1 技術的優位性はクローズドループから生まれ、ポイントソリューションからではない

| **比較次元** | **一般的なポイントソリューション** | **New Sandwichプロトコル設計**                       |
| -------- | ------------------- | --------------------------------------------- |
| リスク識別    | 単一スリッページまたは固定パラメータ  | マルチソース状態 + 取引特徴 + 競争環境の共同スコアリング               |
| 実行前検証    | 単純なeth\_callまたは静的推定 | ターゲットブロック状態、署名済み取引、Bundleコンテキスト、最悪ケースシミュレーション |
| ルーティング   | 固定RPCまたは単一Builder   | 公開、プライベート、Bundle、フォールバックパスを純実行品質で比較           |
| 価値処理     | 攻撃をブロックするが残余MEVを無視  | 制御されたユーザー安全なバックラン実行を許可し、配分可能な価値のユーザーへの再分配を優先  |
| 戦略拡張     | 内部単一ボット             | 外部ストラテジーアダプター + サンドボックス + 権限 + 決済 + 評判        |
| 実行証跡     | 成功/失敗ステータス          | 約定品質、Gas、価値還元、帰属、生のオンチェーン記録                   |

## 全体プロトコル技術アーキテクチャ

*図5-1 | New Sandwichプロトコル技術スタック*

| **Technical レイヤー**      | **コア責任**                                       | **主要出力**               |
| ----------------------- | ---------------------------------------------- | ---------------------- |
| オンチェーンインテリジェンス レイヤー     | オーダーフロー、ブロック、DEX、Gas、オラクル、Builder、マルチチェーン状態を収集 | 標準化された状態ストリームとスナップショット |
| Risk & Simulation レイヤー  | リスク分類、機会スコアリング、パラメータ支援、フォークシミュレーション、最悪ケース検証    | 実行可能な候補とリスクラベル         |
| Execution & ルーティング レイヤー | プライベート送信、Bundle、公開パス、Gas/Nonce、キャンセル、フォールバック   | オンチェーン実行結果             |
| ストラテジーネットワーク レイヤー       | 内部および外部戦略登録、サンドボックス、権限、クォータ、評判、パフォーマンス帰属       | 制御された戦略モジュール           |
| Settlement & Value レイヤー | コスト、純利益、価値還元、パートナーシップ配分、エコシステム予算               | 決済記録と帰属データ             |
| Data & Interface レイヤー   | ダッシュボード、API、ノード照会、証明書、webhook、公開検証             | 製品エントリーポイントとデータ資産      |

### 防御的実行疑似コード

```
ctx = observe(tx, pool, gas, oracle, builder_state)
risk = risk_engine.score(ctx) # AI-assisted ranking
route = PRIVATE if risk.high else compare(PUBLIC, PRIVATE)
sim = simulate(tx, route, target_block_state)
require sim.user_out >= tx.min_out # user constraint
require sim.revert_risk <= policy.max_revert
plan = build_atomic_plan(tx, route, constraints)
receipt = submit_or_fail_closed(plan)
refund = internalize_backrun_value(receipt, policy)
attest(receipt, refund, strategy_id, block_number)
```

## オンチェーンインテリジェンス and リスク識別

プロトコルの最初の技術的優位性は「取引をより速く送る」ことではなく、ブロードキャスト前により完全なオンチェーン状態を形成することです。リスク識別は取引、流動性、Gas、ブロック構築、ルーティング環境を同時に理解しなければなりません。

| **データドメイン**  | **典型的なシグナル**                              | **保護用途**                         |
| ------------ | ----------------------------------------- | -------------------------------- |
| 取引とオーダーフロー   | 対象契約、サイズ、パス、最小受取額、期限、プライバシー設定             | 意図露出とサンドイッチ可能空間を判断               |
| DEXと流動性      | 準備金、曲線、深度、価格影響、クロスプールスプレッド                | 価格動きと代替パスを予測                     |
| Gas & ブロック構築 | Base Fee、Priority Fee、Builder可用性、Bundle状態 | 競争コストと送信方法を推定                    |
| 価格とオラクル      | オンチェーンオラクル、DEX中間価格、クロスマーケット参照             | 価格異常と決済偏差を識別                     |
| 歴史的競争        | サーチャー特徴、失敗モード、ルート衝突、ブロック包含率               | 高リスクウィンドウと戦略混雑を識別                |
| チェーン構造       | 公開メムプール、プライベートシーケンサー、ブロック時間、最終性、リオーグ特性    | 単一チェーンの仮定を他ネットワークに誤ってコピーすることを避ける |

### 6.1 サンドイッチリスクスコアリング

リスクスコアリングは「攻撃者が確実に攻撃する」と予測するものではなく、現在の状態下での取引の観察可能性、価格影響、順序可能性、攻撃経済性を推定します。スコアは実行パスと制約強度の選択に使用されます。

| **スコアリング次元** | **例示メトリクス**                        | **システムアクション**              |
| ------------ | ---------------------------------- | -------------------------- |
| 露出リスク        | 取引が公開オーダーフローに入るか；どれだけのヒント情報が共有されるか | プライバシーレベルを上げるか公開フォールバックを禁止 |
| 価格影響         | 期待価格影響、プール深度対取引サイズ比率               | 分割、リルート、または制約を引き締め         |
| スリッページ空間     | 最小受取額とシミュレーション出力の差                 | 攻撃者の搾取可能空間を判断              |
| 順序競争         | 優先手数料の変動性、Builder競争、最近のサンドイッチパターン  | プライベートパスを選択するか実行を遅延        |
| 状態安定性        | オラクル偏差、流動性移動、ブロック状態変化              | 再シミュレーションまたは一時停止をトリガー      |

## AI支援意思決定と実行前シミュレーション

**AIは識別、ランキング、パラメータ調整の効率を向上させます；決定論的ルール、ユーザー制約、シミュレーション結果が取引の実行可否を決定します。**

*図7-1 | AI支援意思決定と実行ループ*

| **能力**   | **入力**                      | **出力**                        | **実行境界**                  |
| -------- | --------------------------- | ----------------------------- | ------------------------- |
| 状態分類     | 取引、プール深度、Gas、競争、履歴          | 取引タイプ、リスクカテゴリ、候補戦略            | 直接署名や取引提出を行わない            |
| 機会スコアリング | 期待改善、コスト、成功率、状態安定性          | 候補優先度と信頼度                     | ランキングとリソース配分のみに使用         |
| パラメータ提案  | 履歴実行、ボラティリティ、Builderパフォーマンス | Gas、クォータ、ルート、タイムアウト提案         | 戦略上限とシミュレーションを通過しなければならない |
| 異常検出     | シミュレーション/ライブ偏差、価格ソース、決済差    | 一時停止、劣化、フォールバック、または人間レビューシグナル | 異常時はフェイルクローズを優先           |

## 保護実行 and User Value Protection

プライベート取引パスはフロントランニング露出を削減できますが、絶対的なプライバシーや絶対的な包含を意味するものではありません。New Sandwichはプライベートルーティング、Bundle、公開フォールバック、フェイルクローズを設定可能なパスとして設計し、ユーザー制約を最終実行境界とします。

*図8-1 | オンチェーン自動実行パイプライン*

| **実行方法**      | **適用シナリオ**                           | **主要制約**                                |
| ------------- | ------------------------------------ | --------------------------------------- |
| プライベート送信      | 高リスクスワップ、大きな価格影響、またはユーザー選択のプライバシーモード | Builderカバレッジ、タイムアウト、プライバシーヒント、包含ステータス   |
| Atomic Bundle | 一緒に成功または失敗しなければならない複数ステップ            | チェーンとBuilderサポート、順序、ブロックターゲット、ロールバックルール |
| 公開パス          | 公開流動性が明らかに優位でリスクが制御可能                | Gas、スリッページ、期限、不安全フォールバックの禁止             |
| マルチパスオークション   | 約定を競う複数の実行者またはパス                     | プロトコル収益だけでなく、ユーザー純出力と決定性でランク            |

### 8.1 ユーザー優先の保護バックラン実行

ユーザー取引が完了しユーザー制約が満たされた後、New Sandwichは結果として生じる状態変化の周囲で認可されたバックラン戦略の競争を許可することがあり、戦略にサンドイッチ攻撃を可能にする十分な完全な取引意図を開示せず、保護されたユーザー取引の前に戦略取引を配置する候補を受け入れません。このメカニズムはユーザー約定結果を害さずに配分可能な価値を回収し、プロトコルルールの下でユーザーへの価値再分配を優先します。MEV-Shareなどの公開メカニズムも同様に選択的ヒント、シミュレーション、ユーザーへの価値還元に基づいています。

| **ルール**    | **プロトコル要件**                                   |
| ---------- | --------------------------------------------- |
| 順序制約       | 戦略は保護されたユーザー取引の後にのみ配置されるか、ユーザーに無害な独立機会を実行     |
| ユーザー優先     | ユーザー最小受取額、最大Gas、期限、プライバシー設定は戦略によって上書きできない     |
| 情報最小化      | 戦略計算に必要な最小ヒントのみを共有；完全な取引意図の漏洩を避ける             |
| シミュレーション閾値 | 候補は状態シミュレーション、収益性、リバート、ユーザー結果チェックを通過しなければならない |
| 価値配分       | 新たに創出された価値はプロトコルルールによりユーザー、ウォレット、戦略、プロトコルに配分  |
| 検証可能な記録    | 候補、包含、コスト、純価値、価値還元、オンチェーン証跡を記録                |

## オープンストラテジーネットワーク

New Sandwichは外部戦略のフルライフサイクル管理を適用します：入場 — 認可 — シミュレーション — 隔離 — 実行 — 帰属 — 決済。戦略は認可された資産、ネットワーク、取引タイプ、リスクパラメータ内でのみ実行可能；実行前に状態シミュレーションと制約チェックを通過しなければならない；実行はユーザー取引優先に従う；結果は統一された帰属と検証可能な決済システムに入る。プロトコルはいかなる戦略も保護オーダーフローを使用してフロントラン、サンドイッチ、またはその他ユーザー利益を害することを禁止します。

*図9-1 | 孤立したサーチャーから監査可能な戦略モジュールへ*

| **外部チームの先行コスト**             | **能力 Provided by Protocol**                  | **アクセス価値**          |
| --------------------------- | -------------------------------------------- | ------------------- |
| ノード、リスナー、インデクサーの繰り返し構築      | 統一状態ストリーム、イベントサブスクリプション、履歴スナップショット           | インフラとメンテナンスコストの低減   |
| シミュレーション、Gas、Builder接続の独立構築 | 共有シミュレーション、ルーティング、実行アダプタレイヤー                 | 戦略の市場投入時間を短縮        |
| 安定した決済と信頼できる記録の欠如           | 統一コスト帰属、決済、戦略評判                              | 長期的に検証可能なパフォーマンスを形成 |
| 限定されたチェーンとシナリオカバレッジ         | マルチチェーン適応、ウォレットオーダーフロー、エコシステムプロジェクトエントリーポイント | 戦略容量と適用シナリオを拡大      |
| 管理困難な権限と資本境界                | 独立アカウント、クォータ、サンドボックス、ホワイトリスト、サーキットブレーカー      | 相互戦略干渉を削減           |

### 9.1 ストラテジーアダプター Interface

```typescript
interface StrategyAdapter {

 evaluate(ctx: StateContext): Candidate[];

 simulate(candidate: Candidate): SimulationResult;

 build(candidate: Candidate, limits: Policy): BundlePlan;

 attest(receipt: ExecutionReceipt): Attribution;

}

// no direct custody; no unrestricted mempool action; no front-run permission
```

| **制御次元**  | **プロトコル要件**                               |
| --------- | ----------------------------------------- |
| データ権限     | 認可された状態、ヒント、履歴記録のみにアクセス                   |
| 資本権限      | 独立アカウント、クォータ、または非カストディ実行構造を使用             |
| 戦略タイプ     | アービトラージ、清算、保護、ユーザー安全なバックラン実行などの説明可能な戦略を優先 |
| パフォーマンス帰属 | 成功率、失敗率、コスト、純貢献、異常を独立して記録                 |
| 評判とクォータ   | 安定性、データ一貫性、長期貢献に基づき動的に設定                  |
| 退出メカニズム   | 異常戦略は一時停止、縮小、取り消し可能で、履歴は保持                |

## データエンジンと自動検証

*図10-1 | オンチェーンイベントから公開検証へのデータパス*

プロトコルデータエンジンはネイティブオンチェーンイベント、シミュレーション記録、ルーティング決定、決済結果、エコシステム同期データを統一イベントモデルに組織化します。自動配信はエンゲージメントや偽のユーザーコメントを捏造せず、すでに検証されたプロトコル事実をウェブサイト掲示、Xデータカード、Telegram通知、webhook、定期レポートに変換します。

| **データ製品** | **コアコンテンツ**                   | **検証基盤**               |
| --------- | ----------------------------- | ---------------------- |
| 実行証跡      | ルート、ブロック、Gas、実際の出力、価格影響、ステータス | 取引ハッシュ、ブロック、契約イベント     |
| 保護レポート    | リスクスコア、実行パス、ベンチマーク比較、ユーザー結果   | シミュレーションスナップショットと実際の約定 |
| 価値帰属      | 総価値、コスト、価値還元、戦略貢献、プロトコル配分     | 決済アドレスと帰属台帳            |
| 戦略スコア     | 成功率、異常率、純貢献、レイテンシ、安定性         | 長期実行データベース             |
| 公開データカード  | プロトコル実行、保護、エコシステムデータの公開要約     | オリジナルリンク付き決済済みイベント     |

### 10.1 自動公開の真正性制約

* 確認と決済が完了したイベントのみが公開キューに入れられる。
* すべてのデータ要約は取引ハッシュ、ブロック番号、時間、メトリック定義を保持。
* モデル生成テキストは構造化フィールドから生成されなければならず、発生しなかった事実の捏造は禁止。
* 異常、失敗、フォールバックデータは内部およびパートナーレポートに入り、成功事例が完全な運用像を置き換えることはない。
* ソーシャルメディア公開はデータ配信レイヤーであり、取引決定のクリティカルパスに入らない。

## セキュリティ、可用性と技術的境界

| **セキュリティドメイン** | **制御メカニズム**                        | **目的**                        |
| -------------- | ---------------------------------- | ----------------------------- |
| スマートコントラクト     | 権限レイヤリング、マルチシグ、一時停止、アップグレードプロセス、監査 | 主要ルールと資産操作の範囲を制限              |
| ユーザー取引         | 最小受取額、期限、最大Gas、プライバシー、フェイルクローズ     | プロトコル収益のためにユーザー制約を犠牲にしない      |
| 外部戦略           | サンドボックス、アダプタ権限、シミュレーション閾値、クォータ、評判  | 第三者戦略リスクを制御                   |
| オフチェーンサービス     | キー隔離、冗長ノード、監視アラート、フェイルオーバー         | リアルタイムシステム可用性を維持              |
| データ一貫性         | 署名、スナップショット、オンチェーン証跡、クロスチェック       | プロトコル、オンチェーン、エコシステム記録間の一貫性を確保 |
| 異常応答           | サーキットブレーカー、スケール制限、パス切替、人間レビュー      | 極端状態の影響を削減                    |

### 11.1 技術的境界

* プライベートルーティングは取引意図の露出を削減しますが、すべてのチェーン、Builder、シーケンサー、ネットワーク状態下で絶対的なプライバシーや包含を保証することはできません。
* Bundle原子性と順序制御は特定のチェーンとブロック構築インフラに依存し、サポートされていない場合は同等のチェーンレベル実行アダプタを使用しなければなりません。
* AIスコアリングは誤りうるため、直接署名や資金を制御しません。決定論的ルール、シミュレーション、ユーザー制約がより高い優先度を持ちます。
* サンドイッチ攻撃はすべての公開市場でプロトコルによって永久に排除されることはできません；製品目標は搾取可能空間を縮小し、実行を改善し、配分可能な価値を回収することです。
* 技術的優位性は実行成功率、シミュレーション偏差、ユーザー純出力、価値還元、検証可能なカバレッジによって継続的に検証されなければなりません。

{% hint style="info" %}
**New Sandwichの技術ナラティブは実際のエンジニアリング制約から始まります：「ゼロMEV」「決してサンドイッチされない」「すべての取引が必ず価値還元を受け取る」を約束しません。検証可能な実行結果で保護能力を検証します。**
{% endhint %}

## エコシステム開発段階とSWC計画

New Sandwichのエコシステム構築は段階的に進みます。初期段階では、プロトコルは取引保護、ストラテジーネットワーク、エコシステム協力を優先し、シェアサブスクリプションを通じてエコシステムプロジェクトの参加クォータを確認します。ノードと計算力ネットワークは、エコシステムが安定したユーザースケール、実際の使用、協力基盤を有した後にのみローンチされます。

### 11.1 開発段階

| **開発段階**    | **コアフォーカス**                                         | **対応メカニズム**                                                                |
| ----------- | --------------------------------------------------- | -------------------------------------------------------------------------- |
| 初期エコシステム段階  | プロトコル製品、ストラテジーネットワーク、エコシステム協力の完成を優先                 | エコシステムプロジェクトは実際にコミットしたUSDTに応じてエコシステムシェアを購読；ノード販売、計算力設定、または資産出力はまだ開放されていない。 |
| エコシステム拡張段階  | 実際のマルチプロジェクト、マルチチェーン、マルチ戦略使用を形成                     | シェア管理、データ検証、協力決済を改善し、ノードと計算力ネットワークの運用基盤を築く。                                |
| ノードネットワーク段階 | エコシステム繁栄と成熟インフラ後にノードと計算力ネットワークをローンチ                 | 当時公開された正式ルールに従ってノードアイデンティティ、計算力設定、シェアマッピング、照会システムを開放。                      |
| SWC計画段階     | ノードネットワークとエコシステムアプリケーションが安定規模に達した後にプロトコルエコシステム資産を開発 | 将来的にNew SandwichエコシステムトークンSWCを開発する計画；発行アレンジ、機能、総供給、配分、ガバナンスルールは正式公開に従う。    |

シェアサブスクリプションは初期段階におけるエコシステムプロジェクトの参加クォータと協力権を記録します。ノード、計算力、またはSWCと同等ではなく、将来のノードマッピング、資産発行、または利回り結果への事前コミットメントを構成しません。

## ノードアイデンティティと計算力ネットワーク

ノードアイデンティティと計算力ネットワークはNew Sandwichエコシステムの成熟段階計画能力に属し、初期プロトコルフェーズでは直接開放されません。初期エコシステムプロジェクトはシェアサブスクリプションを通じて参加；エコシステムが安定したユーザースケール、実際の使用、協力基盤を形成した後、プロトコルは正式に公開されたルールに従ってノードアイデンティティ、計算力設定、関連計算システムをローンチします。

### 12.1 開発パス

ノードと計算力ネットワークは「シェアサブスクリプション先行、ノードネットワーク後続」のパスに沿って進みます。初期サブスクリプションシェアはエコシステム協力参加クォータを記録；ノードネットワークが正式にローンチされた後、当時公開されたマッピング、設定、決済ルールに従って後続権利が接続されます。

| **段階**         | **運用モード**    | **ルール 説明**                                                              |
| -------------- | ------------ | ----------------------------------------------------------------------- |
| 初期エコシステム       | シェアサブスクリプション | エコシステムプロジェクトはコミットしたUSDTに応じてサブスクリプションクォータを確認；ノード、計算力、または資産出力はまだ設定されていない。 |
| 成熟エコシステム       | ノードネットワーク準備  | プロトコルは実ユーザー、使用規模、協力基盤に基づきノード総数、計算力設定、シェアマッピング、システムアクセスルールを公開。           |
| ノードネットワークローンチ後 | ノード引受と計算力設定  | エコシステムプロジェクトは正式ルールの下でノードアイデンティティを引き受け、有効計算力を設定し、照会と決済システムに接続可能。         |

*図13-1 | ノードアイデンティティと計算力ネットワーク Planning Formula*

| **パラメータ**    | **ルール**                                                                                   |
| ------------ | ----------------------------------------------------------------------------------------- |
| 総ノードアイデンティティ | 計画総数3,000；ノードネットワーク正式開始後にプロトコルアイデンティティと有効計算力を担うために使用。                                     |
| ノードあたり計算力範囲  | 計画範囲100–5,000有効計算力；具体的な設定はノードネットワーク正式ローンチ時に有効。                                            |
| 計算力価値ベースライン  | 計画ベースライン1 USDTが1計算力に対応；初期シェアサブスクリプション額は直接活性化計算力と等しくない。                                    |
| ネットワーク初期日次出力 | 正式ノードネットワークローンチ後の初期日次計算ベースラインは72,000ユニット；対応資産と決済ユニットは当時の正式ルールに従う。                         |
| 個人出力フォーミュラ   | 個人有効計算力 ÷ ネットワーク有効計算力 × 日次ネットワーク出力ベースライン。                                                 |
| 半減サイクル       | 4年ごとの計画調整；ノードネットワークと共に正式公開される実行ルールに従う。                                                    |
| 購入エントリー      | 初期段階はエコシステムシェアサブスクリプションのみ開放；ノードと計算力はエコシステム成熟後にエコシステムプロジェクトシステムを通じて開放；プロトコルウェブサイトは直接販売しない。 |

シェアサブスクリプションはノード、計算力、またはSWCと同等ではありません。ノードネットワーク正式ローンチ後、計算に参加するすべての有効計算力はノードアイデンティティにバインドされなければならず；エコシステムプロジェクトは注文、ユーザー、ノード、計算力記録を同期；プロトコルは署名、スナップショット、照会システムを通じて検証します。

## プロトコル参加証明書

プロトコル参加証明書はオンチェーンエコシステム協力のために確立された検証可能なアクセスツールです。エコシステムプロジェクトと一般ユーザーの両方がウォレットを介して保持可能です。証明書自体は直接利回りを生成せず、主にエコシステムプロジェクトの適格性検証とプロトコルアクセスに使用されます。

| **属性**         | **説明**                                                 |
| -------------- | ------------------------------------------------------ |
| オンチェーン保持       | 証明書はユーザーまたはエコシステムプロジェクトが認可したウォレットに記録される。               |
| オープン購入         | エコシステムプロジェクトと一般ユーザーの両方がプロトコルウェブサイトのウォレットエントリーを介して購入可能。 |
| 適格性検証          | 証明書をサポートするエコシステムプロジェクトはスマートコントラクトで読み取り検証可能。            |
| 直接出力なし         | 証明書は自動的にノード出力、固定配分、またはプロトコル収益を付与しない。                   |
| エコシステムトークンから独立 | 証明書は独立エコシステムプロジェクトが発行するいかなるトークンとも同等ではない。               |

| **保持者**      | **主要用途**                                  | **権限境界**                                |
| ------------ | ----------------------------------------- | --------------------------------------- |
| 一般ユーザー       | 証明書をサポートする独立エコシステムプロジェクトに入り、参加適格性を検証      | 証明書を保持するだけでは制限された戦略または決済インターフェースを呼び出せない |
| エコシステムプロジェクト | エコシステムアクセス、プロジェクト契約検証、認可されたプロトコル能力呼び出しを完了 | 協力認可、インターフェース設定、権限レビューを完了しなければならない      |

## なぜオープンエコシステム協力か

保護実行とストラテジーネットワークは早期プロトコル収益を確立できますが、単一チェーン、単一戦略、単一チーム、単一オーダーフローには容量制限があります。オープンエコシステム協力の目的は、技術的優位性をより多くの実際の使用、ユーザー関係、ブランドエントリーポイント、データ資産、グローバルネットワーク効果に変換することです。

| **成長制約**  | **単一技術チームの限界**                 | **オープンエコシステムからの拡張**                  |
| --------- | ------------------------------ | ------------------------------------ |
| 戦略容量      | チェーン、資本、市場、競争強度によって制限される機会     | マルチプロジェクト、マルチチェーン、マルチ戦略を通じて使用シナリオを拡大 |
| ユーザーとブランド | 実行チームは通常継続的なユーザー関係を欠く          | エコシステムプロジェクトが独立したユーザーシステムと市場リーチを形成   |
| データ規模     | 単一オーダーフローの限定的なデータカバレッジ         | 複数エコシステムが継続的に取引、実行、ユーザーデータを増加        |
| 製品境界      | 純粋な実行収益がより多くの商業ニーズをカバーしにくい     | インターフェース、証明書、ノード、決済、データ製品を輸出         |
| グローバル複製   | プロトコル当事者がすべての地域で同じモデルを運用するのは困難 | 独立エコシステムがローカライズされた製品とコミュニティを完成       |

エコシステム協力は技術プロトコルのスケーリングに奉仕します：まず検証可能な保護と実行能力を確立し、その後協力を通じてそれらの能力をより多くのウォレット、アプリケーション、ユーザーシステム、地域市場に埋め込みます。

## New Sandwich公式エコシステム協力 Modes

公式New Sandwichエコシステム協力とは、独立したエコシステムプロジェクトが自身のエンティティ、ブランド、製品、ユーザー、または経済モデルを変更することなく、標準化されたエントリーポイントを通じてプロトコルの戦略実行、ノード計算力、プロトコル参加証明書、データ照会、エコシステム決済能力にアクセスすることを意味します。エコシステム協力は技術プロトコルのスケーリングに奉仕し、プロトコルコアはサンドイッチ攻撃保護、ユーザー取引保護、検証可能な実行のままです。

**統一定義：New Sandwichは基盤プロトコル能力とアクセスルールを提供；エコシステムプロジェクトは独立してエンティティ、ブランド、製品、ユーザー、トークン、コミュニティ、市場運営を負担。両当事者はプロトコルインターフェース、ノード計算力、またはオンチェーン証明書を介して協力関係を確立。**

*図16-1 | New Sandwich公式エコシステム協力 Modes and デュアルトラックアクセス Structure*

### 15.1 公式協力原則

| **原則**       | **正式定義**                                                             |
| ------------ | -------------------------------------------------------------------- |
| 技術をコアとして     | エコシステム協力は検証可能なサンドイッチ攻撃保護、ユーザー取引保護、戦略実行、データ、決済能力に基づいて構築される。           |
| デュアルトラックアクセス | エコシステムプロジェクトのユーザーアーキテクチャに応じて、アカウント型ノード引受とオンチェーンプロトコル参加証明書の2つのモードを提供。 |
| エコシステム独立性    | エコシステムプロジェクトは独立したエンティティ、コントローラー、ブランド、トークン、ユーザーシステム、コミュニティ、市場戦略を所有。   |
| プロトコル統一      | ノード、計算力、証明書、出力、インターフェース権限、決済はプロトコルルールによって統一的に記録・検証される。               |
| 職務分離         | プロトコル当事者が基盤能力を提供；エコシステムプロジェクトは自身の販売、製品、ユーザーサービス、市場運営に責任を負う。          |

### 15.2 2つの公式モード比較

| **次元**           | **アカウント型エコシステム協業｜ノード引受 / シェアサブスクリプション**                               | **オンチェーンエコシステム協業｜プロトコル参加証明書**                    |
| ---------------- | --------------------------------------------------------------------- | ------------------------------------------------ |
| 主な対象者            | メール、電話、またはアカウントシステムと市場運営能力を持つエコシステムプロジェクト                             | ウォレット、スマートコントラクト、オンチェーンコミュニティ経由で運営するエコシステムプロジェクト |
| アクセス基盤           | 初期エコシステム：コミットしたUSDTに応じてシェアを購読；ノードネットワークローンチ後、正式ルールの下でノード引受と計算力設定に入る可能 | プロジェクトまたは一般ユーザーがプロトコル参加証明書を購入・保持                 |
| ユーザーアイデンティティ     | エコシステムアカウント、メール、または電話番号                                               | ウォレットアドレス                                        |
| 購入エントリー          | エコシステムプロジェクトがシェアサブスクリプションを完了；ノードネットワーク正式ローンチ前はノードと計算力販売は開放されない        | プロトコルウェブサイトがウォレット購入、保持、証明書照会を開放                  |
| ウェブサイト機能         | 初期段階はエコシステム協力とサブスクリプション情報を記録；ノードネットワークローンチ後、正式ルールの下で対応照会能力を提供         | 証明書を購入、保持、照会し、証明書サポートエコシステムプロジェクトに接続             |
| 出力 & Eligibility | 初期段階はサブスクリプション額により参加クォータを記録；ノードネットワークローンチ後、正式ルールの下でノード、計算力、関連権利を確認    | 証明書自体は直接出力を生成せず；エコシステムプロジェクト適格性検証と認可アクセスに使用      |
| 経済モデル            | エコシステムプロジェクトによって独立して設計・運営                                             | エコシステムプロジェクトによって独立して設計・運営 via smart contracts    |

### 15.3 アカウント型エコシステム協業：ノード引受 / シェアサブスクリプション

アカウント型エコシステム協力は、独立したアカウントシステム、市場組織、ユーザーサービス能力を持つエコシステムプロジェクトに適用されます。初期エコシステム段階では、プロジェクトは実際にコミットしたUSDTに応じてエコシステムシェアを購読し、自身のシステム内でサブスクリプション管理、ユーザーサービス、市場運営を完了します。エコシステムが繁栄しノードと計算力ネットワークが正式にローンチされた後、プロジェクトは当時公開されたルールの下でノード引受と計算力設定段階に入ることができます。

#### 運用フロー

{% stepper %}
{% step %}

#### 協力条件を確認

エコシステムプロジェクトとNew Sandwichがエコシステムシェアサブスクリプション規模、コミット額、協力範囲、システムインターフェース、決済ルールを確認。
{% endstep %}

{% step %}

#### エコシステムシェアを購読

ノードネットワークがまだローンチされていない間、エコシステムプロジェクトは実際にコミットしたUSDTに応じて直接エコシステムシェアを購読；プロトコルが対応する参加クォータと協力権を記録。
{% endstep %}

{% step %}

#### アカウントおよび注文情報を同期

エコシステムプロジェクトが認可インターフェースを介してアカウント、注文、サブスクリプション額、シェアレコードを同期し、自身のシステム内でユーザーサービスと市場運営を完了。
{% endstep %}

{% step %}

#### 初期サブスクリプション記録を保持

初期サブスクリプションシェアは直接ノード、計算力、またはプロトコルエコシステムトークンを生成せず；関連記録はエコシステム協力、後続ルール接続、権利確認の基盤として機能。
{% endstep %}

{% step %}

#### ノードネットワークローンチ後のルールを適用

エコシステムが繁栄しノードと計算力ネットワークが正式にローンチされた後、プロトコルは当時公開されたルールの下でシェアマッピング、ノード引受、計算力設定、照会方法を決定。
{% endstep %}

{% step %}

#### 独立した運営システムを構築

エコシステムプロジェクトがプロトコル能力と自身の製品を中心に独立したユーザーシステム、経済モデル、市場運営メカニズムを構築。
{% endstep %}
{% endstepper %}

#### 職務と境界

| **当事者**      | **コア職務**                                                           | **明確な境界**                                           |
| ------------ | ------------------------------------------------------------------ | --------------------------------------------------- |
| New Sandwich | エコシステムシェア登録、協力ルール、ノードと計算力ネットワーク計画、データ検証、プロトコル決済、技術インターフェース         | 初期段階ではノードや計算力を直接販売せず；エコシステムプロジェクトのユーザーチームを管理しない     |
| エコシステムプロジェクト | シェアサブスクリプション、アカウントシステム、注文とユーザーサービス、製品設計、市場運営、自身の経済モデル              | ユーザーに対する製品と運用責任を独立して負担                              |
| エコシステム参加ユーザー | エコシステムプロジェクトシステムを介してシェアサブスクリプションに参加；ノードネットワークローンチ後、正式ルールの下で関連権利を接続 | 初期サブスクリプションはノード、計算力、プロトコルエコシステムトークン、または固定利回りと同等ではない |

### 15.4 オンチェーンエコシステム協業：プロトコル参加証明書

オンチェーンエコシステム協力は、ウォレット、スマートコントラクト、オンチェーンコミュニティを介して運営する独立プロジェクトに適用されます。プロトコル参加証明書はウォレットによって保持され、エコシステムアクセス、プロジェクト参加、適格性検証を記録するために使用されます。証明書自体は直接利回りを生成せず、自動的にノード出力やプロトコル配分を付与しません。

#### 運用フロー

{% stepper %}
{% step %}

#### 証明書エントリーに接続

エコシステムプロジェクトまたは一般ユーザーがウォレットでNew Sandwichプロトコル参加証明書エントリーに接続。
{% endstep %}

{% step %}

#### 証明書を購入または保持

ユーザーがプロトコル参加証明書を購入または保持；証明書は認可されたウォレットに記録される。
{% endstep %}

{% step %}

#### プロジェクト契約で検証

ユーザーが証明書をサポートする独立エコシステムプロジェクトに入り；プロジェクト契約が証明書を読み取り検証。
{% endstep %}

{% step %}

#### プロジェクト独自の権利を開放

エコシステムプロジェクトが自身のルールの下で製品機能、コミュニティ適格性、オンチェーン計算力、またはその他参加権利を開放。
{% endstep %}

{% step %}

#### 制限されたインターフェースを呼び出す

協力認可を完了したエコシステムプロジェクトが制限されたインターフェースを介して戦略、データ、または決済サービスを呼び出す。
{% endstep %}
{% endstepper %}

#### 証明書の位置付けと権限境界

| **参加者**      | **証明書の主要用途**                               | **権限境界**                                       |
| ------------ | ------------------------------------------ | ---------------------------------------------- |
| 一般ユーザー       | 証明書を保持し、サポートする独立エコシステムプロジェクトに入り適格性検証を完了    | 証明書を保持するだけでは制限された戦略、資金、または決済インターフェースを呼び出せない    |
| エコシステムプロジェクト | プロジェクトアクセス、契約検証、認可されたプロトコル能力呼び出しを完了        | 協力認可、インターフェース設定、権限レビュー、技術テストを完了しなければならない       |
| New Sandwich | 証明書購入、オンチェーン記録、検証インターフェース、エコシステムナビゲーションを提供 | 証明書保持者に対して紹介関係、チーム階層、または中央集権的ユーザーアーキテクチャを確立しない |

#### Independence 原則

**プロトコルとエコシステム境界**

すべてのエコシステムプロジェクトは独立したエンティティ、コントローラー、ブランド、トークン、ユーザー組織、経済モデルを所有します。New Sandwichは基盤技術、出力ルール、証明書検証、データ、決済能力を提供し、いかなる単一エコシステムプロジェクトの報酬、チームシステム、または市場戦略を基盤プロトコルルールとして定義しません。

## ビジネスモデルと収益配分

プロトコル商業収益はまず保護実行、ストラテジーネットワーク、技術サービスから生じ、プロトコル参加証明書、オープンインターフェース、データ、エコシステム決済によって補完されます。初期段階のシェアサブスクリプションは協力拡張とインフラ構築をサポート；ノードと計算力サービスはエコシステムが成熟し関連ネットワークが正式にローンチされた後に商業システムに組み込まれます。異なる収益ストリームは異なる会計方法を使用します。

| **収益タイプ**                           | **主要モード**                                                                   | **主要顧客**                  |
| ----------------------------------- | --------------------------------------------------------------------------- | ------------------------- |
| 保護実行 Services                       | Protected RPC、SDK、ルート最適化、ユーザー価値保護、技術サービス料                                   | ウォレット、DEX、アプリ、機関          |
| ストラテジーネットワークサービス                    | 戦略呼び出し、実行、清算、ユーザー安全なバックラン実行、技術シェア                                           | ストラテジーチーム、エコシステムプロジェクト、機関 |
| シェアサブスクリプション & Future Node Services | 初期エコシステムシェアサブスクリプション；エコシステム成熟後、正式ルールの下でノードアイデンティティ、計算力設定、照会、システムインターフェースを開放 | アカウント型エコシステムプロジェクト        |
| プロトコル参加証明書s                         | 証明書購入、検証、エコシステムアクセス、契約呼び出し                                                  | オンチェーンエコシステムプロジェクト、一般ユーザー |
| オープンインターフェースとデータ                    | API、SDK、Data API、Webhook、ホワイトラベル、カスタムデータ                                    | ウォレット、プラットフォーム、開発者、機関     |
| エコシステム決済サービス                        | プロジェクトアクセス、協力決済、予算、定期勘定                                                     | エコシステムプロジェクトと地域パートナー      |

### 16.1 ストラテジーネットワークの配分可能清算収益

ストラテジーネットワークがオンチェーン決済を完了し、Gas、実行コスト、必要な協力手数料を差し引いた後、期間の純配分可能清算収益が形成されます。この部分は20%財団、40%プロトコルエコシステム価値管理、40% New Sandwichエコシステムプールとして実行されます。SWCが正式にローンチされる前、プロトコルエコシステム価値管理部分はエコシステム開発と将来の資産システムのための専用準備金として機能し；エコシステムが繁栄しSWCが正式にローンチされた後、その具体的な用途は当時公開された資産ルールに従います。シェアサブスクリプション、プロトコル参加証明書、インターフェース、企業サービス収益は対応する製品と協力協定の下で別途会計処理されます。

*図17-1 | ストラテジーネットワーク純配分可能清算収益の20 / 40 / 40構造*

## ガバナンスとロードマップ

本章はコアプロトコル技術、戦略権限、エコシステムシェア、将来のノードと計算力ネットワーク、プロトコル参加証明書、エコシステムプール予算、SWC計画、アップグレードプロセスのガバナンス構造に焦点を当てます。

### 17.1 ガバナンス構造

初期プロトコル開発段階では、主要パラメータは財団、コア技術チーム、マルチシグガバナンス委員会によって管理されます。ユーザー保護ポリシー、ルーティング適応、エコシステムシェア、プロトコル参加証明書、エコシステムプール予算、戦略権限、プロトコルアップグレードは階層型ガバナンスを採用；ノード総数、計算力公式、SWC関連ルールは対応する開発段階で正式スキームを形成します。ストラテジーネットワーク、ノード、エコシステムプロジェクトが成長するにつれ、公開意思決定に適した事項が徐々にコミュニティとエコシステムガバナンスに入ります。

### 17.2 製品とエコシステムロードマップ

*図18-1 | Product Roadmap Prioritizing Technical 能力, Then エコシステム規模*

| **段階**       | **Core 目的**                               | **主要成果物**                                               |
| ------------ | ----------------------------------------- | ------------------------------------------------------- |
| プロトコルコア      | 保護取引、リスクスコアリング、シミュレーション、ルーティング、実行証跡を完成    | Protected RPC / SDK、シミュレーションサービス、プライベートルーティング、Dashboard |
| ストラテジーネットワーク | ユーザー取引結果を害さない認可バックラン実行、アービトラージ、清算、保護戦略を開放 | ストラテジーアダプター、サンドボックス、決済、評判、権限システム                        |
| マルチチェーン拡張    | チェーンレベルオーダーフローとブロック構築構造に応じて実行アダプタを展開      | マルチチェーン状態、Builder/Sequencer適応、クロスチェーンデータモデル             |
| エコシステム規模     | ノード引受、プロトコル参加証明書、インターフェース、地域エコシステムを開放     | デュアルトラック協力、開発者ポータル、エコシステムディレクトリ、定期レポート                  |

## コアメトリクス、用語集、技術参考文献

### 17.1 ノーススターメトリック

**New Sandwichのノーススターメトリックは：プロトコルが保護オーダーフローに対して創出する検証可能な純実行価値です。この価値は約定改善、回避損失、ユーザーへの価値還元、戦略純貢献、検証可能なカバレッジから構成されます。**

| **メトリックカテゴリ**  | **コアメトリクス**                                                     |
| -------------- | --------------------------------------------------------------- |
| 保護効果           | 高リスク取引保護カバレッジ、ベンチマーク約定改善、異常スリッページ削減、ユーザーへの価値還元                  |
| オンチェーンインテリジェンス | カバーされたチェーンとデータソース、状態レイテンシ、リスク識別精度                               |
| シミュレーションと実行    | シミュレーション量、偏差、実行成功率、Gas効率、フォールバックとサーキットブレーカー率                    |
| ストラテジーネットワーク   | アクティブ戦略、外部戦略アクセス、安定性、純貢献、評判分布                                   |
| 検証可能性          | 完全実行証跡比率、オリジナルリンクカバレッジ、コスト帰属完全性                                 |
| ビジネスとエコシステム    | 保護取引量、戦略純清算収益、インターフェース呼び出し、エコシステムプロジェクト維持と地域カバレッジ               |
| シェア、ノードと証明書    | 初期シェアサブスクリプション、証明書保持とエコシステム検証；ノードネットワークローンチ後：有効ノード、ネットワーク計算力、分布 |

### 17.2 主要用語

| **用語**          | **定義**                                                |
| --------------- | ----------------------------------------------------- |
| MEV             | Maximal Extractable Value — ブロック生産と取引順序付け中に抽出可能な追加価値。 |
| サンドイッチ攻撃        | 攻撃者がターゲット取引の前後に取引を挿入し、ターゲット取引によって引き起こされる価格変化を捕捉する。    |
| サーチャー           | オンチェーン状態を監視し、アービトラージ、清算、保護、またはその他自動戦略を提出する専門参加者。      |
| Builder / Relay | Bundleを受け取り、ブロックを構築し転送するインフラ役割。                       |
| バックラン           | ターゲット取引の後に実行され、その取引によって引き起こされる状態変化を捕捉する戦略。            |
| 保護オーダーフロー       | 公開メムプールに直接ブロードキャストされず、プライバシーと実行制約の下で処理される取引フロー。       |
| ストラテジーアダプター     | 外部戦略がプロトコルに接続する際に使用される標準入力、出力、権限、決済インターフェース。          |
| プロトコル参加証明書      | ウォレットによって保持されるオンチェーン証明書、エコシステムアクセスと適格性検証に使用。          |


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://newsandwich.gitbook.io/docs/new-sandwich-whitepaper/jp.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.