Reverification-Grace-Period Humanity Gate

Executive Summary

JIL Sovereign's biometric proof-of-humanity (BPoH) system is a two-layer construction. The base layer is a soulbound, non-transferable token minted once per wallet on enrollment, storing an irreversible hash of multi-modal biometric data, a zero-knowledge uniqueness-proof digest consumed against a network-wide uniqueness registry - so the same underlying biometric can never mint a second token even from a different wallet - a liveness-proof digest, and a 0-100 humanity confidence score, all gated behind a replay-protected verifier signature bound to the specific chain and contract.

The refinement layer is an abstract, inheritable access-control gate that any downstream contract adopts to gain requireHumanity-style modifiers without implementing biometric verification itself. Its distinguishing mechanism is how it treats reverification: rather than hard-locking a user out the instant an annual reverification window lapses, it opens a configurable grace period first - the user retains access through the grace window and is only cut off once that additional window has also passed.

Problem Statement

Sybil-resistance schemes that check humanity once at signup degrade over time: a compromised, resold, or abandoned identity keeps its privileges indefinitely because nothing forces recurring proof of continued human control. The naive fix - forcing an instant hard reverification exactly at the expiry timestamp - creates a different failure mode: users who are traveling, briefly unreachable, or simply haven't gotten around to reverifying yet are locked out abruptly and without warning, pushing products toward either permanently stale trust (never re-check) or user-hostile lockouts (re-check with zero tolerance).

Why Existing Solutions Are Insufficient

• One-time iris-scan uniqueness systems (Worldcoin-style): establish uniqueness at enrollment but have no built-in recurring reverification-with-grace-period access-control modifier that downstream contracts inherit.
• Synchronous proof-of-person schemes (Idena-style): require live paired "flip test" sessions at fixed intervals with no soulbound-score-plus-inheritable-gate pattern for arbitrary downstream contracts.
• Aggregated off-chain trust scores (Gitcoin Passport-style): combine multiple weaker signals into a composite score, rather than anchoring on a single biometric-uniqueness-bound soulbound token with its own on-chain reverification lifecycle.
• Social-graph-based verification (BrightID-style): relies on a web of vouches rather than a cryptographic biometric hash, liveness proof, and ZK uniqueness proof bound to a non-transferable token.

Technical Architecture

Base Layer: Soulbound Humanity Proof

Enrollment consumes the uniqueness proof and registers the biometric hash against a network-wide registry in the same transaction - so double-enrollment of the same underlying biometric under a second wallet is rejected at the registry level, not merely discouraged. The verifier's attestation signature is bound (via a standard signed-message digest) to the specific biometric hash, uniqueness proof, score, chain id, and contract address, preventing the same signature from being replayed across chains or across a different deployment of the contract. The token itself is soulbound: any transfer or approval attempt reverts outright, so humanity status cannot be sold or reassigned.

Refinement Layer: The Inheritable Gate

The Grace-Period Mechanism

Reverification becomes due once block.timestamp exceeds lastVerification + reverificationPeriod. Under requireCurrentVerification, if reverification is due and the grace period is enabled, the gate computes gracePeriodEnd = lastVerification + reverificationPeriod + gracePeriod and only reverts once block.timestamp exceeds that later boundary - meaning a user whose reverification lapsed three days ago, with a seven-day grace period configured, still passes the gate today. Only once the combined window has fully elapsed does the gate hard-block the caller with a distinct "reverification required" condition. A read-only companion function lets a caller or front-end check, before submitting a transaction, exactly which of these states applies (never enrolled, revoked, score too low, reverification due but within grace, or grace expired).

Configurable, Not Fixed

The minimum score, whether the grace period is enabled at all, and its duration are each independently configurable per deployment - through an admin-gated variant of the gate - so a high-value product can run a stricter policy (no grace period, higher minimum score) than a lower-stakes one, while both inherit the identical underlying verification and reverification mechanics.

Prior Art Differentiation

Patent Claim