q-armor-chain

The blockchain side of QArmor: a DVN worker whose attestations a quantum computer cannot forge.

Ethereum's signature envelope is ECDSA, and Shor breaks ECDSA. A bridge that trusts only that envelope inherits its expiry date. The attestation inside does not have to.

The DVN worker and contracts/QArmorDVN.sol. It listens for JobAssigned on the contract, verifies the payload with ML-DSA-65 (FIPS 204, not ECDSA) and posts the attestation on-chain. A quantum attacker can break Ethereum's ECDSA envelope; it cannot forge the attestation.

pip install q-armor-chain

Producer zero of the telemetry pipeline (INV-10, ADR-23)

This package does not talk to tx-platform, and that is not a convention: the worker receives no control-plane client, so it cannot. Its intelligence reaches the graph by pull, read from the on-chain events by q-chain-indexer.

It used to push a dvn_job_verified event for every job. Being best-effort and non-blocking did not save it: it was still a coupling route, and it was the estate's only live invariant violation.

The decoy survived the cut. The canary's URL was the useful content of that push: an attacker who harvested that HTTPS and decrypted it tomorrow found the URL and visited it. It now travels in the canary's registration in canary-network, which is a QArmor endpoint and not a source of the pipeline. With no canary_network_url configured there is no channel to harvest and the decoy is inert, exactly as it was before in open mode, and that is said rather than hidden.

Why this package still carries cryptography

The L2 emission (iden-q-post-quantum) publishes ML-KEM-768 and ML-DSA-44, in Python and in TypeScript. ML-DSA-65 is emitted by no language, and it is the one that signs these attestations. That is why q-armor-pqc still exists; see its README.

The QArmor family

Five packages, one version, published together from a single tag.

Next

idenq.io