Runtime Auditor
Why should you believe a
hardware accelerator?
A verdict from opaque silicon is a claim, not a proof. Ask any auditor: you don't trust the report — you trust the independent check. Every Blitz card carries its own: a separate processor that keeps putting the K1 engine to the test against the cryptographic reference the ecosystem itself trusts — for as long as the card runs.
A second opinion, by construction
The auditor is an independent RISC-V processor beside the K1 accelerator, and the two answer the same question from opposite media. The K1 core is a hardened, deeply pipelined hardware datapath built for throughput; the auditor is software — the trusted libsecp256k1 C library, the same reference implementation the ecosystem uses to verify signatures, compiled onto the RISC-V core.
The split is deliberate: the auditor is not a second RTL verifier, which could repeat the same design mistake. It shares nothing with the K1 core but the mathematics — different authors, different medium, different tools — and implementations that share nothing else rarely share a bug. This one is also the code the rest of the ecosystem already trusts to decide what a valid signature is.
The check is continuous, not occasional. Once self-test passes, the auditor feeds vectors through the accelerator's own datapath at 100 audit sigchecks per second (the default): the published known-answer corpus, plus freshly randomized vectors — including invalid signatures the engine must reject. Before each vector enters, the auditor declares to the hardware the verdict libsecp256k1 requires; it never sees the engine's answers at all — a comparator in the card's fabric checks every one. Alignment between the two implementations is being re-proven for as long as the card is powered, in your machine rather than just in our lab.
Coverage, stated plainly: at 100 audits a second against an engine doing hundreds of thousands, the auditor is not checking your records — it never sees them. It is sampling the datapath itself, and what a sampled probe catches is persistent disagreement: a wrong or tampered engine, a bad build, silicon degrading out of spec — faults that answer wrong all day and so cannot hide from even a slow stream of known-answer and must-reject checks. A transient fault on one of your records is a different problem with different guards: any failure of the machinery surfaces as an UNKNOWN verdict (re-check in software, never trust silence), and real network traffic is cross-checked against the card record by record on the live bench node.
Starts closed. Fails loudly.
At power-up the verification pipeline is physically closed: the input valve resets shut, and the only thing that opens it is the auditor's self-test-done signal, raised once its power-on self-checks pass. Until then the card reports SELFTEST_PENDING; if the self-check fails, the valve never opens. That is deliberate: the production image requires a working auditor to verify at all.
A mismatch during operation benches the card — and not because the auditor says so. The hardware that caught the disagreement latches the output valve shut — no verdict leaves — commits the failure to on-card persistent memory, and lets the watchdog reset the card into a fresh self-check: a transient fault re-proves itself before the valves reopen; a persistent fault never gets them open again. Even the watchdog runs on agreement — it is fed, in hardware, by each passing audit — so a wedged engine, a silent auditor, and a single disagreement all end the same way. The strobes stop, and the card resets.
The card comes back up flagged — last boot followed an audit failure — and the lifetime AUDIT_FAILS counter, which should read zero forever, keeps the permanent record: counted in fabric, append-only by construction. The auditor's processor could never rewrite history, because it was never holding the pen. All of it is readable by any host process through the same two-file API as everything else on the card.
Built, not proposed
Runtime self-audit is easy to promise on a slide. Ours you can read, run, and watch.
Read it
The auditor SoC is open source — the RISC-V core, the firmware running libsecp256k1, the injection machinery. Not a black box auditing a black box.
The auditor SoC on GitLab →It does one job
The auditor is deliberately minimal: no bus access, nothing to read from it. It pushes vectors with their expected verdicts and raises one signal when self-test passes. The card's housekeeping lives entirely outside it, so no control loop can ever break the audit loop.
Watch it
A real card is on the bench right now, auditing as it verifies. Push load onto it yourself and watch.
Live from the bench →Why it matters for consensus software
Signature verification is consensus-critical: a wrong PASS is how a node accepts an invalid chain. Hardware that accelerates it must therefore do more than be fast — it must make its own failure visible. The auditor is one half of that answer; the other is the driver's ternary verdicts: PASS, FAIL, or UNKNOWN, where every failure of the machinery itself surfaces as UNKNOWN — an instruction to re-check in software, never a cryptographic answer.
Together they give the card a property most accelerators don't attempt: it does not merely pass its tests in the lab and hope for the best in the field — it keeps a second, independent opinion on its own results for as long as it runs.
The auditor ships on every Blitz card
Not an option, not a premium tier — the second opinion is part of the platform.
Patent pending — the runtime audit system. The auditor SoC itself is MIT-licensed open source.