AFG — FAQ:
the neutral trust layer for AI agents.

What problem does AFG solve?

Autonomous AI agents are starting to pay for compute, data, APIs, and services on their own. There is no way to know if a given agent is trustworthy before you transact with it. The natural scorers — Coinbase, Stripe, AWS, Circle — each see only their own slice of an agent's activity, and none can be a neutral judge of their own ecosystem.

Why can't an existing payment rail just do this?

It's the conflict of Visa owning Equifax. A rail can't credibly score the agents inside its own ecosystem, and it can't see what an agent does on competing rails. AFG is the independent third party that aggregates trust signals for the same agent across providers — a position structurally closed to any single rail. Neutrality is the moat.

What is the AFG Trust Score?

A 300–850 score for an AI agent's wallet, derived purely from unfakeable on-chain behavior on Base. It is autonomous and keyless: anyone can query any wallet with no signup, no account, no API key, and no human approval.

curl 'https://afg.ai/v2/api/trust?wallet=0x...'

The response includes a transparent factor breakdown, a confidence tier, and an explicit "what this measures / does not measure" block — the page, the docs, and the live JSON all agree.

What does the score measure?

• Wallet longevity — first on-chain activity; unfakeable.
• Counterparty breadth — reputation-weighted, independent-history counterparties.
• Settled USDC payment activity — real volume and cadence on Base.
• Wash / self-dealing detection — bounded, timing-filtered round-trip analysis.

What does it deliberately NOT measure?

• ✕ Payment reliability (success vs. failure). A USDC Transfer event is only emitted on success, and relayer/x402-submitted failures are invisible on-chain. We refuse to claim what we cannot observe.
• ✕ Agent identity, intent, or profitability.
• ✕ Legal or regulatory compliance.
• ✕ Off-chain fulfillment or quality of goods/services.

Honesty is a design constraint: advertised range equals achievable range, and nothing on the site claims a capability the code doesn't deliver.

Does it actually work right now?

Yes — verified by external request against the live host. Example: a known wash-trading bot wallet correctly floors at the minimum:

GET https://afg.ai/v2/api/trust?wallet=0xb2cc224c1c9feE385f8ad6a55b4d94E92359DC59
→ 200  { "trust_score": 300, "bases_used": ["on-chain"], ... }
   wash_fraction ≈ 0.99  →  wash penalty floors the score

A legitimate, long-lived payer wallet with diverse counterparties and zero wash scores in the mid-600s. The score discriminates on real behavior, not on anything fakeable for gas.

If the score is from public chain data, what stops a competitor copying it?

The on-chain score is the open, honest front door. The defensible asset is the next layer: cryptographically provable attestations that a competitor cannot reconstruct from the chain alone. We ran a kill-or-build proof-of-concept to test whether this is real.

What did the proof-of-concept actually test?

The premise: an AI agent can submit an attestation about a payment it was party to, and the server can verify with cryptography alone — no human, no trust — that the attester really was a counterparty to that exact on-chain payment.

The test, run end-to-end against real Base mainnet transactions:

• Sign a structured attestation {tx_hash, payer, payee, amount, role, timestamp} with a wallet's private key (EIP-191).
• Server-side, recover the signer address from the signature alone, fetch the referenced transaction, and accept only if the recovered address is a real USDC Transfer party in that transaction, in the claimed role, with the claimed counterparty.

What were the results?

• ✓ Sign → recover → on-chain match works. A legitimate attestation is accepted; the recovered signer matches the real on-chain counterparty.
• ✓ All forgeries rejected: a wallet that wasn't party to the tx, a real party claiming the wrong role, a wrong counterparty, and any replayed/altered payload (the signature stops matching).

What about relayer / x402 payments — the make-or-break case?

This is the risk that sank an earlier design. Many agent payments are submitted by a relayer, so the transaction's from is the relayer, not the paying agent. We checked whether the agent is still cryptographically verifiable.

Finding: the agent's wallet remains the USDC Transfer-event sender even when a relayer submits the transaction. In one live sample, 16 of 17 USDC transactions were relayer-submitted (tx sender ≠ token sender) — relayer submission is the norm, not the edge case. The signature-recovery-to-counterparty match still succeeds against the Transfer-event party.

✓ The relayer hole does NOT break attestation. The mechanism is sound enough to build on.

Did you prove this end-to-end with real transactions — no simulation?

Yes. We closed the last seam by running the entire pipeline on Base Sepolia with a freshly generated keypair we control, so nothing was substituted at any step:

• ✓ Direct payment: the agent wallet broadcast a real USDC transfer, signed an attestation, and the server recovered the signer from the signature alone — the recovered address equaled the generating wallet and the on-chain Transfer sender. Accepted.
• ✓ Real relayer payment (EIP-2612 permit): the agent signed a gasless permit; a separate relayer wallet submitted transferFrom. On-chain, the transaction's from is the relayer, but the USDC Transfer sender is the agent. The agent's attestation was recovered and matched to the Transfer-event party, not the transaction submitter. Accepted.
• ✓ All forgeries rejected on the real transactions: non-party signer, wrong role, wrong counterparty, and any replayed or altered payload.

Every signature, recovery, and on-chain match was real — including the relayer case that previously could only be observed on third-party transactions. There are no remaining asterisks: the attestation mechanism is demonstrated, not inferred.

So what is the roadmap item this unlocks?

Proof-carrying attestations (not yet live): reports where the reporter cryptographically signs with the wallet that was the actual on-chain counterparty. They are trustless and need no human approval — which lets AFG accumulate provable, non-public reputation data that no competitor can reconstruct from the chain. We removed the old human-vetted reporter path from the live surface precisely because it wasn't trustless; it returns only when it's proof-carrying.

What are AFG's design commitments?

• Autonomous: no human in the loop. No issued keys, no approval gate, no signup to query.
• Neutral: independent — not owned by or affiliated with any wallet, rail, or cloud provider.
• Honest: the score claims only what unfakeable evidence supports. We say plainly what we cannot measure.
• Trustless: trust is derived from cryptography and on-chain fact, never granted on someone's word.

What's the one-line pitch for the XPRIZE judges?

AFG is autonomous, neutral trust infrastructure for the agent economy: a keyless on-chain trust score live today, plus a cryptographically-proven attestation layer that gives it a moat no payment rail can structurally occupy.