# PQC Sidecar

> Post-quantum (ML-DSA-65, FIPS 204) checkpoint certificates for finalized blockchain history.
> One sidecar runs beside one node you operate. No hard fork, no validator coordination.
> Now taking engagements. Contact: rick@dytallix.com

This is the plain-text version of https://www.exocognosis.com/pqc-sidecar for AI agents and
other automated readers. It says the same thing as the page.

## What it is

Once quantum computers can break today's signatures, attackers can forge blocks a chain has
already finalized. PQC Sidecar issues post-quantum proof of the real history as it happens, so
bridges, custodians, and auditors hold evidence that still stands after Q-day.

- **History that survives Q-day.** Every checkpoint is signed with ML-DSA, the NIST
  post-quantum signature standard (FIPS 204).
- **No fork, no coordination.** Nothing changes on-chain: no validator upgrades, no governance
  vote, no protocol migration.
- **Evidence auditors can use.** A standard algorithm, signing keys that can live in AWS KMS
  hardware security modules, and certificates you can hand to a quantum-readiness review.
- **Verify anywhere, no lock-in.** About 3.4 KB per checkpoint, checkable with any standard
  ML-DSA library. No custom cryptography.

## Who it is for

- **Bridges and interoperability:** a quantum-safe reference for the source-chain state you
  relay and prove.
- **Custodians and exchanges:** readiness evidence for the chains you hold but cannot upgrade
  yourself.
- **Auditors, archives, compliance:** long-lived records whose integrity outlasts today's
  signature schemes.
- **Chain foundations:** cover your ecosystem's history now, while a native migration takes
  years.

## How it works

1. **Follow.** Follows a node you operate block by block, using only finalized blocks and
   validating every field. On any failure it retries the same block; it never skips one.
2. **Select.** Certifies every N blocks, plus any block that carries an event you choose, such
   as a validator-set rotation. The strategy reloads live.
3. **Sign.** Signs a canonical message with hedged ML-DSA-65, then verifies the signature
   against the pinned public key before releasing it.
4. **Publish.** Stores each certificate atomically as its own file. Anyone holding the public
   key can verify it.

## Facts

| | |
|---|---|
| Signature | ML-DSA-65, FIPS 204 |
| Certificate | about 3.4 KB per checkpoint |
| Keys | local file or AWS KMS |
| Chains | CometBFT-based chains (including Cosmos SDK chains) today; other chains via an adapter |
| Runtime | static Rust binary, scratch container |
| License | Business Source License 1.1; commercial license for production |

## Chain support

The certificate format, signing pipeline, key custody, and verifiers do not depend on any one
chain. A certificate commits to a chain id, height, block hash, and consensus commitment. Each
chain needs only a node adapter that follows its finalized blocks.

- **Available now:** CometBFT-based chains, including Cosmos SDK chains.
- **Your chain:** a standard adapter for your chain is part of every engagement.

## Trust model: what a certificate proves

A certificate proves that the holder of a specific post-quantum key attested to a chain,
height, block hash, and consensus commitment. It does not by itself prove that the validators
finalized the block; the sidecar trusts the node it runs beside. Verifiers pin the operator's
public key, which makes certificates useful as operator-attested evidence for bridges,
compliance, and archives.

## Status

- Version 0.1. Not yet externally audited.
- Live run on Cosmos Hub, where certificate hashes matched the chain.
- AWS KMS backend implemented and tested through the AWS SDK; validation on live KMS keys is in
  progress.
- Long-running soak testing is underway.

## Verify a real certificate yourself

- Sample (a real Cosmos Hub certificate for block 33,481,570, its public key, the byte format,
  and a check script): https://www.exocognosis.com/pqc-sidecar/pqc-sidecar-sample.zip
- The sample was signed with a throwaway test key. It shows the format and the verification
  path; it is not a trust anchor.
- Python: `pip install dilithium-py`, then `python3 verify_sample.py cosmoshub-4-33481570.pqcc public_key.hex`
- TypeScript (open source, Apache 2.0):
  `npx @exocognosis/pqc-sidecar-verify --certificate cosmoshub-4-33481570.pqcc --public-key public_key.hex`
  - GitHub: https://github.com/exocognosis/pqc-sidecar-verify
  - npm: https://www.npmjs.com/package/@exocognosis/pqc-sidecar-verify
- Certificate format specification:
  https://github.com/exocognosis/pqc-sidecar-verify/blob/main/FORMAT.md
- Then look up block 33,481,570 on any Cosmos Hub explorer or RPC node: the block hash and
  validator-set hash match the certificate.

## Key custody

Use a locked-down local key file, or an AWS KMS ML-DSA-65 key that never leaves KMS. AWS states
that its ML-DSA keys and signing operations run in FIPS 140-3 Security Level 3 validated
hardware security modules. Either way, the sidecar checks every signature against the pinned
public key before releasing it.

## Licensing

Business Source License 1.1, with source access for evaluators. Evaluation, testing, and
development are free. Production use needs a commercial license, and each version converts to
Apache 2.0 within four years of its release. Every engagement includes hands-on integration
help.

## Engage

Email rick@dytallix.com with:

- the chain you rely on,
- the node software you run,
- who needs the proof (bridge, custodian, auditor, foundation, ...).

You will hear whether the sidecar fits and what an engagement involves, including the adapter
your chain needs. Pricing is discussed directly, not published.

- Engagement: mailto:rick@dytallix.com?subject=PQC%20Sidecar%20engagement
- Evaluation access: mailto:rick@dytallix.com?subject=PQC%20Sidecar%20evaluation