Architecture Overview

Veriproof’s enterprise architecture is designed around a single principle: cryptographic proof without data exposure. Your AI session payloads never have to transit Veriproof’s infrastructure to produce a blockchain-backed audit trail.

The Commitment Model

Every session ingested by Veriproof is reduced to a single 32-byte SHA-256 commitment hash before any external communication. In Enterprise Hybrid mode, this hash is the only data that leaves your network. The hash is:

Cryptographically one-way: the hash cannot be reversed to recover the original content
Deterministic: the same session always produces the same hash (enabling independent verification)
Unique: hash collisions are computationally infeasible

The hash is included in a Merkle tree, anchored as a Solana transaction, and the Solana transaction signature is returned to your infrastructure as the verifiable proof.

Deployment Mode Architecture

SaaS Mode

All session data — encrypted payloads, metadata, and commitment hashes — is stored and processed in the Veriproof cloud. The Customer Portal is hosted at my.veriproof.app. Retention, compliance scoring, and blockchain anchoring are fully managed.


Your AI App → Veriproof Ingest API → Veriproof Cloud Storage
                                   → Blockchain Worker → Solana
                                   → Customer Portal (my.veriproof.app)

This is the default mode. No infrastructure changes are required.

Enterprise Hybrid Mode

Session data is stored exclusively in your infrastructure. The SDK writes directly to your PostgreSQL database and your Azure Key Vault. Only the 32-byte commitment hash is sent to the Veriproof Enterprise Commitment API for anchoring.


Your AI App → Veriproof SDK (EnterpriseHybrid)
                 ├─→ Your PostgreSQL DB (full session data)
                 ├─→ Your Azure Key Vault (encryption keys)
                 └─→ Veriproof Commitment API (32-byte hash only)
                          └─→ Blockchain Worker → Solana

Your Staff → Self-Hosted Customer Portal → Your PostgreSQL DB

What Veriproof receives: Only the 32-byte hash and a session timestamp. No content, no PII, no metadata.

Local First Mode

Identical to Enterprise Hybrid in terms of data placement, but blockchain anchoring requires a manual or scheduled synchronization step. Designed for environments with intermittent internet connectivity.


Your AI App → Veriproof SDK (LocalFirst)
                 ├─→ Your PostgreSQL DB
                 └─→ Sync Queue (local)

[On connectivity] Sync Worker → Veriproof Commitment API → Solana

Disconnected Mode

Purely local storage with no outbound communication to Veriproof. Evidence packages can be exported and submitted to a verifier manually. Suitable for classified or air-gapped environments.


Your AI App → Veriproof SDK (Disconnected)
                 └─→ Your PostgreSQL DB

[Manual] Export → Verifier

Infrastructure Components (Hybrid Mode)

Component	Hosted by	Description
SDK ingest library	Your application	.NET / Python / TypeScript library for session recording
PostgreSQL database	Your infrastructure	Stores all session data, metadata, and audit entries
Azure Key Vault	Your Azure tenant	Stores pepper keys, data subject encryption salts
Self-hosted portal	Your infrastructure	The Customer Portal frontend + API Function App
Veriproof Commitment API	Veriproof cloud	Receives hashes, batches them, anchors to Solana
Solana blockchain	Decentralized	Immutable anchor for commitment Merkle trees

Network Requirements (Enterprise Hybrid)

Outbound connectivity is required only from the Veriproof SDK (or a designated sync service) to:

Endpoint	Port	Protocol	Purpose
`api.veriproof.app`	443	HTTPS	Commitment API
`mainnet.helius-rpc.com` (or your RPC node)	443	HTTPS	Solana RPC for verification

No inbound connectivity to your infrastructure is required. The Veriproof platform never initiates connections into your network.

In environments where direct internet access from application servers is restricted, deploy a lightweight sync service on a DMZ host. The sync service receives hashes over your internal network and forwards them to api.veriproof.app on port 443.

Deployment Context & Setup Security

Self-hosted portals must determine whether they are configured or in a fresh-install state. Veriproof uses a three-layer fail-safe mechanism:

Static deployment config (deployment-config.json) — a cryptographically signed file shipped with the frontend assets. If the API is unreachable, this file authoritatively indicates whether setup is complete, preventing setup wizards from reappearing during outages.
Database flag — an immutable is_setup_complete flag in the portal database. Once set to true, it cannot be reverted via the API.
Runtime API (GET /v1/deployment/context) — provides real-time validation and any additional configuration needed by the frontend.

This layered approach means an API outage during a production incident never causes the portal to present a setup wizard that could be exploited for unauthorized re-initialization.

See the Configuration guide for details on generating the signed deployment configuration file.