BARUCH Receipts: Cryptographic Proof That Compliance Happened

|7 min readCompliance

When an auditor asks "did you screen this transaction for sanctions compliance?", most companies point to a log file. The log says the check happened. But logs can be modified, back-dated, selectively deleted, or fabricated entirely. A log is a claim. A BARUCH receipt is proof.

BARUCH (Blockchain-Anchored Receipt for Unified Compliance History) is Shulam's cryptographic audit trail system. Every compliance check, every trust score calculation, every governance decision on the Shulam network generates a BARUCH receipt — a tamper-evident, hash-chained record that proves the action happened, when it happened, what the inputs were, and what the result was.

How BARUCH Receipts Work

Each BARUCH receipt contains five fields:

  • Action hash: A SHA-256 hash of the compliance action performed (e.g., OFAC screening, trust score calculation, hold decision).
  • Input hash: A hash of the data that was screened or evaluated. For OFAC checks, this includes the counterparty identifier and transaction details. The raw PII is never stored in the receipt — only the hash.
  • Result: The outcome of the check (clear, held, blocked) along with a confidence score and any matching rules that triggered.
  • Timestamp: UTC timestamp with microsecond precision, sourced from an NTP-synchronized clock.
  • Chain hash: A hash of the previous receipt in the chain, plus the current receipt's content. This is what makes the chain tamper-evident.

The chain hash is the critical innovation. Each receipt includes a hash of the previous receipt. This means if anyone modifies, inserts, or deletes a receipt anywhere in the chain, every subsequent chain hash becomes invalid. To tamper with a single receipt, you would need to recompute every chain hash after it — and because Shulam periodically anchors chain hashes to a public blockchain (Ethereum L2), even a full chain recomputation would be detectable because the anchored hashes would not match.

Why BARUCH Receipts Are Not Logs

The distinction matters. Logs and receipts serve different purposes and have fundamentally different trust properties:

PropertyTraditional LogsBARUCH Receipts
Tamper evidenceNone (can be modified in place)Hash-chained (modification breaks the chain)
Ordering guaranteeTimestamp-based (clock can be spoofed)Cryptographic ordering (chain hash enforces sequence)
Deletion detectionNo (gaps are invisible)Yes (missing receipt breaks the chain)
External verificationRequires trusting the log producerAnchored to public blockchain — verifiable by anyone
PII exposureOften contains raw dataOnly hashes — PII never stored in receipts

What Auditors See

When an auditor requests compliance evidence from the Shulam network, they receive a BARUCH chain export: a sequence of receipts covering the requested time period, with chain hashes intact. The auditor can independently verify the chain by recomputing each hash. If every hash matches, the chain is intact — no receipts were modified, inserted, or deleted.

The verification process is automated. Shulam provides an open-source verification tool (MIT license) that auditors can run on their own infrastructure. It takes a chain export file and outputs a pass/fail result with details on any broken links. Median verification time for a 30-day chain of 50,000 receipts: 4.2 seconds.

For auditors accustomed to reviewing server logs and hoping they have not been tampered with, BARUCH receipts are a fundamental upgrade. As one SOC 2 auditor told us: "This is the first time I have been able to mathematically prove that a compliance record is complete and unmodified. I do not have to trust the company — I verify the chain."

How Receipts Connect to Trust Scores

Every trust score calculation generates a BARUCH receipt. This means the trust score itself is auditable — not just the current number, but the entire history of how it was calculated, what inputs were used, and how it changed over time. If an operator disputes a trust score, they can request the receipt chain and verify every calculation independently.

This transparency is a design requirement, not a feature. If agents are going to be governed by trust scores, the scoring process itself must be trustworthy. BARUCH receipts close the loop: agents are scored, scores generate receipts, receipts are verifiable, and the verification is independent of Shulam. No trust-me-bro required.

The Numbers

  • BARUCH receipts generated to date: 2.4 million+
  • Average receipts per day: 28,000
  • Chain integrity verification failures: 0 (zero — the chain has never been broken)
  • Median receipt generation latency: 12ms (receipts are generated inline, not async)
  • Blockchain anchor frequency: Every 6 hours (4 anchors per day to Ethereum L2)
  • Auditor verification tool downloads: 340+

Explore the Compliance Index to see receipt data in real time, or visit the Glossary for a complete reference of compliance terminology.

Verify Compliance, Mathematically

See how BARUCH receipts provide tamper-evident compliance proof for every transaction on the network.

View the Compliance Index