SALT™ (Sealed Accounting Ledger Technology) is how Sealed Ledger seals your accounting records — cryptographically tamper-evident, independently verifiable, time-stamped by an external authority. No proprietary tool required to verify, decades from now.
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 bundle's components have specific seal roles. snapshot.db carries the captured data, per-row provenance hashes, and self-documentation (per-table descriptions in _schema_doc, per-column source attributions in _field_provenance, and the verbatim canonical schema DDL in _schema.canonical_ddl). manifest.json carries the .db's SHA-256, the seal algorithm, and the RFC 3161 timestamp token from the Time Stamp Authority. The seal cannot live inside the database, because the TSA signs the database's SHA-256 as a single unit — writing the token, or the .db's own hash, into the database would change that hash and break the very signature it represents. Everything seal-related therefore lives in manifest.json, alongside the .db it signs.
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.manifest.json at captureSeal.tsa.tokenBase64, alongside the TSA's identity and the timestamp it certified.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).
manifest.jsonThe seal lives entirely in manifest.json at the bundle root. Nothing seal-related lives inside snapshot.db — the TSA signs the SHA-256 of snapshot.db as a single unit, so writing the seal (its hash, the TSA token, or any other seal value) into the database would change its hash and break the very signature it represents.
The full seal record at captureSeal looks like this:
{
"captureSeal": {
"db": { "sha256": "...", "byteLength": ..., "schemaVersion": "sealedledger-sqlite-2.0", ... },
"bundleMerkleRoot": "...",
"sealAlgorithm": "salt-v1-single-leaf",
"tsa": {
"tsaName": "FreeTSA",
"tsaTime": "2026-05-09T07:15:45Z",
"tokenBase64": "MIIH3wYJKoZIhvcN...",
"durationMs": 279
}
}
}
The TSA token in tokenBase64 is the RFC 3161 TimeStampResp signing the database's SHA-256. Verifiers extract it from there.
What lives inside the database is the captured data itself, the per-row provenance hashes, the structural integrity-check results, and three self-documentation features that travel inside the sealed perimeter: _schema_doc (per-table narrative descriptions), _field_provenance (per-column source attribution), and _schema.canonical_ddl (the verbatim DDL the materializer ran). A reviewer opening the .db decades from now can reconstruct what each table and column is for without any external documentation — the documentation is part of what the TSA signed.
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
cd qbosnapshot-*-bundle
sha256sum snapshot.db
# Compare against manifest.json's recorded hash:
# captureSeal.db.sha256
# 2. Extract the TSA token from manifest.json
python3 -c "import json; print(json.load(open('manifest.json'))['captureSeal']['tsa']['tokenBase64'])" \
| base64 -d > token.tsr
# 3. Verify the TSA token against the database's hash
DBHASH=$(sha256sum snapshot.db | cut -d' ' -f1)
openssl ts -verify \
-digest "$DBHASH" \
-in token.tsr \
-CAfile freetsa-cacert.pem
# 4. Inspect embedded integrity checks
sqlite3 snapshot.db "SELECT * FROM _integrity_checks WHERE status != 'pass'"
If all checks pass, the archive's integrity is confirmed. If any fail, the failure point identifies what was tampered with — corrupted file, broken seal, or invalid timestamp. Every bundle ships with verify.sh and verify.js scripts that perform the same checks automatically; the manual procedure above is for reviewers who prefer to inspect each step.
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.