BitSeal's guarantees come from published cryptography, not from our word. Every seal is verifiable against a public key. Every primitive is standard. The threat model and key governance below describe what we can and cannot attest to.
Every seal is signed with Ed25519. The default v2 manifest format binds the SHA3-512 of the canonical manifest under that signature; legacy v1 binds the 40-byte root || LE_f64(timestamp). Both verify with any conforming Ed25519 library against the published public key.
BLAKE3 drives the 64 KiB Merkle leaves and tree. A whole-file SHA3-512 is recorded alongside as a second, independent digest for long-term archival integrity.
Every manifest is signed before it is written to the ledger. Any alteration, accidental or malicious, invalidates the signature and is detectable by anyone holding the public key.
Files are chunked and hashed in your browser. The bytes never leave your device. The Authority only ever sees the manifest, which is the fingerprint plus metadata.
An attacker with our servers cannot retroactively forge past seals, every historical signature remains verifiable against the published public key. Live signing access via the runtime IAM credential would let an attacker sign arbitrary new manifests for as long as they hold that credential, but cannot exfiltrate the Authority private key itself, which lives inside an AWS KMS HSM and cannot be exported. Rotation procedures are documented in the published key ceremony and rotation policy.
Client-side hashing means the file never crosses the wire. An attacker in the middle sees the manifest (root hash plus metadata), never the bytes. The signature is computed on payloads the client already possesses and can re-verify locally.
A second-preimage attack against BLAKE3 is not considered feasible with current or foreseeable compute. SHA3-512 is recorded in parallel as a structurally independent backstop. Both are standard, widely audited constructions.
The server re-derives the root from the supplied leaves before signing, so a client cannot pin a signature to a root that does not match its own leaves. Verifiers re-fold the stored leaves and compare, so tampering with the leaves relative to the signed root is detected on every verify.
The Authority key is the single root of trust for every BitSeal signature. Its generation, storage, and rotation are governed by two public documents.
How the current Authority key was generated, where it is stored, what we can and cannot attest to, and how to independently verify the published fingerprint.
Scheduled rotation cadence, emergency triggers that force rotation within 72 hours, and how retired keys remain valid for verifying past seals.
Every seal occupies a monotonic position in a Merkle log. The Authority periodically signs a Signed Tree Head (STH) committing to a Merkle root over every seal up to that moment. Each STH's signature is submitted to OpenTimestamps and Bitcoin-anchored within 1 to 24 hours, after which deletion or omission of any committed seal becomes cryptographically detectable against a public Bitcoin block. The genesis STH anchored at Bitcoin block 952212 on 2026-06-03.
The full byte-stable spec is at spec/log-sth.md. Any holder of a seal can request an inclusion proof from /api/log/inclusion, fetch the current STH from /api/log/heads/latest, and verify the chain locally using the helpers in the Python SDK (bitseal.verify_inclusion, bitseal.verify_sth_signature, bitseal.verify_seal_in_log). A 95-line reference verifier in JavaScript with no BitSeal-specific dependencies lives at web/scripts/inclusion-verify-third-party-demo.mjs.
Operational limits, stated plainly. The STH cadence is once per day, so the non-equivocation property binds at the same cadence: any STH that has anchored into a confirmed Bitcoin block cannot be rewritten by anyone, and equivocation outside that window is detectable from a Bitcoin block time alone. Lookup-by-root continues to depend on the BitSeal API being available; if it ever goes down, the cryptography still verifies offline against a retained PDF, manifest, and OTS proof using any standard BLAKE3 + Ed25519 library.
Think you have found a way to forge a seal, bypass verification, compromise the Authority key, or otherwise undermine BitSeal? Tell us before you tell anyone else.
[bitseal-security].Machine-readable version at /.well-known/security.txt per RFC 9116. BitSeal does not currently run a paid bug bounty. Reports are still very welcome and will be credited publicly on this page if you want it.
Researchers who have reported valid vulnerabilities under the disclosure policy above. None yet. If that changes, your name will live here.