Substantive changes to the manifest spec, the verification path, and the platform around it. Minor fixes live in the git history.
The Ed25519 private key that signs every BitSeal manifest now lives in AWS KMS (us-east-1) and never exists as plaintext bytes outside an HSM-backed boundary. The verifier tolerates the rotation: pre-migration seals continue to verify via the historical_keys fallback published in the well-known endpoint. SDK 0.3.3 ships the matching client-side fallback so any third-party verifier handles the rotation correctly too.
kms:Sign with SigningAlgorithm=ED25519_SHA_512 replaces node:crypto sign(). Vercel runtime IAM user scoped to kms:Sign + kms:GetPublicKey on the one key ARN only.
Old key retired to historical_keys with effective_until=2026-05-29. Pre-rotation seals (including the original test seal a7a6360...d6e9) keep verifying without any user action.
verify_manifest_signature now iterates current_key + each historical_keys entry from /.well-known/bitseal-authority-key.json. Returned key_id tells you which entry matched.
BITSEAL_SIGNING_BACKEND env var defaults to KMS but can be flipped back to local PEM mode for emergency rollback. AWS Budgets alarm at $4/$5 covers any cost surprise.
Following a top-to-bottom cryptographic audit, the seal manifest format was rebuilt so the Ed25519 signature covers the SHA3-512 of every byte of the manifest (key sort, no whitespace, no JSON floats) rather than just the root hash and timestamp. Closes the audit findings that flagged unsigned metadata as the only remaining trust gap before HSM custody. v1 seals on the ledger continue to verify via seal_mode dispatch.
Frozen at github.com/OrygnsCode/BitSeal/blob/main/spec/v2-manifest.md with cross-language byte vectors and tamper test cases. SDK and server agree byte-for-byte.
The /api/legal/ceremony-attestation signature now binds to a SHA-256 of a deterministic fact-sheet (authority identity, fingerprint, spec versions, URLs) — tampering with the published ceremony page is detectable.
Archive-the-proof downloads the .ots in the standard DetachedTimestampFile envelope. Download updated certificate regenerates the PDF with the Bitcoin-anchored proof attached after upgrade.
/.well-known/bitseal-authority-key.json (schema_version=4) publishes both v1 and v2 signing_format + manifest_specs arrays. /legal/key-ceremony renders the canonical content fact-sheet verbatim.
Up from 50 MB across server, browser sealer, SDK, and docs. Browser sealing is reliable to about 500 MB; the BitSeal SDK is the recommended path for anything larger or for automation.
Every new seal is stamped to four public OpenTimestamps calendars at sealing time. A daily sweep upgrades pending proofs once Bitcoin confirms the commitment, and the BitSeal SDK ships a --ots flag so anyone can re-check the anchor against mempool.space without trusting Orygn.
SHA-256 of each seal's signature is submitted to four public calendars at seal time.
Pending proofs upgrade automatically once any calendar's commitment lands in a Bitcoin block, typically within 1 to 6 hours.
/verify renders block height, block time, and a mempool.space deep-link once the seal's anchor is upgraded.
verify.py --ots parses the upgraded proof locally and compares the committed merkle root against the real block header via mempool.space.
First public release of the BitSeal platform. Client-side hashing, three-axis verification, and signed manifests, wired through a public ledger.
Browser-only BLAKE3 over 64 KiB chunks, files never leave the device.
Signed seal record rendered to a downloadable PDF on request.
GET /api/verify returns the three-axis verdict over any root hash.
Seals persist to a public ledger; verify reads from the same store.
Closed alpha validating the Merkle construction and signing payload against the BitSeal SDK. Format frozen at merkle-blake3-64k-v1.
64 KiB leaves, BLAKE3 internal nodes, odd-layer-duplicate rule.
40 bytes, root || LE_f64(timestamp), over Ed25519.