SALT-sealed archives are delivered to the user. The user is the custodian. Sealed Ledger's role ends at delivery — by design.
Sealed Ledger uses a non-custodial delivery model. At the conclusion of a SALT capture, the sealed archive is delivered to the user. The user becomes the sole long-term custodian. Sealed Ledger does not retain copies, does not provide recovery, and does not maintain an archive of past captures.
This is a deliberate design choice. It removes Sealed Ledger from a long list of risks the user does not benefit from us bearing: data breaches against our storage, subpoenas seeking client records we no longer hold, retention obligations across jurisdictions, recovery requests we cannot honor, and service-continuity concerns that would otherwise impact the user's records.
From an audit perspective, the non-custodial model also matches how auditors expect evidence custody to work. When an auditor requests a record, they request it from the audited entity, not from the entity's tooling vendor. The archive lives where the auditor expects to find it.
_integrity_checks.manifest.json at captureSeal.tsa.tokenBase64. (It cannot be written into the database itself — the TSA signs the database's SHA-256, so embedding the token in the database would change that hash and break the signature.)During an active engagement, Sealed Ledger holds the archive in working storage for the purpose of analysis, plan generation, and review. This temporary working copy is:
After the engagement concludes, Sealed Ledger:
At the moment of delivery, the user takes on the following responsibilities:
The user is responsible for storing the bundle in a manner appropriate to its sensitivity and the user's retention requirements. Recommended practice:
verify.sh scriptThe user determines who has access to the archive. The bundle contains complete accounting records; treat it as you would any source-of-truth financial dataset.
The user determines the retention period. Common considerations:
When the user determines an archive is no longer needed, secure disposal is the user's responsibility. Cryptographic erasure (deleting the encryption key on encrypted storage) is acceptable; physical destruction of the storage medium is acceptable. Casual deletion may leave forensically recoverable copies.
For records that may face evidentiary challenge, the user should maintain a custody log: who received the archive, who has accessed it, when it was moved between systems, and any transformations applied. SALT's seal proves the bundle is unchanged; the custody log proves who handled it.
To be unambiguous about scope:
The list above is a feature, not a limitation. It is what allows Sealed Ledger to make narrow, defensible claims about what the seal proves.
The SALT seal addresses integrity, not confidentiality. Whether a bundle is encrypted at delivery depends on which capture path produced it.
QuickBooks Desktop capture runs locally, on the user's own machine, via sealedledger.exe. The tool writes its bundle as an encrypted .enc file using AES-256-GCM under a per-bundle key that Sealed Ledger generates and holds in its bundle registry. The key is released to the user, after which it is deleted from the registry and Sealed Ledger retains no means of decrypting that bundle.
Until release, Sealed Ledger holds the key. This is disclosed plainly because it is the one point in the workflow where the non-custodial model does not hold: during that window, Sealed Ledger possesses key material for a bundle sitting on the user's machine. The window is bounded by key release, and the registry records the deletion time.
Sealed Ledger's tools accept .enc bundles directly — the verifier, restore, and reporting endpoints decrypt in memory using the key on file and never write plaintext to disk.
QuickBooks Online capture runs on Sealed Ledger's server and delivers a plaintext .zip. There is no delivery-layer encryption on this path. The transport is authenticated and TLS-protected; the bundle itself is not encrypted at rest once the user has it.
In both cases, confidentiality of the delivered bundle is the user's responsibility. A SALT bundle contains complete accounting records, including identifiable customer, vendor, and employee data. Users should store bundles on encrypted storage and control access accordingly — see User responsibilities above.
Users who require encrypted delivery of a QuickBooks Online bundle, or an encryption scheme under their own key material, should raise it before capture so it can be arranged as part of the engagement.
For engagements where the standard non-custodial model is not appropriate, alternative arrangements can be made on a case-by-case basis:
For litigation holds, M&A escrows, or audit-firm custody requirements, the bundle can be delivered directly to a designated third-party recipient (an attorney, escrow agent, or audit firm). The user authorizes the alternate recipient in writing prior to capture.
Bundles can be delivered to multiple recipients simultaneously (e.g., the company and its outside CPA). Each recipient receives an identical copy; bundles are byte-for-byte identical and verifiable against each other.
If the user requires Sealed Ledger to retain a working copy beyond the standard engagement period, this is contracted explicitly with documented retention term, access controls, and a deletion date. Default retention beyond engagement close is not provided.
Auditors and forensic accountants evaluating an archive will ask a custody question: "Where did this archive come from, who has handled it, and how do I know it hasn't been swapped or modified along the way?"
The non-custodial model gives a clean answer. The bundle was delivered by Sealed Ledger to the user at a specific time. The seal proves the bundle has not been modified since that delivery. The user's custody log (if maintained) describes what happened in between. There is no third party in the middle whose practices need to be evaluated.
From the auditor's perspective: fewer hands on the data, fewer questions to investigate.