Skip to main content
Droplinked’s trust fabric is published as four EAS schemas on Base mainnet. Every verifiable claim — verified brand, lender underwriting verdict, append-only repayment record, peer trust — is anchored to one of these schemas. The records are public, the issuers are operator-registered, and the reconciler closes the loop on revocations and registry drift. If you only need aggregate counts (lenders, attestations, service providers), see /v2/trust-fabric/stats. The pages in this group are the on-chain reference — UIDs, field tables, and copy-pasteable read examples in viem / ethers / Cast for verifiers that want to read EAS directly without going through Droplinked’s API.

​
The 4 axes

​
How the axes compose

Read the flow as: A anchors the entity → B is a lender’s verdict on that entity → C is the append-only evidence of how that verdict performed → D is a peer cross-check by any registered party. The reconciler never auto-revokes — it only mirrors current registry state so verifiers can apply their own policy.

​
Network coverage

EAS is a predeploy on every OP-Stack chain at the same address; Droplinked’s schemas are registered separately per chain. The active chain is configured via EAS_ACTIVE_CHAIN (base in production) and every /v2/attestations/* response includes the chain in its envelope.

​
Schema UIDs (Base mainnet, registered 2026-06-14)

The same axes are also registered on Base Sepolia for development. Testnet UIDs differ from mainnet; resolve them at runtime via the chain field on any /v2/attestations/* response, or via the Droplinked-side admin registry (operator-only).
Schema UIDs are per-chain. A Schema B mainnet UID is NOT valid on Sepolia and vice versa. Always pair the UID with the chain when constructing a verifier query.

​
Three ways to read

For any schema, you have three independent paths to the same on-chain record:
  1. Droplinked verifier API — GET /v2/attestations/<schema>/<subject>. Returns the latest active attestation with the registry-mirror envelope (lenderCurrentStatus, attestorCurrentStatus). Best for hot-path reads where you already trust Droplinked’s projection.
  2. EAS contract directly — call getAttestation(uid) on 0x4200…0021 via viem / ethers / Cast. Best for independent verification: you read the attestation bytes straight off chain.
  3. EAS GraphQL indexer — query https://base.easscan.org/graphql (or https://base-sepolia.easscan.org/graphql for testnet). Best for enumeration: “all Schema B attestations for this merchant”, “all Schema D attestations issued by this lender”.
Each schema page below documents all three.

​
Issuer registries (who is authorized)

A schema UID alone does not prove authority — the issuing wallet must be currently registered + ACTIVE in the matching registry. Verifiers SHOULD always cross-check: The reconciler cron mirrors the current registry status onto every ACTIVE Schema B + Schema D row every 6 hours (lenderCurrentStatus / attestorCurrentStatus). A verifier reading the Droplinked API gets this mirror for free; a verifier reading EAS directly should re-check the issuer wallet against the registry.

​
Subject anchors (subjectRootUid)

Schemas B, C, and D address subjects via a subjectRootUid (Schema D also has issuerRootUid). The current production scheme is a labeled string:
A future schema-rotation will swap this to keccak256(entityType || entityId) bytes32 (already reflected as the persistent subjectRootUid field in the verifier API). When that rotation lands, the schema UID changes and legacy attestations remain valid against the legacy UID. Both forms will be queryable side-by-side during the transition window.

​
Next

Continue to the per-schema reference pages for fields, ABI types, and copy-pasteable read examples: