ZK-PKI

What is ZK-PKI

ZK-PKI is a Substrate FRAME pallet that implements a blockchain-native Public Key Infrastructure. It solves a problem that no existing system has cleanly solved: proving that a blockchain address is controlled by a real human being, on real hardware, without surrendering biometric data to any authority.

The approach is simple. Every modern laptop and smartphone ships with a hardware security chip — a TPM or equivalent — that contains a cryptographic key burned in at manufacture. That key cannot be copied or faked. ZK-PKI uses that key to anchor an identity certificate on-chain. The certificate is an NFT. You own it. No issuer can take it from you.

ZK-PKI is live on Paseo testnet. 267 tests passing across pallet and runtime. Validated against real hardware: Samsung Galaxy S20+ and AMD Ryzen laptop.

The Ceremony

Minting a ZK-PKI certificate is called the ceremony. It is a multi-step process that concludes with an atomic on-chain transaction. Here is what happens:

1. 1

   Issuer creates a certificate template

   The issuer defines the terms: whether proof of personhood is required, the TTL bounds, the Extended Key Usages to grant, and the maximum number of certs that can be issued from this template.

2. 2

   Issuer makes an offer

   The issuer calls offer_contract for a specific user. The pallet generates a unique block-bound nonce and writes the offer to chain. The nonce expires if not consumed — replay is impossible by design.

3. 3

   Keypair and TOTP secret generated inside hardware

   The user's device — via the Dotwave app — generates a cert_ec keypair inside Android StrongBox or TPM. For proof-of-personhood certs, a TOTP secret is also generated atomically inside the same hardware. Neither the private key nor the TOTP secret ever leave the chip.

4. 4

   User authenticates with their device biometric

   An authenticator app uses the device's local biometric — face, fingerprint, or PIN — to produce a one-time password from the hardware-generated TOTP secret. The biometric never leaves the device. ZK-PKI never sees it. But a real person holding the physical device must be present.

5. 5

   User submits the mint transaction

   The user calls mint_cert with the attestation payload, their cert_ec public key, the OTP (for PoP certs), and the contract nonce. The pallet verifies everything atomically: attestation chain, EK deduplication, OTP, nonce. If anything fails, nothing is written.

6. 6

   Certificate minted as NFT

   The pallet computes a Blake2b-256 thumbprint, mints the NFT, writes hot and cold cert records, registers the EK hash in the deduplication registry, and distributes fees. All in a single atomic execution. The certificate now belongs to the user's SS58 address permanently.

Attestation Tiers

Not all hardware provides the same security guarantees. ZK-PKI recognizes three attestation types. The tier reflects how strongly the hardware can prove it has not been tampered with — and whether the cert is eligible for proof of personhood.

Roots and Issuers

ZK-PKI uses a three-tier trust hierarchy. Trust flows downward — roots issue to issuers, issuers issue to end users. There is no universal trust assumption at any tier. Relying parties decide which roots and issuers they accept.

Extended Key Usage inheritance

EKU capability flows strictly downward and cannot be amplified. An issuer cannot grant an end user an EKU that the issuer's root did not grant to the issuer. A root cannot grant an issuer the ProofOfPersonhood EKU unless the root itself holds it. This prevents privilege escalation at every layer of the hierarchy.

Root registration is open

There is no application process to become a root. Any entity with valid hardware attestation and a proxy account in pallet_proxy can call register_root. A newly registered root has minimal reputation. Relying parties are under no obligation to trust it. Trust is earned over time through the reputation scoring system, not granted at registration.

Reputation Scoring

Because root registration is open, ZK-PKI includes a reputation scoring system that tracks the behavior of roots and issuers over time. Relying parties can use reputation scores as a signal when deciding which trust chains to accept.

Reputation accrues from: certs issued without incident, longevity on-chain, hardware attestation tier of the root's own certificate, and the absence of compromise events. Reputation is damaged by: issuer invalidations, compromise flags, and address lineage to previously compromised entities.

If a compromised issuer's principals attempt to register a new root, the reputation system detects address lineage and flags the new root automatically. Bad actors cannot simply abandon a compromised identity and start fresh without consequence.

KYC vs No KYC

ZK-PKI does not require KYC. The protocol is agnostic. Whether an issuer performs identity verification before offering a certificate is entirely up to the issuer and their use case.

Without KYC

Any user with a compatible device can receive a certificate from an issuer that does not require KYC. A person with three devices — a phone, a second phone, a laptop — can hold three certificates. All three are valid. All three are hardware-anchored. None of them prove the three certs belong to the same person. For many use cases — machine identity, service authentication, developer access — this is exactly right.

With KYC

An issuer that is regulated — a bank, a government service, a licensed exchange — may be legally required to verify that a user meets certain criteria before opening an account or providing a service. That verification happens off-chain, on the issuer's own infrastructure. ZK-PKI does not touch it. Once the issuer is satisfied, they make a certificate offer. The user mints. The on-chain cert reflects that an issuer with a KYC obligation vouches for this identity.

KYC-backed issuers can enforce one-cert-per-person at the template level by setting max_certs and tracking their off-chain verification records against EK hashes. The hardware deduplication ensures that even if a user tries to enroll multiple devices, each enrollment is a distinct transaction the issuer must approve.

Proof of Personhood

A Proof of Personhood certificate is a ZK-PKI certificate issued under the ProofOfPersonhood Extended Key Usage. It carries a stronger set of guarantees than a standard cert.

What PoP proves

• 1

  Real hardware

  The cert is anchored to a physical TPM or Android StrongBox. The Endorsement Key cannot be faked or duplicated in software.

• 2

  One cert per device

  EK deduplication enforces exactly one active PoP cert per hardware root. Minting a second PoP cert on the same device is rejected at the protocol level.

• 3

  Physical presence at ceremony

  The TOTP secret is generated inside hardware and can only be unlocked by passing the device's own biometric check. A person who does not physically hold the device cannot complete the ceremony.

• 4

  Hardware continuity on every signing operation

  After genesis, every signing operation from a PoP-certified address requires a Hardware Integrity Proof — a fresh attestation that the device is the same device that enrolled, with its security posture unchanged.

What PoP does not prove

A PoP cert proves the above properties about the hardware. It does not prove that the person holding the hardware is who they claim to be, that they are an adult, that they are a citizen of any particular country, or that they have not enrolled a second device. Those claims require issuer-level KYC on top of the hardware guarantee.

Extrinsics

ZK-PKI exposes 19 extrinsics. Full parameter signatures, weight annotations, and error codes are in the SDK and the full specification.

Root and Issuer Management

• register_root Register a new root entity with hardware attestation and proxy account.
• issue_issuer_cert Root issues an issuer certificate to a candidate address.
• invalidate_issuer Root marks an issuer as compromised. Write-once.
• flag_root_compromised OpenGov-only. Records a root in the compromise registry.
• deregister_root Root voluntarily deregisters.
• challenge_compromise Root contests a compromise flag during the 45-day window.
• resolve_challenge Resolve a pending compromise challenge.

Certificate Lifecycle

• offer_contract Issuer offers a certificate to a user. Block-bound nonce generated.
• mint_cert User accepts an offer and mints their certificate.
• suspend_cert Issuer suspends a certificate. NFT remains with user.
• reactivate_cert Issuer reactivates a suspended certificate.
• invalidate_cert Issuer removes cert from lookup table. NFT remains.
• self_discard_cert User discards their own cert. Recovery path available for device loss.
• reissue_cert Atomic cert removal and new cert mint. Used for device replacement.
• renew_cert Extend cert validity within template TTL bounds.
• cleanup Anyone can reap an expired cert past the 60-day grace window and claim the deposit as a bounty.

Template Management

• create_cert_template Issuer creates a certificate template with policy parameters.
• deactivate_cert_template Mark template inactive. Blocks new offers.
• discard_cert_template Remove template entirely. Requires zero active certs.