Skip to main content
Schema B is the writer attestation — a registered lender’s signed verdict on a merchant. Every approved lending application that mints on-chain mints a Schema B row, anchoring the line ceiling, term, rate, and methodology hash for downstream consumers (order credit-leg, attribution credit-leg, lender-agent quote enrichment).

Network & UIDs

EAS registry version: v1.4.0.

Field reference

ABI schema string:
EAS envelope fields:

Lender-registry mirror (lenderCurrentStatus)

The reconciler sweeps every 6 hours and mirrors the current LenderRegistry status onto every ACTIVE Schema B row. A verifier reading the Droplinked API sees:
The reconciler never auto-revokes. A Schema B attestation that’s still on-chain ACTIVE but issued by a now-SUSPENDED lender is honored or not per verifier policy. The MCP verify_credit_risk tool and the verifier API both expose this mirror.

Read via Droplinked API

Read via viem (TypeScript)

Read via ethers (TypeScript)

Read via Cast (Foundry)

Indexer access (EAS GraphQL)

All Schema B attestations issued by a specific lender wallet, newest first:
All Schema B attestations for a merchant — there is no on-chain index on subjectRootUid; for scale, query the Droplinked API (GET /v2/attestations/credit-risk/:merchantId) which serves an indexed projection.

Trust assumptions

A Schema B attestation is authoritative if and only if:
  1. The on-chain schema matches the mainnet UID above.
  2. The on-chain attester is currently ACTIVE in LenderRegistry. Check via GET /v2/lenders/:lenderId or read the Droplinked-API envelope’s lenderCurrentStatus mirror.
  3. revocationTime == 0 AND expirationTime > now.
  4. The methodologyHash resolves to an ACTIVE row in the methodology registry for that lender — the lender’s published methodology document is the explanation surface for the verdict.
A Schema B attestation issued by a lender that has since been SUSPENDED or ARCHIVED remains on-chain ACTIVE — the chain has no opinion on the lender’s current standing. The Droplinked reconciler exposes the current registry status via lenderCurrentStatus. Verifier-side policy decides whether to honor it. The agentic PM shadow protocol is explicit: this is a verifier decision, not a reconciler decision.