PQC Safe Payload Rollout: From Merkle Production to the SP1 Execution Path
How StygiaScore turned a difficult backend and proving milestone into a commercial public surface, a Safe-first operator flow, and a more credible PQC story
Executive Summary
StygiaScore now presents three layers of the same product story more clearly: a public scanner for discovery, a capability inventory for commercial trust, and a Safe payload lane for the next PQC/SP1 operator workflow.
The important nuance is that we did not collapse all of that into a fake claim of “full PQC production.” The core documentation still describes the system as PQC-ready / crypto-agile unless the trustless verifier path, active verifier, and readiness signals actually support a stronger statement.
What is already real in production
The production lane today is not marketing copy. It is the Merkle-backed QEP path that runs through the backend, the prover, the adapter, the Diamond, and the Polygon settlement flow. That lane remains the source of operational truth for production demos and live execution.
In practical terms, the current production story is:
- The backend derives the Merkle leaf from target, signer, message hash, public key hash, and scheme.
- The prover generates a fresh Groth16 proof for the authorized Merkle dataset.
- The adapter and Diamond verify the inclusion path on-chain before the echo is generated.
- The public site exposes read surfaces without exposing the protected execution path.
Scanner
Public production-backed discovery layer for exposure, signature dependence, and migration posture.
Capability Inventory
Commercial page that separates what is already operational from what still depends on the final verifier rollout.
Dashboard Lane
Safe-ready transaction preparation for PQC registration and SP1-backed execution without browser-side contract writes.
What was difficult about this rollout
The hard part was not adding another button. The hard part was operational alignment across the prover, the SP1 guest and host flow, the public signals, the on-chain verifier path, the adapter call shape, and the Safe execution boundary. When a proof can be single-use on-chain, there is very little margin for careless iteration.
That is why this release matters commercially. It shows the product moving from architecture slides to execution discipline: status checks, proof generation, payload preparation, verifier awareness, and operator-safe handoff into a Safe.
What the Safe payload lane changes
The new dashboard lane consumes the live PQC status route and uses the backend as the source of truth for both the proof lifecycle and the final transaction payload. The browser does not need to compose low-level calldata by itself.
The operator now sees the exact fields that matter for execution:preferredMode, safePayloadAvailable, sp1Verifier, and activeVerifierType.
POST /v1/qep/register-pqc-keycan prepare registration withsubmissionMode: "safe_payload".POST /v1/qep/generate-echo-pqc-autocan generate the proof path and return a Safe-ready transaction.- The UI renders
to,value,data, andoperationfor operator review. - The interface also reminds operators that an SP1 proof becomes consumed once it is accepted on-chain.
Why we do not overclaim PQC
The core documentation is explicit: the broader system should still be presented as PQC-ready / crypto-agile unless the trustless path is actually live. That distinction matters. A product can already be operationally useful, commercially credible, and materially ahead of most teams without pretending that every layer is already post-quantum complete.
For StygiaScore, the honest status is:
- Merkle + Groth16 remains the production execution lane today.
- The SP1 lane is real product work with real backend and on-chain wiring.
- The UI should only present trustless PQC strongly when the active verifier is SP1 and the status confirms readiness.
- The scanner and capability pages are public-facing because they do not depend on protected write flows.
Why the commercial narrative matters now
The broader market is moving toward cryptographic inventory, migration governance, and machine-readable reporting. That is why the scanner is strategically important: it is the public entry point to a much bigger enterprise conversation about discovery, cryptographic posture, and migration evidence.
This is also why recent industry work around CBOM matters. The PKI Consortium launch of the CBOM Profiles Working Group and IBM's documented use of CBOM-driven crypto-agility workflows make one thing clear: buyers increasingly want an inventory story before they trust a migration story.
What this means for StygiaScore
StygiaScore should not sell the scanner as magical certification. It should sell it as the front door to posture discovery, risk signaling, and eventually standardized cryptographic inventory. That is commercially stronger and technically cleaner.
Meanwhile, the dashboard keeps moving up the stack: from Merkle execution today, toward a stronger SP1-backed trustless path when the backend, verifier, and readiness signals justify it. That combination is what makes the current release credible.