Related · tier-1 reading. For what a portable artifact actually is, see Portable Artifact.
A ZK-STARK proof of secp256k1 private key knowledge, cryptographically bound to a three-family post-quantum identity via H33-74. When quantum arrives, the binding is already on-chain.
Pay-to-Public-Key (P2PK) outputs expose the secp256k1 public key on the blockchain. A quantum adversary running Shor's algorithm can derive the private key and spend those coins.
Including early Satoshi-era coinbase rewards. Public keys sitting on-chain, waiting for quantum.
Moving coins to a new address costs transaction fees and breaks UTXO history. Proof of life costs nothing on-chain.
The ZK-STARK proof reveals nothing about the private key. Not a single bit. Not to anyone. Not ever.
Pre-quantum migration. You prove you control a classical key today and bind that proof to a post-quantum identity. The binding is timestamped, three-family PQ-signed, and anchored to Bitcoin. When quantum arrives, the record is already on-chain and unforgeable.
Proof of life does not make your classical key quantum-resistant. The secp256k1 private key is still classical. A quantum computer can still derive it from the public key. What proof of life provides is a cryptographic record — created before quantum — that proves who controlled the key and when they migrated to a PQ identity. The key stays classical. The attestation is quantum-resistant.
Six steps from private key control to Bitcoin-anchored post-quantum attestation.
Confirm pk = sk · G on secp256k1. The prover actually knows the private key.
Build a 256-row execution trace (one per scalar bit). Projective coordinates, 8×32-bit non-native Goldilocks limbs. 836 constraints per row. ~213,000 total. The private key is used here and nowhere else.
SHA3-256 of the STARK proof's Merkle roots (trace + constraint commitments via FRI). This 32-byte hash is the proof commitment — the proof itself is not stored.
Domain-tagged digest: SHA3-256(h33:proof-of-life:v1: || proof || pk || pq_pk_hash || nonce). This binds the classical key proof to a specific three-family post-quantum key set.
Type 0x12 (PostQuantumMigration). The binding digest becomes the content field of a 58-byte H33-74 primitive.
ML-DSA-65 (MLWE) + FALCON-512 (NTRU-SIS) + SLH-DSA-SHA2-128f (hash). Or the NIST Level 5 composition for maximum security. Anchor the 32-byte signing message to Bitcoin via Taproot tweak. No fork. No new opcodes.
Same 74-byte footprint. Same API. Same Bitcoin anchor. Different weight class.
| Property | NIST Level 1 (Default) | NIST Level 5 (Premium) |
|---|---|---|
| Slot 1 | ML-DSA-65 (3,309 B sig) | ML-DSA-87 (4,627 B sig) |
| Slot 2 | FALCON-512 (~666 B sig) | FALCON-1024 (~1,280 B sig) |
| Slot 3 | SLH-DSA-SHA2-128f (17,088 B sig) | SLH-DSA-SHA2-256f (49,856 B sig) |
| Bundle size | ~21 KB ephemeral | ~56 KB ephemeral |
| Persistent footprint | 74 bytes | 74 bytes (identical) |
| Sign time (release) | ~5 ms | ~20 ms |
| NIST security level | Bounded at Level 1 | Uniform Level 5 |
| Target use case | Production pipeline (2.17M auth/sec) | High-value Bitcoin holdings |
Cold STARK proof generation + Cachee-backed caching for repeat attestations.
| Metric | Apple Silicon (Release) | Graviton4 (Release) |
|---|---|---|
| Cold proof generation | 495 ms | 813 ms |
| Cached proof generation | 14.5 ms (34x) | — |
| Verification | 800 µs | — |
| Cached verification | <1 µs | — |
Differential testing against k256 (RustCrypto) as a trusted oracle. 1,100 keys. Zero mismatches.
Differential testing caught a modular multiplication error in the native secp256k1 field arithmetic. The original bit-by-bit shift reduction produced correct results for sk=1 but diverged from k256 for sk≥2. The bug was invisible to internal consistency testing because the AIR constraints faithfully encoded the incorrect arithmetic — prover and verifier agreed on the wrong answer. Only oracle-based differential testing detected it. Fixed with num-bigint. All 1,100 keys match k256 exactly after the fix. We consider this a strong argument for mandatory oracle testing of any ZK circuit with non-native field arithmetic.
The holder knows the private key corresponding to a specific secp256k1 public key, without revealing the private key. Zero-knowledge. Post-quantum sound (STARK, not SNARK).
ZK-STARKThat knowledge is cryptographically bound to a specific three-family post-quantum key set via a domain-tagged SHA3-256 commitment. Changing the PQ key requires a new proof (requires the private key).
H33-74 type 0x12The binding is attested via H33-74 with a millisecond timestamp and, optionally, a Bitcoin anchor (Taproot tweak or OP_RETURN). The record is immutable, globally verifiable, and quantum-resistant.
Bitcoin anchor| Property | Proof of Life (H33-74) | QSB / BINOHASH |
|---|---|---|
| What it protects | Key control attestation | UTXO spending |
| Where it lives | Application layer | Bitcoin script layer |
| What it proves | "I controlled this key at this time" | "This spend is quantum-safe" |
| Fork required | No | No |
| Coins moved | Zero | Yes (spending tx) |
| Composable | Yes — deploy both for full coverage | |
Proof of Life is one computation type minted on the H33-74 primitive. H33-74 is the portable 74-byte post-quantum proof — a 32-byte on-chain commitment plus a 42-byte off-chain receipt, signed under three independent NIST families (ML-DSA, FALCON, SLH-DSA). The proof and its verification come from that cryptography. The Bitcoin anchor is one interchangeable notarization medium for the commitment; it adds an immutable public timestamp but is never the source of the proof or the trust. What differs between blockchains are their operational and integration characteristics. The H33-74 primitive and its cryptographic properties remain unchanged.
H33-74 produces and anchors the portable proof primitive. It does not monitor systems for control drift (that is HATS), it does not render the pass/fail verdict on an attestation (an independent verifier does — see Verification), and it does not govern agents or preserve decision authority (that is Agent-008).
| Does anchoring on Bitcoin change the proof? | No. The proof is the ZK-STARK-plus-PQ binding attested in the H33-74 receipt. The Bitcoin anchor adds an immutable public timestamp; it does not alter the receipt, its signatures, or what the verifier checks. |
| Is the trust from Bitcoin or from H33-74? | From H33-74. Trust rests on the ZK-STARK, the three post-quantum signatures, and the open-source verifier — not on Bitcoin. Bitcoin provides an anchoring medium, never the proof. |
| Can the attestation move to another chain? | Yes. The receipt is chain-portable; anchor the same unchanged receipt elsewhere. Migrating chains changes the anchoring substrate, not the H33-74 primitive, the cryptographic evidence, or the verification model. |
| Does proof of life make my classical key quantum-resistant? | No. The secp256k1 key stays classical and a quantum computer can still derive it from the public key. Proof of life provides a pre-quantum, quantum-resistant record of who controlled the key and when they bound it to a PQ identity. |
The verifier is open source. The construction is in the whitepaper. The circuit audit is public.