> ## Documentation Index
> Fetch the complete documentation index at: https://docs.droplinked.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Forensic Chain Workflow

> End-to-end walkthrough — how a verifier audits a Schema B credit-risk attestation from the on-chain UID back to the lender, the methodology, and the merchant's repayment history.

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](/concepts/trust-fabric). 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

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

```json theme={null}
{
  "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)

<Note>
  **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.
</Note>

## Step 2: verify the lender

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

```json theme={null}
{
  "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

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

```json theme={null}
{
  "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

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

```json theme={null}
{
  "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

| Check                                                     | If pass | If fail                                                |
| --------------------------------------------------------- | ------- | ------------------------------------------------------ |
| Attestation found + `status: ACTIVE`                      | Proceed | Refuse                                                 |
| `lenderCurrentStatus: ACTIVE`                             | Proceed | Verifier policy decides                                |
| Lender found + `signingWallet` matches `issuerWallet`     | Proceed | **Refuse — schema impersonation**                      |
| Methodology found + hash matches downloaded doc           | Proceed | **Refuse — methodology tampering**                     |
| Repayment-history rollup consistent with attestation tier | Proceed | Verifier policy decides (could be a stale attestation) |
| On-chain UID resolves on easscan.org                      | Proceed | **Refuse — 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

```bash theme={null}
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

```bash theme={null}
curl -s https://apiv3.droplinked.com/v2/lenders/$LENDER_ID
```

See [Lender Registry Lookup](/api-reference/public/lender-registry) 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

```bash theme={null}
curl -s https://apiv3.droplinked.com/v2/methodologies/$LENDER_ID/$METHODOLOGY_HASH
```

See [Methodology Registry Lookup](/api-reference/public/methodology-registry) 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](/api-reference/public/methodology-registry#verifier-integrity-check)
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

```bash theme={null}
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).

<Note>
  The timeline endpoint replaces ad-hoc "look at the audit log" requests with a public,
  verifier-callable surface. No SUPER\_ADMIN access required.
</Note>

### Cross-links

* [Trust Fabric overview](/concepts/trust-fabric) — where each registry sits in the 4-axis fabric
* [Methodology Registry Lookup](/api-reference/public/methodology-registry) — request/response shape + integrity-check recipe
* [Lender Registry Lookup](/api-reference/public/lender-registry) — `signingWallet` cross-check field reference

## Related

* [Trust Fabric overview](/concepts/trust-fabric)
* [Underwriting MCP Tools](/agentic/underwriting-mcp-tools)
* [Lender Trinity MCP Tools](/agentic/lender-trinity-mcp-tools)