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.
Capability matrix
| Capability | Knox | OTS alone | C2PA | AWS QLDB | DocuSign | Sigstore | DB audit log |
|---|---|---|---|---|---|---|---|
| SHA-256 hash commitment | Yes | Yes | Yes | Yes | Partial | Yes | Partial |
| Bitcoin-backed public timestamp | Yes | Yes | No | No | No | No | No |
| Verification without vendor's server online Sigstore depends on Rekor transparency log; C2PA depends on PKI CA chain. | Yes | Yes | Partial | No | No | Partial | No |
| Machine-checked formal specification (TLA+) | Yes | No | No | No | No | No | No |
| Self-authenticating FRE 902(13)/(14) affidavit | Yes | No | Partial | No | Partial | No | No |
| Zero-dependency air-gap verifier OTS has a standalone client but for anchor-only; Knox includes the envelope and affidavit. | Yes | Partial | No | No | No | No | No |
| Multi-signal evidence envelope (signers + geo + device + oracles) | Yes | No | Partial | No | Partial | No | No |
| Federal exclusions enrichment (OFAC SDN + FAR 889 + SAM) | Yes | No | No | No | No | No | No |
| Hash-chain linkage between records (tamper-evident ordering) | Yes | No | No | Yes | No | Partial | Partial |
| Multi-chain redundancy (not single-chain dependent) | Yes | Partial | No | No | No | No | No |
| Vendor-independent — survives operator bankruptcy | Yes | Yes | Partial | No | No | Partial | No |
| Sub-penny per anchor at enterprise volume | Yes | Yes | Partial | Partial | No | Yes | Yes |
| Native image/video manifest embed C2PA is the industry direction for content provenance specifically — Knox does not embed manifests into media files. | No | No | Yes | No | No | No | No |
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
OpenTimestamps alone
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.
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.
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.
C2PA (Content Authenticity Initiative)
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.
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.
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.
AWS QLDB (Amazon Quantum Ledger Database)
Enterprise-ready, deep AWS IAM integration, SQL-like query interface, managed service with no operational burden, committed data model.
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.
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.
DocuSign / Adobe Sign / eSign platforms
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.
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.
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.
Sigstore / signed git commits
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.
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.
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.
Plain database audit log / append-only table
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.
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.
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.
Other Bitcoin-notarization services (OriginStamp, Woleet, etc.)
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.
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.
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.