The Gateway, measured.

Which algorithm signs what

One plain map, so the numbers on this page are never confused with the live product.

• Public origin signing uses ML-DSA-65. The signatures you can make yourself, in the typed signer and the free receipt, are real ML-DSA-65 (NIST FIPS 204) post-quantum signatures. That is the live public path.
• Gateway hardening uses the hybrid profile. The Gateway hardening campaign (below) signs each receipt with a hybrid profile: an Ed25519 and an ML-DSA-65 signature bound to the same canonical digest. A hybrid receipt is valid only if both signatures verify.
• This benchmark is the Ed25519 reference baseline. The measured numbers on this page are the Ed25519-only receipt path, run on 2026-07-19. It is a historical reference measurement of per-receipt cost, not the active hybrid campaign and not a production SLA. The active hybrid campaign publishes its own numbers only after it completes and its manifest verifies.

What was actually tested

The Gateway sits in the request path, before your model and tool providers. For each arrival it builds an attestation envelope, canonicalizes it (RFC 8785 JCS), hashes it (SHA-256), and signs the digest with Ed25519. The signed receipt links to the origin request hash when a CarnacPrompt™ receipt is present, and is verifiable offline against a public key.

• The real receipt path. The benchmark exercises the same Ed25519 / RFC 8785 JCS / SHA-256 code shipped in the open receipt verifier. It is not a decorative mock.
• No plaintext. Arrivals carry a request hash and metadata, never prompt text. The core stores hashes only.
• Two modes, measured separately. Synchronous countersign (returns after the signature) and an async sidecar (ack now, receipt after). The async ack is never reported as signature latency.
• Envelope overhead vs crypto. Routing and envelope build are timed apart from the Ed25519 signing cost.

This is the Ed25519 reference receipt path, deliberately distinct from the public ML-DSA-65 (FIPS 204) demo signer. No ML-DSA-65 or post-quantum performance is claimed here, and the public endpoint was not load-tested.

Measured results

10,000 completed countersign operations per run, after a 1,000-op warmup, at four concurrency levels, in both modes. Every run: zero errors.

Scroll table →

Node.js is single-threaded and Ed25519 signing here is CPU-bound, so throughput is flat near 1,900 to 2,300 ops/s regardless of concurrency. Higher concurrency does not add throughput; it raises latency because in-flight operations queue behind one core. The single-worker row is the honest per-core figure. Envelope and routing overhead is roughly 11 to 14 microseconds, so the arrival receipt cost is dominated by the signature itself.

For an inference platform team

A quick read of the numbers above, in the terms a provider cares about.

Exact environment

Everything needed to judge and reproduce the run.

What these numbers do and do not prove

• They prove the reference receipt path works, verifies, and has a measured, reproducible cost on a named machine, with zero errors across 80,000 operations.
• They do not prove a production SLA. Real throughput and latency depend on placement in your request path, hardware, native crypto builds, network, the signing profile you choose per consequence, and your traffic shape.
• They are not a comparison to any specific inference provider, and make no claim of running at another platform's scale. This is a baseline you can reproduce and then re-measure in your own environment.

Reproduce it

The core, the smoke suite, and the benchmark are in the repository. Run them locally.

cd carnac-gateway-core
NODE_PATH=./node_modules node smoke.mjs            # 10-case functional suite, exit 0 = pass
NODE_PATH=./node_modules node bench.mjs 10000      # benchmark, 10k ops/run
NODE_PATH=./node_modules node verify-manifest.mjs  # check the signed manifest

Verify the signed manifest

The benchmark manifest is signed with a real Ed25519 signature over its RFC 8785 JCS / SHA-256 digest. Verify it with no trust in Hive: recompute the digest, then check the signature against the published public key.

Raw artifacts

• benchmark-manifest.json — signed manifest (environment, summary, attestation)
• benchmark-raw.json — full per-run results
• benchmark-summary.csv — summary table

There is no public load endpoint. The benchmark is local-only by design, so nothing here can be used to load the production service.

Hardening campaign

The benchmark above measures the single-worker receipt cost. Separately, we run a longer campaign that puts the Gateway under sustained, realistic load and checks that every receipt is correct. It is a soak and stress test, not a speed test. Its job is to prove the Gateway stays honest and loses nothing over hours of traffic.

What the campaign adds beyond the benchmark

• Post-quantum and hybrid receipts. Alongside the Ed25519 path, the core now signs with ML-DSA-65 (FIPS 204) and a hybrid profile that binds an Ed25519 and an ML-DSA-65 signature to the same canonical digest. A hybrid receipt is valid only if both signatures verify. The ML-DSA-65 build is @noble/post-quantum, a vetted pure-JS implementation. It is not a native or AVX2 build, and we do not call it one.
• A real network service. The core runs behind a local HTTP service with bearer auth, per-tenant key isolation, request size caps, a bounded in-flight queue that sheds with 503, request timeouts, health and readiness endpoints, graceful shutdown, and multiple workers. It never logs or stores plaintext. It binds to loopback only. There is no public load endpoint.
• Full receipt verification, every time. The campaign independently re-verifies every completed receipt from its own signable payload, with no trust in the issuing Gateway. It also injects safe faults, such as duplicate requests, tampered hashes, malformed input, and signer outages, to confirm the correct reject or fail-open behavior.

How the campaign runs

The campaign moves through gated phases and stops early if any hard integrity check fails, preserving its evidence.

• Smoke and security tests. The functional and crypto suites must pass first.
• Short preflight. A brief warmup run below saturation to confirm the service is healthy.
• One-hour shakedown. Sustained load below saturation, with traffic bursts and injected failures. This phase is a gate. The soak only starts if it passes.
• Twenty-four-hour soak. The long run at a steady rate, checkpointed atomically so it can resume, with a signed manifest and raw artifacts saved per phase.

The pass bar

The campaign requires zero lost, mismatched, cross-tenant, or unverifiable receipts. A single occurrence fails the run and stops it. Throughput and latency are recorded, but the primary result is integrity, not speed.

Status is reported as prepared or in progress until the full soak completes and its manifest verifies. We do not report the campaign as passed, and we do not publish final campaign numbers, before then. The run is local and loopback-only, so nothing here can be used to load the production service.