Announcements

Cred Protocol SDKs: Trust-Gate Any Endpoint in One Line — TypeScript, Python, Express, Hono, Next.js, FastAPI

Official SDKs are live on npm and PyPI. One evaluate() call turns a wallet address into a 0–100 trust score, a tier, and a pass/fail against a policy — and the framework adapters turn that into a single middleware line in front of your API.

Julian Gay
Julian Gay
Cred Protocol
August 18, 2026
7 min read
Cred Protocol SDKs: Trust-Gate Any Endpoint in One Line — TypeScript, Python, Express, Hono, Next.js, FastAPI

The Problem Every Team Ends Up Solving Badly

If your product has wallets on the other end — a DeFi app, an agent marketplace, an API that agents pay for, a faucet, an airdrop, a governance forum — you eventually need to answer one question at request time: should this wallet get in?

Most teams answer it the hard way. Somebody writes a sybil heuristic. Somebody else bolts on an attestation lookup. A third person adds a "must have used the protocol for 30 days" rule. Six months later there are three half-maintained trust checks in three services, none of them agree, and nobody wants to touch the code that decides who gets blocked.

Cred Protocol already computes the underlying signals — credit history, sybil likelihood, identity attestations, on-chain reputation — across 10 EVM networks. What was missing was the last mile: a way to drop that judgement into your stack without becoming an expert in it. That's what the SDKs are.

What Shipped

Five packages, all at 0.1.0, all MIT-licensed:

PackageRegistryWhat it is
@cred-protocol/sdknpmCore TypeScript client (Node 20+, edge runtimes; zero dependencies)
@cred-protocol/expressnpmExpress middleware
@cred-protocol/hononpmHono middleware (Cloudflare Workers, Bun, Deno, Node)
@cred-protocol/nextjsnpmNext.js middleware / route guard
cred-protocolPyPIAsync Python client; cred-protocol[fastapi] adds a FastAPI dependency

They all wrap the same thing: Cred Protocol's trust evaluation API. You give it a wallet and a policy; it gives back a decision you can act on.

One Call, One Decision

Here's the whole integration in TypeScript:

import { CredClient } from '@cred-protocol/sdk'

const cred = new CredClient({ apiKey: process.env.CRED_API_KEY })

const result = await cred.evaluate({
  walletAddress: '0xd8dA6BF26964aF9D7eEd9e03E53415D37aA96045',
  policy: 'standard',
})

result.trustScore   // 75         — 0-100 composite
result.trustTier    // "verified" — trusted | verified | limited | untrusted | blocked
result.allPassed    // true       — did the wallet clear the policy?
result.gateResults  // per-gate breakdown, if you want to explain the decision

Python is the same shape, async-first:

from cred_protocol import CredClient

async with CredClient(api_key="cred_sk_...") as cred:
    result = await cred.evaluate(wallet_address="0xd8dA…", policy="standard")
    print(result.trust_score, result.trust_tier, result.all_passed)

That's it. No chain RPCs, no indexer, no scoring model to maintain. Results are cached on our side, so repeated checks against the same wallet are fast and don't multiply your bill.

Policies: Say What You Mean, Not How to Compute It

The policy argument is where the SDKs earn their keep. Instead of hand-tuning thresholds, you pick a template that describes the risk posture you want:

TemplateWhat it checksUse it for
quickHuman gate, relaxed threshold, fails openLow-stakes rate limiting, first-touch UX
basicHuman gateBasic sybil protection on public APIs
standardHuman + verified identityThe default. Most products should start here
strictHuman + verified + established historyHigh-value resources, large allocations
financialAll first-party gates, tight thresholdsLending, credit, anything with money at risk
reputationWeighted composite of every signalTiered access and dynamic pricing

Under each template are individual gateshuman, verified, established, active, kyc — and if a template isn't quite right you can compose your own: pick gates, choose an operator (AND, OR, or WEIGHTED with your own weights), and set a composite threshold. Policies are portable across all five SDKs because the evaluation runs server-side; change the policy, and every service using it changes with it.

Trust-based pricing

The reputation template also unlocks something we've found agent platforms want badly: price by trust. Pass includePricing: true and a basePriceUsdc, and the response includes a priceMultiplier and suggestedPriceUsdc — charge unknown wallets full price and let proven ones through cheaper, or free. Same call, one extra field.

Framework Adapters: The One-Liner

Most teams don't want to call evaluate() by hand in every handler. The adapters make trust a property of the route:

import { credGates } from '@cred-protocol/express'

app.use('/api', credGates({
  apiKey: process.env.CRED_API_KEY,
  policy: 'standard',
}))

app.get('/api/resource', (req, res) => {
  res.json({ data: '…', tier: req.credTrust!.trustTier })
})

The middleware reads the wallet from an X-Wallet-Address header or ?wallet= query parameter (or a custom extractWallet function you supply), evaluates it, and either lets the request through with the trust result attached, denies it with a 403, or — the default — answers with a 402 and a machine-readable challenge so an agent that fails the policy knows exactly what it would take to pass. Optional response headers (X-Cred-Trust-Score, X-Cred-Trust-Tier) let downstream services and logs see the decision without re-evaluating.

Hono and Next.js use the identical credGates() signature, so a policy that works on your Express API works unchanged on a Cloudflare Worker or in Next.js middleware. On the Python side, require_trust() is a FastAPI dependency: add it to a route and the handler receives a typed TrustResult, with the same deny / challenge / pass failure modes.

Built for Agents as Much as Apps

We designed the failure path around agents deliberately. When an autonomous agent hits an endpoint it isn't trusted for, a bare 403 is a dead end. A 402 with a structured challenge is an instruction: here's the policy, here's what you're missing, here's how to pay or prove your way in. That connects directly to the rest of the platform:

  • Every paid Cred Protocol endpoint is itself machine payable — a 402 advertises x402 and MPP challenges (Tempo, Stripe crypto deposits, and reputation-backed Cred credit), so an agent with no account can still get a score. The new Machine Payments guide documents the exact challenge formats.
  • The same evaluation is available as an MCP tool for agents that speak MCP rather than HTTP.
  • Assessments can be written on-chain via ERC-8004, so trust earned in one place is legible everywhere.

The SDKs are the developer-facing end of that loop: your service publishes what it requires, agents and users discover it, and Cred Protocol does the evaluating.

Where This Is Going

0.1.0 is deliberately small: evaluate(), policies, gates, pricing, and the four adapters. We'd rather grow it from what you actually build than guess — the obvious candidates are more framework adapters, batch evaluation, and access to the raw credit-score and report endpoints from the same client. If one of those (or something else) would unblock you, tell us.

Versioning follows semver from here; anything that changes a response shape gets a minor bump and a migration note in the docs.

Get Started

npm install @cred-protocol/sdk        # + @cred-protocol/express | hono | nextjs
pip install "cred-protocol[fastapi]"

Grab an API key from the dashboard, start with policy: 'standard', and put credGates() in front of one route. The SDK docs cover every option, the Quickstart has the shortest path to a first result, and if you'd rather not create an account at all, the payments guide shows how to pay per call instead.

Trust checks shouldn't be the code nobody wants to touch. Now they're one line.

Ready to integrate credit scoring?

Start building with Cred Protocol today. Free sandbox access included.