Alive402

Documentation

A fair trial in four steps.

Alive402 is a small policy and payment layer for existing HTTP APIs. The upstream handler remains ordinary application code.

Architecture

1. Verify the enrollment

Alive402 generates the RP signature on your server. IDKit requests selfieCheckLegacy(), then your backend forwards the complete proof to World’s v4 verification endpoint and stores the scoped nullifier.

2. Grant one promotional call

The SDK atomically consumes the provider campaign entitlement. A new email, wallet, or browser does not recreate it because the policy is keyed by the World nullifier and action.

3. Return HTTP 402

After the entitlement is consumed, the protected endpoint returns PAYMENT-REQUIRED with an x402 v2 exact requirement for USDC on hedera:testnet.

4. Verify and settle

The client signs PAYMENT-SIGNATURE. Blocky402 verifies the partially signed transaction, pays the network fee, settles on Hedera, and the API returns PAYMENT-RESPONSE.

Required environment

WORLD_APP_ID=app_...
WORLD_RP_ID=rp_...
WORLD_RP_SIGNING_KEY=...
SUPABASE_URL=https://...supabase.co
SUPABASE_SECRET_KEY=...
HEDERA_AGENT_ACCOUNT_ID=0.0...
HEDERA_AGENT_PRIVATE_KEY=0x...
HEDERA_SERVICE_ACCOUNT_ID=0.0...
HEDERA_SERVICE_PRIVATE_KEY=0x...
OPENROUTER_API_KEY=...
PUBLIC_APP_URL=https://alive402.vercel.app

Canonical HTTP exchange

POST /api/demo/inference
→ 402 Payment Required
PAYMENT-REQUIRED: <base64 x402 v2 declaration>

POST /api/demo/inference
PAYMENT-SIGNATURE: <partially signed Hedera transaction>
→ 200 OK
PAYMENT-RESPONSE: <Blocky402 settlement receipt>

Security decisions

  • Selfie images and raw proof payloads are never persisted.
  • Nullifiers are normalized as decimal 256-bit values.
  • Signing and payer keys remain server-only.
  • The demo client accepts only the configured token, receiver and maximum amount.
  • Selfie Check is described as medium-assurance abuse resistance, not strict personhood.