Data Flow
This page describes the exact data flows for each deployment mode, including what data is stored where, what traverses network boundaries, and how the cryptographic chain of custody is maintained.
SaaS Mode Data Flow
In SaaS mode, all data is managed by Veriproof:
┌──────────────────────────────────┐
│ Your Application │
│ │
│ SDK records session steps │
│ Session is finalized │
└──────────────┬───────────────────┘
│ Encrypted session payload
│ (AES-256, data-subject key)
▼
┌──────────────────────────────────┐
│ Veriproof Ingest API │
│ POST /v1/ingest/session │
│ │
│ 1. Validates API key │
│ 2. Stores encrypted payload │
│ 3. Stores session metadata │
│ 4. Enqueues for blockchain │
└──────────────┬───────────────────┘
│
┌───────┴───────┐
▼ ▼
┌────────────┐ ┌────────────────────────────┐
│ PostgreSQL │ │ Blockchain Worker │
│ (encrypted │ │ │
│ payloads, │ │ 1. Reads pending sessions │
│ metadata) │ │ 2. Computes SHA-256 hash │
└────────────┘ │ 3. Builds Merkle tree │
│ 4. Submits to Solana │
│ 5. Stores tx signature │
└──────────┬─────────────────┘
│
▼
┌────────────┐
│ Solana │
│ Blockchain │
└────────────┘Enterprise Hybrid Mode Data Flow
In Enterprise Hybrid mode, only hashes cross the boundary into Veriproof’s infrastructure:
┌──────────────────────────────────────────────────────────────┐
│ YOUR INFRASTRUCTURE │
│ │
│ ┌────────────────────────────────┐ │
│ │ Your Application │ │
│ │ + Veriproof SDK (Hybrid) │ │
│ │ │ │
│ │ SDK records session steps │ │
│ │ Encrypts with subject key │ │
│ │ Writes to local DB │ │
│ │ Computes commitment hash │ │
│ └────────────┬───────────────────┘ │
│ │ │
│ ┌───────┴────────┐ │
│ ▼ ▼ │
│ ┌──────────┐ ┌──────────────────┐ │
│ │ Your │ │ Your Azure │ │
│ │ PostgreSQL│ │ Key Vault │ │
│ │ (FULL │ │ (pepper + subject│ │
│ │ session │ │ encryption keys)│ │
│ │ data) │ └──────────────────┘ │
│ └──────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Self-Hosted Customer Portal │ │
│ │ Reads directly from your PostgreSQL DB │ │
│ └──────────────────────────────────────────────────────┘ │
└───────────────────────────────┬──────────────────────────────┘
│
32-byte hash + timestamp ONLY
(Zero PII, zero session content)
│
▼
┌──────────────────────────────────────────────────────────────┐
│ VERIPROOF CLOUD │
│ │
│ POST /v1/enterprise/commitments │
│ │
│ ┌────────────────────────┐ ┌──────────────────────────┐ │
│ │ Enterprise Commitment │ │ Blockchain Worker │ │
│ │ API │ │ │ │
│ │ Stores hash only │──│ Batches pending hashes │ │
│ │ No session content │ │ Builds Merkle tree │ │
│ └────────────────────────┘ │ Anchors to Solana │ │
│ └──────────┬────────────────┘ │
│ │ │
└─────────────────────────────────────────┼────────────────────┘
│
▼
┌────────────┐
│ Solana │
│ Blockchain │
└────────────┘What The Boundary Carries
| Data Type | Crosses to Veriproof? | Notes |
|---|---|---|
| Session payload (encrypted) | ❌ No | Stored in your PostgreSQL only |
| Input / output content | ❌ No | Never leaves your infrastructure |
| Data subject identifiers | ❌ No | Stored in your PostgreSQL only |
| Session metadata (name, tags) | ❌ No | Stored in your PostgreSQL only |
| Encryption keys / salts | ❌ No | In your Azure Key Vault only |
| 32-byte commitment hash | ✅ Yes | This is all Veriproof receives |
| Session timestamp (approximate) | ✅ Yes | Used for Merkle tree ordering |
| Solana transaction signature | ✅ Yes (returned) | Veriproof returns this as proof |
Verification Data Flow
After anchoring, anyone with the session hash and Merkle proof can verify the anchor independently using publicly available Solana data — without any involvement from Veriproof:
Verifier Solana RPC Node
│
│ 1. Have: commitment hash, tx signature, Merkle proof
│
│ 2. Fetch transaction from Solana
│──────────────────────────────────────────────────────►
│◄─────────────────────────────────────────────────────
│ Transaction containing Merkle tree root
│
│ 3. Verify: hash is in Merkle tree
│ Merkle tree root matches on-chain root
│ → VERIFIED: session existed at that timestamp
│
│ (No Veriproof involvement required for verification)The Public Verification endpoint at POST /v1/public/verify provides a convenience API for this verification step. You may also verify directly against Solana using the Merkle proof included in the commitment receipt.
Encryption Key Hierarchy (Enterprise Hybrid)
┌─────────────────────────────────────────────────────────────────┐
│ Customer Azure Key Vault │
│ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Pepper Key (HKDF master secret) │ │
│ │ - 256-bit random key │ │
│ │ - Customer-owned, never transmitted to Veriproof │ │
│ └──────────────────────────────┬──────────────────────────┘ │
│ │ │
│ HKDF-Expand(pepper, dataSubjectId) │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Per-Subject Salt │ │
│ │ - Derived per data subject from pepper │ │
│ │ - Stored in your PostgreSQL data_subjects table │ │
│ └──────────────────────────────┬──────────────────────────┘ │
│ │ │
│ AES-256-GCM(salt, session_payload) │
│ │ │
│ ▼ │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ Encrypted Session Blob │ │
│ │ - Stored in your PostgreSQL or Azure Blob │ │
│ │ - Cryptographically unreadable without the salt │ │
│ └─────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────────┘GDPR erasure in hybrid mode destroys the per-subject salt in your Key Vault. Once the salt is gone, all encrypted session payloads for that data subject become permanently unreadable — even to you.
Last updated on