- DeFi capital — your vault / treasury sits on idle stablecoin or asset reserves looking for diversified, non-synthetic yield.
- The trust fabric — droplinked’s on-chain attestation layer (EAS Schema v2 — see Trust Fabric) lets you publish your underwriting methodology in a cryptographically verifiable way and issue per-merchant credit-risk attestations regulators can independently audit.
- Real-world commerce — droplinked merchants (physical goods, digital, POD, in-store retail) generating actual sales — actual cash flow — and therefore actual repayments back to your wallet.
Architecture at a glance
Every arrow above is either an on-chain attestation, a registry mutation captured in an append-only audit log, or a verifiable settlement event. A regulator — FSRA, SCA, or your jurisdiction’s equivalent — can reconstruct the full history of any underwriting decision you made and any repayment you received without trusting droplinked.Why droplinked?
- Real-world yield, not synthetic. Every repayment is anchored to a real merchant order on a real PSP (Stripe, PayPal, Telr, Bonum, PayMob). No rehypothecation, no second-order DeFi exposure.
- Cryptographic verifiability. Every credit-risk decision you issue is an on-chain attestation (Schema B) pinning a SHA-256 of the underwriting methodology you published. Verifiers re-hash and refuse on divergence.
- Per-merchant credit-risk granularity. Underwrite one merchant or one thousand;
each gets its own Schema B attestation with its own
creditTier+maxCreditLineUsdCents+expiresAtlifecycle. No portfolio-level smearing. - Methodology hash pinning. You can’t silently swap underwriting basis. If you publish v2 of your scorecard, old attestations stay pinned to the v1 hash they cited at mint time; new mints cite v2. Every divergence is auditable.
- Audit trail for regulators. Every registry mutation — lender registration, status change, methodology supersession, methodology revocation — lands in an append-only audit log preserved by droplinked. Regulators querying the operator console can reconstruct any state at any past timestamp.
- Routing surfaces. Verified merchants in matching jurisdictions can discover
you via
GET /v2/lender-routing/recommend— exact-jurisdiction first,GLOBALfallback. Your jurisdiction is your first-mover moat. - MCP surface for consumer agents. ChatGPT / Claude / Cursor / OpenAI Agents SDK can discover and recommend you to onboarding merchants directly via the droplinked-mcp server. No partner BD required.
The 4-step onboarding flow
Register your entity in the LenderRegistry
The operator console gates lender registration (SUPER_ADMIN). Provide the
legal entity name, archetype, jurisdiction, signing wallet placeholder, and
regulator reference. Status starts at What changes: a new row in
PENDING_KYB.LenderRegistry (status PENDING_KYB) +
a LENDER_REGISTERED event in lender-audit-log (preserved forever).Publish your underwriting methodology
Upload your methodology document (PDF or markdown) to a stable URL — your
own domain, IPFS, Arweave — and register the SHA-256 hash with droplinked.What changes: a new row in
MethodologyRegistry (status ACTIVE) +
a METHODOLOGY_REGISTERED event in methodology-audit-log. From this
moment on, every Schema B mint by your lenderId cites this hash.Status flip to ACTIVE
Once your KYB is verified by droplinked, the operator flips your status
to What changes:
ACTIVE. Only ACTIVE lenders can mint Schema B attestations.LenderRegistry.status flips to ACTIVE + a
LENDER_STATUS_CHANGED event lands in lender-audit-log. The
EasIssuer.isActive gate now lets your wallet sign Schema B attestations.Issue per-merchant credit-risk attestations
For each merchant you underwrite, issue a Schema B What changes: a new on-chain attestation on Base Sepolia (mainnet
pending KMS migration). Verifiers can pull it via
CreditRiskAttestation
pinning your methodology hash. The on-chain UID becomes the verifiable
primary key.GET /v2/attestations/credit-risk/:merchantId
and walk the forensic chain back to your
methodology + your registry profile.What verifiers see
Once registered + ACTIVE, your offering is exposed via these public read endpoints — no JWT, no IP-allowlist:| Endpoint | Surfaces |
|---|---|
GET /v2/lenders/:lenderId | Your public profile + signing wallet (verifiers cross-check vs the on-chain issuerWallet) |
GET /v2/lenders/:lenderId/timeline | Your lifecycle history (registered, status changes, metadata updates — operator-only fields redacted) |
GET /v2/lenders | Your discoverable presence in the public lender list |
GET /v2/methodologies/:lenderId/active | The current methodology in force for new Schema B mints |
GET /v2/methodologies/:lenderId/:hash | Hash lookup — verifier downloads documentUrl + re-hashes for integrity |
GET /v2/methodologies/:lenderId/versions | Your full methodology lineage (ACTIVE + SUPERSEDED + REVOKED, newest-first) |
GET /v2/methodologies/:lenderId/:hash/timeline | Per-version lifecycle (registered → superseded → revoked, redacted) |
GET /v2/trust-fabric/stats | Your jurisdiction’s aggregate weight in the trust fabric |
Agent surface (MCP)
Consumer agents — ChatGPT, Claude, Cursor, OpenAI Agents SDK — call these tools on the droplinked-mcp server and surface you to onboarding merchants automatically:| Tool | How this surfaces your offering |
|---|---|
verify_lender | Agent resolves a lenderId from a Schema B attestation back to your human-readable profile |
recommend_lender | Agent answering “which lenders should this merchant approach?” — you appear ranked by jurisdiction-match + track record |
verify_methodology | Agent confirms an attestation cites a real, published methodology you registered |
get_lender_history | Agent walks your lifecycle to confirm you were ACTIVE at attestation mint time |
get_methodology_timeline | Agent walks a methodology’s lifecycle to confirm it wasn’t already revoked / superseded at mint time |
get_methodology_versions | Agent walks your full methodology lineage when no specific hash is in hand |
get_trust_fabric_stats | Agent gauges platform scale (and your jurisdiction’s share) before recommending you |
Audit-trail commitment
Every registry mutation produces an append-only audit-log entry preserved by
droplinked. The two logs (
lender-audit-log + methodology-audit-log) are
write-only at the operator console — there is no delete path. Regulators querying
the operator console can reconstruct any state at any past timestamp. Methodology
document tampering is provably detectable because the SHA-256 hash is on-chain at
mint time: a verifier downloads documentUrl, re-hashes, and refuses on divergence.Status semantics
LenderRegistry status
| Status | Meaning | Can mint Schema B? | Verifier policy |
|---|---|---|---|
PENDING_KYB | Registered but droplinked KYB not complete | No | Refuse |
ACTIVE | KYB verified, fully operational | Yes | Honor |
SUSPENDED | Temporarily de-listed (operator decision) | No new mints | Honor existing per policy, flag |
ARCHIVED | Permanently de-listed | No | Honor existing per policy, flag |
MethodologyRegistry status
| Status | Meaning | New mints cite this? | Verifier policy |
|---|---|---|---|
ACTIVE | Currently in force | Yes | Honor |
SUPERSEDED | Lender published a newer version | No | Honor historical attestations issued before supersededAt (methodology was in force at the time) |
REVOKED | Operator pulled the methodology | No | Red flag — refuse pending review |
LenderRegistry.status onto every ACTIVE
Schema B attestation via the lenderCurrentStatus + lenderCurrentStatusAt
fields. The reconciler never auto-revokes an attestation; it only mirrors. See
Trust Fabric — Issuer-state mirroring
for the full semantics.
Reference dashboard
You can embed the trust-fabric scale + your own activity in your own internal portal or partner-facing UI. See the Trust-Fabric Dashboard Template for a drop-in copy-pastable HTML + JavaScript implementation (vanilla JS and React flavors) that polls/v2/trust-fabric/stats + the public lender list.
Verifier integrity recipe
The canonical 3-step verifier flow any regulator or counter-party will run:- Read the on-chain Schema B attestation —
GET /v2/attestations/credit-risk/:merchantId. PinattestationUid,lenderId,issuerWallet,methodologyHash,occurredAt. - Resolve the methodology hash —
GET /v2/methodologies/:lenderId/:methodologyHash. PulldocumentUrl+status+effectiveAt. - Re-hash the document —
curl -sLo /tmp/methodology.pdf $DOC_URL && shasum -a 256 /tmp/methodology.pdf. Compare against the on-chainmethodologyHash. Any divergence is methodology tampering and the attestation must be refused.
Operator gates
Related
- Trust Fabric (EAS Schema v2) — 4-axis architecture overview
- Forensic Chain Workflow — end-to-end verifier walkthrough
- Lender Registry Lookup —
/v2/lenders/*reference - Methodology Registry Lookup —
/v2/methodologies/*reference - Trust-Fabric Stats —
/v2/trust-fabric/statsreference - Lender Trinity MCP Tools — agent-callable wrappers
- Trust-Fabric Dashboard Template — drop-in HTML + JS reference