Biometric Proof-of-Humanity Operational Specification

Executive Summary

This document resolves four open operational questions that remained after the BPoH Implementation Specification was finalized. While the implementation spec defined the core architecture - multi-modal biometric capture, zero-knowledge privacy, soulbound Humanity NFTs, and smart contract design - it intentionally deferred several policy-level decisions that require cross-team alignment.

The four questions addressed here are: (1) minimum device capability requirements for enrollment, (2) re-verification cadence and trigger policies, (3) the governance process for revoking and appealing Humanity NFT status, and (4) selection of ZK proving systems for on-chain and off-chain verification.

These decisions collectively ensure that BPoH is accessible to the widest possible user base (three device tiers), maintains ongoing verification integrity (hybrid re-verification model), provides fair recourse for false revocations (three-level appeals), and minimizes gas costs while preserving cryptographic flexibility (multi-system ZK approach).

Device Capability Tiers

BPoH enrollment quality depends directly on the hardware capabilities of the user's device. Rather than imposing a single high bar that excludes a large portion of potential users, the protocol defines three enrollment tiers. Each tier corresponds to a set of minimum hardware requirements, a subset of available biometric modalities, and a maximum humanity score.

Tier Definitions

Tier 1 - Full BPoH

Tier 1 devices support the complete multi-modal biometric capture pipeline. The TrueDepth or IR camera enables 3D face recognition with depth mapping, which is the primary defense against deepfake and photo replay attacks. Combined with voice print analysis, behavioral biometrics, and randomized liveness challenges, Tier 1 enrollment achieves a combined false-accept rate below one in ten million.

The TEE (Trusted Execution Environment) or Secure Enclave requirement ensures that biometric feature extraction and ZK proof generation occur in a hardware-isolated context. This prevents malware on the device from intercepting raw biometric data or tampering with the proof construction process.

Tier 2 - Partial

Tier 2 devices lack the structured-light camera required for 3D face recognition but can still perform voice print analysis and behavioral biometric capture. The humanity score cap of 70 reflects the reduced confidence from omitting the strongest biometric modality. Users enrolled at Tier 2 receive basic protection coverage and can participate in governance, but cannot access Premium tier benefits.

Tier 3 - Desktop/Webcam

Tier 3 exists to provide an onboarding path for users who only have access to a desktop or laptop with a standard webcam. Enrollment is limited to behavioral biometrics (typing rhythm, mouse dynamics) and basic liveness detection. The humanity score is capped at 40, and users must upgrade to a Tier 1 or Tier 2 device within 90 days or their Humanity NFT will be suspended.

Tier Detection and Enforcement

The BPoH enrollment client performs automatic hardware capability detection at the start of the enrollment flow. The detected tier is included in the enrollment metadata and signed by the device's TEE attestation (for Tier 1) or by a software-based attestation (for Tier 2/3). The BiometricHumanity contract enforces the score cap based on the declared tier, and validators independently verify the tier claim against the submitted proof structure.

Re-verification Policy

A one-time enrollment is insufficient for a production identity system. Users may pass enrollment legitimately and later compromise their credentials, or biometric models may drift over time as users age. The re-verification policy defines when and why a user must re-confirm their humanity.

Cadence Schedule

Grace Period and Notifications

When a re-verification deadline approaches, the system issues push notifications at three intervals: 30 days before expiry, 7 days before expiry, and 1 day before expiry. After the deadline passes, a 7-day grace period begins during which the user can still complete re-verification without any service interruption.

If the grace period expires without re-verification, the Humanity NFT is suspended (not revoked). Suspended NFTs cannot be used for governance votes, protection claims, or gated transactions, but they can be reactivated by completing re-verification at any time. No appeals process is needed for suspension due to expiry - the user simply re-verifies.

Transaction-Triggered Re-verification

The compliance engine computes a per-transaction risk score based on amount, counterparty history, geographic signals, and behavioral patterns. When any single transaction scores above 0.8, the system requires immediate re-verification before the transaction can settle. This is a blocking check - the transaction is held in pending state until re-verification completes or the 24-hour timeout expires (at which point the transaction is rejected).

Risk-Triggered Re-verification

A cumulative risk score is maintained per wallet, calculated as an exponentially-weighted moving average of recent transaction risk scores. When this cumulative score exceeds 0.9, the system demands immediate re-verification regardless of the calendar-based schedule. This catches gradual escalation patterns that no single transaction would trigger on its own.

Revocation Governance

Revoking a Humanity NFT is a serious action that removes a user's ability to participate in BPoH-gated activities across the entire JIL ecosystem. False revocations - whether caused by biometric model drift, device malfunction, or adversarial reporting - must have a clear and fair appeals path. This section defines the three-level appeals process and the emergency pause mechanism.

Three-Level Appeals Process

Level 1 - Automated Re-evaluation

The simplest appeal path. The user opens the BPoH enrollment client and re-submits their biometrics. The system runs the full verification pipeline again, including liveness detection, and compares the result against the original enrollment data. If the new submission passes all checks and the biometric hash matches the original enrollment (within the configured tolerance), the revocation is automatically overturned and the Humanity NFT is reactivated.

Level 1 is rate-limited to 3 attempts per calendar year to prevent abuse. Each attempt is logged on-chain with a timestamp, and the rate limit is enforced by the BiometricHumanity contract.

Level 2 - Human Review

If Level 1 fails or the user believes the automated system is producing incorrect results, they can file a Level 2 appeal. This routes the case to a certified BPoH reviewer - a human operator who has passed JIL's reviewer certification program and is bound by confidentiality agreements.

The reviewer receives: the revocation reason code, the anonymized biometric confidence scores from both the original enrollment and the failed re-verification, device attestation metadata, and any risk flags from the compliance engine. The reviewer does not receive raw biometric data. The 10 JIL filing fee is fully refunded if the reviewer overturns the revocation.

Level 3 - Validator Vote

The highest appeals level. The user stakes 100 JIL and submits a formal appeal to the validator set. A 14-day voting window opens during which validators review the case materials (same anonymized data as Level 2, plus the Level 2 reviewer's decision and reasoning). A 7-of-20 validator quorum is required to overturn the revocation. If the appeal succeeds, the 100 JIL stake is returned in full.

Emergency Pause Mechanism

An emergency committee of 3-of-5 designated key holders can instantly suspend any Humanity NFT pending investigation. This is designed for time-sensitive situations such as credible reports of identity theft, active exploitation of a compromised enrollment, or law enforcement requests with proper legal process.

Emergency pauses auto-expire after 24 hours unless explicitly extended by the committee. Extensions require a new 3-of-5 signature and can be renewed in 24-hour increments up to a maximum of 7 days. After 7 days, the pause must either be converted to a formal revocation (which enters the appeals process) or be lifted entirely.

ZK Proving System Selection

The choice of zero-knowledge proving system has direct implications for gas costs, proof generation time, trusted setup requirements, and upgrade flexibility. Rather than committing to a single system, BPoH employs a multi-system approach that uses the optimal proving system for each operational context.

System Selection Matrix

Groth16 - Primary On-Chain System

Groth16 is selected as the primary proving system for on-chain BPoH enrollment verification because it offers the lowest gas cost (~230K gas per verification) and the smallest proof size (~128 bytes). These properties are critical for an operation that every user performs at least once and that is verified on-chain by the BiometricHumanity contract.

The main tradeoff is the requirement for a circuit-specific trusted setup. Any change to the enrollment verification circuit (such as adding a new biometric modality or updating the hash function) requires a new MPC ceremony. JIL mandates a minimum of 100 participants in each ceremony, sourced from the validator set, independent security researchers, and community contributors. As long as at least one participant is honest, the setup is secure.

PLONK - Circuit Upgrade Flexibility

PLONK serves as the secondary on-chain proving system, activated when the enrollment circuit requires updates that would necessitate a new Groth16 trusted setup. PLONK uses a universal reference string that does not need to be regenerated when the circuit changes, allowing rapid deployment of circuit updates.

The gas cost premium (~330K vs ~230K, approximately 43% higher) is acceptable for transitional periods. Once a new Groth16 ceremony is completed for the updated circuit, the system migrates back to Groth16 for new enrollments. Existing PLONK proofs remain valid and verifiable.

STARKs - Off-Chain Batch Verification

STARKs are used exclusively for off-chain batch verification of re-verification proofs. When thousands of users complete their annual re-verification within a short window, verifying each proof individually on-chain would be prohibitively expensive. Instead, re-verification proofs are aggregated off-chain into a single STARK proof that attests to the validity of the entire batch.

The transparent setup (no trusted ceremony required) is important for this use case because re-verification circuits may be updated more frequently than enrollment circuits as new biometric attack vectors emerge. STARKs also provide post-quantum security guarantees, which aligns with JIL's broader post-quantum migration roadmap.

Gas Cost Comparison

The batch verification approach reduces per-user re-verification costs by approximately 99% compared to individual on-chain verification. This makes annual re-verification economically viable even at scale.

Cross-Reference Matrix

Each operational decision in this document maps to specific services, contracts, and configuration parameters in the JIL Sovereign codebase. This matrix serves as the authoritative reference for implementation teams.