The methodology behind every Sealed Ledger archive: cryptographically tamper-evident, independently verifiable, time-stamped by an external authority. No proprietary tool required to verify.
Accounting records are only defensible if you can later prove they were not altered. Conventional backups answer "what's in the file." A SALT-sealed archive answers something stronger: "this is the data captured at this moment, and any change to it since would be detectable by anyone, using only standard cryptographic tools."
SALT verifies not only cryptographic integrity, but also structural accounting consistency — debits equal credits, transaction indexes reconcile, foreign-key references resolve. The result is a single archive that is simultaneously tamper-evident and internally validated.
SALT achieves this with three properties:
Every captured record is hashed individually. The complete archive is hashed once. Any modification to any byte invalidates the seal mathematically — there is no "partially valid" state.
The archive's hash is signed by an external Time Stamp Authority using RFC 3161, the international standard for trusted timestamping. The timestamp proves the archive existed in its captured form on or before a specific date, signed by a third party Sealed Ledger does not control.
Anyone with the archive can verify it using standard, freely available software (SHA-256 implementations, OpenSSL). No Sealed Ledger software, account, or service is required to confirm the seal. The verification process is transparent and replicable.
SALT is the technology behind every Sealed Ledger engagement deliverable. The same methodology applies whether the source data came from QuickBooks Online, QuickBooks Desktop, or another accounting system.
Trust models matter. SALT is precise about what it proves so that the proof remains defensible under scrutiny.
This precision is what makes SALT defensible. A claim that overreaches — "this proves the books are authentic" — collapses under cross-examination. A claim that's narrowly true — "this proves the captured data is unchanged since this timestamp" — survives it.
A SALT-sealed archive is a ZIP container holding the following files:
archive.zip
├── snapshot.db — SQLite 3 database (the captured data)
├── manifest.json — file inventory with per-file SHA-256 hashes
├── LIMITATIONS.txt — human-readable disclosure of what the archive
│ does and does not cover
└── freetsa-cacert.pem — public certificate of the Time Stamp Authority,
bundled for offline verification
The complete schema is published openly as part of SALT's verification model.
The container itself is unsigned. The seal lives inside snapshot.db, in a dedicated _seal table. This means the seal travels with the data even if the bundle is unzipped, repackaged, or partially extracted.
SALT uses SHA-256 (FIPS 180-4) at multiple layers:
Every row of every captured table includes four provenance columns:
_source_system — identifies the originating platform (e.g., qbo, qbd)_source_record_hash — SHA-256 of the canonicalized record from the source API_raw_json — the original source-system payload, preserved verbatim_raw_json_sha256 — SHA-256 of _raw_jsonThis means tampering can be localized: if any single row is altered, that row's hash mismatches the recomputed hash of its _raw_json, immediately identifying which record was changed.
The complete snapshot.db file is hashed as a single unit. This hash is recorded in the bundle's manifest.json and is the value that the Time Stamp Authority signs.
RFC 3161 is the IETF standard for trusted time-stamping, widely used in legal, financial, and forensic contexts. The protocol works as follows:
snapshot.db._seal table along with the TSA's identity.Sealed Ledger's default Time Stamp Authority is FreeTSA (https://freetsa.org), a publicly available service. The TSA's public certificate is bundled with every archive so verification can be performed offline. Because the signed token and the TSA certificate are embedded in the archive, future verification does not depend on the continued availability of the TSA service itself — only on the cryptographic signature chain, which remains valid indefinitely.
For engagements with stricter institutional requirements, SALT supports alternative TSAs without changing the bundle format or verification procedure. Commercial authorities (DigiCert, GlobalSign, Sectigo) and internal corporate PKIs that issue RFC 3161 tokens can be used in place of the default. The choice of TSA is recorded in the seal and is part of what a reviewer evaluates.
The time-stamp token cryptographically binds this specific archive to this specific moment. To forge it would require both modifying the archive (detectable via the seal) and forging the TSA's signature (computationally infeasible without the TSA's private key).
_seal tableInside snapshot.db, the seal record contains:
seal_algorithm = 'sha256-single-leaf' ir_archive_hash = (provenance reference) legacy_sha256 = (provenance reference) bundle_merkle_root = SHA-256 of the bundle's hash tree tsa_timestamp_token = base64-encoded RFC 3161 token tsa_timestamp_at = ISO-8601 timestamp from the TSA tsa_authority = TSA identifier (e.g. 'FreeTSA')
Beyond cryptographic sealing, the archive runs structural integrity checks at capture time and persists results in a dedicated _integrity_checks table. These include:
_raw_json_sha256 values match recomputed hashesIf any check fails at the blocking severity level, the archive is flagged. A reviewer opening the archive can immediately see whether the data has internal consistency problems independent of any seal verification.
Independent verification of a SALT-sealed archive uses only standard tools. A reviewer with no Sealed Ledger software can:
# 1. Verify the bundle's file hashes unzip archive.zip sha256sum snapshot.db # Compare against manifest.json's recorded hash # 2. Verify the embedded TSA timestamp sqlite3 snapshot.db "SELECT tsa_timestamp_token FROM _seal" \ | base64 -d > token.tsr openssl ts -verify \ -digest <snapshot.db sha256> \ -in token.tsr \ -CAfile freetsa-cacert.pem # 3. Inspect embedded integrity checks sqlite3 snapshot.db "SELECT * FROM _integrity_checks WHERE status != 'pass'"
If all three steps pass, the archive's integrity is confirmed. If any fails, the failure point identifies what was tampered with — corrupted file, broken seal, or invalid timestamp.
Before transitioning to a new accounting platform, a SALT-sealed archive of the source system preserves the historical record permanently. The new platform starts clean; the history doesn't depend on the source system, the source vendor, or any continuing subscription.
SALT-sealed archives serve as defensible evidence in audits, due diligence, and forensic accounting. The chain of custody is cryptographic, the timestamp is third-party, and the verification process is transparent enough to satisfy outside reviewers.
When a company is acquired, divested, or restructured, financial records must be preserved in a form that survives organizational change. A SALT seal proves the financial state at a specific moment without depending on the continued operation of the source system.
For organizations with multi-year recordkeeping obligations (IRS retention, regulatory archives, grant compliance), SALT archives provide documentary evidence that records have not been modified since the engagement period.
In adversarial situations — partner disputes, divorce, fraud allegations — a SALT seal applied at a known moment establishes a baseline. Anything changed in the live books afterward becomes provably distinct from the sealed record.
Most accounting backup solutions optimize for restoration: getting your data back into a working system. SALT optimizes for integrity: preserving a defensible record of what existed when.
The difference shows up at the moment a record is challenged. A conventional backup says "here's what we have." A SALT-sealed archive says "here is what existed at this exact moment, signed by an external authority, and any modification would be cryptographically detectable by anyone."
SALT is what we deliver at the conclusion of every Sealed Ledger engagement. The seal is not a feature add-on — it is the deliverable. Everything else is either preparation for the seal or work performed alongside it.