Skip to main content
Droplinked sits between on-chain capital and real-world commerce. If you run a DeFi vault, a protocol treasury, or a credit-line lending protocol with stable assets you’d like to deploy into yield-bearing real-economy positions, this page is the canonical onboarding narrative. The bridge is three layers:
  1. DeFi capital — your vault / treasury sits on idle stablecoin or asset reserves looking for diversified, non-synthetic yield.
  2. 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.
  3. 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.
The yield is real repayment streams from real merchant sales, with full chain-anchored auditability. Not synthetic yield. Not rehypothecated collateral. Not a wrapped-up money-market position with a TradFi counterparty risk you can’t see.

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 + expiresAt lifecycle. 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, GLOBAL fallback. 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

1

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 PENDING_KYB.
What changes: a new row in LenderRegistry (status PENDING_KYB) + a LENDER_REGISTERED event in lender-audit-log (preserved forever).
2

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.
3

Status flip to ACTIVE

Once your KYB is verified by droplinked, the operator flips your status to ACTIVE. Only ACTIVE lenders can mint Schema B attestations.
What changes: 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.
4

Issue per-merchant credit-risk attestations

For each merchant you underwrite, issue a Schema B CreditRiskAttestation pinning your methodology hash. The on-chain UID becomes the verifiable primary key.
What changes: a new on-chain attestation on Base Sepolia (mainnet pending KMS migration). Verifiers can pull it via 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:

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:

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

MethodologyRegistry status

The reconciler cron (every 6h) mirrors 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:
  1. Read the on-chain Schema B attestationGET /v2/attestations/credit-risk/:merchantId. Pin attestationUid, lenderId, issuerWallet, methodologyHash, occurredAt.
  2. Resolve the methodology hashGET /v2/methodologies/:lenderId/:methodologyHash. Pull documentUrl + status + effectiveAt.
  3. Re-hash the documentcurl -sLo /tmp/methodology.pdf $DOC_URL && shasum -a 256 /tmp/methodology.pdf. Compare against the on-chain methodologyHash. Any divergence is methodology tampering and the attestation must be refused.
See Forensic Chain Workflow for the full end-to-end walkthrough including lender + repayment-history cross-checks.

Operator gates

Actual onboarding is operator-gated (SUPER_ADMIN). The endpoints in the 4-step flow above are admin-only — droplinked’s operator console executes them on your behalf after verifying your KYB packet.To start, contact support@droplinked.com with:
  • Legal entity name + corporate jurisdiction
  • Regulator reference (FSRA / SCA / equivalent license number, or N/A if DeFi vault)
  • Methodology document URL (https:// or ipfs://) — must be stable + immutable
  • Signing wallet address (EVM, 20-byte) — this is the wallet that will sign Schema B attestations and the address you’ll receive repayments at
  • Archetype: fsra-licensed / defi-vault / generic
  • Jurisdiction: ISO 3166-1 alpha-2 (e.g. AE, SG, US) or GLOBAL for unrestricted DeFi vaults
Mainnet is currently gated on the KMS-backed signer migration. Onboarding can proceed against Base Sepolia testnet today; mainnet flip is operator-coordinated.