Honest Comparison

Knox isn't the first to anchor to Bitcoin. Here's what it adds.

The primitives — SHA-256, Merkle trees, OpenTimestamps, Bitcoin — are not proprietary. Several tools use them. Below is an honest head-to-head comparison against the nearest alternatives. The places Knox loses are called out as loudly as the places Knox wins. If another tool fits your use case better, this page will tell you.

Not a superset claimEach alternative has a row it winsBrutally honest — survives expert review

Capability matrix

CapabilityKnoxOTS aloneC2PAAWS QLDBDocuSignSigstoreDB audit log
SHA-256 hash commitmentYesYesYesYesPartialYesPartial
Bitcoin-backed public timestampYesYesNoNoNoNoNo
Verification without vendor's server online
Sigstore depends on Rekor transparency log; C2PA depends on PKI CA chain.
YesYesPartialNoNoPartialNo
Machine-checked formal specification (TLA+)YesNoNoNoNoNoNo
Self-authenticating FRE 902(13)/(14) affidavitYesNoPartialNoPartialNoNo
Zero-dependency air-gap verifier
OTS has a standalone client but for anchor-only; Knox includes the envelope and affidavit.
YesPartialNoNoNoNoNo
Multi-signal evidence envelope (signers + geo + device + oracles)YesNoPartialNoPartialNoNo
Federal exclusions enrichment (OFAC SDN + FAR 889 + SAM)YesNoNoNoNoNoNo
Hash-chain linkage between records (tamper-evident ordering)YesNoNoYesNoPartialPartial
Multi-chain redundancy (not single-chain dependent)YesPartialNoNoNoNoNo
Vendor-independent — survives operator bankruptcyYesYesPartialNoNoPartialNo
Sub-penny per anchor at enterprise volumeYesYesPartialPartialNoYesYes
Native image/video manifest embed
C2PA is the industry direction for content provenance specifically — Knox does not embed manifests into media files.
NoNoYesNoNoNoNo

Legend: Yes — meets the capability as a core design goal. Partial — meets part of the capability, or only under certain assumptions. No — not intended to meet this capability; using the tool this way is a misuse.


Honest notes per alternative

The protocol Knox runs on top of.

OpenTimestamps alone

Strengths

The primitive Knox depends on. Published standard, independent calendar-server infrastructure, maintained by a community that predates Bonis. If all you need is 'prove this hash existed at time T' for an individual file, you don't need Knox — just run `ots stamp file.pdf` directly.

Gaps

OTS is a timestamp primitive, not a system of record. No hash-chain for ordering between records, no evidentiary envelope (signers, geography, device attestation, oracles), no public API to query an anchor by payload hash, no self-authenticating affidavit scaffold, no integration with federal exclusions or SBOM vulnerability feeds.

Where Knox fits

Knox is the operational wrapper around OTS for commercial and federal use cases that need the envelope, audit trail, affidavit, and integrations. The Bitcoin anchor under Knox IS OpenTimestamps — we did not replace it. We built the layer around it.

The media-provenance standard.

C2PA (Content Authenticity Initiative)

Strengths

Deep backing from Adobe, Microsoft, BBC, major camera makers. Content provenance manifests embedded directly into images and videos so the proof travels with the file. For media specifically, C2PA is the current industry direction and rightfully so.

Gaps

PKI-custodial. The manifest integrity depends on a certificate chain that can be revoked — which means prior records become ambiguous unless the revocation timeline is itself provable. C2PA does not publish a public-chain anchor by default; verification depends on a CA being online and trustworthy. Scope is limited to media content; not intended for generic business records, supply-chain events, or multi-signal attestations.

Where Knox fits

Different scope (any record, not just media) and different trust model (Bitcoin anchor that PKI rotations don't compromise). C2PA and Knox are complementary, not competing — a media file can carry a C2PA manifest AND be anchored into Knox for public-chain permanence. Knox does NOT embed manifests into media; for that specific feature, C2PA is the right tool.

Vendor-controlled immutable ledger.

AWS QLDB (Amazon Quantum Ledger Database)

Strengths

Enterprise-ready, deep AWS IAM integration, SQL-like query interface, managed service with no operational burden, committed data model.

Gaps

Vendor-controlled. AWS can be served a subpoena for your ledger; your records' integrity depends on AWS being truthful and online. No Bitcoin anchor, no external permanence layer. Lock-in: your ledger is in Amazon's ion format and exiting means re-anchoring to something else. If AWS discontinues the service (as it has done with other products), your ledger survives only as long as AWS keeps a read-only archive available.

Where Knox fits

Knox is vendor-independent by design. If Bonis Systems disappears tomorrow, your records verify against Bitcoin without any Bonis server. That is the Continuity Guarantee — QLDB cannot make it because AWS is the custodian.

The signature-workflow default.

DocuSign / Adobe Sign / eSign platforms

Strengths

Default for contract signatures. Deep enterprise adoption, accepted by most courts, ESIGN Act / UETA compliant, well-understood legal posture. If you need a signed PDF with a timestamp and signer identity verification, DocuSign is the right tool.

Gaps

Vendor-controlled audit trail. DocuSign's certificate of completion depends on DocuSign being online and operational. No public-chain anchor — if the DocuSign record is disputed, the counter-party has to subpoena DocuSign to produce the evidence, and the record depends on DocuSign's internal chain-of-custody practices. No tamper-evident hash-chain linkage between separate signatures.

Where Knox fits

Complementary. Use DocuSign for the signature workflow — and Knox to anchor the signed-document hash to Bitcoin. DocuSign provides the identity ceremony; Knox provides the public permanence. For audit integrity of the DocuSign record itself over decades, the Knox anchor outlasts any vendor.

The code-provenance standard.

Sigstore / signed git commits

Strengths

Established developer workflow for code and artifact signing. Short-lived certificates + Rekor transparency log. Backing from Google, Linux Foundation, OpenSSF. For software supply-chain provenance specifically, Sigstore is the right direction.

Gaps

Rekor is itself a centralized transparency log, independently operated by the Linux Foundation. Re-verification of a Sigstore signature requires Rekor to be online. Short-lived certs mean the signer's identity is not self-evident from the signature alone — the chain-of-trust relies on the OIDC identity provider's historical state. Scope is code signing; not intended for generic business-record anchoring or multi-signal attestation.

Where Knox fits

Different scope (evidence records, not code artifacts), different primitive (Bitcoin anchor, not certificate + transparency log). Sigstore and Knox can coexist: a Sigstore-signed container image's manifest hash can itself be Knox-anchored for permanence beyond Rekor.

The 90%-case default.

Plain database audit log / append-only table

Strengths

Cheap, trivial to implement, works today with any RDBMS. For most internal audit needs that will never be litigated, it's sufficient. Do not over-engineer.

Gaps

Any single DBA with the right credentials can alter both the records and the audit trail of the alteration. Custodian-controlled. No external witness. In a dispute, the plaintiff's first move is to argue the defendant's audit log is incomplete or altered — and without an external anchor, there is no way to refute that argument without calling the DBAs as witnesses.

Where Knox fits

For records that will be subject to regulatory audit, litigation, vendor bankruptcy, or a dispute between two parties who don't trust each other, the custodian-controlled log is insufficient. Knox anchors the audit log's own hash-chain checkpoints to Bitcoin — the audit log remains where it is; Knox makes it tamper-evident against the operator.

Adjacent Bitcoin-anchoring products.

Other Bitcoin-notarization services (OriginStamp, Woleet, etc.)

Strengths

Same Bitcoin primitive, some operational for years longer than Knox. For the specific problem of public-timestamping a hash, they may already meet your requirement.

Gaps

Most do not publish a machine-checked formal specification. Most are closed-source black-boxes whose algorithm is not independently verifiable. No federal-exclusions enrichment, no hash-chain linkage between records, no self-authenticating affidavit scaffold, no zero-dep air-gap verifier distributed for public redistribution.

Where Knox fits

If your requirement is 'timestamp a hash to Bitcoin' and nothing else, any of these may work. Knox's differentiation is the operational and evidentiary layer around the timestamp — formal spec, affidavit, air-gap verifier, federal-integration, charter governance, hash-chain of custody.


The one-paragraph version

For the plain "prove this file existed at time T" problem, use OpenTimestamps directly — it is what Knox runs on. For media provenance specifically, use C2PA — it is the industry direction. For a vendor-managed immutable ledger inside AWS, use QLDB. For signed contracts, use DocuSign. For code signing, use Sigstore. For most internal audit logs that will never be litigated, use your RDBMS's append-only table. Knox is the operational wrapper for regulated commercial and federal use cases that need a multi-signal evidentiary envelope, a hash-chain of custody across records, a self-authenticating FRE 902(13)/(14) affidavit, a zero-dep air-gap verifier, federal-exclusions enrichment, a formal specification, and a public Bitcoin anchor — in the same record. That full stack is what separates Knox; each component alone has a better-fit alternative above.

Independent verification

Formal spec (TLA+)

Downloadable, model-checked, re-verifiable on any machine with Java 17+ in under 60 seconds.

/bonis/spec →

Zero-dep verifier + sample record

~12 KB Node.js script, no dependencies. Feed it the sample-record.json and it passes all four checks offline.

/bonis/verifier →

OpenAPI 3.1 spec

Machine-readable API definition covering every public endpoint. Feed it to Swagger UI, Postman, or an SDK generator.

/api/knox/openapi →

Operator: Bonis Systems LLC · UEI R2BPJDC5CBA3 · CAGE 1TSP2 · USPTO provisional 64/038,359 (inventor: Jonis Aaron Fields) · Contact: [email protected] · +1 (210) 452-3767.