Skip to main content
Cred Protocol runs an independent ERC-8004 validator at https://validator.credprotocol.com. Given an agent’s wallet, it computes a 0–100 composite trust score from three on-chain signals, pins the evidence to IPFS, and (optionally) submits the assessment on-chain to the ERC-8004 Reputation Registry on Base. This page is the methodology reference linked from the validator’s agent card.
Methodology version 1.0. Deployed on Base Mainnet (chain 8453); testable on Sepolia (11155111). Validator wallet: 0xc38947DA1EB4466D17d5C6c34a0f26Dbe803d107.

​
Composite score

composite_score = 0.40·credit + 0.30·sybil + 0.30·identity, rounded to an integer. If a signal is unavailable its weight is redistributed and the result is marked lower-confidence.

​
Trust levels

An agent with composite_score ≥ 50 is reported as verified: true.

​
Confidence

​
Pipeline

  1. Fetch signals — credit score, sybil score and identity attestations for the wallet (from the Cred Protocol API).
  2. Score — weighted composite as above.
  3. Pin evidence (only when publishing) — the composite, its breakdown, confidence, the attestation count, the sybil risk level, consent_basis and a correction_policy are pinned to IPFS (Pinata); the CID is returned as evidence_cid. The evidence never lists which identities the address holds or its granular sybil indicators (such as the funding source).
  4. Submit on-chain (optional) — giveFeedback on the ERC-8004 Reputation Registry (and the Validation Registry where deployed) with the composite score and evidence URI. tx_hash / tx_status (pending → submitted → confirmed | failed) track it.
  5. Persist — results are readable afterwards without recomputation.
Pinned evidence and on-chain entries are permanent, so the validator only publishes about an address that controls the agent it names. Publishing (submit_onchain=true or submit_reputation=true, both off by default) requires agent_id, and the address must be that agent’s owner or verified agentWallet in the Identity Registry. Otherwise the call returns 403 subject_consent_required before any payment is taken (an unknown agent is 404, also before payment). Without publication the assessment is computed and returned, and nothing is pinned. If a disputed input is corrected, a superseding entry is published; existing entries cannot be removed.

​
API

Example response:
POST /v1/validate/{address} without payment returns 402 with x402 (X-PAYMENT-REQUIRED) and MPP (WWW-Authenticate: Payment …) challenges — see Machine Payments. Everything else above is free. Full OpenAPI: validator.credprotocol.com/docs.