Sparcle is not in the verification loop
The verifier runs entirely inside your perimeter. No outbound calls. The operator-root key is the only Sparcle artifact you need, and it's a public key — there's nothing for an attacker to extract.
Verify our claims
Your auditor runs the verifier. Not us.
A Bolt audit chain is a sealed sequence of Ed25519-signed Merkle epochs. The verifier is a single statically-linked binary that takes the chain and the operator-root public key and returns a yes/no per epoch. It runs offline. It has no Sparcle dependencies. It is the strongest trust signal we can ship: your auditor never has to take our word for it.
The model
Sparcle does not get to verify its own claims.
A vendor that says “trust us, the audit log is good” is asking the buyer to accept an asymmetry. Bolt's audit chain inverts that: your auditor runs the verifier on hardware you control, against bytes you exported, using a public key whose private half you never need to see. There is no point in the verification path where you have to take Sparcle's word for it.
Bit-stable across versions
The hashing canonicalization is byte-stable across Bolt and Aeira versions. A chain produced by Bolt 1.0 is verifiable by sparcle-verify-chain 1.5. The conformance test suite gates this; any change that would break replay refuses to ship.
Tamper-evident, not tamper-proof
The chain cannot be silently modified — every tampered byte invalidates downstream signatures. It can, in principle, be deleted, which is why retention is contractually specified and the storage substrate (WORM or audit-replicated Postgres) is the customer's choice, not Sparcle's.
Post-erasure verification still works
If a tenant CMK has been cryptographically shredded (per the crypto-shred construction at /trust/cryptographic-erasure), the audit-receipt for the disposal is still verifiable. The receipt is signed under the operator-root key, which is distinct from the destroyed tenant CMK.
The procedure
Four commands, zero network calls.
The verification path is small by design. Each step has a specific failure mode and a structured exit code so it can be wrapped by your auditor's existing tooling without ceremony.
-
1. Pull the audit chain you want to verify
Bolt's audit chain is stored in your Postgres. Export it with the bundled CLI: bolt audit export --from <ts> --to <ts> --out chain.ndjson. The export is byte-stable; running the same command twice produces identical bytes. The export is independently parseable and includes the per-epoch Merkle roots, the operator-root signature, and the leaf event hashes.
-
2. Pull the operator-root public key
The operator-root key is the one Sparcle uses to sign Merkle epoch roots. The public half lives in your tenant's KMS-managed bundle and is also published in your release-signing manifest. Pulling it twice from different sources is the first sanity check.
-
3. Run the verifier
sparcle-verify-chain --chain chain.ndjson --key operator-root.pub. The verifier (a single statically-linked Rust binary) checks: leaf-hash → epoch-root membership; epoch-root signature under the operator-root key; chain continuity across epochs; absence of orphan epochs. No network calls, no Sparcle dependencies — runs offline on air-gapped hardware.
-
4. Inspect the result
Verifier exits 0 on a valid chain and prints a per-epoch summary. Exit non-zero on any failure with a precise reason (broken hash chain, invalid signature, missing epoch, tampered receipt). The output is structured JSON and can feed directly into your SOC's audit-evidence pipeline.
The full canonical verification, in one block:
# export the chain you want to verify
bolt audit export --from 2026-01-01 --to 2026-01-31 --out chain.ndjson
# run the standalone verifier — no network calls, no Sparcle deps
sparcle-verify-chain \
--chain chain.ndjson \
--key operator-root.pub \
--output report.json
# exit 0 = valid; non-zero with a precise reason on failure
echo "exit: $?"What's available
What you can get today, what activates with pilot.
The same honest framing the rest of the trust center uses. The sample chain and the verifier are designed to be in your hands well before any contract is signed.
Sample audit chain
A 500-event sample chain with the corresponding operator-root public key. Lets you run sparcle-verify-chain end-to-end against a known-good input before installing anything. Available on request.
Verifier binary
The statically-linked Rust binary, signed and SBOM-attested. Builds for macOS · Linux · Windows. Distributed during pilot evaluation; the binary is the same one shipped with the production Bolt and Aeira packages.
Verifier source
The verifier is intended for source release under a permissive license so a customer's auditor can build it themselves and confirm there is no Sparcle-only inspection path. Source distribution is gated on the OSS-release sign-off currently in flight.
Conformance test suite
The byte-stability test suite that gates every Bolt and Aeira release. Lets your auditor confirm that the verifier they ran six months ago is still the correct binary to run today against a fresh chain. Available under NDA during pilot evaluation; intended for public release alongside the verifier source.
What the verifier does not claim
The edges of the construction.
- The verifier confirms chain integrity. It does not confirm that the events recorded are complete. Detecting a missing event requires comparing chain content against a complementary signal — typically the customer's SIEM or their own access logs.
- The verifier does not validate the operator-root key's chain-of-custody. That is a separate trust decision the customer makes when they accept the key bundle.
- Verifying a chain that spans multiple operator-root key rotations requires the verifier to be given the full operator-root key history. The rotation manifest is included in the release-signing bundle for that reason.
- Quantum-resistance for Ed25519 signatures is not in scope today. A migration path to post-quantum signature schemes is on the roadmap; the verifier is signature-scheme-agnostic by design.
Related trust artifacts
How this primitive sits next to the rest of the trust posture.
Want to run the verifier against a sample chain?
Ask for verifier access. We send a sample chain, the operator-root public key, and the binary for your platform. Your auditor can run it on a laptop in under five minutes. No NDA required for the sample run.