Metadata-Version: 2.5
Name: q-armor-chain
Version: 0.1.0
Summary: QArmor blockchain side: the DVN worker and QArmorDVN.sol. Producer zero of the telemetry pipeline (INV-10).
License-Expression: LicenseRef-Proprietary
License-File: LICENSE
Requires-Python: >=3.11
Requires-Dist: httpx>=0.27
Requires-Dist: q-armor-lib==0.1.0
Requires-Dist: q-armor-pqc==0.1.0
Requires-Dist: web3>=6.0
Description-Content-Type: text/markdown

# q-armor-chain

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

[![PyPI](https://img.shields.io/pypi/v/q-armor-chain.svg)](https://pypi.org/project/q-armor-chain/)
[![Python](https://img.shields.io/pypi/pyversions/q-armor-chain.svg)](https://pypi.org/project/q-armor-chain/)
[![Licence](https://img.shields.io/badge/licence-proprietary-1f6feb.svg)](https://idenq.io)
[![FIPS 204](https://img.shields.io/badge/NIST-ML--DSA--65-000000.svg)](https://csrc.nist.gov/pubs/fips/204/final)

> 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.

```bash
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`](https://pypi.org/project/q-armor-pqc/) still exists; see its
README.

## The QArmor family

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

| Package | What it is |
|---|---|
| [`q-armor-lib`](https://pypi.org/project/q-armor-lib/) | Detection, scoring and the control-plane client |
| [`q-armor-cli`](https://pypi.org/project/q-armor-cli/) | `q-armor`, the operator's command line |
| [`q-armor-proxy`](https://pypi.org/project/q-armor-proxy/) | Enterprise runtime: protection proxy, firewall, SIEM webhook |
| [`q-armor-chain`](https://pypi.org/project/q-armor-chain/) | This one: the DVN worker and `QArmorDVN.sol` |
| [`q-armor-pqc`](https://pypi.org/project/q-armor-pqc/) | Interim ML-DSA-65 primitive |

## Next

[idenq.io](https://idenq.io)
