Skip to main content
A consumer agent or external verifier presented with a Schema B credit-risk attestation can independently audit every claim it makes by composing the trust fabric MCP tools. This page walks through the canonical forensic chain.

​
Scenario

A consumer agent is about to extend BNPL terms based on a merchant’s credit-risk attestation. The agent wants to verify, end-to-end:
  1. The attestation exists on-chain at the cited UID
  2. The lender that issued it is real, ACTIVE, and licensed
  3. The methodology the lender cited is the one they actually published
  4. The merchant’s repayment history matches the tier on the attestation

​
Step 1: read the attestation

const attestation = await mcp.callTool('verify_credit_risk', {
  merchantId: '6a207db0d29923bffaa983ca',
  lenderId: 'crediblex-uae',
});

{
  "found": true,
  "attestationUid": "0xattest...",
  "lenderId": "crediblex-uae",
  "creditTier": "T2",
  "maxCreditLineUsdCents": 5000000,
  "issuedAt": "2026-06-01T12:00:00Z",
  "expiresAt": "2026-09-01T12:00:00Z",
  "status": "ACTIVE",
  "lenderCurrentStatus": "ACTIVE",
  "issuerWallet": "0xD5F6...",
  "methodologyHash": "0xmeth..."
}
The agent reads:
  • attestationUid — the on-chain UID
  • lenderId — who issued it
  • issuerWallet — the wallet that signed
  • methodologyHash — the underwriting basis cited
  • lenderCurrentStatus — the registry-state mirror (updated every 6h by the reconciler)
Watch the mirror: status: ACTIVE means the attestation is on-chain valid. lenderCurrentStatus: SUSPENDED would mean the lender has been de-listed in the registry since mint. Verifier-side policy decides whether to honor an attestation from a since-de-listed lender.

​
Step 2: verify the lender

const lender = await mcp.callTool('verify_lender', {
  lenderId: attestation.lenderId,
});

{
  "found": true,
  "lenderId": "crediblex-uae",
  "displayName": "CredibleX (UAE)",
  "archetype": "fsra-licensed",
  "jurisdiction": "AE",
  "status": "ACTIVE",
  "signingWallet": "0xD5F6...",
  "regulatorReference": "FSRA-12345",
  "issuedAttestationCount": 42,
  "lastAttestationAt": "2026-06-11T22:00:00Z"
}
Cross-check: lender.signingWallet must equal attestation.issuerWallet. A mismatch indicates schema impersonation — someone signed an attestation pretending to be CredibleX. The agent must refuse in that case.

​
Step 3: verify the methodology

const methodology = await mcp.callTool('verify_methodology', {
  lenderId: attestation.lenderId,
  methodologyHash: attestation.methodologyHash,
});

{
  "found": true,
  "lenderId": "crediblex-uae",
  "version": "2026.06.1",
  "methodologyHash": "0xmeth...",
  "documentUrl": "https://crediblex.example.com/methodology-2026-06-1.pdf",
  "displayName": "CredibleX Inventory-Financing v2",
  "status": "ACTIVE",
  "effectiveAt": "2026-06-01T00:00:00Z",
  "supersededAt": null
}
Off-tool cross-check:
  1. Download methodology.documentUrl
  2. Compute SHA-256 of the document bytes
  3. Compare against methodology.methodologyHash
Any divergence flags methodology tampering. The verifier must refuse if the hashes don’t match. If methodology.status is SUPERSEDED, the attestation cites a methodology version the lender has since updated. That’s acceptable — old attestations stay tied to their original methodology — but the verifier should note it. If methodology.status is REVOKED, the operator has pulled this methodology. The attestation should be considered invalid pending re-issuance.

​
Step 4: verify the repayment-history rollup

const signals = await mcp.callTool('get_underwriting_signals', {
  merchantId: attestation.merchantId,
});

{
  "creditRisk": {
    "maxObservedTier": "T3",
    "latestPerLender": [
      { "lenderId": "crediblex-uae", "creditTier": "T2",
        "lenderCurrentStatus": "ACTIVE", "status": "ACTIVE" }
    ]
  },
  "repaymentHistory": {
    "merchantWide": {
      "totalSettlements": 17, "totalOnTime": 13,
      "totalLate": 3, "totalDefaults": 1
    }
  },
  "summary": {
    "anchorTier": "T3",
    "reliabilityScore": 76
  }
}
Cross-check:
  • signals.summary.anchorTier = max(observed-from-repayment, already-issued) — load-bearing risk signal
  • signals.summary.reliabilityScore — overall on-time fraction
  • If the verifier needs to know whether the attestation’s creditTier is currently justified by the repayment history, compare with signals.upgradeEligibility.observedTier

​
Step 5: independent on-chain verification

The agent can quote attestationUid + chain back to the end-user with a link to: 
https://base-sepolia.easscan.org/attestation/view/0xattest...
…where the user can see the on-chain receipt without trusting droplinked’s API.

​
Decision tree

CheckIf passIf fail
Attestation found + status: ACTIVEProceedRefuse
lenderCurrentStatus: ACTIVEProceedVerifier policy decides
Lender found + signingWallet matches issuerWalletProceedRefuse — schema impersonation
Methodology found + hash matches downloaded docProceedRefuse — methodology tampering
Repayment-history rollup consistent with attestation tierProceedVerifier policy decides (could be a stale attestation)
On-chain UID resolves on easscan.orgProceedRefuse — UID fabricated

​
End-to-end verifier walkthrough

The MCP tool chain above is the agent-runtime shortcut. A third-party verifier — a regulator, a counter-party PSP, an external auditor — can walk the exact same proof using the public HTTP read endpoints with no MCP client at all. Five steps, all public, no JWT, no IP-allowlist.

​
1. Read the Schema B attestation

curl -s https://apiv3.droplinked.com/v2/attestations/credit-risk/$MERCHANT_ID
Returns attestationUid, lenderId, methodologyHash, issuerWallet, occurredAt, creditTier, status, and the registry-mirror fields (lenderCurrentStatus etc.). The verifier pins occurredAt — every downstream check is evaluated as-of that timestamp, not as-of now.

​
2. Resolve the issuing lender

curl -s https://apiv3.droplinked.com/v2/lenders/$LENDER_ID
See Lender Registry Lookup for the full response shape. The verifier cross-checks lender.signingWallet === attestation.issuerWallet; a mismatch is schema impersonation and the attestation must be refused.

​
3. Resolve the methodology

curl -s https://apiv3.droplinked.com/v2/methodologies/$LENDER_ID/$METHODOLOGY_HASH
See Methodology Registry Lookup for the response shape. Returns the documentUrl + status + lifecycle timestamps (effectiveAt, supersededAt).

​
4. Download + re-hash the methodology document

The verifier downloads documentUrl, computes SHA-256 of the bytes, and compares against the on-chain methodologyHash. The exact recipe (with a working curl + shasum example) lives on the Methodology Registry Lookup page — don’t re-implement it, link to it. A divergence here is methodology tampering and the attestation must be refused regardless of every other check passing.

​
5. Inspect the public lifecycle timeline

curl -s https://apiv3.droplinked.com/v2/methodologies/$LENDER_ID/$METHODOLOGY_HASH/timeline
The methodology lifecycle timeline endpoint surfaces the full DRAFT → ACTIVE → SUPERSEDED → REVOKED transition history for a methodology, with timestamps + the operator/event that drove each transition. A verifier composes the transition history against the attestation’s occurredAt to make a time-honest policy call:
  • A methodology that’s currently SUPERSEDED but was ACTIVE at attestation occurredAt is still legitimate — the lender used the methodology that was in force at the time, and the attestation should be honored.
  • A methodology that’s REVOKED is a red flag regardless of when the attestation was issued. The operator has retroactively pulled this methodology; verifier-side policy decides whether to honor (most verifiers refuse).
The timeline endpoint replaces ad-hoc “look at the audit log” requests with a public, verifier-callable surface. No SUPER_ADMIN access required.