Under the Hood — DocSats Technical Architecture | AES-256, Bitcoin Ordinals, IPFS

🖥️ AI Infrastructure

Local inference — your plaintext never touches a third-party API

ModelLlama 3.1 70B

RuntimeOllama

HardwareMac Mini M4 Pro · 64GB Unified RAM

NetworkIsolated during inference

PersistenceNone — plaintext exists only in RAM

Unlike every other AI-powered legal platform, DocSats runs its own large language model on dedicated hardware. Your Will's content is never sent to OpenAI, Anthropic, Google, or any cloud AI provider. The plaintext of your document exists only in server memory during generation and is never written to disk.

# Our AI server — no cloud APIs involved
$ ollama run llama3.1:70b

# The model runs entirely on local hardware
# Inference happens in-memory on Apple Silicon
# No network calls to external services
# Plaintext is garbage-collected after response
            

🔒 Encryption Protocol

Military-grade encryption that happens in your browser — before any data leaves your device

AlgorithmAES-256-GCM

Key Length256-bit symmetric

IV Length96-bit random per encryption

Auth Tag128-bit GCM integrity tag

Key GenerationWeb Crypto API · crypto.getRandomValues()

Key LocationBrowser only — never transmitted

AES-256-GCM (Galois/Counter Mode) provides both confidentiality and authenticity. The GCM authentication tag ensures that any tampering with the ciphertext is immediately detectable upon decryption. Keys are generated using the browser's cryptographically secure random number generator and never leave the client.

// Step 1: Generate a 256-bit encryption key in the browser
const key = await crypto.subtle.generateKey(
  { name: 'AES-GCM', length: 256 },
  true,
  ['encrypt', 'decrypt']
);

// Step 2: Generate a unique 96-bit initialization vector
const iv = crypto.getRandomValues(new Uint8Array(12));

// Step 3: Encrypt — this runs entirely in the browser
const ciphertext = await crypto.subtle.encrypt(
  { name: 'AES-GCM', iv },
  key,
  new TextEncoder().encode(willDocument)
);

// Step 4: Export key for beneficiary backup (optional)
const exportedKey = await crypto.subtle.exportKey('raw', key);

// Only ciphertext + IV are uploaded
// Key stays in your browser — we NEVER receive it
const payload = {
  ciphertext: bufferToBase64(ciphertext),
  iv: bufferToBase64(iv),
  // key is NOT included — that's the whole point
};
await uploadToIPFS(payload);
            

🌐 Storage Architecture

Content-addressed, decentralized, and tamper-evident

NetworkIPFS (InterPlanetary File System)

PinningPinata

AddressingCID (Content Identifier) — SHA-256 hash

RedundancyMulti-node global pinning

Content StoredEncrypted ciphertext only

IPFS uses content-addressing instead of location-addressing. Every file is identified by a cryptographic hash of its contents (a CID). This means: if anyone modifies even a single byte, the CID changes — making tampering immediately detectable. Documents are replicated across global nodes, so no single server failure can destroy them.

// Traditional storage (LegalZoom, Trust & Will):
"https://legalzoom.com/storage/user123/will.pdf"
//   ↳ Location-based — company controls it
//   ↳ Can be deleted, altered, or breached
//   ↳ Single point of failure
//   ↳ Company shutdown = documents lost

// DocSats on IPFS:
"ipfs://QmX7b3a9d4e2f186c7..."
//   ↳ Content-addressed — CID IS the fingerprint
//   ↳ Change 1 byte → completely different CID
//   ↳ Replicated across nodes globally
//   ↳ No single company can delete or alter it
//   ↳ Survives independently of DocSats
            

₿ Blockchain Layer

Immutable proof-of-existence on the world's most secure ledger

NetworkBitcoin Mainnet

MethodOrdinals Inscription

IntegrationUniSat API

Data InscribedProof object (NOT your Will)

VerificationAny Bitcoin full node

We inscribe a small JSON proof object — not your Will itself — onto the Bitcoin blockchain using Ordinals. This proof contains a hash of your encrypted document, the IPFS CID where it's stored, and a timestamp. Anyone can independently verify that your Will existed at a specific point in time and has not been modified since.

// What gets permanently inscribed on Bitcoin
{
  "protocol":      "docsats-will-proof",
  "version":       "1.0",
  "document_hash": "sha256:a3f2b8c9e1d4f6...",
  "ipfs_cid":      "QmX7b3a9d4e2f186c7...",
  "timestamp":     "2026-03-26T05:00:00Z",
  "encryption":    "AES-256-GCM",
  "key_hash":      "sha256:7f1c3d..."
}

// This permanently proves:
// ✓ Your Will existed at this exact moment
// ✓ The document has not been modified since
// ✓ Anyone with a Bitcoin node can verify this
// ✓ No authority can remove or alter the record
//
// This does NOT reveal:
// ✗ The contents of your Will
// ✗ Your identity
// ✗ Your beneficiaries
            

🔑 Dead Man's Switch Protocol

Automated key release — no courts, no lawyers, no delays

Check-inConfigurable: weekly / bi-weekly / monthly

ChannelsEmail + SMS dual verification

Grace PeriodConfigurable (default: 30 days)

Key DistributionEncrypted fragments to beneficiaries

False Positive ProtectionMultiple missed check-ins required

The Dead Man's Switch periodically verifies that the Will creator is still active. After a configurable number of missed check-ins and a grace period, the system automatically distributes encrypted key material to designated beneficiaries, giving them the ability to decrypt and access the Will without requiring probate, lawyers, or court proceedings.

🏗️ Application Stack

Modern, auditable infrastructure

FrontendNext.js 14 · React · Tailwind

HostingVercel Edge Network

AuthClerk

DatabaseSupabase (PostgreSQL)

AILlama 3.1 70B via Ollama (local)

StoragePinata (IPFS)

BlockchainUniSat (Bitcoin Ordinals)

PaymentsStripe

EmailKit (ConvertKit)

The database stores only encrypted references and metadata — never plaintext document content. Authentication is handled by Clerk, which provides zero-knowledge session management. All sensitive operations (encryption, key generation) happen client-side in the browser.

🛡️ Threat Model

What we protect against — and how

DocSats is designed with a zero-trust architecture. Even if every component except the user's browser is compromised, document confidentiality is maintained.

Server breach — Attackers obtain only encrypted ciphertext, computationally infeasible to decrypt without the 256-bit key
Insider threat — DocSats engineers cannot decrypt documents; encryption keys exist only in the user's browser
Legal compulsion — We cannot produce plaintext even under subpoena; we do not possess the technical capability
Platform shutdown — IPFS storage and Bitcoin records persist independently; users always have local PDF + key backups
Document tampering — Bitcoin inscription creates an immutable hash; any modification is detectable by comparing hashes
AI data leakage — Local AI processing means no third-party service ever sees plaintext; model runs on isolated hardware
Single point of failure — Documents exist across three independent layers: local PDF, IPFS network, Bitcoin blockchain

Under the Hood:
Technical Architecture

On This Page

🖥️ AI Infrastructure

🔒 Encryption Protocol

🌐 Storage Architecture

₿ Blockchain Layer

🔑 Dead Man's Switch Protocol

🏗️ Application Stack

🛡️ Threat Model

Convinced? Create your Will in 20 minutes.

Under the Hood:Technical Architecture

On This Page

🖥️ AI Infrastructure

🔒 Encryption Protocol

🌐 Storage Architecture

₿ Blockchain Layer

🔑 Dead Man's Switch Protocol

🏗️ Application Stack

🛡️ Threat Model

Convinced? Create your Will in 20 minutes.

Under the Hood:
Technical Architecture