We Scored a C.
Here's Why We're Publishing It.

We Ate Our Own Dog Food

H33-Procure is a product that evaluates codebases cryptographically — without ever seeing the source code. A STARK proof attests the evaluation ran correctly. A Dilithium signature seals the result. The vendor keeps their code. The buyer gets a verified grade.

Before we ask anyone else to run it, we ran it on ourselves. The full H33 Digital SCIF backend — 2,583 files, 1.5 million lines of code, 22 product modules, every cryptographic primitive we've built.

The result: 70/100. Grade: C.

We could have tuned the algorithm to give ourselves an A. We didn't. We could have excluded the findings that hurt. We didn't. We could have published this quietly after fixing everything. We're not doing that either.

Here's exactly what the algorithm found.

What Dragged Us Down

The H33-Procure scoring algorithm has five categories: Cryptographic Security (30%), Vulnerability Surface (25%), Data Handling (20%), Operational Resilience (15%), and Code Health (10%). Our score breakdown:

Four categories at 100. One category at zero. Cryptographic Security — the thing we sell — scored a zero and tanked the entire grade.

The irony is not lost on us.

Why Cryptographic Security Scored Zero

The algorithm found 391 cryptographic findings across our codebase. 358 were classified as critical. The total deductions exceeded 154 points against a 100-point category. When deductions exceed the category maximum, the score floors at zero.

The findings fall into three groups:

1. Ed25519 in our Solana stack. H33 has a Solana integration for on-chain token operations and smart contracts. Solana mandates Ed25519 for all transaction signing. Ed25519 is not post-quantum safe. The algorithm correctly identifies this as a PQ vulnerability. It doesn't care that Solana requires it — the math is the math. Every Ed25519 signing operation is a harvest-now-decrypt-later exposure.

2. Classical crypto references in our application layer. Our API server, JWT handling, and session management still reference classical cryptographic algorithms in several places. Our cryptographic libraries are post-quantum (Kyber, Dilithium, FALCON, SPHINCS+). But the application layer that calls those libraries hasn't been fully migrated. The plumbing is world-class. The wiring isn't done.

3. ECDSA and RSA in hybrid transition code. H33's PQC module implements hybrid classical-plus-post-quantum schemes as recommended by NIST SP 1800-38. Those hybrid implementations necessarily reference ECDSA and RSA — that's what they're hybridizing with. The algorithm flags them because the classical algorithm is present. This is a correct finding. Hybrid is a migration strategy, not a destination.

What We're Fixing

We're not explaining away the score. We're fixing the code. Here's the plan:

Phase 1: Application-layer migration. Every JWT signing operation, session token, and API authentication flow that currently uses RS256 or ES256 will be migrated to Dilithium ML-DSA-65. This is the highest-impact change — it covers the most findings with the least architectural disruption.

Phase 2: Solana PQ wrapper. Solana mandates Ed25519, but we can wrap the signing layer with a hybrid scheme: Ed25519 for Solana protocol compliance, Dilithium for an additional attestation layer that survives a CRQC. The transactions satisfy Solana's requirements. The Dilithium signature provides post-quantum non-repudiation.

Phase 3: Full hybrid sunset. As the NIST post-quantum transition completes and classical algorithms are deprecated, we'll remove the hybrid fallback paths and run pure PQ. The algorithm's score will reflect this automatically — classical crypto references drop to zero, deductions drop to zero, positive credits remain.

We'll re-scan after each phase and publish the updated score.

Why We're Publishing This

Every vendor who runs H33-Procure will see their score. Some will be lower than ours. Some will be higher. The question every buyer will ask is: "What did H33 score?"

If we hide it, the product has no credibility. If we publish a perfect score, nobody believes it. If we publish a C and show the work — the specific findings, the rationale, the fix plan — that's something no other vendor in this space has ever done.

The algorithm is open source. The weights are published. The methodology is documented. Anyone can audit the scoring logic and verify that we didn't put a thumb on the scale. The STARK proof in every certificate makes tampering mathematically impossible.

Our score will improve. The algorithm won't change to make that happen. The code will.

What This Means for You

If you're evaluating H33 as a vendor, you now have something no other vendor gives you: an honest, cryptographically-attested assessment of our own code, published publicly, with specific findings and a remediation timeline.

If you're a vendor considering H33-Procure for your own product, you've just seen what it does. It found 391 findings in a codebase built by a team that does post-quantum cryptography for a living. It will find things in yours too. That's not a threat. That's the value.

If you're a procurement officer evaluating software from any vendor, ask them one question: "What's your H33-Procure score?" If they don't have one, ask them why not. If they won't run it, that tells you everything.

The H33-Procure scoring algorithm is open source. The methodology is documented in full at h33.ai/zk-procure. Our current score is 70. We'll update this post as we fix the findings and re-scan.

Current status: Fixing. Next scan target: Phase 1 complete, estimated score 85+.