Trust & Verification

Signing Keys

Bench'd maintains two active Ed25519 signing keys. The primary key signs all production receipts. The secondary key is used for disaster recovery and is stored offline. Both public keys are published here so anyone can verify a receipt without trusting our infrastructure.

Primary Signing Key

Active

AlgorithmEd25519Created2025-08-15FingerprintSHA256:bQ9f+3kLm7xR2vNpTcWdYhA8sE1uG4jZ6oI5wX0rM/s

Public Key (hex)

public keyplaintext

a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2

Secondary Signing Key

Active

AlgorithmEd25519Created2025-11-01FingerprintSHA256:kP7m+1xRn5vQ8wLcTfYdZhB3sE9uG2jW4oI6aX7rK/q

Public Key (hex)

public keyplaintext

f0e1d2c3b4a5968778695a4b3c2d1e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d

Verify a Receipt Yourself

You do not need to trust Bench'd. Every signed receipt can be verified locally using standard cryptographic tools. Fetch the receipt JSON from any run page, then verify the Ed25519 signature against the public key published above.

Choose your preferred language below. All three examples are complete and runnable — copy, paste, and run.

verify-receipt.shbash

#!/usr/bin/env bash
# Verify a Bench'd receipt using curl + openssl
# Requires: curl, jq, openssl, base64

RECEIPT_URL="https://benchd.dev/api/receipt/run_abc123.json"
PUBLIC_KEY_URL="https://benchd.dev/.well-known/benchd-signing-key.pem"

# 1. Fetch the receipt and public key
curl -sL "$RECEIPT_URL" -o receipt.json
curl -sL "$PUBLIC_KEY_URL" -o benchd-public.pem

# 2. Extract the manifest (the signed payload) and signature
MANIFEST=$(jq -r '.manifest' receipt.json)
SIGNATURE=$(jq -r '.signature' receipt.json)

# 3. Write the manifest to a temp file for openssl
echo -n "$MANIFEST" > /tmp/benchd-manifest.bin

# 4. Decode the base64 signature
echo -n "$SIGNATURE" | base64 -d > /tmp/benchd-sig.bin

# 5. Verify the Ed25519 signature
openssl pkeyutl -verify \
  -pubin -inkey benchd-public.pem \
  -rawin -in /tmp/benchd-manifest.bin \
  -sigfile /tmp/benchd-sig.bin

# Expected output: "Signature Verified Successfully"

# 6. Optional: verify Merkle root integrity
MERKLE_ROOT=$(echo "$MANIFEST" | jq -r '.merkleRoot')
echo "Merkle root: $MERKLE_ROOT"

# Clean up
rm -f /tmp/benchd-manifest.bin /tmp/benchd-sig.bin

The verification checks two properties: data integrity (the Merkle root matches the individual question hashes) and authenticity (the signature was produced by a key published on this page). If either check fails, the receipt has been tampered with.

Key Rotation Log

Every key change is logged publicly. Rotated keys remain listed so historical receipts can still be verified against the key that signed them. We never delete key records.

Fingerprint	Algorithm	Created	Status	Rotated
bQ9f+3kL...M/s	Ed25519	2025-08-15	Active	—
kP7m+1xR...K/q	Ed25519	2025-11-01	Active	—
wT4j+8nF...D/e	Ed25519	2025-06-01	Rotated	2025-08-15

Governance

The primary signing key is held by two Bench'd core maintainers under a 2-of-3 threshold scheme. No single individual can sign a receipt or rotate a key unilaterally. The secondary key is stored in a hardware security module (HSM) in a separate geographic location and requires physical access to use.

Key rotation is triggered on a fixed schedule (every 12 months) or immediately if a compromise is suspected. When a key is rotated, the old key is marked as rotated in the public log above, and all future receipts are signed with the new key. Historical receipts remain valid against the old key.

The rotation process is documented in an internal runbook and requires approval from at least two maintainers. Every rotation event is announced on the Bench'd GitHub repository and mirrored to our signing-keys repository, which maintains a Git-signed commit history of all key changes.

Conflicts of Interest

Bench'd is independently funded and does not accept investment, sponsorship, or payment from any vendor whose product appears on the leaderboard. No Bench'd maintainer holds equity in, consults for, or receives compensation from any evaluated vendor.

If a maintainer develops a material relationship with a vendor, they must disclose it publicly, recuse themselves from benchmark runs involving that vendor, and surrender their signing key share for those runs. This policy is enforced through the same 2-of-3 threshold scheme that governs key management.

We believe that benchmark credibility requires structural independence, not just good intentions. The cryptographic receipts, public keys, and open-source harness exist so that our claims are verifiable even if you do not trust the people making them.

Last updated: May 2026. For the full scoring methodology, see the Methodology page. View revision history on GitHub.

Cryptographic transparency