Skip to Content
Security & TrustArchitectureSystem Architecture Overview

System Architecture Overview

VeriProof is built on a dual-tier architecture that serves two distinct operational models from a shared infrastructure core. Understanding which tier fits your use case determines your deployment path, data residency characteristics, and operational responsibilities.

Two tiers, one platform

Standard Tier — Multi-Tenant SaaS

The Standard Tier is for organizations that want zero infrastructure responsibility. Your AI application sends session data to VeriProof’s hosted endpoints, and the platform handles everything: storage, governance processing, Merkle batching, and blockchain anchoring.

Customer AI Application
      │  VeriProof SDK
      ▼
Ingest Functions (REST /v1/ingest)
      │
      ├──▶ PostgreSQL — session records + governance data
      │
      └──▶ Notary Outbox ──▶ Blockchain Functions
                                    │
                                    ▼
                            Solana Concurrent Merkle Tree

All data lives in VeriProof’s Azure infrastructure. Tenant isolation is enforced at both the application layer (EF Core global query filters) and the database layer (PostgreSQL Row-Level Security). See Multi-Tenant Isolation for details.

Best for: Most organizations — startups through mid-market, any volume under ~500K sessions/month.

Enterprise Tier — Federated Hub

The Enterprise Tier deploys VeriProof components inside your own Azure subscription. Your data never leaves your environment. Only 32-byte Merkle commitments — not session content — are forwarded to VeriProof’s central infrastructure for blockchain anchoring.

Your Azure Subscription
┌─────────────────────────────────────────────────────┐
│  Your AI Application                                │
│        │  VeriProof SDK                             │
│        ▼                                            │
│  Confidential Notary (AMD SEV-SNP ACI)              │
│        │                       │                    │
│        ▼                       ▼                    │
│  Your PostgreSQL         Azure Blob (WORM)          │
│  (full session data)     (encrypted logs)           │
└────────────────┬────────────────────────────────────┘
                 │ 32-byte commitment only
                 ▼
VeriProof Central Infrastructure
  Blockchain Functions ──▶ Solana CMT

Session content stays in your subscription. VeriProof’s infrastructure only ever receives a 32-byte cryptographic commitment derived from each batch — the minimum needed to anchor the Merkle root on-chain.

Best for: Financial services, healthcare, and defense organizations with strict data sovereignty requirements; volumes over 500K sessions/month.

Core components

Ingest Functions

The Ingest Functions service is the receiving endpoint for all session data. It:

  • Validates the API key and tenant identity
  • Accepts OTLP trace payloads from the SDK
  • Verifies the Merkle root submitted with each batch
  • Writes session records to PostgreSQL
  • Enqueues records to the Notary outbox for anchoring

Both /v1/ingest/otlp (single session) and /v1/ingest/otlp/batch (multiple sessions) are handled here.

Blockchain Functions

The Blockchain Functions service runs as a background worker that:

  • Picks up records from the Notary outbox
  • Batches Merkle roots from multiple sessions into a single Concurrent Merkle Tree update
  • Submits the batch to Solana
  • Records the resulting transaction ID and block number against each session

This service runs continuously. Anchoring typically completes within 30 seconds of ingest.

Customer Portal

The Customer Portal is a React 19 / Vite application served from Azure Static Web Apps. It provides:

  • AI session search, filtering, and detail views (Time Machine)
  • Governance dashboard and compliance center
  • Alert rule configuration
  • API key management
  • Evidence export

The portal communicates exclusively with the Customer Portal Functions API, which enforces JWT authentication and per-tenant data isolation.

Staff Portal

The Staff Portal provides VeriProof’s internal operations team with cross-tenant visibility for support and platform operations. It uses a separate database role (staff_role) that bypasses PostgreSQL RLS — every action is audit-logged. Staff portal access is restricted to VeriProof employees with verified identity.

Request flow: ingest to anchor

  1. Your application calls the SDK (session.complete() or framework adapter span flush)
  2. The SDK batches pending spans, computes a Merkle root over the batch, and POSTs to /v1/ingest/otlp
  3. Ingest Functions validates the API key, verifies the submitted Merkle root matches the payload, and writes records to PostgreSQL
  4. A trigger enqueues the batch to the Notary outbox
  5. Blockchain Functions picks up the outbox entry, groups it with other recent batches, and submits a CMT transaction to Solana
  6. Once the Solana transaction confirms, the session records are updated with anchored_at, transaction_id, and block
  7. The session’s anchor status updates to ✅ in the Customer Portal

Provider-agnostic design

The ingest pipeline uses abstract interfaces for attestation, storage, and metering. Azure-specific implementations (Azure MAA, Azure Blob WORM, Azure Marketplace metering) are loaded at runtime via dependency injection. This design allows future expansion to AWS Nitro Enclaves and GCP Confidential Space without changes to the core pipeline logic.

Next steps

Last updated on
OverviewData Flow & Isolation