An Open Standard for Deterministic, Post-Quantum-Safe Custody, Compliance, and AI Operations
- Specification Version: 2.0.0
- Status: Public beta
- Date: 2026
- Author: rosiea
- Contact: PQRosie@proton.me
- Licence: Apache License 2.0 — Copyright 2026 rosiea
PQ is a composed ecosystem of specifications that eliminates entire classes of security failures present in modern systems while ensuring cryptographic agility for the post-quantum transition.
Most post-quantum projects focus narrowly on future cryptography. PQ addresses attacks that succeed daily—replay, time forgery, silent runtime compromise, consent reuse, execution-gap exploitation—while preparing for quantum-capable adversaries.
PQ replaces trust assumptions with explicit, verifiable predicates. No component grants authority in isolation. All enforcement flows through a single deterministic core: PQSEC.
This document is a conceptual overview and ecosystem guide. For normative enforcement semantics, predicate definitions, and implementation requirements, see PQSEC.
This section is NOT part of the conformance surface.
It is provided for explanatory and onboarding purposes only.
PQ is a family of specifications that work together to provide deterministic, auditable security for custody, AI operations, and regulated transactions. Each specification produces evidence or defines structure. None grants authority alone. Authority emerges only when all required predicates are satisfied and evaluated by PQSEC.
| PQ IS | PQ IS NOT |
|---|---|
| An ecosystem of composed specifications | A single monolithic protocol |
| A conceptual and architectural framework | An enforcement engine (that's PQSEC) |
| A guide to component relationships | A replacement for component specs |
| Post-quantum ready | Post-quantum only |
Nothing grants authority. Everything produces evidence. PQSEC refuses or doesn't refuse.
That's the entire security model.
Modern systems fail because they assume:
- clocks are honest
- runtimes are stable
- models behave consistently
- signatures imply authority
- stored data can be protected indefinitely
These assumptions are routinely false. PQ replaces them with structural guarantees: explicit verification of time, runtime state, intent, consent, policy, and authority—all enforced deterministically through a single refusal-only core.
| If you want to... | Start with... |
|---|---|
| Understand the architecture | This document (PQ) |
| Implement enforcement | PQSEC — the enforcement core |
| Implement Bitcoin custody | PQHD → PQSEC |
| Implement AI governance | PQAI → PQSEC |
| Understand time semantics | Epoch Clock |
| Understand encoding rules | PQSF |
| Implement execution boundaries | ZET/ZEB → PQEH |
┌─────────────────────────────────────────┐
│ PQ (this document) │
│ Conceptual hub and guide │
└─────────────────────────────────────────┘
│
┌─────────────────────────────┼─────────────────────────────┐
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Epoch Clock │ │ PQSF │ │ PQVL │
│ Verifiable │ │ Canonical │ │ Runtime │
│ Time │ │ Encoding │ │ Attestation │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
└────────────────────────────┼────────────────────────────┘
│
▼
┌───────────────────────┐
│ PQSEC │
│ ━━━━━━━━━━━━━━━━━━━ │
│ ENFORCEMENT CORE │
│ All authority flows │
│ through here │
└───────────┬───────────┘
│
┌──────────────┬───────────┼───────────┬──────────────┐
│ │ │ │ │
▼ ▼ ▼ ▼ ▼
┌───────────┐ ┌───────────┐ ┌─────────┐ ┌─────────┐ ┌────────────┐
│ PQHD │ │ PQAI │ │ ZET/ZEB │ │ PQEH │ │Neural Lock │
│ Custody │ │ AI │ │Execution│ │Quantum │ │ Human │
│ Policy │ │ Identity │ │Boundary │ │Hardening│ │ State │
└───────────┘ └───────────┘ └─────────┘ └─────────┘ └────────────┘
All specifications in the PQ ecosystem produce evidence or define structure. No specification grants authority in isolation. All enforcement and refusal semantics are defined exclusively by PQSEC.
| Specification | Depends On |
|---|---|
| PQSEC | PQSF, Epoch Clock, PQVL |
| PQHD | PQSEC, PQSF, Epoch Clock |
| PQAI | PQSEC, PQSF, Epoch Clock, PQVL |
| ZET / ZEB | PQSEC, Epoch Clock |
| PQEH | PQSEC, PQHD, ZET / ZEB, Epoch Clock |
| Neural Lock | PQSEC, PQSF, PQHD, Epoch Clock |
| PQVL | PQSF, Epoch Clock |
| Epoch Clock | Bitcoin |
| PQSF | Epoch Clock |
PQ does not ask “is this allowed?” It asks “is there any reason to refuse?”
No artefact, key, model, device, or component grants authority. An operation proceeds only if PQSEC does not refuse it after evaluating all required predicates.
This is not a semantic distinction. It changes the failure mode from “fail-open on missing permission” to “fail-closed on missing evidence.”
Every component except PQSEC produces evidence:
| Component | Produces |
|---|---|
| Epoch Clock | Time artefacts (ticks) |
| PQVL | Runtime attestation envelopes |
| PQAI | Model identity, behavioural fingerprints, drift classification |
| PQHD | Custody policy, predicate requirements |
| ZET/ZEB | Execution intents and results |
| Neural Lock | Operator state attestations |
None of these artefacts carry authority. They are inputs to PQSEC, which produces the sole authoritative output: an EnforcementOutcome.
PQSEC is the only component that produces enforcement decisions.
Any parallel enforcement logic outside PQSEC is non-conformant and creates bypass vectors. This is not a recommendation; it is a structural requirement.
Given identical inputs, PQSEC produces identical outputs. There is no probabilistic evaluation, no heuristic judgment, no “usually works.” Enforcement is reproducible and auditable.
Uncertainty results in refusal:
- Missing input → refuse
- Non-canonical encoding → refuse
- Ambiguous time → refuse
- Unverifiable signature → refuse
- Partial predicate satisfaction → refuse
There are no degraded modes for Authoritative operations.
Across the entire PQ ecosystem, enforcement authority is centralized.
- Only PQSEC MAY emit an authoritative ALLOW outcome for any operation attempt.
- No other specification, component, artefact, or subsystem MAY emit any signal whose semantics imply permission, approval, or execution capability.
- All other specifications define structure or produce evidence only. They MUST NOT grant authority, directly or indirectly.
- Any implementation that produces an allow or approval signal outside PQSEC is non-conformant and creates enforcement bypass vectors.
This invariant applies uniformly across custody, execution, time, runtime attestation, AI operations, and human-state extensions.
Problem: System clocks lie. Network time can be manipulated.
Solution: Bitcoin-anchored, threshold-signed time artefacts.
Epoch Clock produces signed ticks that can be verified independently. Profiles are inscribed as Bitcoin ordinals (immutable). Ticks are distributed via mirrors without trust requirements. Consumers verify signatures locally.
Epoch Clock produces time artefacts only. It does not enforce freshness—PQSEC does.
Specification: Epoch Clock v2.1.1
Problem: Ambiguous encoding breaks signatures. Algorithm transitions break systems.
Solution: Deterministic CBOR, JCS Canonical JSON (for Epoch Clock), and CryptoSuiteProfile indirection.
PQSF defines how artefacts are encoded, hashed, and signed. It provides cryptographic agility through profile references—algorithm changes don't require architectural changes.
PQSF defines grammar and encoding only. It grants no authority.
Specification: PQSF v2.0.2
Problem: Compromised runtimes produce compromised outputs.
Solution: Deterministic probe collection, baseline comparison, and drift classification.
PQVL produces attestation envelopes describing measured runtime state. Drift is classified as NONE, WARNING, or CRITICAL. Attestation is evidence, not permission—PQSEC decides what to do with it.
Specification: PQVL v1.0.3
Problem: Distributed enforcement creates bypass vectors.
Solution: Single, deterministic, refusal-only enforcement authority.
PQSEC consumes evidence from all other components and produces exactly one outcome per operation: ALLOW, DENY, or FAIL_CLOSED_LOCKED. It evaluates predicates, enforces freshness and monotonicity, manages lockout, and maintains audit trails.
PQSEC is where authority lives. All other components feed into it.
Specification: PQSEC v2.0.2
Session continuity and optional session resumption are treated as evidence-only mechanisms. Any reuse of session state across connections is subject to deterministic evaluation by PQSEC and MUST NOT bypass time, policy, consent, runtime, or ledger predicates.
Normative enforcement rules for session resumption, when enabled by policy, are defined exclusively in PQSEC.
Problem: Key possession is treated as authority. Keys can be stolen.
Solution: Predicate-driven custody where keys are necessary but not sufficient.
PQHD defines what must be true before Bitcoin signing is allowed: time bounds, consent, policy, runtime integrity, quorum, ledger continuity. Key possession alone conveys no authority.
PQHD defines custody policy. PQSEC enforces it.
Specification: PQHD v1.1.0
Problem: Executable artefacts exist before authorization completes, enabling front-running and reaction attacks.
Solution: Strict phase separation between intent and execution.
ZET defines a rail-agnostic execution boundary: intents are non-authoritative and safe to observe; execution occurs only after PQSEC approval. ZEB implements the Bitcoin profile with broadcast discipline and exposure detection.
ZET/ZEB provide execution mechanics only. They grant no authority.
Specification: ZEB v1.2.0 (includes ZET)
Problem: Classical signatures can be observed before broadcast, enabling quantum pre-construction attacks.
Solution: S1/S2 revelation pattern that denies pre-construction.
PQEH separates commitment (S1, non-executable) from execution revelation (S2). No valid transaction exists until S1 is revealed, which happens only after PQSEC approval and immediately before broadcast. This reduces the quantum attack window from signing-to-confirmation to broadcast-to-confirmation.
PQEH does not provide full post-quantum immunity (a Bitcoin consensus limitation). It provides state-of-the-art denial-of-pre-construction within current consensus.
Specification: PQEH v2.1.1
Problem: AI systems cannot be trusted to self-assert safety or permission.
Solution: Externalized behavioural verification through inspectable artefacts.
PQAI defines model identity binding, behavioural fingerprinting, drift detection, and SafePrompt consent binding. Models cannot self-classify their action authority. PQSEC gates AI operations based on PQAI artefacts.
Specification: PQAI v1.1.1
Problem: Coercion attacks succeed because keys equal authority.
Solution: Operator state as an additional predicate dimension.
Neural Lock produces attestations about human cognitive/physiological state (NORMAL, STRESSED, DURESS, IMPAIRED). It does not authorize or sign transactions—it provides evidence that PQSEC can use to gate high-risk operations.
Neural Lock is optional and deployment-specific.
Specification: Neural Lock v1.0.0
PQ structurally eliminates the following failure classes:
| Failure Class | Eliminated By |
|---|---|
| Replay attacks | Epoch Clock ticks + single-use binding |
| Time forgery | Bitcoin-anchored, threshold-signed time |
| Silent runtime compromise | PQVL attestation + PQSEC drift gating |
| AI behavioural drift | PQAI fingerprinting + drift classification |
| Consent reuse | Session-bound, single-use ConsentProof |
| Execution-gap attacks | ZET boundary + PQEH S1/S2 pattern |
| Key-equals-authority | PQHD predicate composition |
| Distributed enforcement bypass | PQSEC consolidation |
These are structural guarantees, not probabilistic mitigations.
PQ explicitly does NOT define:
- Identity federation or SSO protocols
- OAuth, JWT, SAML, or X.509 compatibility
- Transport-layer authorization
- Optimistic execution models
- Heuristic or probabilistic enforcement
- Implicit trust assumptions
- Privacy or anonymity guarantees
- Censorship resistance
- Miner behaviour or mempool strategy
These are either out of scope or explicitly rejected as incompatible with PQ’s security model.
-
Emergency Revocation and Kill-Switches:
PQ does not define emergency revocation or “kill switch” orchestration at the ecosystem level.
Revocation semantics, including identity or session invalidation under compromise, are expected to be defined by producing specifications and enforced by PQSEC through existing refusal, lockout, and monotonicity guarantees. -
Hardware-Rooted Attestation:
PQ does not define manufacturer trust anchors, hardware roots of trust, or device-specific measurement grammars (e.g., TPM, SGX, TEE).
Where hardware attestation is required, it MUST be provided by an external producing specification and consumed as evidence by PQSEC. PQ intentionally avoids embedding vendor- or jurisdiction-specific trust assumptions into the core ecosystem. -
Social Recovery Orchestration:
While PQ supports multi-signature custody models, guardian quorums, and recovery delays via PQHD and PQSEC, it does not define the user-experience, communication, or coordination protocols for social recovery.
Recovery orchestration is the responsibility of the implementing wallet or custody service.
An implementation claiming PQ ecosystem conformance MUST:
- Delegate all enforcement to PQSEC
- Use Epoch Clock ticks for all time references
- Use PQSF canonical encoding for all signed/hashed artefacts
- Treat no artefact as authoritative until PQSEC evaluation
- Fail closed on any ambiguity, missing input, or verification failure
Each component specification defines its own conformance requirements. See individual specifications for details.
The following patterns are explicitly non-conformant:
- Parallel enforcement logic outside PQSEC
- System clock usage for authority decisions
- Non-canonical encoding of signed artefacts
- Implicit trust in network identity, coordinator identity, or mirror identity
- Degraded modes for Authoritative operations
- Model self-assertion of action class or permission
The following specification versions are aligned and implementation-ready within the PQ ecosystem:
| Specification | Version | Status |
|---|---|---|
| PQ (this document) | 2.0.0 | Implementation Ready |
| Epoch Clock | 2.1.1 | Implementation Ready |
| PQSF | 2.0.2 | Implementation Ready |
| PQSEC | 2.0.2 | Implementation Ready |
| PQVL | 1.0.3 | Implementation Ready |
| PQHD | 1.1.0 | Implementation Ready |
| ZEB (includes ZET) | 1.2.0 | Implementation Ready |
| PQEH | 2.1.1 | Implementation Ready |
| PQAI | 1.1.1 | Implementation Ready |
| Neural Lock | 1.0.0 | Domain Evaluation Requested |
The following specifications are formally deprecated and MUST NOT be used in new implementations:
| Specification | Status | Superseded By |
|---|---|---|
| UDC (User-Defined Control) | DEPRECATED | PQAI + PQSEC |
PQ assumes adversaries may:
- Compromise individual devices, coordinators, or mirrors
- Manipulate system clocks and network time
- Replay, reorder, or suppress messages
- Present stale or fabricated artefacts
- Possess future quantum computation capability
- Exploit ambiguity in encoding or representation
- Attempt model substitution or behavioural manipulation
- Coerce or impersonate legitimate operators
PQ operates under minimal trust assumptions:
- Bitcoin blockchain consensus is honest majority
- Threshold signature schemes resist minority compromise
- Hash functions (SHA-256, SHAKE-256) are pre-image resistant
- Cryptographic verification is performed locally
- Canonical encoding eliminates representation ambiguity
PQ does NOT assume:
- Trusted system clocks
- Trusted networks or coordinators
- Trusted runtimes without attestation
- Honest model self-reporting
- Secrecy of classical key material (for post-quantum readiness)
PQ does not protect against:
- Total compromise of all threshold signers
- Bitcoin consensus failure
- Post-broadcast quantum attacks (within current Bitcoin consensus)
- Long-term captivity with patient adversaries
- Miner censorship or transaction exclusion
These are acknowledged limitations, not specification failures.
The following predicates are evaluated by PQSEC. This list is informative only; see PQSEC for normative definitions, evaluation rules, and enforcement semantics.
Predicates listed here do not grant authority. They are evaluated exclusively by PQSEC according to the active enforcement configuration and policy.
| Predicate | Evaluated From |
|---|---|
| valid_structure | PQSF canonical encoding |
| valid_tick | Epoch Clock artefacts |
| valid_policy | Policy bundles |
| valid_runtime | PQVL AttestationEnvelope |
| valid_consent | ConsentProof artefacts |
| valid_quorum | Custody quorum satisfaction |
| valid_ledger | Ledger continuity |
| valid_action_class | PQAI action classification |
| valid_model_identity | PQAI ModelIdentity |
| valid_drift | PQAI drift classification |
| valid_delegation | DelegationConstraint artefacts |
| valid_guardian_quorum | Guardian approvals |
| recovery_delay_elapsed | Time since RecoveryIntent |
| safe_mode_active | SafeModeState |
| valid_payment_endpoint | PaymentEndpointKey |
| operator_state_ok | Neural Lock attestation |
| valid_build_provenance | BuildAttestation and related supply-chain artefacts |
| valid_runtime_signature | RuntimeSignature |
| valid_publish_signature | PublishSignature |
| valid_operation_key | OperationKey |
| valid_audit_chain | AuditSignature and ledger continuity |
- Predicates are refusal-only signals.
- No predicate grants authority, permission, or execution capability.
- Absence of a predicate requirement MUST NOT be interpreted as trust.
- Supply-chain predicates are evaluated only when explicitly required by policy or enforcement configuration.
- All enforcement, refusal, escalation, and lockout behaviour is defined exclusively by PQSEC.
This annex provides a reference map only. Normative behaviour is defined by PQSEC.
Artefact — A cryptographically signed, canonically encoded data structure produced by a PQ component.
Authoritative Operation — An operation with irreversible effects (signing, custody mutation, policy change). Requires PQSEC ALLOW outcome.
Drift — Measured deviation from baseline behaviour. Classified as NONE, WARNING, or CRITICAL.
EnforcementOutcome — The authoritative decision produced by PQSEC: ALLOW, DENY, or FAIL_CLOSED_LOCKED.
Epoch Clock Tick — A signed, monotonic time artefact anchored to Bitcoin.
Execution Gap — The dangerous period when executable artefacts exist before authorization completes.
Fail-Closed — Security posture where uncertainty results in refusal rather than permission.
Non-Authoritative Operation — A read-only operation with no irreversible effects.
Predicate — A boolean condition that must be satisfied for an operation to proceed.
Refusal-Only — Enforcement model where the engine only refuses; it never grants authority.
S1/S2 Pattern — PQEH revelation pattern separating commitment (S1) from execution capability (S2).
- Enforcement Centralization: Centralized all enforcement logic and authority decisions into a single deterministic core: PQSEC.
- Scope Expansion: Shifted from "PQ-ready" cryptography to addressing modern execution-gap exploits, including replay, time forgery, and consent reuse.
- Structural Decoupling: Redefined the relationship between modules (Clock, VL, AI) such that no component grants authority in isolation; they now provide verifiable predicates for the core enforcement layer.
- Deprecation Management: Formally retired the UDC specification and migrated its normative functions into PQAI and PQSEC.
The PQ ecosystem builds on decades of work in cryptography, distributed systems, protocol design, and adversarial security analysis.
- Satoshi Nakamoto — for Bitcoin's trust-minimised consensus model
- Whitfield Diffie and Martin Hellman — for public-key cryptography
- Ralph Merkle — for Merkle trees and tamper-evident structures
- Daniel J. Bernstein — for cryptographic engineering and constant-time design
- The NIST Post-Quantum Cryptography Project — for standardising post-quantum primitives
- The IETF CBOR, COSE, and TLS working groups — for canonical encoding and session binding primitives
- Bitcoin Core developers and BIP contributors — for PSBT, Taproot, and script semantics
- Zero-trust architecture researchers — for refusal-based security models
- Byzantine fault tolerance researchers — for threshold and quorum patterns
- Stuart Russell, Paul Christiano, and AI alignment researchers — for externalised oversight models
- Anthropic, OpenAI, and model evaluation researchers — for behavioural analysis frameworks
This ecosystem was developed through extensive collaboration with AI systems, demonstrating that human-AI partnership can produce rigorous, auditable security specifications. The architectural patterns, authority boundaries, and fail-closed semantics emerged from iterative refinement across hundreds of review cycles.
Any errors or omissions remain the responsibility of the author.
If you find this work useful and want to support continued development:
Bitcoin:
bc1q380874ggwuavgldrsyqzzn9zmvvldkrs8aygkw