> 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/cn.md).

# New\_Sandwich\_Whitepaper\_CN

| **协议核心：New Sandwich 是一套面向三明治攻击防护、链上执行优化与用户侧用户价值返还的协议。协议通过实时链上感知、执行前仿真、受保护路由、合规后置策略竞争和可验证结算，将原本由信息差与排序优势捕获的价值，重新组织为面向用户、钱包、策略团队和生态项目的公开能力。** |
| ------------------------------------------------------------------------------------------------------------------------------------------- |

## 执行摘要

| **New Sandwich 是面向公开订单流的链上交易保护与策略执行基础协议，通过系统化技术能力应对三明治攻击和执行价值外流，并向独立生态项目开放标准化、可组合的协议接入与协作能力。** |
| ---------------------------------------------------------------------------------------------- |

New Sandwich 是面向钱包、交易应用、链上用户、策略团队和独立生态项目的三明治攻击防护与链上执行保护协议。产品围绕用户交易保护形成六个连续环节：风险识别、保护提交、执行前仿真、受约束执行、用户侧价值优化与返还、结果验证。

New Sandwich 通过降低交易意图暴露、严格执行用户约束、识别并阻断有害排序，将可分配价值按规则返还用户并支持协议运行。Flashbots MEV-Share 的公开机制表明，受保护订单流可以在选择性披露与仿真约束下允许后置竞争，并将部分价值返还原始交易方。

New Sandwich 的技术领先性建立在系统组合能力上：多源链上状态流、三明治风险评分、Fork状态仿真、跨路由净值比较、私有提交与Bundle执行、策略适配器、成本归因和公开数据证明。任何单点能力都不是New Sandwich的全部；New Sandwich的领先性来自这些能力在同一执行闭环中的协同。

生态合作是New Sandwich协议技术能力的规模化路径，而不是协议产品本身的替代。New Sandwich 以三明治攻击防护、用户交易保护与执行优化为核心，在此基础上通过节点承销和链上协议凭证两种官方合作方式，将策略、产出、数据与结算能力开放给独立生态项目。

图 1-1｜New Sandwich 三明治攻击防护闭环

| **核心能力**   | **产品功能**                      | **用户结果**          |
| ---------- | ----------------------------- | ----------------- |
| **风险识别**   | 识别公开暴露、滑点空间、池深度、Gas竞争与排序风险    | 在广播前判断交易是否容易被夹击   |
| **保护执行**   | 私有路由、受控订单流、Bundle与失败关闭策略      | 减少意图提前暴露和不安全回退    |
| **用户价值返还** | 仅允许经授权且不会损害用户结果的后置执行，禁止任何前置夹击 | 将可分配MEV回流用户、钱包和协议 |
| **执行证明**   | 记录仿真、路由、成交质量、成本、返还和交易哈希       | 让保护效果可查询、可复核、可积累  |
| **开放策略**   | 外部策略通过标准适配器、权限和结算规则接入         | 扩大策略覆盖，同时保持安全边界   |

## 链上交易环境与三明治攻击

| **MEV 是区块生产者或其他参与者通过交易排序、包含或排除获得的额外价值。套利与清算可以提升DeFi效率，但三明治交易会直接造成用户更差的成交价格与滑点。** |
| -------------------------------------------------------------------------------- |

### 2.1 链上交易为何天然存在排序竞争

链上交易不是在用户点击“确认”后立即完成。交易需要经过RPC、公共或私有订单流、Builder、区块提议和最终确认。公开订单流中的交易意图可能在确认前被观察；大额交换、浅流动性、宽松滑点和活跃竞争共同构成三明治攻击的条件。

| **结构位置**  | **攻击者观察的信号**              | **对用户的影响**        |
| --------- | ------------------------- | ----------------- |
| **交易意图**  | 交易对、数量、最低接收量、Gas与目标合约     | 暴露价格影响与可接受滑点空间    |
| **AMM状态** | 池储备、价格曲线、跨池价差与流动性深度       | 判断前置交易可推动的价格范围    |
| **区块构建**  | 优先费、Bundle、Builder覆盖和区块竞争 | 决定前置、用户交易和后置交易的排序 |
| **执行结果**  | 用户成交、攻击者平仓、Gas与净利润        | 用户承受更差价格，攻击者捕获价差  |

图 2-1｜三明治攻击的高层执行链

### 2.2 机器人系统正在从脚本升级为执行基础设施

早期机器人依赖固定阈值和单一交易池；新一代搜索系统会同时读取池状态、Gas、Oracle、Builder和跨市场状态，并用仿真比较候选路径。公开内存池并非所有链和L2的统一结构，私有排序器与私有内存池会改变攻击可行性，因此协议必须采用链级适配，而不能把Ethereum L1的假设复制到所有网络。

图 2-2｜搜索者与夹子机器人系统的技术演进

### 2.3 现有单点防护的不足

| **常见方案**    | **能够解决的问题** | **仍然存在的缺口**                 |
| ----------- | ----------- | --------------------------- |
| **收紧滑点**    | 压缩攻击利润空间    | 过度收紧可能导致失败；不处理隐私与路由         |
| **单一私有RPC** | 降低公开暴露      | 依赖Builder覆盖与服务可用性；不自动比较执行质量 |
| **交易模拟**    | 识别回滚与价格影响   | 若状态、区块和Bundle上下文不一致，结果会偏离   |
| **单一机器人**   | 覆盖一个策略或一个链  | 维护成本高，难以持续适配不同市场结构          |
| **数据看板**    | 展示执行结果      | 若缺少成本归因和原始证明，只能形成表面透明       |

## New Sandwich 产品功能

| **New Sandwich 是一个“保护用户交易 - 降低意图暴露 - 阻断有害排序 - 验证执行结果”的完整防护协议。** |
| --------------------------------------------------------------- |

### 3.1 三层防护机制

| **层级**         | **产品动作**                                | **核心结果**                          |
| -------------- | --------------------------------------- | --------------------------------- |
| **Shield｜保护**  | 交易经Protected RPC / SDK进入；识别风险并选择私有或受控路径 | 减少交易意图公开暴露                        |
| **Guard｜主动防护** | 在用户约束不被破坏的前提下，仅允许合规后置策略参与竞争             | 在不损害用户的前提下，将可分配后置价值按规则返还用户并支持协议运行 |
| **Proof｜证明**   | 生成执行回执、价格影响、Gas、返还与策略归因记录               | 用可验证数据证明保护效果                      |

图 3-1｜受保护订单流与用户侧价值返还

### 3.2 产品形态

| **产品入口**              | **服务对象**      | **主要功能**               |
| --------------------- | ------------- | ---------------------- |
| **Protected RPC**     | 普通用户与钱包       | 受保护提交、路由选择、交易状态与返还查询   |
| **Wallet / DApp SDK** | 钱包、DEX、聚合器、应用 | 风险预检、最小接收量保护、路由和前端状态   |
| **Execution API**     | 机构与生态项目       | 批量执行、约束策略、私有通道和结算回执    |
| **Strategy Adapter**  | 搜索者与策略团队      | 标准状态输入、候选输出、仿真、权限和绩效归因 |
| **Data Dashboard**    | 用户、合作方与市场     | 交易保护、执行质量、净值、返还和协议运行数据 |

### 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｜技术领先性的六项系统能力

### 4.1 领先性来自闭环，而非单点

| **比较维度**  | **常见单点方案**       | **New Sandwich 协议设计**        |
| --------- | ---------------- | ---------------------------- |
| **风险识别**  | 单一滑点或固定阈值        | 多源状态 + 交易特征 + 竞争环境联合评分       |
| **执行前验证** | 简单eth\_call或静态估算 | 目标区块状态、签名交易、Bundle上下文与最坏情形仿真 |
| **路由**    | 固定RPC或单一Builder  | 公开、私有、Bundle和回退路径按净执行质量比较    |
| **价值处理**  | 阻止攻击但不处理剩余MEV    | 允许受控、用户无害的后置执行，并优先将可分配价值返还用户 |
| **策略扩展**  | 内部单机器人           | 外部策略适配器 + 沙盒 + 权限 + 结算 + 信誉  |
| **证明**    | 成功/失败状态          | 成交质量、Gas、返还、归因和原始链上记录        |

## 协议总体技术架构

图 5-1｜New Sandwich 协议技术栈

| **技术层**    | **核心职责**                             | **关键输出**   |
| ---------- | ------------------------------------ | ---------- |
| **链上感知层**  | 采集订单流、区块、DEX、Gas、Oracle、Builder与多链状态 | 标准化状态流与快照  |
| **风险与仿真层** | 风险分类、机会评分、参数辅助、Fork仿真和最坏情形验证         | 可执行候选与风险标签 |
| **执行与路由层** | 私有提交、Bundle、公开路径、Gas/Nonce、取消和回退     | 链上执行结果     |
| **策略网络层**  | 内部与外部策略注册、沙盒、权限、额度、信誉和绩效归因           | 受控策略模块     |
| **结算与价值层** | 成本、净收益、返还、合作分配和生态预算                  | 结算记录与归因数据  |
| **数据与接口层** | Dashboard、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)
```

## 链上感知与风险识别

协议的第一项技术优势不是“更快发送交易”，而是在广播前形成更完整的链上状态。风险识别必须同时理解交易、流动性、Gas、区块构建和路由环境。

| **数据域**       | **典型信号**                                  | **防护用途**          |
| ------------- | ----------------------------------------- | ----------------- |
| **交易与订单流**    | 目标合约、数量、路径、最低接收量、期限、隐私偏好                  | 判断意图暴露和可被夹击空间     |
| **DEX与流动性**   | 储备、曲线、深度、价格影响、跨池价差                        | 预测价格移动和替代路径       |
| **Gas与区块构建**  | Base Fee、Priority Fee、Builder可用性、Bundle状态 | 估算竞争成本和提交方式       |
| **价格与Oracle** | 链上Oracle、DEX中间价、跨市场参考                     | 识别价格异常和结算偏差       |
| **历史竞争**      | 搜索者特征、失败模式、路线冲突、区块包含率                     | 识别高风险窗口和策略拥堵      |
| **链级结构**      | 公共内存池、私有排序器、区块时间、最终性与重组特征                 | 避免把单一链假设错误复制到其他网络 |

### 6.1 三明治风险评分

风险评分不是“预测攻击者一定会攻击”，而是估计一笔交易在当前状态下的可观察性、价格影响、可排序性和攻击经济性。评分用于选择执行路径和约束强度。

| **评分维度**  | **示例指标**               | **系统动作**      |
| --------- | ---------------------- | ------------- |
| **暴露风险**  | 交易是否进入公开订单流、共享了多少提示信息  | 提高隐私级别或禁止公开回退 |
| **价格影响**  | 预期价格影响、池深度与交易规模比       | 拆分、换路或收紧约束    |
| **滑点空间**  | 最低接收量与仿真输出差值           | 判断攻击可利用空间     |
| **排序竞争**  | 优先费波动、Builder竞争与近期夹击模式 | 选择私有路径或延迟执行   |
| **状态稳定性** | Oracle偏差、流动性迁移、区块状态变化  | 触发重新仿真或暂停     |

## AI辅助决策与执行前仿真

| **AI提高识别、排序和调参效率；确定性规则、用户约束和仿真结果决定交易能否执行。** |
| ------------------------------------------- |

图 7-1｜AI辅助决策与执行闭环

| **能力**   | **输入**             | **输出**          | **执行边界**    |
| -------- | ------------------ | --------------- | ----------- |
| **状态分类** | 交易、池深度、Gas、竞争与历史记录 | 交易类型、风险类别、候选策略  | 不直接签名或提交交易  |
| **机会评分** | 预期改善、成本、成功率与状态稳定性  | 候选优先级与置信度       | 仅用于排序与资源分配  |
| **参数建议** | 历史执行、波动、Builder表现  | Gas、额度、路由与超时建议  | 必须经过策略上限与仿真 |
| **异常检测** | 仿真/实盘偏差、价格源与结算差异   | 暂停、降级、回退或人工复核信号 | 异常时优先失败关闭   |

## 受保护执行与用户价值保护

私有交易路径可以降低前置暴露，但不等于绝对隐私或绝对包含。New Sandwich 将私有路由、Bundle、公开回退和失败关闭设计为可配置路径，并以用户约束作为最终执行边界。

图 8-1｜链上自动执行流水线

| **执行方式**      | **适用场景**              | **关键约束**                 |
| ------------- | --------------------- | ------------------------ |
| **私有提交**      | 高风险交换、较大价格影响或用户选择隐私模式 | Builder覆盖、超时、隐私提示与包含状态   |
| **原子化Bundle** | 多个步骤需要共同成功或共同失败       | 链与Builder支持、顺序、区块目标和回滚规则 |
| **公开路径**      | 公开流动性明显更优且风险可控        | Gas、滑点、期限与禁止不安全回退        |
| **多路径竞价**     | 多个执行方或路径竞争成交          | 以用户净输出和确定性排序，而非仅看协议收入    |

### 7.1 用户优先的受保护后置执行

New Sandwich 可以在用户交易完成且用户约束已满足之后，允许经授权的后置策略围绕状态变化进行竞争，但不向策略披露足以实施前置夹击的完整交易意图，也不接受任何将策略交易置于受保护用户交易之前的候选。该机制用于在不损害用户成交结果的前提下回收可分配价值，并按照协议规则优先返还用户。MEV-Share 的公开机制同样以选择性提示、仿真和用户侧价值返还为基础。

| **规则**    | **协议要求**                      |
| --------- | ----------------------------- |
| **顺序约束**  | 策略只能位于受保护用户交易之后，或执行与用户无害的独立机会 |
| **用户优先**  | 用户最低接收量、最大Gas、期限与隐私偏好不可被策略覆盖  |
| **信息最小化** | 仅共享策略计算所需的最小提示，避免泄露完整交易意图     |
| **模拟门槛**  | 候选必须通过状态仿真、盈利性、回滚与用户结果检查      |
| **价值分配**  | 新增价值按照协议规则分配给用户、钱包、策略与协议      |
| **可验证记录** | 记录候选、包含、成本、净值、返还和链上回执         |

## 开放策略网络

| **New Sandwich 对外部策略实行“准入—授权—仿真—隔离—执行—归因—结算”的全生命周期管理。策略仅能在授权资产、网络、交易类型与风险参数范围内运行；执行前须通过状态仿真和约束检查，执行过程遵循用户交易优先原则，执行结果进入统一归因与可验证结算系统。协议禁止任何策略利用受保护订单流实施前置抢跑、三明治攻击或其他损害用户利益的交易。** |
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |

图 8-1｜从孤立搜索者到可审计策略模块

| **外部团队原有成本**             | **协议提供的能力**       | **接入价值**    |
| ------------------------ | ----------------- | ----------- |
| **重复建设节点、监听和索引系统**       | 统一状态流、事件订阅和历史快照   | 降低基础设施和维护成本 |
| **独立搭建仿真、Gas和Builder连接** | 共享仿真、路由和执行适配层     | 缩短策略上线周期    |
| **缺少稳定结算和可信记录**          | 统一成本归因、结算与策略信誉    | 形成长期可证明业绩   |
| **覆盖链与场景有限**             | 多链适配、钱包订单流与生态项目入口 | 扩大策略容量和应用场景 |
| **权限和资金边界难管理**           | 独立账户、额度、沙盒、白名单与熔断 | 降低策略相互影响    |

### 8.1 策略适配器接口

```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
```

| **控制维度**  | **协议要求**                     |
| --------- | ---------------------------- |
| **数据权限**  | 只访问被授权的状态、提示和历史记录            |
| **资金权限**  | 使用独立账户、额度或非托管执行结构            |
| **策略类型**  | 优先支持套利、清算、保护与用户无害的后置执行等可解释策略 |
| **绩效归因**  | 独立记录成功率、失败率、成本、净贡献和异常        |
| **信誉与额度** | 根据稳定性、数据一致性和长期贡献动态配置         |
| **退出机制**  | 异常策略可暂停、降额、撤销权限并保留历史记录       |

## 数据引擎与自动化证明

图 9-1｜从链上事件到公开证明的数据链路

协议数据引擎将链上原生事件、仿真记录、路由决策、结算结果和生态同步数据组织为统一事件模型。自动化传播不是制造互动或伪装用户评论，而是把已经验证的协议事实转换为官网快讯、X数据卡、Telegram通知、Webhook和周期报告。

| **数据产品**              | **核心内容**               | **验证基础**     |
| --------------------- | ---------------------- | ------------ |
| **Execution Receipt** | 路由、区块、Gas、实际输出、价格影响和状态 | 交易哈希、区块与合约事件 |
| **Protection Report** | 风险评分、执行路径、基准比较与用户结果    | 仿真快照与实际成交    |
| **Value Attribution** | 毛价值、成本、返还、策略贡献和协议分配    | 结算地址与归因账本    |
| **Strategy Score**    | 成功率、异常率、净贡献、延迟和稳定性     | 长期执行数据库      |
| **Public Data Card**  | 可公开的协议执行、保护与生态数据摘要     | 带原始链接的已结算事件  |

### 9.1 自动化发布的真实性约束

* 只有完成确认和结算的事件可以进入公开发布队列。
* 每条数据摘要保留交易哈希、区块号、时间和指标口径。
* 模型生成的文字必须从结构化字段生成，不允许补充未发生的事实。
* 异常、失败和回退数据进入内部与合作方报告，不以成功案例替代完整运行情况。
* 社媒发布属于数据分发层，不进入交易决策关键路径。

## 安全、可用性与技术边界

| **安全域**   | **控制机制**               | **目标**         |
| --------- | ---------------------- | -------------- |
| **智能合约**  | 权限分层、多签、暂停、升级流程和审计     | 限制关键规则与资产操作范围  |
| **用户交易**  | 最低接收量、期限、最大Gas、隐私和失败关闭 | 不以协议收入牺牲用户约束   |
| **外部策略**  | 沙盒、适配器权限、仿真门槛、额度和信誉    | 控制第三方策略风险      |
| **链下服务**  | 密钥隔离、冗余节点、监控告警和故障回退    | 维持实时系统可用性      |
| **数据一致性** | 签名、快照、链上回执和交叉校验        | 保证协议、链上和生态记录一致 |
| **异常响应**  | 熔断、规模限制、路径切换和人工复核      | 降低极端状态影响       |

### 10.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 确认认购额度，暂不配置节点、算力或资产产出。      |
| 生态成熟期   | 节点网络筹备    | 协议根据真实用户、调用规模和合作基础，公布节点总量、算力配置、份额映射与系统接入规则。 |
| 节点网络上线后 | 节点承销与算力配置 | 生态项目方可按照正式规则承销节点身份、配置有效算力，并接入查询与结算体系。       |

图 12-1｜节点身份与算力网络规划公式

| **参数**      | **规则**                                          |
| ----------- | ----------------------------------------------- |
| **节点身份总量**  | 规划总量为 3,000 个；在节点网络正式启动后用于承载协议身份与有效算力。          |
| **单节点算力范围** | 规划范围为 100 - 5,000 有效算力；具体配置在节点网络正式推出时执行。        |
| **算力价值基准**  | 规划采用 1 USDT 对应 1 算力的配置基准；早期份额认购金额不直接等同于已生效算力。   |
| **全网初始日产出** | 节点网络正式启动后的初始日计算基准为 72,000 份；对应资产与结算单位以届时正式规则为准。 |
| **个人产出公式**  | 个人有效算力 ÷ 全网有效算力 × 当日全网产出基准。                     |
| **减产周期**    | 规划每四年调整一次；以节点网络正式发布的执行规则为准。                     |
| **购买入口**    | 早期仅开放生态份额认购；节点与算力将在生态成熟后通过生态项目方系统开放，协议官网不直接销售。  |

份额认购不等同于节点、算力或 SWC。节点网络正式推出后，所有参与计算的有效算力须绑定节点身份；生态项目方同步订单、用户、节点和算力记录，协议通过签名、快照与查询系统进行核验。

## 协议参与凭证

协议参与凭证是面向链上生态合作建立的可验证接入工具。生态项目方和普通用户均可通过钱包持有；凭证本身不直接产生收益，主要用于生态项目资格验证和协议接入。

| **属性**      | **说明**                    |
| ----------- | ------------------------- |
| **链上持有**    | 凭证记录在用户或生态项目方授权钱包中。       |
| **开放购买**    | 生态项目方和普通用户均可通过协议官网钱包入口购买。 |
| **资格验证**    | 支持凭证的生态项目可以在智能合约中读取和验证凭证。 |
| **不直接产出**   | 凭证不自动获得节点产出、固定分配或协议收益。    |
| **独立于生态代币** | 凭证不等同于任何独立生态项目发行的代币。      |

| **持有者**   | **主要用途**               | **权限边界**              |
| --------- | ---------------------- | --------------------- |
| **普通用户**  | 进入支持该凭证的独立生态项目并验证参与资格  | 不能仅凭持有凭证直接调用受限策略或结算接口 |
| **生态项目方** | 完成生态接入、项目合约验证和授权协议能力调用 | 需完成合作授权、接口配置和权限审核     |

## 为什么开放生态合作

受保护执行与策略网络可以建立协议早期收入，但任何单一链、单一策略、单一团队和单一订单流都存在容量上限。开放生态合作的目的，是把技术优势转化为更多真实调用、用户关系、品牌入口、数据资产和全球网络效应。

| **增长约束**  | **单一技术团队的限制**      | **开放生态带来的扩展**      |
| --------- | ------------------ | ------------------ |
| **策略容量**  | 机会受链、资金、市场和竞争强度限制  | 通过多项目、多链与多策略扩大调用场景 |
| **用户与品牌** | 执行团队通常缺少持续用户关系     | 生态项目形成独立用户体系与市场触达  |
| **数据规模**  | 单一订单流的数据覆盖有限       | 多生态持续增加交易、执行与用户数据  |
| **产品边界**  | 纯执行收入难覆盖更多商业需求     | 输出接口、凭证、节点、结算和数据产品 |
| **全球复制**  | 协议方难以在每个区域直接运营同一模式 | 独立生态完成本地化产品与社区     |

| **生态合作服务于技术协议的规模化：先有可验证的保护与执行能力，再通过合作把能力嵌入更多钱包、应用、用户体系和区域市场。** |
| -------------------------------------------------------------- |

## New Sandwich 官方生态合作方式

New Sandwich 官方生态合作方式，是指独立生态项目在不改变自身主体、品牌、产品、用户和经济模型的前提下，通过标准化入口接入协议的策略执行、节点算力、协议凭证、数据查询和生态结算能力。生态合作服务于技术协议的规模化，协议核心始终是三明治攻击防护、用户交易保护与可验证执行。

| **统一定义：New Sandwich 提供底层协议能力与接入规则；生态项目方独立承担主体、品牌、产品、用户、代币、社区和市场运营。双方通过协议接口、节点算力或链上凭证建立合作关系。** |
| --------------------------------------------------------------------------------------------- |

图 15-1｜New Sandwich 官方生态合作方式与双轨接入结构

### 15.1 官方合作原则

| **原则**    | **正式定义**                                  |
| --------- | ----------------------------------------- |
| **技术为核心** | 生态合作建立在可验证的三明治攻击防护、用户交易保护、策略执行、数据与结算能力之上。 |
| **双轨接入**  | 根据生态项目的用户架构，提供账户型节点承销和链上协议凭证两种方式。         |
| **生态独立**  | 生态项目拥有独立主体、控制人、品牌、代币、用户体系、社区和市场策略。        |
| **协议统一**  | 节点、算力、凭证、产出、接口权限和结算由协议规则统一记录与验证。          |
| **职责分离**  | 协议方提供底层能力；生态项目方负责自身销售、产品、用户服务和市场运营。       |

### 15.2 New Sandwich官方生态合作方式

| **维度**    | **账户型生态合作｜节点承销 / 份额认购**                         | **链上生态合作｜协议凭证**           |
| --------- | ----------------------------------------------- | ------------------------- |
| **主要对象**  | 具备邮箱、手机号或账户体系，并拥有市场运营能力的生态项目方                   | 采用钱包、智能合约和链上社区方式运行的生态项目方  |
| **接入基础**  | 生态早期按照投入的 USDT 认购生态份额；节点网络推出后可按正式规则进入节点承销与算力配置。 | 项目方或普通用户购买并持有协议参与凭证       |
| **用户身份**  | 生态方账户、邮箱或手机号                                    | 钱包地址                      |
| **购买入口**  | 份额认购由生态项目方完成；节点网络正式推出前不开放节点与算力销售。               | 协议官网开放钱包购买、持有与查询凭证        |
| **官网功能**  | 早期记录生态合作与认购信息；节点网络推出后按正式规则提供相应查询能力。             | 购买、持有、查询凭证并连接支持凭证的生态项目    |
| **产出与资格** | 早期按照认购金额记录生态参与额度；节点网络推出后再按正式规则确认节点、算力及相关权益。     | 凭证本身不直接产出，用于生态项目资格验证与授权接入 |
| **经济模型**  | 由生态项目方独立设计和运营                                   | 由生态项目方通过智能合约独立设计和运营       |

### 账户型生态合作：节点承销 / 份额认购

账户型生态合作适用于拥有独立账户系统、市场组织和用户服务能力的生态项目方。生态早期，项目方按照实际投入的 USDT 认购生态份额，并在自身系统内完成认购管理、用户服务和市场运营；在生态发展繁荣、节点与算力网络正式推出后，项目方可按照届时规则进入节点承销与算力配置阶段。

#### 15.3 运行流程

{% stepper %}
{% step %}

### 确认合作范围

生态项目方与 New Sandwich 确认生态份额认购规模、投入金额、合作范围、系统接口和结算规则。
{% endstep %}

{% step %}

### 认购生态份额

在节点网络尚未推出的阶段，生态项目方按照实际投入的 USDT 直接认购生态份额，协议记录对应的参与额度与合作权益。
{% endstep %}

{% step %}

### 同步记录与用户服务

生态项目方通过授权接口同步账户、订单、认购金额和份额记录，并在自身系统内完成用户服务与市场运营。
{% endstep %}

{% step %}

### 记录早期认购边界

早期认购份额不直接产生节点、算力或协议生态代币；相关记录作为生态合作、后续规则衔接和权益确认的基础。
{% endstep %}

{% step %}

### 衔接节点与算力网络

在生态发展繁荣并正式推出节点与算力网络后，协议按照届时公布的规则确定份额映射、节点承销、算力配置与查询方式。
{% endstep %}

{% step %}

### 建立独立生态体系

生态项目方围绕协议能力与自身产品建立独立的用户体系、经济模型和市场运营机制。
{% endstep %}
{% endstepper %}

#### 15.4 职责与边界

| **主体**           | **核心职责**                             | **明确边界**                   |
| ---------------- | ------------------------------------ | -------------------------- |
| **New Sandwich** | 生态份额登记、合作规则、节点与算力网络规划、数据核验、协议结算和技术接口 | 生态早期不直接销售节点或算力，不管理生态项目用户团队 |
| **生态项目方**        | 份额认购、账户系统、订单与用户服务、产品设计、市场运营和自身经济模型   | 独立承担对用户的产品与运营责任            |
| **生态参与用户**       | 通过生态项目方系统参与份额认购；节点网络推出后按正式规则衔接相关权益   | 早期认购不等同于节点、算力、协议生态代币或固定收益  |

{% hint style="info" %}
发展阶段说明：生态早期以份额认购为主要合作方式；节点与算力网络将在生态发展繁荣后推出。届时节点身份、算力配置、份额映射、查询与结算规则将以正式发布内容为准。
{% endhint %}

### 链上生态合作：协议凭证

链上生态合作适用于采用钱包、智能合约和链上社区方式运行的独立项目。协议参与凭证由钱包持有，用于记录生态接入、项目参与和资格验证；凭证本身不直接产生收益，也不自动获得节点产出或协议分配。

#### 15.5 运行流程

{% stepper %}
{% step %}

### 连接凭证入口

生态项目方或普通用户使用钱包连接 New Sandwich 协议凭证入口。
{% endstep %}

{% step %}

### 购买或持有凭证

用户购买或持有协议参与凭证，凭证记录在授权钱包中。
{% endstep %}

{% step %}

### 验证凭证

用户进入支持该凭证的独立生态项目，由项目合约读取并验证凭证。
{% endstep %}

{% step %}

### 开放生态项目权限

生态项目按照自身规则开放产品功能、社区资格、链上算力或其他参与权限。
{% endstep %}

{% step %}

### 调用受限协议服务

完成合作授权的生态项目方，通过受限接口调用策略、数据或结算服务。
{% endstep %}
{% endstepper %}

#### 15.6 凭证定位与权限边界

| **参与者**          | **凭证的主要用途**                | **权限边界**                   |
| ---------------- | -------------------------- | -------------------------- |
| **普通用户**         | 持有凭证并进入支持该凭证的独立生态项目，完成资格验证 | 不能仅凭持有凭证直接调用受限策略、资金或结算接口   |
| **生态项目方**        | 完成项目接入、合约验证和授权协议能力调用       | 需完成合作授权、接口配置、权限审核与技术测试     |
| **New Sandwich** | 提供凭证购买、链上记录、验证接口和生态导航      | 不为凭证持有者建立推荐关系、团队层级或中心化用户架构 |

#### 15.7 独立性原则

| **协议与生态边界任何生态项目均拥有独立主体、控制人、品牌、代币、用户组织和经济模型。New Sandwich 提供底层技术、产出规则、凭证验证、数据与结算能力，不将任何单一生态项目的奖励、团队制度或市场策略定义为协议基础规则。** |
| -------------------------------------------------------------------------------------------------------------------- |

## 商业模式与收益分配

协议商业收入首先来自受保护执行、策略网络和技术服务，并由协议凭证、开放接口、数据与生态结算形成补充。生态早期的份额认购用于支持合作拓展与基础设施建设；节点与算力服务将在生态成熟并正式推出相关网络后纳入商业体系。不同收入采用不同核算方式。

| **收入类型**        | **主要模式**                               | **主要客户**     |
| --------------- | -------------------------------------- | ------------ |
| **受保护执行服务**     | Protected RPC、SDK、路由优化、用户价值保护与技术服务费    | 钱包、DEX、应用、机构 |
| **策略网络服务**      | 策略调用、执行、清算、用户无害的后置执行和技术分成              | 策略团队、生态项目、机构 |
| **份额认购及未来节点服务** | 生态早期份额认购；生态成熟后按正式规则开放节点身份、算力配置、查询与系统接口 | 账户型生态项目方     |
| **协议凭证**        | 凭证购买、验证、生态接入与合约调用                      | 链上生态项目方、普通用户 |
| **开放接口与数据**     | API、SDK、Data API、Webhook、白标与定制数据       | 钱包、平台、开发者、机构 |
| **生态结算服务**      | 项目接入、合作结算、预算和周期账目                      | 生态项目方与区域伙伴   |

### 16.1 策略网络可分配清算收益

策略网络完成链上结算并扣除 Gas、执行成本和必要合作费用后，形成当期净可分配清算收益。该部分按照 20% 基金会、40% 协议生态价值管理、40% New Sandwich 生态池执行。在 SWC 正式推出之前，协议生态价值管理部分作为生态发展与未来资产体系的专项储备；在生态发展繁荣并正式推出 SWC 后，其具体用途将按照届时公布的资产规则执行。份额认购、协议凭证、接口和企业服务收入按照对应产品与合作协议单独核算。

图 16-1｜策略网络净可分配清算收益的20 / 40 / 40结构

## 治理与路线图

本章聚焦协议核心技术、策略权限、生态份额、未来节点与算力网络、协议凭证、生态池预算、SWC 规划和升级流程的治理结构。

### 17.1 治理结构

协议发展早期由基金会、核心技术团队和多签治理委员会管理关键参数。用户保护策略、路由适配、生态份额、协议凭证、生态池预算、策略权限和协议升级采用分层治理；节点总量、算力公式及 SWC 相关规则将在对应发展阶段形成正式方案。随着策略网络、节点和生态项目增长，适合公开决策的事项逐步进入社区与生态治理。

### 17.2 产品与生态路线图

图 17-1｜技术能力优先、生态规模递进的产品路线

| **阶段**   | **核心目标**                           | **关键交付**                                |
| -------- | ---------------------------------- | --------------------------------------- |
| **协议核心** | 完成受保护交易、风险评分、仿真、路由和执行回执            | Protected RPC / SDK、仿真服务、私有路由、Dashboard |
| **策略网络** | 开放经授权、不会损害用户交易结果的后置执行、套利、清算与保护策略接入 | 策略适配器、沙盒、结算、信誉和权限体系                     |
| **多链扩展** | 按链级订单流与区块构建结构部署执行适配                | 多链状态、Builder/Sequencer适配、跨链数据模型         |
| **生态规模** | 开放节点承销、协议凭证、接口与区域生态                | 双轨合作、开发者门户、生态目录和周期报告                    |

## 核心指标、术语与技术参考

### 18.1 北极星指标

| **New Sandwich 的北极星指标是：协议为受保护订单流创造的可验证净执行价值。该价值由成交改善、避免损失、用户返还、策略净贡献和可验证覆盖共同构成。** |
| --------------------------------------------------------------------------------- |

| **指标类别**     | **核心指标**                                |
| ------------ | --------------------------------------- |
| **保护效果**     | 高风险交易保护覆盖率、基准成交改善、异常滑点降低、用户返还           |
| **链上感知**     | 覆盖链与数据源、状态延迟、风险识别准确率                    |
| **仿真与执行**    | 仿真量、偏差、执行成功率、Gas效率、回退和熔断率               |
| **策略网络**     | 活跃策略、外部策略接入、稳定性、净贡献与信誉分布                |
| **可验证性**     | 完整执行回执比例、原始链接覆盖、成本归因完整度                 |
| **商业与生态**    | 受保护交易量、策略净清算收益、接口调用、生态项目留存与区域覆盖         |
| **份额、节点与凭证** | 早期份额认购、凭证持有与生态验证；节点网络推出后的有效节点、全网算力与分布情况 |

### 17.2 关键术语

| **术语**                  | **定义**                                            |
| ----------------------- | ------------------------------------------------- |
| **MEV**                 | Maximal Extractable Value，区块生产和交易排序过程中可以被提取的额外价值。 |
| **三明治攻击**               | 攻击者在目标交易前后插入交易，通过目标交易造成的价格变化捕获价差。                 |
| **Searcher**            | 监测链上状态并提交套利、清算、保护或其他自动化策略的专业参与者。                  |
| **Builder / Relay**     | 参与Bundle接收、区块构建和转发的基础设施角色。                        |
| **Backrun**             | 在目标交易之后执行的策略，用于捕获该交易造成的状态变化。                      |
| **Protected Orderflow** | 不直接广播到公开交易池、按隐私和执行约束处理的交易流。                       |
| **策略适配器**               | 外部策略接入协议时使用的标准输入、输出、权限和结算接口。                      |
| **协议参与凭证**              | 由钱包持有，用于生态接入和资格验证的链上凭据。                           |


---

# 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/cn.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.