Blockchain Anchoring

Every compliance record captured by VeriProof is cryptographically anchored to the Solana blockchain. This creates an independent, verifiable proof that a governance record existed and has not been altered — a proof that remains valid even if VeriProof’s own infrastructure were unavailable.

Why blockchain for compliance records?

Traditional compliance systems have a foundational problem: the same organization that produces an AI decision also controls the system that stores the audit trail. A sufficiently motivated actor can alter records after the fact, and no amount of database auditing can completely distinguish between “this record was always like this” and “this record was changed.”

VeriProof solves this with a hash commitment to an external, immutable ledger. Once a Merkle root is written to the Solana blockchain, altering any compliance record would change its hash, invalidate the Merkle root, and produce a mismatch with the on-chain value — detectable independently by any auditor.

This is not a claim about making AI governance blockchain-native. It is a simpler, more practical guarantee: your records can be verified by a third party without trusting VeriProof.

How it works

Merkle hashing at ingest

When the SDK sends a batch of compliance records to the Ingest API, it computes a SHA-256 Merkle root over all records in the batch before sending. The server independently computes the same root and validates the match — any tampering in transit is detected immediately.

Batch of n records
  record[0] → SHA-256 → leaf hash[0] ─┐
  record[1] → SHA-256 → leaf hash[1]  │
  ...                                  ├→ SHA-256 Merkle root
  record[n] → SHA-256 → leaf hash[n] ─┘

Batching and anchoring

Individual records are not anchored one-by-one. Anchoring every record separately would cost $0.000035 × n — economical, but slower. Instead, VeriProof batches records through a notary outbox:

1. Validated records accumulate in the notary outbox after ingest.
2. A background worker reads the outbox on a configurable schedule (production default: every 30 seconds).
3. All leaf hashes from the batch are combined into a single Merkle root.
4. That Merkle root is written as a single leaf to a Solana Concurrent Merkle Tree (CMT).
5. The resulting Solana transaction signature is stored alongside each record in the batch.

This means one $0.000035 transaction on Solana covers every record in a 30-second window, regardless of how many records arrived in that window.

Solana Concurrent Merkle Trees (CMT)

VeriProof uses Solana’s state compression  technology — specifically Concurrent Merkle Trees — as the anchoring substrate. CMTs are a Solana-native feature designed for high-throughput leaf insertions.

VeriProof’s CMT configuration:

When a tree reaches 1,048,576 leaves, VeriProof automatically allocates a new tree. Each new session anchoring links back to the correct tree by the tree’s Solana account address, which is stored alongside the session record.

Verifying a record independently

To verify that a compliance record has not been altered, an auditor needs:

1. The compliance record — exported from VeriProof in JSON format.
2. The Merkle proof path — a list of sibling hashes from the record’s leaf up to the CMT root.
3. The Solana account address of the CMT tree.
4. A Solana RPC endpoint — public mainnet RPC endpoints are freely available.

from veriproof_sdk import compute_merkle_root_hex, verify_proof
 
# Step 1: Recompute the leaf hash from the exported record
record_json = '{"session_id": "loan_001", "decision": "approve", ...}'
leaf_hash = sha256(record_json.encode()).hexdigest()
 
# Step 2: Reconstruct the Merkle root from the proof path
# (proof_path comes from the VeriProof evidence export)
root = compute_merkle_root_hex([leaf_hash] + proof_path)
 
# Step 3: Compare against the value stored on-chain in the Solana CMT
# If root == on_chain_root, the record is authentic and unmodified

The Customer Portal’s Evidence Export feature produces a bundle containing the JSON record, proof path, and Solana account address pre-packaged for this verification flow. Auditors do not need any VeriProof account to perform the verification — only the exported bundle and a Solana RPC endpoint.

Enterprise Federated anchoring

In an Enterprise Federated deployment, VeriProof can optionally write to a customer-owned Solana account instead of the shared VeriProof account. This means:

• Your organization controls the on-chain state for your compliance records.
• Even if VeriProof were to cease operations, your records remain anchored under your account.
• The Solana account key is held in your Azure Key Vault, never shared with VeriProof.

Contact your account team to configure federated anchoring.

Blockchain status in the portal

Every session in the Customer Portal displays a Blockchain Status indicator:

Anchoring typically completes within 60 seconds of session ingest in production. Sandbox sessions are not anchored (status shows “Sandbox — no anchor”).

Network and cost details

VeriProof anchors to Solana mainnet-beta. The Solana network provides:

• Finality: Blocks finalize in ~400ms; records are fully anchored within seconds.
• Uptime: Solana mainnet has maintained >99.9% availability over the last 12 months.
• Independence: Solana is a permissionless blockchain — no VeriProof dependency for verification.

There is no per-session blockchain cost billed to your VeriProof plan. CMT allocation costs are absorbed in VeriProof’s infrastructure costs.

FAQ

What if Solana is unavailable during anchoring?

The notary worker retries failed anchoring attempts with exponential backoff. Records are not lost — they remain in the outbox until anchoring succeeds. If Solana is unavailable for an extended period, VeriProof operations continue normally; anchoring resumes automatically when the network recovers.

Is the compliance record content stored on Solana?

No. Only the Merkle root hash is stored on-chain. The full record content remains in VeriProof’s managed database. On-chain storage of record content would be both extremely expensive (Solana charges per byte of account storage) and unnecessary for audit purposes.

Can regulators access Solana directly?

Yes. Solana is a public blockchain. Any auditor, regulator, or third party can query the CMT’s on-chain state using any Solana RPC endpoint without any VeriProof account or permission.

Next steps

• API Authentication — how API keys authenticate sessions to the correct tenant
• Multi-Tenant Isolation — how your records are isolated from other tenants
• Evidence Export Guide — package compliance records for an audit