> ## Documentation Index
> Fetch the complete documentation index at: https://docs.shieldhq.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Trust Model

> Understanding what you need to trust when using SHIELD

# Trust Model

Understanding what you're trusting is essential for secure communication. This document explains SHIELD's trust assumptions and security guarantees.

## The Core Promise

> **SHIELD cannot read your content. Even if we wanted to, even if compelled, we cannot decrypt what you share.**

This is the fundamental difference between SHIELD and centralized services like email, Dropbox, or Google Drive.

## What You DON'T Trust

### The SHIELD Backend

| What Backend Sees | What Backend CANNOT See |
| ----------------- | ----------------------- |
| Policy ID         | Decryption key          |
| IPFS CID          | Content (encrypted)     |
| Wallet addresses  | File names              |
| Timestamps        | Message text            |
| Access counts     |                         |

The backend stores metadata only—never the means to decrypt.

### IPFS/Pinata

IPFS nodes store encrypted blobs:

* ✅ Can see **encrypted data**
* ❌ Cannot see **decryption key**
* ❌ Cannot see **original content**
* ❌ Cannot **corrupt** data (CID verification)

### The Blockchain

The Base blockchain stores access policies:

* ✅ Can see **policy rules** (who, when, how many)
* ❌ Cannot see **content**
* ❌ Cannot see **IPFS CID** (not stored on-chain)
* ❌ Cannot **bypass** rules (immutable contracts)

## What You DO Trust

### Your Browser

The browser is your trusted execution environment:

* **Encryption** happens in Web Crypto API
* **Decryption** happens in your browser
* **Key handling** never leaves memory
* **No extension** can read the URL fragment

<Warning>
  Browser security is your responsibility:

  * Keep browser updated
  * Be cautious of extensions
  * Verify HTTPS connection
</Warning>

### The Smart Contract

The Shield contract enforces access control:

```solidity theme={null}
// These rules are immutable and transparent
require(msg.sender == policy.recipient, "Unauthorized");
require(block.timestamp < policy.expiry, "Expired");
require(policy.attempts < policy.maxAttempts, "Max reached");
```

* ✅ Contract code is **verifiable** on BaseScan
* ✅ Rules are **immutable** once deployed
* ✅ Execution is **transparent** and auditable
* ❌ Cannot be changed by SHIELD team

### Your Wallet

Your wallet holds the keys to your identity:

* **Sender**: Signs policy creation transactions
* **Recipient**: Proves ownership via SIWE
* **Private keys**: Never leave your wallet

## The "SHIELD Can't Help" Guarantee

<CardGroup cols={2}>
  <Card title="Lost Link?" icon="link-slash">
    We cannot recover it. The key was only in that URL.
  </Card>

  <Card title="Forgot Recipient?" icon="user-x">
    We cannot tell you who you sent it to. Only the policy ID is stored.
  </Card>

  <Card title="Wrong Address?" icon="triangle-exclamation">
    We cannot change the recipient. The contract is immutable.
  </Card>

  <Card title="Expired Early?" icon="clock">
    We cannot extend expiration. Timestamps are on-chain.
  </Card>
</CardGroup>

This isn't a limitation—it's the **feature** that makes SHIELD trustless.

## Threat Scenarios

### Scenario 1: SHIELD Servers Hacked

**Impact**: Minimal

* Attacker gets policy metadata
* Attacker cannot decrypt content without keys
* Attacker cannot modify contracts

### Scenario 2: SHIELD Team Malicious

**Impact**: Limited

* Team could shut down API (access via contract still works)
* Team cannot read past content
* Team cannot create fake policies

### Scenario 3: IPFS Node Compromised

**Impact**: None

* Encrypted blobs are useless without keys
* Content integrity verified by CID

### Scenario 4: Blockchain Reorg

**Impact**: Temporary

* Access logs might change temporarily
* Policies remain valid
* Content remains accessible

### Scenario 5: Sender's Machine Compromised

**Impact**: High

* Attacker could intercept before encryption
* This is the sender's responsibility to prevent

### Scenario 6: Recipient's Machine Compromised

**Impact**: Content exposed

* Attacker sees decrypted content after access
* Use reasonable device security

## Comparison: Trust Required

| Service       | Trust Server with Content? | Trust Server with Keys? | Immutable Policy? |
| ------------- | -------------------------- | ----------------------- | ----------------- |
| Email (Gmail) | ✅ Yes                      | ✅ Yes                   | ❌ No              |
| Dropbox       | ✅ Yes                      | ✅ Yes                   | ❌ No              |
| iMessage      | ⚠️ Metadata                | ✅ Yes                   | ❌ No              |
| Signal        | ⚠️ Metadata only           | ❌ No                    | ❌ No              |
| **SHIELD**    | ❌ **No**                   | ❌ **No**                | ✅ **Yes**         |

## Verifying Trustlessness

You can verify these claims yourself:

### 1. Check the Contract

```bash theme={null}
# View contract on BaseScan
https://basescan.org/address/0x4b8F46e5E3d95D78f30F80F1280fE7e5F92c8ce8
```

### 2. Inspect Network Traffic

Open DevTools → Network tab:

* You'll see encrypted blobs going to IPFS
* You'll see policy IDs sent to backend
* You'll **never** see decryption keys in requests

### 3. Review Open Source Code

```bash theme={null}
git clone https://github.com/Babs0022/SHIELD.git
# Verify encryption happens client-side
```

## When Trust is Required

There are still some trust assumptions:

1. **Frontend code**: You trust the code served from shield.app (verifiable via open source)
2. **Wallet software**: You trust MetaMask/Rainbow not to leak keys
3. **Network**: You trust HTTPS/TLS for transport
4. **Smart contract**: You trust the deployed code (auditable)

These are minimal compared to traditional services where you must trust the server with everything.

## Summary

> **SHIELD's trust model is: Trust your browser, trust the blockchain, trust mathematics. Don't trust us.**

This is what makes SHIELD different. We built a system where we *can't* access your data, even if we wanted to.