Human judgment your agent can call.

One request, two gates, one human answer.

1. Submit intent, claim, and the requester wallet.
2. If gate 1 requests payment, sign 0.10 USDC and repeat the same action.
3. Store verify_id. Prefer callback_url for ready or failed events.
4. If no callback is available, or delivery fails, poll while status is processing.
5. If status is failed, stop and check the entry credit.
6. If status is ready, call the separate unlock action.
7. If gate 2 requests payment, sign 2.90 USDC and repeat the unlock.
8. Use the answer only when status is completed.

Submit a request

HTTP endpoint: POST https://verifi.cloud/verify

curl -X POST https://verifi.cloud/verify \
  -H "Content-Type: application/json" \
  -d '{
    "intent": "refund decision",
    "claim": "Read the policy and write which exception applies to order 482.",
    "agent_id": "0xYourWalletAddress",
    "callback_url": "https://your-agent.example/verifi-events"
  }'

An admitted request returns HTTP 202 with status: processing, a durable verify_id, and retry_after_seconds.

Let Verifi tell your agent when to continue

Pass an HTTPS callback_url with verify_claim or POST /verify. Verifi sends verify.ready when gate 2 can be called, or verify.failed when the chain must stop.

{
  "event": "verify.ready",
  "verify_id": "a1b2c3d4-0000-4000-8000-000000000000",
  "status": "ready",
  "next_action": "unlock"
}

Poll the same request

Use MCP get_verify or HTTP GET /verify/{verify_id} when no callback is available or as recovery after a delivery failure. Polling never costs money.

{
  "verify_id": "a1b2c3d4-0000-4000-8000-000000000000",
  "status": "ready",
  "verdict": null,
  "explanation": null,
  "next_action": "unlock",
  "unlock": {
    "price_usdc": "2.90",
    "payment_required": true
  }
}

Unlock the human answer

Use MCP unlock_verify or HTTP POST /verify-unlock?id={verify_id} only after status becomes ready. Paid and entry-credit reviews receive a new 2.90 USDC requirement. A complete free review passes without payment.

{
  "verify_id": "a1b2c3d4-0000-4000-8000-000000000000",
  "status": "completed",
  "verdict": "refined",
  "explanation": "Use the corrected delivery date: 22 July.",
  "response": "Use the corrected delivery date: 22 July.",
  "funding": {
    "entry_charged_usdc": "0.10",
    "unlock_charged_usdc": "2.90",
    "total_charged_usdc": "3.00"
  }
}

The human verdict is true, false, or refined. A refined free-text answer is returned in explanation and response.

x402 on Base

Both paid gates use x402 v2, scheme exact, USDC on Base mainnet eip155:8453. The buyer needs USDC but no ETH.

HTTP returns a base64 PAYMENT-REQUIRED header and accepts the signed authorization in PAYMENT-SIGNATURE. MCP returns a standard PaymentRequired result and accepts the signed payload through x402/payment metadata. Successful settlement returns PAYMENT-RESPONSE over HTTP or x402/payment-response through MCP.

The entry and unlock payments are separate EIP-3009 authorizations and separate on-chain settlements connected to the same verify_id.

Automatic HTTP payment with @x402/fetch

The x402 client reads the 402 requirement, creates the EIP-3009 authorization with the requester's wallet, and retries the same request automatically. Install @x402/core, @x402/fetch, @x402/evm, and viem:

npm install @x402/core @x402/fetch @x402/evm viem

import { wrapFetchWithPayment } from "@x402/fetch";
import { x402Client } from "@x402/core/client";
import { ExactEvmScheme } from "@x402/evm/exact/client";
import { privateKeyToAccount } from "viem/accounts";

const signer = privateKeyToAccount(
  process.env.EVM_PRIVATE_KEY as `0x${string}`
);
const client = new x402Client();
client.register("eip155:*", new ExactEvmScheme(signer));
const paidFetch = wrapFetchWithPayment(fetch, client);

const response = await paidFetch("https://verifi.cloud/verify", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: JSON.stringify({
    intent: "Review this customer update",
    claim: "Check the promise and write a safer version.",
    agent_id: signer.address,
    callback_url: "https://your-agent.example/verifi-events"
  })
});

const verify = await response.json();

Use the same paidFetch for POST /verify-unlock?id={verify_id}. It handles the separate 2.90 USDC requirement when the callback reports ready. See the official x402 buyer quickstart.

Failure and entry credit

{
  "verify_id": "a1b2c3d4-0000-4000-8000-000000000000",
  "status": "failed",
  "next_action": "stop",
  "failure": {
    "reason": "human_timeout",
    "entry_credit_granted": true,
    "entry_credit_value_usdc": "0.10"
  }
}

The credit is not cash. It covers gate 1 of the same wallet's next request. Gate 2 still costs 2.90 USDC when that next answer is ready.

Callbacks, errors, and audit

An optional callback sends verify.ready or verify.failed. It replaces active polling during normal operation, never exposes a locked answer, and leaves polling available as the recovery path if delivery fails.

Capacity and active-request checks happen before payment. PostgreSQL records the wallet, request, both prices, both charged amounts, transaction hashes, free uses, credits, lifecycle timestamps, and the append-only audit trail.