BitSeal

Prove a file existed, at an exact moment in time.

BitSeal hashes your file locally, sends only the manifest, and records an Ed25519-signed Merkle root to a public ledger. Anyone can verify a seal with a BLAKE3 and Ed25519 library, offline, years later.

  • Client-side BLAKE3
  • Ed25519 signed
  • Three-axis verification
How it works

A seal in four steps.

The file is streamed through a hasher and chunked into a Merkle tree in your browser. Only the manifest crosses the wire. The Authority refolds the tree, signs the root, and records the signed manifest to a public ledger.

01 / Hash

Hash locally

The file is streamed in 64 KiB chunks. Each chunk is BLAKE3-hashed. Adjacent digests are folded into a Merkle root that commits to every byte.

BLAKE3 · SHA3-512 · byte entropy
02 / Send

Send the manifest

Leaf hashes, root, whole-file digests, filename, size, and timestamp. No file bytes, no folder paths, no thumbnails.

HTTPS · under 100 KB typical
03 / Sign

Authority signs

The server refolds the tree to confirm the root, then signs root concatenated with the UTC timestamp using Ed25519. The client never signs.

Trust no client
04 / Record

Ledger records

The signed manifest is persisted and is queryable by root. A PDF certificate returns with the Merkle root as the verification handle.

Verify now or years later
Three-axis verification

Every seal is checked three ways, independently.

Collapsing a cryptographic proof into a single green checkmark hides what is actually being asserted. BitSeal separates the three claims, reports each one, and refuses to conflate them.

1 / 3Ledger presence

Was this root ever sealed?

A lookup against the BitSeal ledger confirms that the Authority observed this exact Merkle root at the recorded UTC timestamp.

SELECT * FROM seals WHERE root_hash = ?
2 / 3Ed25519 signature

Did the Authority sign it?

The stored signature is re-verified against the current or any historical public key published at the well-known endpoint.

verify(sig, root || LE_f64(ts), pubkey)
3 / 3Merkle consistency

Do the leaves still hash to the root?

The stored leaves are refolded under merkle-blake3-64k-v1. Any tampering with any leaf changes the recomputed root.

BLAKE3(left || right) -> parent
Data boundary

What stays. What crosses the wire.

The most honest privacy diagram is a list. Here is everything BitSeal receives, and everything it does not.

ON YOUR DEVICE
Never transmitted
  • The file's bytes
  • Folder paths, thumbnails, previews
  • System metadata (owner, created, EXIF)
  • Any private keys you hold

Raw bytes are read, hashed, and discarded in memory. They never enter a network buffer.

ON BITSEAL SERVERS
The manifest, only
  • root_hash, blake3_hash, sha3_512_hash
  • merkle_tree[] (leaf digests in file order)
  • filename, size_bytes, mime_type, entropy
  • timestamp_utc, signer, signature
  • IP and user agent in edge logs (abuse prevention only)

The manifest is self-describing. Given a public key and a BLAKE3 library, a third party can verify it with no BitSeal call.

Who this is for

Closer to a notary than a cloud service.

Not a storage service. Not a blockchain wallet. Not a document signing platform. A cryptographic register for files whose existence needs to be provable later.

Researchers and creators

First-existence timestamps on drafts, datasets, and designs.

Seal the manuscript, the spreadsheet, the render. Months later, prove the version predated a dispute without disclosing its contents.

Journalists and investigators

Preserve source-document integrity at the moment of acquisition.

Any subsequent edit becomes visible the instant a verifier refolds the Merkle root. The file stays with you.

Independent professionals

Self-sovereign proofs without a notary appointment.

Legal, medical, engineering, architectural. A tamper-evident record a counterparty can verify without ever calling BitSeal.

Engineering teams

CI/CD provenance via the open Python SDK.

A CLI seal and a web seal of identical bytes produce byte-identical Merkle roots under the same manifest format.

Independent verification

You do not have to trust BitSeal.

The Authority publishes its public key, algorithm, signing format, and manifest spec at a well-known URL. Historical keys remain listed so retired-key seals stay verifiable. Every cryptographic artifact is reproducible with standard libraries on any platform.

A verifier who has never heard of BitSeal can still reconstruct the root from the file, check the signature against the published key, and compare the two. There is no proprietary curve, no custom encoding, no cloud dependency.

  • LedgerQuery the ledger by root, or query your own archive.
  • SignatureAny Ed25519 library verifies the signature against the published key.
  • MerkleAny BLAKE3 library reproduces the Merkle root from the file.
  • BitcoinEvery new seal is stamped to OpenTimestamps. The SDK's --ots flag independently re-checks the anchor against mempool.space.
verify.pyOffline
# Offline verification. No BitSeal call required.
from blake3 import blake3
from cryptography.hazmat.primitives.asymmetric import ed25519
import struct

def fold(leaves):
    level = [bytes.fromhex(h) for h in leaves]
    while len(level) > 1:
        level = [
            blake3(level[i] + (level[i+1] if i+1 < len(level)
                                         else level[i])).digest()
            for i in range(0, len(level), 2)
        ]
    return level[0].hex()

# 1. Re-derive root from the manifest's leaves.
assert fold(manifest["merkle_tree"]) == manifest["root_hash"]

# 2. Re-verify the Ed25519 signature against the published key.
msg = bytes.fromhex(manifest["root_hash"]) + struct.pack("<d", ts)
authority_key.verify(bytes.fromhex(manifest["signature"]), msg)
Common questions

What people ask, answered precisely.

Short, load-bearing answers. Deeper material lives in the docs and on the security page.

  • What does BitSeal prove about a file?

    BitSeal proves two things a counterparty can check independently: (1) the exact bytes of a file existed on or before a recorded UTC moment, and (2) the BitSeal Authority observed that moment and signed over it with Ed25519. Any modification to a single byte of the file changes the recomputed Merkle root and breaks the seal.

  • Does BitSeal upload my file?

    No. The file bytes never leave the device. BitSeal streams the file through BLAKE3 in the browser, computes a 32-byte Merkle root, and sends only a manifest of leaf hashes, the root, whole-file digests, filename, size, MIME type, entropy, and a UTC timestamp. The manifest is typically under 100 KB regardless of file size.

  • How do I verify a seal years later without BitSeal?

    Keep the signed manifest JSON. Any BLAKE3 library can recompute leaves from the file, fold them to a Merkle root, and compare. Any Ed25519 library can verify the Authority signature against a historical public key published at /.well-known/bitseal-authority.json. No BitSeal service call is required.

  • How is BitSeal different from OpenTimestamps or OriginStamp?

    OpenTimestamps gives you a Bitcoin timestamp with no signed manifest, no filename, no identity. OriginStamp is a SaaS timestamping service. BitSeal wraps OpenTimestamps inside an Ed25519-signed manifest and a public ledger, so a verifier gets both "this file existed" and "the Authority observed it," plus the Bitcoin anchor as an independent bonus axis.

  • What cryptographic primitives does BitSeal use?

    BLAKE3 for file hashing and Merkle leaves, SHA3-512 as a second whole-file digest for belt-and-braces, Ed25519 (RFC 8032) for Authority signatures, and OpenTimestamps with Bitcoin as the decentralized anchor. All choices are standard, widely implemented, and verifiable without BitSeal-specific tooling.

  • Is BitSeal free?

    Yes. The web app and the open-source Python SDK are free to use. The SDK is MIT licensed on GitHub at OrygnsCode/BitSeal-SDK.

  • Who operates BitSeal?

    Orygn LLC, a Texas limited liability company based in the Houston area. Founder: Daniel Okwor. Company site: orygn.tech. BitSeal is one of several products in Orygn's catalog.

  • Can I verify a seal fully offline?

    Yes, the cryptographic check is offline-native. Recompute the BLAKE3 Merkle root from the file, compare it to the manifest, and verify the Ed25519 signature against a published historical public key. The Bitcoin-anchor check also works offline once you have an upgraded OpenTimestamps proof; only the block-header lookup requires network, and that can hit any Bitcoin node.

Seal a file in the browser. Keep the root. Verify it anywhere.