Skip to main content

​
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 SeesWhat Backend CANNOT See
Policy IDDecryption key
IPFS CIDContent (encrypted)
Wallet addressesFile names
TimestampsMessage 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
Browser security is your responsibility:
  • Keep browser updated
  • Be cautious of extensions
  • Verify HTTPS connection

​
The Smart Contract

The Shield contract enforces access control: 
// 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

Lost Link?

We cannot recover it. The key was only in that URL.

Forgot Recipient?

We cannot tell you who you sent it to. Only the policy ID is stored.

Wrong Address?

We cannot change the recipient. The contract is immutable.

Expired Early?

We cannot extend expiration. Timestamps are on-chain.
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

ServiceTrust 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

# 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

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.