Verified Payments

Zentity adds a compliance layer to x402 payment settlement. The Proof-of-Human token carries verification tier, sybil resistance, and method, bound to the payer's DPoP key, proving what they can do without revealing who they are.

Composable compliance

Payment settlement and compliance verification are separate concerns that compose through a single extension field. The x402 protocol handles settlement; Zentity provides a compliance extension that resource servers declare alongside payment terms, signaling what level of verification the payer needs to present.

Standard x402

// HTTP 402: payment terms
{
  "accepts": [{
    "scheme": "exact",
    "network": "eip155:84532",
    "amount": "10000",
    "asset": "0x036CbD...USDC",
    "payTo": "0xmerchant..."
  }]
}

Standard x402 payment terms.

With compliance extension

// HTTP 402: payment + compliance extension
{
  "accepts": [{ /* payment terms */ }],
  "extensions": {
    "zentity": {
      "minComplianceLevel": 2,
      "pohIssuer": "/.well-known/proof-of-human",
      "identityRegistry": "0x7a3F..."
    }
  }
}

The same payment terms, plus a compliance extension declaring the required verification tier.

From request to verified access

The Proof-of-Human endpoint issues a compact JWT carrying verification tier, sybil resistance, and method, bound to the requester's DPoP key. It contains no personal data; resource servers verify the signature locally via standard JWKS discovery.

The protocol in five steps

No new infrastructure is required: the resource server adds one extension field to its 402 response, and the client adds one token to the retry.

Client requests a resource

POST to a protected endpoint, no credentials attached.

Server responds 402

Payment terms with a compliance extension declaring the required verification tier.

Client acquires PoH token

A DPoP-bound JWT from Zentity carrying tier, sybil status, and verification method.

Client retries with proof

Payment signature in the header, PoH token in the body.

Server verifies and serves

JWKS signature check, tier comparison, and optional on-chain lookup.

proof-of-human.jwt

// Proof-of-Human token: compact, no PII
{
  "iss": "https://zentity.xyz",
  "sub": "pairwise:8f3a...c7e1",
  "exp": 1711003600,
  "scope": "poh",
  "poh": {
    "tier": 3,
    "verified": true,
    "sybil_resistant": true,
    "method": "nfc_chip"
  },
  "cnf": {
    "jkt": "dpop-key-thumbprint"
  }
}

3 tiers, 1 protocol

All 3 tiers share the same HTTP extension mechanism. What varies is the required evidence: payment-only resources need no identity proof, identity-gated resources verify a Proof-of-Human tier, and regulated resources add on-chain attribute checks via FHEVM.

Payment only

Public API

Use case: Weather data, public feeds, metered APIs
Payer proves: Valid USDC authorization
Server checks: Facilitator verifies payment signature

Tier 2+

Verified Identity

Use case: Licensed content, KYC-gated APIs, professional services
Payer proves: Payment + Proof-of-Human token
Server checks: JWKS verification of PoH JWT + tier ≥ 2

Tier 3 + on-chain

Regulated Finance

Use case: Cross-border settlement, DeFi, sanctions-sensitive APIs
Payer proves: Payment + PoH + wallet attestation
Server checks: PoH JWT + IdentityRegistry.checkCompliance()

2 verification paths

The same identity data supports 2 trust models. HTTP verification uses the Proof-of-Human JWT for lightweight API gating. On-chain verification uses FHEVM encrypted attributes for trustless smart contract settlement.

HTTP verification

The resource server fetches Zentity's JWKS once, then verifies every Proof-of-Human token locally without further API calls to Zentity.

Standard JWKS discovery: the same mechanism as any OIDC provider
EdDSA signatures: compact and fast to verify
DPoP binding: proof-of-possession, not bearer
Pairwise sub: no cross-RP correlation

Best for: API gating, SaaS metering, content access

On-chain verification

The facilitator contract calls checkCompliance() on the IdentityRegistry. FHEVM returns an encrypted boolean; the contract never sees the underlying data.

// FHEVM — compliance check on-chain
function settleWithCompliance(
  address payer
) external returns (ebool) {
  // Encrypted — never reveals identity
  ebool compliant = registry.checkCompliance(
    payer, requiredLevel
  );

  // Conditional settlement via FHE
  euint64 actual = FHE.select(
    compliant,
    FHE.asEuint64(amount),
    FHE.asEuint64(0)
  );

  return compliant;
}

Best for: DeFi settlement, smart contract gating, trustless compliance

Delegated payments, bounded risk

When an AI agent pays on a human's behalf, PACT capability grants constrain every dimension of the transaction: amount, currency, network, asset, and frequency. The human approves once; the constraints enforce continuously.

PACT capability grants

When an AI agent acquires payment authorization via CIBA, the human sets constraints that bind every subsequent transaction.

Per-request cap: Maximum amount per individual x402 payment
Daily aggregate: Cumulative limit across all payments in 24 hours
Network and asset: Restrict to specific chains and stablecoins
Cooldown: Minimum interval between consecutive payments

Constraints are enforced server-side via the usage ledger; the agent cannot bypass them even with a valid token.

capability-grant.json

// PACT capability grant for x402 payments
{
  "capability": "purchase",
  "constraints": {
    "amount.value": { "max": 100 },
    "amount.currency": { "in": ["USD"] },
    "x402.network": { "in": ["eip155:8453"] },
    "x402.dailyTotal": { "max": 50 }
  },
  "daily_limit_count": 10,
  "cooldown_sec": 60
}

Try the x402 demo Read the agent architecture