A reviewer needs to verify a record. An agent needs to justify a decision. A business needs to explain why a transfer cleared. Each needs the right evidence, with access to the right information.
8DB brings proof components, provenance and controlled disclosure into the same data system.
A supplier wants a buyer to check an inspection record against an authenticated batch. The buyer can receive that record and its membership proof while the remaining records stay with the supplier.
8DB’s embedded engine implements signed Merkle batches for this job. The verifier checks the record’s hash, the path to the batch root and the root’s signature against a trusted signing identity.
Illustrative review packageSelected record
01
Inspection recordThe information approved for this review
02
Membership pathHashes linking the record to its batch
03
Signed batch rootAn authenticated boundary to check against
The check establishes membership in the authenticated batch. The reviewer still needs to trust the issuer of the inspection and assess what the inspection actually establishes.Built into 8DB
Different questions need different evidence.
These are implemented components with defined verification paths. The examples show where an application can use them.
01 / Authenticity & membership
Is this record part of the signed batch?
Share a selected inspection, research record or transaction record with evidence of its membership. Other records in the batch do not have to be downloaded.
What is checked
The selected record’s digest reaches a root authenticated by a trusted signer.
What is shared
The selected record or its agreed digest, a sibling-hash path and the signed batch boundary.
Implementation and scope
Domain-separated SHA-384 hashes and ML-DSA-87 batch signatures are implemented in the embedded engine. Membership establishes integrity within that batch. It does not establish the truth of the source record, completeness of a query, or conceal every piece of metadata.
02 / Defined computation
Does this aggregate match its inputs?
Attach a compact sum-check transcript to a declared sum of products. A receiving service can check the encoded arithmetic against the supplied input vectors.
What is checked
A defined finite-field aggregate: H = Σ fᵢgᵢ.
What is shared
The input vectors, declared result and proof transcript. This component uses public inputs.
Implementation and scope
The implemented transcript is 264 bytes for 1,024 entries. This is an encoding size, not a timing benchmark or total transfer size. The full verifier still processes both input vectors in linear time. A business application must also define its value encoding and range conditions.
03 / Policy binding
Which policy is this resource bound to?
Connect a protected resource to its declared key-derivation policy and a signed attestation. Give an authorized verifier the context needed to check that binding.
What is checked
A designated verifier with the required secret can recompute the policy binding.
What is shared
The declared policy context and attestation. A public-key-only check authenticates the issuer’s statement.
Implementation and scope
8DB implements ML-DSA-signed policy attestations. The public signature check and the authorized recomputation provide different guarantees. This is a designated-verifier mechanism, not a public zero-knowledge proof.
Implementation scope reviewed 14 September 2026. These descriptions come from source and recorded qualification work. They are not a new performance run or an independent security audit.
Our technology, in our own application
Digital Fabric. Financial decisions with their evidence attached.
Digital Fabric is an 8Braid-owned implementation of 8DB for settlement and compliance infrastructure. It brings encrypted records, policy checks and replayable transaction evidence into one application.
The useful question is simple: why did this transfer clear, and what can each participant verify about it?
With the compliance gate installed, the transfer path requires its prescribed envelope, including originator, beneficiary and jurisdiction information.
At the decision
Retain the policy context.
Governed transactions, signed policy attestations and audit records give the application material to explain the authorization.
During review
Expose the appropriate evidence.
Authorized views and replayable records support different operational and review roles. The chosen verification path determines what each receiver can check.
The public product separates built components from its planned public multi-operator network. Configured policy enforcement depends on the rules and evidence supplied; it is not automatic legal compliance or a claim of anonymous settlement.
Why this belongs in a database
Give an AI workflow something to check before it acts.
An application can require a valid signature, an approved policy context or a successful verifier result before releasing a record or accepting a proposed action. That creates a concrete way to catch certain errors during the workflow.
Keep the check near its source.
Connect a result to the data version, source identity and supporting evidence it used. A later review can ask which state was checked.
Give each role an appropriate view.
A model, operator and external reviewer can have different information needs. Native governance can enforce the authorized data path.
Preserve uncertainty.
A passed arithmetic check can coexist with an unresolved experimental question. Confidence and evidence remain part of interpreting the result.
Reduce integration work.
Applications can connect records, relationships, policy and verifier outputs in one environment, with fewer separate stores to reconcile.
These checks have a defined reach. A valid proof of a calculation cannot establish that a sensor was honest, a model was appropriate or a business rule was correct. The benefit is knowing which question was checked and which question remains open.
That is the promise of a zero-knowledge protocol: a verifier can check a specified statement without learning the private witness beyond what the statement reveals. An eligibility check is a useful example: demonstrate that a credential meets an agreed rule while limiting disclosure of the underlying record.
8DB has implemented STARK proof machinery and credential-condition circuits, alongside the integrity and attestation components above. Witness-hiding guarantees and end-to-end private credential workflows are separate qualification work. We do not treat a short proof, an encrypted record or a signed statement as evidence of zero knowledge.
Useful today
Authenticated record membership, defined aggregate checks, policy attestations, authorized views and content-minimizing queries.
Protocol-specific research
Private eligibility, constrained entitlement redemption and verifiable protected queries. Each needs an explicit statement, disclosure model and validated implementation.
Why the distinction matters: Winterfell’s own documentation separates succinct proofs from its unfinished perfect-zero-knowledge feature. Privacy must be established for the actual protocol, not inferred from the proof system’s name.
Another useful distinction: checking presence without reading content
8DB also has index-based presence and count checks. For example, a workflow can ask whether required inspection-document categories are present without opening the documents. That minimizes content access. The result is a database check, not by itself a portable cryptographic zero-knowledge proof.
Bring one fact to check, the information the reviewer may see, and the authority they should trust. We can map the existing components and the work needed for your application.