# Sentinel Protocol (哨兵协议) Technical Whitepaper

## **1. Abstract**
Sentinel Protocol proposes a digital asset protection framework based on "sovereignty origin + recursive fragmentation." By reducing adoption barriers through **AI privacy proxy**, locking sovereignty execution root through **TEE hardware**, and combining **multi-level SSS algorithms** to enable perpetual asset succession. The core innovation lies in the dual-track guarantee of **smart contract dead man switch** and **statutory trust storage mechanism**, ensuring that after a commercial entity ceases service, the open-source community can take over access rights, and encrypted data remains physically preserved and decryptable over long historical periods.

---

## **2. Core Architecture: Four-Layer Defense System**

### **2.1 AI Accessibility Layer**
* **Functional Assistant**: Encapsulates advanced prompts into preset plugins, providing natural language interaction entry points.
* **Privacy Proxy**:
    * **Local Interception**: Executes sensitive keyword filtering on the client side, ensuring private key fragments or personally identifiable information **never** leave the local environment.
    * **De-identified Forwarding**: Relay proxy removes metadata such as IP addresses and device IDs, allowing third-party AI vendors to receive only anonymized pure instructions.
* **Local Semantic Summary**: Client-side AI locally summarizes assets, only prompting users to enter hardening process when valuable targets are discovered.

### **2.2 Hardware Sovereignty Layer**
* **Master Key (K)**: Derived from mnemonic phrases, locked within the phone's **TEE (Trusted Execution Environment)**. We don't trust software systems, only mathematics locked in chip architectures.
* **Inner Hardening**: Data completes the first-layer hardware-level inner encryption using $K$ before leaving the device.

### **2.3 Sentinel Vault Layer**
* **Outer Hardening**: Server clusters perform secondary public key encryption on ciphertext to defend against transmission risks.
* **Perpetual Storage**: Double-encrypted ciphertext is custodied on decentralized permanent networks such as Arweave.

### **2.4 Third-Party API Integration Layer**
* **Mode A: Standalone Sovereignty**: Third-party applications work with **independent mnemonics**. Sentinel Protocol serves solely as storage medium and algorithm suite, with completely isolated logic.
* **Mode B: Collaborative SDK**: Third-party applications integrate **Sentinel encryption SDK**. After user biometric authorization, collaborative sharing of master authorization data breaks down data silos.

---

## **3. Role Definitions and Key Derivation System**

The system follows strict derivation logic from "mathematical meta-seed" to "physical shards":
* **Mnemonic**: System's **root seed**, the sole mathematical origin of all keys.
* **Master Key (K)**: Locked within TEE chip, serving as the daily sovereignty execution root.
* **S0 (Redundancy)**: Redundancy backup shard. Saved offline by users (physical printout/USB drive) as final recourse.
* **S1 (Cloud)**: Distributed recursive shard, custodied by cloud nodes.
* **S2 (Heir)**: Heir shard. Distributed by user to designated estate handlers.

---

## **4. S1 Distributed Recursive Fragmentation (Multi-Server Fragmentation)**

To completely eliminate centralized node data breach and collusion risks, $S_1$ adopts a "divide and conquer" strategy:

### **4.1 Secondary Fragmentation Logic**
After the mobile device generates $S_1$, instead of uploading it directly, it is fragmented again through the SSS algorithm into $n$ sub-shards ($n \ge 2$): $\{S_{1a}, S_{1b} \dots S_{1n}\}$.

### **4.2 Node Encryption and Storage**
* **Independent Encryption**: Each sub-shard is encrypted using the independent public key of its corresponding storage node.
* **Distributed Storage**: Sub-shards are distributed to multiple geographically isolated and logically independent sentinel server nodes.
* **Security Characteristics**: No single server possesses complete $S_1$. Hackers breaching a single database only obtain "fragments of fragments."

---

## **5. Business Logic Workflow**

### **5.1 Data Ingestion Flow**
1. **Identification and Confirmation**: Local AI discovers information, obtaining user biometric authorization.
2. **Double Encryption**: TEE invokes $K$ to complete inner hardening $\rightarrow$ Server executes outer hardening.
3. **Recursive Distribution**: $S_1$ is fragmented into multiple sub-shards, then encrypted and sent to different geographic nodes.

### **5.2 Succession and Recovery Flow**
1. **Status Determination**: Smart contract detects incapacity signal.
2. **Shard Aggregation**: Multiple nodes verify contract instructions, decrypt and release their respective sub-shards.
3. **Multi-level Reconstruction**:
    * **First-level Reconstruction**: Sub-shards reconstruct the original cloud shard $S_1$.
    * **Second-level Reconstruction**: $S_1$ combined with heir-held $S_2$ (or redundancy shard $S_0$) synthesizes Master Key (K).
4. **Asset Decryption**: Using $K$ to peel off inner encryption and retrieve original assets.

---

## **6. Survival Guarantee and Security Summary**

### **6.1 Survival Guarantee (The Great Survival Protocol)**
* **Statutory Trust and Renewal**: Dedicated trust fund independent from commercial entities, ensuring physical validity of storage fees over long historical periods.
* **Dead Man Switch**: Once the commercial entity becomes incapacitated, smart contracts automatically release ciphertext indexes and node private keys, with open-source community taking over access.
* **Open-Source Self-Rescue**: Users can leverage open-source tools, combined with mnemonic phrases or $S_2/S_0$, to locally restore $K$; even if official services disappear, data can be recovered.

### **6.2 Security Highlights**
* **Anti-Database Breach (Anti-DB Leak)**: Cloud-side $S_1$ exists in fragmented state; single-point compromise is meaningless.
* **Privacy Sovereignty**: Privacy Proxy physically isolates AI-side profiling risks.
* **Uniqueness and Robustness**: $K$ locked in TEE, and system can reconstruct data even when some nodes go offline.

---