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

# New\_Sandwich\_Whitepaper\_EN

\| **Protocol Core:** New Sandwich is a protocol focused on sandwich-attack protection, on-chain execution optimization, and user-centric value recovery. Through real-time on-chain intelligence, pre-execution simulation, protected routing, compliant back-run strategy competition, and verifiable settlement, it redistributes value previously captured through information asymmetry and ordering advantages into open capabilities for users, wallets, strategy teams, and ecosystem projects. |

## Executive Summary

New Sandwich is a foundational on-chain transaction protection and strategy execution protocol for public order flow. It addresses sandwich attacks and execution-value leakage through systematic technical capabilities, and provides standardized, composable protocol access and collaboration for independent ecosystem projects.

New Sandwich is a sandwich-attack protection and on-chain execution protection protocol for wallets, trading applications, on-chain users, strategy teams, and independent ecosystem projects. The protocol implements a six-stage protection pipeline for user transaction execution: risk identification, protected submission, pre-execution simulation, constrained execution, user-centric value recovery, and result verification.

By reducing transaction-intent exposure, strictly enforcing user constraints, and identifying and mitigating harmful ordering, New Sandwich redistributes allocable value according to protocol rules while contributing to protocol sustainability. Public mechanisms such as Flashbots MEV-Share demonstrate that protected order flow can allow back-run competition under selective disclosure and simulation constraints, redistributing a portion of the value to the original transaction party.

New Sandwich’s technical leadership is built on system composition: multi-source on-chain state streams, sandwich risk scoring, fork-state simulation, cross-route net-value comparison, private submission and Bundle execution, strategy adapters, cost attribution, and public data proofs. No single capability constitutes New Sandwich in isolation; its technical advantage arises from the system-level integration of these capabilities within a unified execution loop.

Ecosystem collaboration is the primary path to scale New Sandwich’s technical capabilities, not a substitute for the protocol product itself. With sandwich-attack protection, user transaction protection, and execution optimization at the core, New Sandwich exposes strategy execution, data, and settlement capabilities to independent ecosystem projects through two official cooperation modes: node participation and on-chain protocol participation credentials.

*Figure 1-1 | New Sandwich Sandwich-Attack Protection Loop*

| **Core Capability**         | **Product Function**                                                                                   | **User Outcome**                                               |
| --------------------------- | ------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| Risk Identification         | Identify public exposure, slippage space, pool depth, Gas competition, and ordering risk               | Judge before broadcast whether a trade is easily sandwichable  |
| Protected Execution         | Private routing, controlled order flow, Bundle, and fail-closed policies                               | Reduce premature intent exposure and unsafe fallback           |
| User-Centric Value Recovery | Allow only authorized back-run execution that does not harm user results; prohibit any sandwich attack | Redistribute allocable MEV to users, wallets, and the protocol |
| Execution Attestation       | Record simulation, routing, fill quality, cost, return, and transaction hash                           | Make protection effects queryable, auditable, and accumulable  |
| Open Strategies             | External strategies connect via standard adapters, permissions, and settlement rules                   | Expand strategy coverage while maintaining safety boundaries   |

## On-Chain Trading Environment and Sandwich Attacks

**MEV is the additional value that block producers or other participants obtain by ordering, including, or excluding transactions. Arbitrage and liquidation can improve DeFi efficiency, but sandwich trades directly cause worse fill prices and slippage for users.**

### 2.1 Why Ordering Competition Is Inherent On-Chain

On-chain trades are not completed the moment a user clicks “confirm.” Transactions pass through RPCs, public or private order flow, builders, block proposal, and final confirmation. In public order flow, transaction intent may be observed before confirmation; large swaps, shallow liquidity, loose slippage, and active competition together create the conditions for sandwich attacks.

| **Structural Position** | **Signals Observed by Attackers**                                    | **Impact on Users**                                        |
| ----------------------- | -------------------------------------------------------------------- | ---------------------------------------------------------- |
| Transaction Intent      | Pair, size, minimum received, Gas, and target contract               | Exposes price impact and acceptable slippage space         |
| AMM State               | Pool reserves, price curves, cross-pool spreads, and liquidity depth | Determines the price range a front-running trade can push  |
| Block Building          | Priority fees, Bundles, builder coverage, and block competition      | Determines ordering of front-run, user trade, and back-run |
| Execution Result        | User fill, attacker unwind, Gas, and net profit                      | User bears worse price; attacker captures the spread       |

*Figure 2-1 | High-Level Execution Chain of a Sandwich Attack*

### 2.2 Bot Systems Are Evolving from Scripts to Execution Infrastructure

Early bots relied on fixed parameters and a single trading pool. Next-generation search systems simultaneously read pool state, Gas, oracles, builders, and cross-market state, and use simulation to compare candidate paths. Public mempools are not a uniform structure across all chains and L2s; private sequencers and private mempools change attack feasibility. Therefore the protocol must adopt chain-level adaptation and cannot copy Ethereum L1 assumptions to every network.

*Figure 2-2 | Technical Evolution of Searcher and Sandwich Bots (MEV Searchers)*

### 2.3 Limitations of Existing Point Solutions

| **Common Approach**    | **Problems It Addresses**           | **Remaining Gaps**                                                                                     |
| ---------------------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------ |
| Tighten Slippage       | Compresses attacker profit space    | Over-tightening may cause failures; does not address privacy or routing                                |
| Single Private RPC     | Reduces public exposure             | Depends on builder coverage and service availability; does not automatically compare execution quality |
| Transaction Simulation | Identifies reverts and price impact | Results diverge if state, block, and Bundle context are inconsistent                                   |
| Single Bot             | Covers one strategy or one chain    | High maintenance cost; hard to continuously adapt to different market structures                       |
| Data Dashboard         | Displays execution results          | Without cost attribution and raw proofs, only surface transparency                                     |

## New Sandwich Product Functionality

**New Sandwich is a complete protection protocol that “protects user transaction execution — reduces intent exposure — mitigates harmful ordering — verifies execution results.”**

### 3.1 Three-Layer Protection Mechanism

| **Layer**               | **Product Action**                                                                                       | **Core Result**                                                                                                        |
| ----------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
| Shield \| Protect       | Trades enter via Protected RPC / SDK; risk is identified and private or controlled paths are selected    | Reduce public exposure of transaction intent                                                                           |
| Guard \| Active Defense | Under the premise that user constraints are not violated, only compliant back-run strategies may compete | Redistribute allocable back-run value to users by rule and contribute to protocol sustainability without harming users |
| Execution Attestation   | Generate execution receipts, price impact, Gas, returns, and strategy attribution records                | Prove protection effects with verifiable data                                                                          |

*Figure 3-1 | Protected Order Flow and User-Centric Value Recovery*

### 3.2 Product Forms

| **Product Entry** | **Audience**                        | **Main Functions**                                                                           |
| ----------------- | ----------------------------------- | -------------------------------------------------------------------------------------------- |
| Protected RPC     | Retail users and wallets            | Protected submission, route selection, transaction status and return queries                 |
| Wallet / DApp SDK | Wallets, DEXes, aggregators, apps   | Risk pre-check, minimum-received protection, routing and front-end status                    |
| Execution API     | Institutions and ecosystem projects | Batch execution, constrained strategies, private channels, and settlement receipts           |
| Strategy Adapter  | Searchers and strategy teams        | Standard state input, candidate output, simulation, permissions, and performance attribution |
| Data Dashboard    | Users, partners, and the market     | Trade protection, execution quality, net value, returns, and protocol operating data         |

### 3.3 Complete Path of a User Trade

{% stepper %}
{% step %}

### User or wallet submits trade intent

Submit trade intent, minimum received, deadline, and privacy preference.
{% endstep %}

{% step %}

### Risk engine scores the trade

Score using pool depth, slippage, public exposure, Gas competition, and builder state.
{% endstep %}

{% step %}

### Routing engine compares paths

Compare expected execution results of public paths, private paths, and controlled order flow.
{% endstep %}

{% step %}

### Simulation engine validates execution

Validate fill, Gas, reverts, competitive impact, and worst-case scenarios against target block state.
{% endstep %}

{% step %}

### Execution layer submits under user constraints

If constraints cannot be met, cancel, degrade, or return a clear failure state.
{% endstep %}

{% step %}

### Authorized back-run strategies may participate

After the user trade completes and user constraints are satisfied, the protocol may allow authorized back-run strategies that do not harm user results to participate, and allocate newly created value by rule.
{% endstep %}

{% step %}

### Settlement layer generates a verifiable receipt

Show actual fill, cost, return, strategy contribution, and on-chain proof.
{% endstep %}
{% endstepper %}

## Technical Leadership and Differentiation

**New Sandwich continuously builds technical leadership in on-chain transaction protection and strategy execution through systematic architecture, quantifiable execution metrics, and auditable on-chain results.**

*Figure 4-1 | Six System Capabilities of Technical Leadership*

### 4.1 Leadership Comes from the Closed Loop, Not Point Solutions

| **Comparison Dimension** | **Common Point Solutions**            | **New Sandwich Protocol Design**                                                                      |
| ------------------------ | ------------------------------------- | ----------------------------------------------------------------------------------------------------- |
| Risk Identification      | Single slippage or fixed parameters   | Multi-source state + trade features + competitive environment joint scoring                           |
| Pre-Execution Validation | Simple eth\_call or static estimates  | Target block state, signed transactions, Bundle context, and worst-case simulation                    |
| Routing                  | Fixed RPC or single builder           | Public, private, Bundle, and fallback paths compared by net execution quality                         |
| Value Handling           | Block attacks but ignore residual MEV | Allow controlled, user-safe back-run execution and prioritize redistributing allocable value to users |
| Strategy Expansion       | Internal single bot                   | External strategy adapters + sandbox + permissions + settlement + reputation                          |
| Execution Attestation    | Success/failure status                | Fill quality, Gas, returns, attribution, and raw on-chain records                                     |

## Overall Protocol Technical Architecture

*Figure 5-1 | New Sandwich Protocol Technology Stack*

| **Technical Layer**         | **Core Responsibilities**                                                                                          | **Key Outputs**                          |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------ | ---------------------------------------- |
| On-Chain Intelligence Layer | Collect order flow, blocks, DEX, Gas, oracle, builder, and multi-chain state                                       | Standardized state streams and snapshots |
| Risk & Simulation Layer     | Risk classification, opportunity scoring, parameter assistance, fork simulation, and worst-case validation         | Executable candidates and risk labels    |
| Execution & Routing Layer   | Private submission, Bundle, public path, Gas/Nonce, cancel, and fallback                                           | On-chain execution results               |
| Strategy Network Layer      | Internal and external strategy registration, sandbox, permissions, quotas, reputation, and performance attribution | Controlled strategy modules              |
| Settlement & Value Layer    | Cost, net profit, returns, partnership allocation, and ecosystem budget                                            | Settlement records and attribution data  |
| Data & Interface Layer      | Dashboard, API, node queries, credentials, webhooks, and public proofs                                             | Product entry points and data assets     |

#### Defensive Execution Pseudocode

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

## On-Chain Intelligence and Risk Identification

The protocol’s first technical advantage is not “sending transactions faster,” but forming a more complete on-chain state before broadcast. Risk identification must simultaneously understand the trade, liquidity, Gas, block building, and routing environment.

| **Data Domain**        | **Typical Signals**                                                                 | **Protection Use**                                               |
| ---------------------- | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------- |
| Trades & Order Flow    | Target contract, size, path, minimum received, deadline, privacy preference         | Judge intent exposure and sandwichable space                     |
| DEX & Liquidity        | Reserves, curves, depth, price impact, cross-pool spreads                           | Predict price moves and alternative paths                        |
| Gas & Block Building   | Base Fee, Priority Fee, builder availability, Bundle state                          | Estimate competition cost and submission method                  |
| Price & Oracle         | On-chain oracles, DEX mid-prices, cross-market references                           | Identify price anomalies and settlement deviations               |
| Historical Competition | Searcher features, failure modes, route conflicts, block inclusion rates            | Identify high-risk windows and strategy congestion               |
| Chain Structure        | Public mempool, private sequencers, block time, finality, and reorg characteristics | Avoid wrongly copying single-chain assumptions to other networks |

### 6.1 Sandwich Risk Scoring

Risk scoring does not “predict that an attacker will definitely attack”; it estimates a trade’s observability, price impact, orderability, and attack economics under current state. Scores are used to select execution paths and constraint strength.

| **Scoring Dimension** | **Example Metrics**                                                             | **System Action**                             |
| --------------------- | ------------------------------------------------------------------------------- | --------------------------------------------- |
| Exposure Risk         | Whether the trade enters public order flow; how much hint information is shared | Raise privacy level or forbid public fallback |
| Price Impact          | Expected price impact, pool depth vs. trade size ratio                          | Split, re-route, or tighten constraints       |
| Slippage Space        | Difference between minimum received and simulated output                        | Judge exploitable space for attackers         |
| Ordering Competition  | Priority-fee volatility, builder competition, recent sandwich patterns          | Choose private path or delay execution        |
| State Stability       | Oracle deviation, liquidity migration, block state changes                      | Trigger re-simulation or pause                |

## AI-Assisted Decision and Pre-Execution Simulation

**AI improves identification, ranking, and parameter-tuning efficiency; deterministic rules, user constraints, and simulation results decide whether a trade may execute.**

*Figure 7-1 | AI-Assisted Decision and Execution Loop*

| **Capability**       | **Input**                                                        | **Output**                                        | **Execution Boundary**                        |
| -------------------- | ---------------------------------------------------------------- | ------------------------------------------------- | --------------------------------------------- |
| State Classification | Trade, pool depth, Gas, competition, and history                 | Trade type, risk category, candidate strategies   | Does not directly sign or submit trades       |
| Opportunity Scoring  | Expected improvement, cost, success rate, state stability        | Candidate priority and confidence                 | Used only for ranking and resource allocation |
| Parameter Suggestion | Historical execution, volatility, builder performance            | Gas, quota, route, and timeout suggestions        | Must pass strategy caps and simulation        |
| Anomaly Detection    | Simulation/live deviation, price sources, settlement differences | Pause, degrade, fallback, or human review signals | Prefer fail-closed on anomalies               |

## Protected Execution and User Value Protection

Private transaction paths can reduce front-running exposure, but do not equal absolute privacy or absolute inclusion. New Sandwich designs private routing, Bundles, public fallback, and fail-closed as configurable paths, with user constraints as the final execution boundary.

*Figure 8-1 | On-Chain Automated Execution Pipeline*

| **Execution Method** | **Applicable Scenarios**                                           | **Key Constraints**                                                   |
| -------------------- | ------------------------------------------------------------------ | --------------------------------------------------------------------- |
| Private Submission   | High-risk swaps, large price impact, or user-selected privacy mode | Builder coverage, timeout, privacy hints, and inclusion status        |
| Atomic Bundle        | Multiple steps that must succeed or fail together                  | Chain and builder support, ordering, block target, and rollback rules |
| Public Path          | Public liquidity clearly superior and risk controllable            | Gas, slippage, deadline, and prohibition of unsafe fallback           |
| Multi-Path Auction   | Multiple executors or paths competing for the fill                 | Rank by user net output and determinism, not only protocol revenue    |

### 8.1 User-First Protected Back-Run Execution

After the user trade completes and user constraints are satisfied, New Sandwich may allow authorized back-run strategies to compete around the resulting state change, without disclosing to strategies enough of the full trade intent to enable sandwich attacks, and without accepting any candidate that places strategy transactions before the protected user trade. This mechanism recovers allocable value without harming user fill results, and prioritizes redistributing value to users under protocol rules. Public mechanisms such as MEV-Share are likewise based on selective hints, simulation, and user-centric value recovery.

| **Rule**                 | **Protocol Requirement**                                                                                                         |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------------- |
| Ordering Constraint      | Strategies may only be placed after the protected user trade, or execute independent opportunities that are harmless to the user |
| User Priority            | User minimum received, max Gas, deadline, and privacy preference cannot be overridden by strategies                              |
| Information Minimization | Share only the minimum hints needed for strategy computation; avoid leaking full trade intent                                    |
| Simulation Threshold     | Candidates must pass state simulation, profitability, revert, and user-result checks                                             |
| Value Allocation         | Newly created value is allocated to users, wallets, strategies, and the protocol by protocol rules                               |
| Verifiable Record        | Record candidates, inclusion, cost, net value, returns, and on-chain receipts                                                    |

## Open Strategy Network

New Sandwich applies full-lifecycle management of external strategies: admission — authorization — simulation — isolation — execution — attribution — settlement. Strategies may run only within authorized assets, networks, trade types, and risk parameters; they must pass state simulation and constraint checks before execution; execution follows user-trade priority; results enter a unified attribution and verifiable settlement system. The protocol prohibits any strategy from using protected order flow to front-run, sandwich, or otherwise harm user interests.

*Figure 9-1 | From Isolated Searchers to Auditable Strategy Modules*

| **Prior Cost for External Teams**                               | **Capability Provided by Protocol**                                           | **Access Value**                                   |
| --------------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------- |
| Repeatedly building nodes, listeners, and indexers              | Unified state streams, event subscriptions, and historical snapshots          | Lower infrastructure and maintenance cost          |
| Independently building simulation, Gas, and builder connections | Shared simulation, routing, and execution adapter layer                       | Shorten strategy time-to-market                    |
| Lack of stable settlement and trusted records                   | Unified cost attribution, settlement, and strategy reputation                 | Form long-term provable performance                |
| Limited chain and scenario coverage                             | Multi-chain adaptation, wallet order flow, and ecosystem project entry points | Expand strategy capacity and application scenarios |
| Hard-to-manage permissions and capital boundaries               | Independent accounts, quotas, sandbox, whitelist, and circuit breakers        | Reduce mutual strategy interference                |

### 9.1 Strategy Adapter 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
```

| **Control Dimension**   | **Protocol Requirement**                                                                                   |
| ----------------------- | ---------------------------------------------------------------------------------------------------------- |
| Data Permissions        | Access only authorized state, hints, and historical records                                                |
| Capital Permissions     | Use independent accounts, quotas, or non-custodial execution structures                                    |
| Strategy Types          | Prefer explainable strategies such as arbitrage, liquidation, protection, and user-safe back-run execution |
| Performance Attribution | Independently record success rate, failure rate, cost, net contribution, and anomalies                     |
| Reputation & Quotas     | Dynamically configure based on stability, data consistency, and long-term contribution                     |
| Exit Mechanisms         | Anomalous strategies may be paused, down-sized, revoked, with history retained                             |

## Data Engine and Automated Attestation

*Figure 10-1 | Data Path from On-Chain Events to Public Proof*

The protocol data engine organizes native on-chain events, simulation records, routing decisions, settlement results, and ecosystem sync data into a unified event model. Automated distribution does not fabricate engagement or fake user comments; it converts already-verified protocol facts into website bulletins, X data cards, Telegram notifications, webhooks, and periodic reports.

| **Data Product**  | **Core Content**                                                           | **Verification Basis**                       |
| ----------------- | -------------------------------------------------------------------------- | -------------------------------------------- |
| Execution Receipt | Route, block, Gas, actual output, price impact, and status                 | Transaction hash, block, and contract events |
| Protection Report | Risk score, execution path, benchmark comparison, and user result          | Simulation snapshots and actual fills        |
| Value Attribution | Gross value, cost, returns, strategy contribution, and protocol allocation | Settlement addresses and attribution ledger  |
| Strategy Score    | Success rate, anomaly rate, net contribution, latency, and stability       | Long-term execution database                 |
| Public Data Card  | Public summary of protocol execution, protection, and ecosystem data       | Settled events with original links           |

### 10.1 Authenticity Constraints for Automated Publication

* Only events that have completed confirmation and settlement may enter the public publication queue.
* Every data summary retains transaction hash, block number, time, and metric definitions.
* Model-generated text must be produced from structured fields; inventing facts that did not occur is forbidden.
* Anomaly, failure, and fallback data enter internal and partner reports; success cases do not replace complete operational picture.
* Social media publication is a data distribution layer and does not enter the critical path of trading decisions.

## Security, Availability, and Technical Boundaries

| **Security Domain** | **Control Mechanism**                                                       | **Objective**                                                      |
| ------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| Smart Contracts     | Permission layering, multi-sig, pause, upgrade process, and audits          | Limit the scope of key rules and asset operations                  |
| User Trades         | Minimum received, deadline, max Gas, privacy, and fail-closed               | Do not sacrifice user constraints for protocol revenue             |
| External Strategies | Sandbox, adapter permissions, simulation thresholds, quotas, and reputation | Control third-party strategy risk                                  |
| Off-Chain Services  | Key isolation, redundant nodes, monitoring alerts, and failover             | Maintain real-time system availability                             |
| Data Consistency    | Signatures, snapshots, on-chain receipts, and cross-checks                  | Ensure consistency among protocol, on-chain, and ecosystem records |
| Anomaly Response    | Circuit breakers, scale limits, path switching, and human review            | Reduce impact of extreme states                                    |

### 11.1 Technical Boundaries

* Private routing reduces transaction-intent exposure but cannot guarantee absolute privacy or inclusion under all chains, builders, sequencers, and network states.
* Bundle atomicity and ordering control depend on specific chain and block-building infrastructure; when unsupported, equivalent chain-level execution adapters must be used.
* AI scoring may err; therefore it does not directly control signing or funds. Deterministic rules, simulation, and user constraints have higher priority.
* Sandwich attacks cannot be permanently eliminated by the protocol in all public markets; the product goal is to shrink exploitable space, improve execution, and recover allocable value.
* Technical leadership must be continuously proven by execution success rate, simulation deviation, user net output, returns, and verifiable coverage.

{% hint style="info" %}
**New Sandwich’s technical narrative starts from real engineering constraints: it does not promise “zero MEV,” “never sandwichable,” or “every trade necessarily receives a return.” It proves protection capability with verifiable execution results.**
{% endhint %}

## Ecosystem Development Stages and SWC Planning

New Sandwich’s ecosystem construction advances in stages. Early on, the protocol prioritizes trade protection, the strategy network, and ecosystem cooperation, confirming participation quotas of ecosystem projects via share subscription. The node and computing-power network will be launched only after the ecosystem has stable user scale, real usage, and a cooperation foundation.

### 11.1 Development Stages

| **Development Stage**     | **Core Focus**                                                                                    | **Corresponding Mechanism**                                                                                                                                                  |
| ------------------------- | ------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Early Ecosystem Stage     | Prioritize completing protocol product, strategy network, and ecosystem cooperation               | Ecosystem projects subscribe to ecosystem shares according to actual USDT committed; node sales, computing-power configuration, or asset output are not yet open.            |
| Ecosystem Expansion Stage | Form real multi-project, multi-chain, multi-strategy usage                                        | Improve share management, data verification, and cooperation settlement to lay the operational foundation for the node and computing-power network.                          |
| Node Network Stage        | Launch node and computing-power network after ecosystem prosperity and mature infrastructure      | Open node identity, computing-power configuration, share mapping, and query systems according to then-published formal rules.                                                |
| SWC Planning Stage        | Develop protocol ecosystem asset after node network and ecosystem applications reach stable scale | Future plan to develop New Sandwich ecosystem token SWC; issuance arrangements, functions, total supply, allocation, and governance rules are subject to formal publication. |

Share subscription records ecosystem projects’ participation quotas and cooperation rights in the early stage. It is not equivalent to nodes, computing power, or SWC, and does not constitute a pre-commitment to future node mapping, asset issuance, or yield outcomes.

## Node Identity and Computing-Power Network

Node identity and the computing-power network belong to the mature-stage planning capabilities of the New Sandwich ecosystem and are not opened directly in the early protocol phase. Early ecosystem projects participate via share subscription; after the ecosystem forms stable user scale, real usage, and a cooperation foundation, the protocol will launch node identity, computing-power configuration, and related computation systems according to formally published rules.

### 12.1 Development Path

The node and computing-power network advances along the path “share subscription first, node network later.” Early subscription shares record ecosystem cooperation participation quotas; after the node network is formally launched, subsequent rights are connected according to then-published mapping, configuration, and settlement rules.

| **Stage**                 | **Operating Mode**                                 | **Rule Description**                                                                                                                                               |
| ------------------------- | -------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Early Ecosystem           | Share Subscription                                 | Ecosystem projects confirm subscription quotas according to USDT committed; nodes, computing power, or asset output are not yet configured.                        |
| Mature Ecosystem          | Node Network Preparation                           | Protocol publishes node total, computing-power configuration, share mapping, and system access rules based on real users, usage scale, and cooperation foundation. |
| After Node Network Launch | Node Participation & Computing-Power Configuration | Ecosystem projects may underwrite node identity, configure effective computing power, and connect to query and settlement systems under formal rules.              |

*Figure 13-1 | Node Identity and Computing-Power Network Planning Formula*

| **Parameter**                  | **Rule**                                                                                                                                                                                               |
| ------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Total Node Identities          | Planned total of 3,000; used to carry protocol identity and effective computing power after the node network formally starts.                                                                          |
| Per-Node Computing-Power Range | Planned range 100–5,000 effective computing power; specific configuration takes effect when the node network is formally launched.                                                                     |
| Computing-Power Value Baseline | Planned baseline of 1 USDT corresponding to 1 computing power; early share subscription amounts are not directly equal to activated computing power.                                                   |
| Network Initial Daily Output   | Initial daily computation baseline after formal node network launch is 72,000 units; corresponding assets and settlement units follow then-formal rules.                                               |
| Individual Output Formula      | Individual effective computing power ÷ network effective computing power × daily network output baseline.                                                                                              |
| Halving Cycle                  | Planned adjustment every four years; subject to execution rules formally published with the node network.                                                                                              |
| Purchase Entry                 | Early stage opens only ecosystem share subscription; nodes and computing power will be opened through ecosystem project systems after ecosystem maturity; the protocol website does not sell directly. |

Share subscription is not equivalent to nodes, computing power, or SWC. After the node network is formally launched, all effective computing power participating in computation must be bound to node identity; ecosystem projects synchronize orders, users, nodes, and computing-power records; the protocol verifies via signatures, snapshots, and query systems.

## Protocol Participation Credential

The protocol participation credential is a verifiable access tool established for on-chain ecosystem cooperation. Both ecosystem projects and ordinary users may hold it via wallet. The credential itself does not directly generate yield; it is primarily used for ecosystem project eligibility verification and protocol access.

| **Attribute**                   | **Description**                                                                                |
| ------------------------------- | ---------------------------------------------------------------------------------------------- |
| On-Chain Holding                | Credential is recorded in the wallet authorized by the user or ecosystem project.              |
| Open Purchase                   | Both ecosystem projects and ordinary users may purchase via the protocol website wallet entry. |
| Eligibility Verification        | Ecosystem projects that support the credential may read and verify it in smart contracts.      |
| No Direct Output                | Credential does not automatically grant node output, fixed allocation, or protocol revenue.    |
| Independent of Ecosystem Tokens | Credential is not equivalent to any token issued by an independent ecosystem project.          |

| **Holder**         | **Primary Use**                                                                                       | **Permission Boundary**                                                                   |
| ------------------ | ----------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| Ordinary Users     | Enter independent ecosystem projects that support the credential and verify participation eligibility | Cannot call restricted strategy or settlement interfaces solely by holding the credential |
| Ecosystem Projects | Complete ecosystem access, project contract verification, and authorized protocol capability calls    | Must complete cooperation authorization, interface configuration, and permission review   |

## Why Open Ecosystem Cooperation

Protected execution and the strategy network can establish early protocol revenue, but any single chain, single strategy, single team, and single order flow has capacity limits. The purpose of open ecosystem cooperation is to convert technical advantages into more real usage, user relationships, brand entry points, data assets, and global network effects.

| **Growth Constraint** | **Limits of a Single Technical Team**                                      | **Expansion from Open Ecosystems**                                        |
| --------------------- | -------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| Strategy Capacity     | Opportunities limited by chain, capital, market, and competition intensity | Expand usage scenarios via multi-project, multi-chain, multi-strategy     |
| Users & Brand         | Execution teams usually lack continuous user relationships                 | Ecosystem projects form independent user systems and market reach         |
| Data Scale            | Limited data coverage of a single order flow                               | Multiple ecosystems continuously increase trade, execution, and user data |
| Product Boundary      | Pure execution revenue hard to cover more commercial needs                 | Export interfaces, credentials, nodes, settlement, and data products      |
| Global Replication    | Protocol party hard to operate the same model in every region              | Independent ecosystems complete localized products and communities        |

Ecosystem cooperation serves the scaling of the technical protocol: first establish verifiable protection and execution capabilities, then embed those capabilities into more wallets, applications, user systems, and regional markets through cooperation.

## New Sandwich Official Ecosystem Cooperation Modes

Official New Sandwich ecosystem cooperation means that independent ecosystem projects, without changing their own entity, brand, product, users, or economic model, access the protocol’s strategy execution, node computing power, protocol participation credentials, data query, and ecosystem settlement capabilities through standardized entry points. Ecosystem cooperation serves the scaling of the technical protocol; the protocol core remains sandwich-attack protection, user transaction protection, and verifiable execution.

**Unified definition: New Sandwich provides underlying protocol capabilities and access rules; ecosystem projects independently bear entity, brand, product, users, tokens, community, and market operations. The two parties establish a cooperation relationship via protocol interfaces, node computing power, or on-chain credentials.**

*Figure 16-1 | New Sandwich Official Ecosystem Cooperation Modes and Dual-Track Access Structure*

### 15.1 Official Cooperation Principles

| **Principle**          | **Formal Definition**                                                                                                                                           |
| ---------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Technology as Core     | Ecosystem cooperation is built on verifiable sandwich-attack protection, user transaction protection, strategy execution, data, and settlement capabilities.    |
| Dual-Track Access      | According to the user architecture of ecosystem projects, provide account-type node participation and on-chain protocol participation credentials as two modes. |
| Ecosystem Independence | Ecosystem projects own independent entities, controllers, brands, tokens, user systems, communities, and market strategies.                                     |
| Protocol Unification   | Nodes, computing power, credentials, output, interface permissions, and settlement are uniformly recorded and verified by protocol rules.                       |
| Separation of Duties   | Protocol party provides underlying capabilities; ecosystem projects are responsible for their own sales, products, user service, and market operations.         |

### 15.2 Two Official Modes Compared

| **Dimension**        | **Account-Type Ecosystem Cooperation \| Node Participation / Share Subscription**                                                                                           | **On-Chain Ecosystem Cooperation \| Protocol Participation Credential**                                                       |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- |
| Primary Audience     | Ecosystem projects with email, phone, or account systems and market operation capability                                                                                    | Ecosystem projects operating via wallets, smart contracts, and on-chain communities                                           |
| Access Basis         | Early ecosystem: subscribe shares according to USDT committed; after node network launch, may enter node participation and computing-power configuration under formal rules | Project or ordinary users purchase and hold protocol participation credentials                                                |
| User Identity        | Ecosystem account, email, or phone number                                                                                                                                   | Wallet address                                                                                                                |
| Purchase Entry       | Share subscription completed by ecosystem project; node and computing-power sales not open before node network formal launch                                                | Protocol website opens wallet purchase, holding, and credential query                                                         |
| Website Functions    | Early stage records ecosystem cooperation and subscription info; after node network launch, provides corresponding query capability under formal rules                      | Purchase, hold, query credentials and connect to credential-supporting ecosystem projects                                     |
| Output & Eligibility | Early stage records participation quotas by subscription amount; after node network launch, confirms nodes, computing power, and related rights under formal rules          | Credential itself does not directly produce output; used for ecosystem project eligibility verification and authorized access |
| Economic Model       | Independently designed and operated by the ecosystem project                                                                                                                | Independently designed and operated by the ecosystem project via smart contracts                                              |

### 15.3 Account-Type Ecosystem Cooperation: Node Participation / Share Subscription

Account-type ecosystem cooperation applies to ecosystem projects with independent account systems, market organization, and user-service capability. In the early ecosystem stage, projects subscribe to ecosystem shares according to actual USDT committed, and complete subscription management, user service, and market operations within their own systems. After the ecosystem prospers and the node and computing-power network is formally launched, projects may enter the node participation and computing-power configuration stage under then-published rules.

#### Operating Flow

{% stepper %}
{% step %}

### Confirm subscription and cooperation terms

Ecosystem project and New Sandwich confirm ecosystem share subscription scale, committed amount, cooperation scope, system interfaces, and settlement rules.
{% endstep %}

{% step %}

### Subscribe to ecosystem shares

While the node network is not yet launched, the ecosystem project directly subscribes to ecosystem shares according to actual USDT committed; the protocol records corresponding participation quotas and cooperation rights.
{% endstep %}

{% step %}

### Synchronize records through authorized interfaces

Ecosystem project synchronizes accounts, orders, subscription amounts, and share records via authorized interfaces, and completes user service and market operations within its own system.
{% endstep %}

{% step %}

### Establish the basis for future cooperation

Early subscription shares do not directly produce nodes, computing power, or protocol ecosystem tokens; related records serve as the basis for ecosystem cooperation, subsequent rule connection, and rights confirmation.
{% endstep %}

{% step %}

### Connect subsequent rights under published rules

After the ecosystem prospers and the node and computing-power network is formally launched, the protocol determines share mapping, node participation, computing-power configuration, and query methods under then-published rules.
{% endstep %}

{% step %}

### Build independent ecosystem operations

Ecosystem project builds independent user systems, economic models, and market operation mechanisms around protocol capabilities and its own products.
{% endstep %}
{% endstepper %}

#### Duties and Boundaries

| **Party**                     | **Core Duties**                                                                                                                                              | **Clear Boundaries**                                                                                         |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------ |
| New Sandwich                  | Ecosystem share registration, cooperation rules, node and computing-power network planning, data verification, protocol settlement, and technical interfaces | Does not directly sell nodes or computing power in early stage; does not manage ecosystem project user teams |
| Ecosystem Project             | Share subscription, account system, order and user service, product design, market operations, and own economic model                                        | Independently bears product and operational responsibility to users                                          |
| Ecosystem Participating Users | Participate in share subscription via ecosystem project system; after node network launch, connect related rights under formal rules                         | Early subscription is not equivalent to nodes, computing power, protocol ecosystem tokens, or fixed yields   |

### 15.4 On-Chain Ecosystem Cooperation: Protocol Participation Credential

On-chain ecosystem cooperation applies to independent projects operating via wallets, smart contracts, and on-chain communities. Protocol participation credentials are held by wallets and used to record ecosystem access, project participation, and eligibility verification. The credential itself does not directly generate yield and does not automatically grant node output or protocol allocation.

#### Operating Flow

{% stepper %}
{% step %}

### Connect to the credential entry

Ecosystem project or ordinary user connects to the New Sandwich protocol participation credential entry with a wallet.
{% endstep %}

{% step %}

### Purchase or hold the credential

User purchases or holds the protocol participation credential; credential is recorded in the authorized wallet.
{% endstep %}

{% step %}

### Enter a supporting ecosystem project

User enters an independent ecosystem project that supports the credential; the project contract reads and verifies the credential.
{% endstep %}

{% step %}

### Access project-defined participation rights

Ecosystem project opens product functions, community eligibility, on-chain computing power, or other participation rights under its own rules.
{% endstep %}

{% step %}

### Call restricted protocol services

Ecosystem projects that have completed cooperation authorization call strategy, data, or settlement services via restricted interfaces.
{% endstep %}
{% endstepper %}

#### Credential Positioning and Permission Boundaries

| **Participant**    | **Primary Use of Credential**                                                                            | **Permission Boundary**                                                                                              |
| ------------------ | -------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Ordinary Users     | Hold credential and enter supporting independent ecosystem projects to complete eligibility verification | Cannot call restricted strategy, fund, or settlement interfaces solely by holding the credential                     |
| Ecosystem Projects | Complete project access, contract verification, and authorized protocol capability calls                 | Must complete cooperation authorization, interface configuration, permission review, and technical testing           |
| New Sandwich       | Provide credential purchase, on-chain recording, verification interfaces, and ecosystem navigation       | Does not establish referral relationships, team hierarchies, or centralized user architecture for credential holders |

#### Independence Principle

**Protocol and Ecosystem Boundary**

Every ecosystem project owns an independent entity, controller, brand, tokens, user organization, and economic model. New Sandwich provides underlying technology, output rules, credential verification, data, and settlement capabilities, and does not define any single ecosystem project’s rewards, team systems, or market strategies as foundational protocol rules.

## Business Model and Revenue Allocation

Protocol commercial revenue first comes from protected execution, the strategy network, and technical services, and is supplemented by protocol participation credentials, open interfaces, data, and ecosystem settlement. Early-stage share subscription supports cooperation expansion and infrastructure building; node and computing-power services will be incorporated into the commercial system after the ecosystem matures and related networks are formally launched. Different revenue streams use different accounting methods.

| **Revenue Type**                          | **Primary Mode**                                                                                                                                                 | **Primary Customers**                            |
| ----------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------ |
| Protected Execution Services              | Protected RPC, SDK, route optimization, user value protection, and technical service fees                                                                        | Wallets, DEXes, apps, institutions               |
| Strategy Network Services                 | Strategy invocation, execution, liquidation, user-safe back-run execution, and technical share                                                                   | Strategy teams, ecosystem projects, institutions |
| Share Subscription & Future Node Services | Early ecosystem share subscription; after ecosystem maturity, open node identity, computing-power configuration, query, and system interfaces under formal rules | Account-type ecosystem projects                  |
| Protocol Participation Credentials        | Credential purchase, verification, ecosystem access, and contract calls                                                                                          | On-chain ecosystem projects, ordinary users      |
| Open Interfaces & Data                    | API, SDK, Data API, Webhook, white-label, and custom data                                                                                                        | Wallets, platforms, developers, institutions     |
| Ecosystem Settlement Services             | Project access, cooperation settlement, budgets, and periodic accounts                                                                                           | Ecosystem projects and regional partners         |

### 16.1 Allocable Liquidation Revenue of the Strategy Network

After the strategy network completes on-chain settlement and deducts Gas, execution costs, and necessary cooperation fees, the period’s net allocable liquidation revenue is formed. This portion is executed as 20% Foundation, 40% Protocol Ecosystem Value Management, and 40% New Sandwich Ecosystem Pool. Before SWC is formally launched, the Protocol Ecosystem Value Management portion serves as a dedicated reserve for ecosystem development and the future asset system; after the ecosystem prospers and SWC is formally launched, its specific uses will follow then-published asset rules. Share subscription, protocol participation credentials, interfaces, and enterprise service revenue are accounted for separately under corresponding products and cooperation agreements.

*Figure 17-1 | 20 / 40 / 40 Structure of Strategy Network Net Allocable Liquidation Revenue*

## Governance and Roadmap

This chapter focuses on the governance structure for core protocol technology, strategy permissions, ecosystem shares, future node and computing-power network, protocol participation credentials, ecosystem pool budget, SWC planning, and upgrade processes.

### 17.1 Governance Structure

In the early protocol development stage, key parameters are managed by the Foundation, the core technical team, and a multi-sig governance committee. User protection policies, routing adaptation, ecosystem shares, protocol participation credentials, ecosystem pool budget, strategy permissions, and protocol upgrades adopt layered governance; node totals, computing-power formulas, and SWC-related rules will form formal schemes at the corresponding development stages. As the strategy network, nodes, and ecosystem projects grow, matters suitable for public decision-making gradually enter community and ecosystem governance.

### 17.2 Product and Ecosystem Roadmap

*Figure 18-1 | Product Roadmap Prioritizing Technical Capability, Then Ecosystem Scale*

| **Stage**             | **Core Objective**                                                                                                        | **Key Deliverables**                                                                |
| --------------------- | ------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| Protocol Core         | Complete protected trades, risk scoring, simulation, routing, and execution receipts                                      | Protected RPC / SDK, simulation service, private routing, Dashboard                 |
| Strategy Network      | Open authorized back-run execution, arbitrage, liquidation, and protection strategies that do not harm user trade results | Strategy adapters, sandbox, settlement, reputation, and permission system           |
| Multi-Chain Expansion | Deploy execution adapters according to chain-level order flow and block-building structure                                | Multi-chain state, Builder/Sequencer adaptation, cross-chain data model             |
| Ecosystem Scale       | Open node participation, protocol participation credentials, interfaces, and regional ecosystems                          | Dual-track cooperation, developer portal, ecosystem directory, and periodic reports |

## Core Metrics, Glossary, and Technical References

### 17.1 North Star Metric

**New Sandwich’s North Star metric is: the verifiable net execution value the protocol creates for protected order flow. This value is composed of fill improvement, avoided losses, user returns, strategy net contribution, and verifiable coverage.**

| **Metric Category**         | **Core Metrics**                                                                                                                                               |
| --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Protection Effect           | High-risk trade protection coverage, benchmark fill improvement, abnormal slippage reduction, user returns                                                     |
| On-Chain Intelligence       | Covered chains and data sources, state latency, risk identification accuracy                                                                                   |
| Simulation & Execution      | Simulation volume, deviation, execution success rate, Gas efficiency, fallback and circuit-breaker rates                                                       |
| Strategy Network            | Active strategies, external strategy access, stability, net contribution, and reputation distribution                                                          |
| Verifiability               | Complete execution receipt ratio, original-link coverage, cost attribution completeness                                                                        |
| Business & Ecosystem        | Protected trade volume, strategy net liquidation revenue, interface calls, ecosystem project retention and regional coverage                                   |
| Shares, Nodes & Credentials | Early share subscription, credential holding and ecosystem verification; after node network launch: effective nodes, network computing power, and distribution |

### 17.2 Key Terms

| **Term**                          | **Definition**                                                                                                                        |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| MEV                               | Maximal Extractable Value — additional value that can be extracted during block production and transaction ordering.                  |
| Sandwich Attack                   | An attacker inserts transactions before and after a target trade to capture the price change caused by the target trade.              |
| Searcher                          | A professional participant who monitors on-chain state and submits arbitrage, liquidation, protection, or other automated strategies. |
| Builder / Relay                   | Infrastructure roles that receive Bundles, build blocks, and forward them.                                                            |
| Backrun                           | A strategy executed after a target trade to capture the state change caused by that trade.                                            |
| Protected Orderflow               | Transaction flow that is not broadcast directly to the public mempool and is processed under privacy and execution constraints.       |
| Strategy Adapter                  | Standard input, output, permission, and settlement interface used when external strategies connect to the protocol.                   |
| Protocol Participation Credential | On-chain credential held by wallet, used for ecosystem access and eligibility verification.                                           |


---

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