Custody & Handoff

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.

At the moment of delivery, the user takes on the following responsibilities:

Storage

The user is responsible for storing the bundle in a manner appropriate to its sensitivity and the user's retention requirements. Recommended practice:

• Store the bundle on encrypted storage (full-disk encryption or per-file encryption)
• Maintain at least one backup copy at a different physical location or in offline storage
• Verify the bundle's integrity periodically using the included verify.sh script

Access control

The 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.

Retention

The user determines the retention period. Common considerations:

• IRS retention requirements (typically 3–7 years for supporting documentation; longer for fixed assets and certain other items)
• State and local regulatory requirements
• Industry-specific compliance frameworks
• Contractual obligations to investors, lenders, or counterparties
• Anticipated litigation, audit, or due-diligence horizons

Disposal

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.

Custody chain documentation (optional but recommended)

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.

SALT bundles are delivered under a dual-layer encryption model. The model is designed to give the user confidentiality without giving Sealed Ledger any key material.

The two layers

Inner layer — plaintext seal

The standard SALT seal on the unencrypted snapshot.db file. This is the seal documented throughout the rest of the SALT documentation: SHA-256 of the database, signed by an external Time Stamp Authority via RFC 3161, recorded inside the database's _seal table. This layer attests to the integrity of the data itself, and survives any number of encryption/decryption cycles.

Outer layer — ciphertext seal

After the bundle is encrypted, Sealed Ledger computes the SHA-256 of the encrypted file and obtains a separate TSA timestamp over that hash. This is delivered alongside the encrypted bundle as outer-manifest.json. The outer seal lets a recipient confirm the encrypted blob is the one Sealed Ledger delivered, without needing to decrypt.

Together, the two layers cover both "this is the encrypted file you were given" and "this is the data inside it" — verifiable at different stages of handling.

The encryption procedure

1. The user supplies a passphrase at delivery time. They choose either a strong password (16+ characters with mixed case, numbers, symbols) or a passphrase (4+ words, the xkcd-style approach).
2. Sealed Ledger encrypts the bundle file using the user's choice of openssl or age. Both produce standards-based ciphertext that any recipient can decrypt with the passphrase and standard tools.
3. The passphrase is used in-memory for the encryption operation and immediately discarded. It is never written to disk, never logged, and never transmitted off the user's session.
4. Sealed Ledger computes the SHA-256 of the encrypted file and obtains a TSA timestamp over that hash.
5. The encrypted bundle and the outer manifest are delivered to the user.

What Sealed Ledger holds after encryption

• The user's passphrase: never. Used once, in memory, then gone.
• The encrypted bundle: only during the active engagement window, then deleted per the standard retention policy.
• The plaintext bundle: only during the active engagement window, then deleted.
• Any recovery mechanism: none. There is no escrow key, no backup passphrase, no master decryption capability. If the user loses the passphrase, the archive cannot be recovered by anyone, including Sealed Ledger.

The absence of a recovery mechanism is deliberate. A backdoor would convert Sealed Ledger from a non-custodial vendor into a custodian of every client's accounting records, with significant legal exposure (subpoena response, breach notification, regulatory expansion) and a degraded trust posture. The non-custodial model is preserved by the strict discipline of holding no keys.

The user's responsibility

Because no recovery is possible:

• The user must store the passphrase securely. A password manager (1Password, Bitwarden, etc.) is the recommended approach.
• The user should consider sharing the passphrase out-of-band with a trusted second party (an attorney, business partner, or designated successor) for engagement-record continuity.
• For engagements with multiple stakeholders (e.g., the company plus its outside CPA), Sealed Ledger can deliver the same encrypted bundle with the same passphrase to each party, or — for higher-stakes contexts — encrypt separate copies under separate passphrases.

Optional: skip encryption

For engagements where the user prefers to manage encryption themselves (or where the bundle is being delivered into an already-encrypted environment), Sealed Ledger can skip the outer encryption layer. In that case the user receives the bundle with only the inner seal, identical to the SALT bundles documented elsewhere. The choice is recorded in the engagement record.

For engagements where the standard non-custodial model is not appropriate, alternative arrangements can be made on a case-by-case basis:

Direct delivery to a third-party custodian

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.

Multi-party delivery

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.

Extended Sealed Ledger custody

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.