What the Trust Fabric is
Four Ethereum Attestation Service schemas, registered on Base mainnet at the predeploy0x4200…0021. Each one is a different axis of verifiable signal:
Full hex UIDs and the per-schema reference pages: Schema A, Schema B, Schema C, Schema D.
Read the flow as: A anchors your identity → B is a lender’s verdict on you → C is the append-only evidence of how that verdict performs → D lets peers (WMS, 3PL, partners) cross-sign you. Every arrow is a public, verifier-callable record.
What you get out of it
Brand verification
A Schema A attestation tied to your shop slug. Buyers and lenders read it to confirm the brand behind the catalog.
Credit-line eligibility
Registered lenders read your Schema A + sales history and decide whether to mint a Schema B credit-risk attestation. That attestation is your ticket into the capital markets marketplace.
Tier upgrades over time
Every settlement event accrues to your Schema C rollup. Strong repayment lifts you up the AAA → CCC ladder, which lenders read when re-pricing your next line.
The four surfaces you touch
The brand-attestation lifecycle (request → operator review → on-chain mint → public read) is documented step-by-step in the Brand Attestation Lifecycle guide.
Trust tiers — AAA to CCC
Your attestation-coverage tier is the share of your settled orders that are covered by a Schema C repayment-history row. Lenders read this directly when pricing your next line. The bands are operator-locked:
A higher tier means more lender competition for your line, lower indicative rates, and access to deeper pools in the marketplace. Tier movement is mechanical — it follows from your settlement record, not from operator discretion. You move up by settling on time; you move down by missing settlements.
You can preview your projected tier change before it happens via
GET /v2/upgrade-preview — useful for forecasting when your next line will re-price.
Privacy — what’s onchain vs offchain
The Trust Fabric is public by design on the axes that matter for verification, and operator-held on the axes that carry PII. Onchain (public, readable via Base mainnet or the verifier API): brand slug + Schema A; lender + methodology hash on each Schema B; settlement counts, on-time / late / default tallies on Schema C; Schema D peer scores + basis. Offchain (operator-held, never minted): legal entity name, banking info, KYB documents; underwriting methodology document bodies (only the hash is onchain); per-order buyer PII. The Schema D reconciler sweeps every 6 hours and mirrors registry state (active / suspended / revoked) onto every attestation envelope. It never auto-revokes — it only mirrors current registry status so each verifier can apply its own policy. You control the brand-attestation request and the credit-line application; everything else (rollups, registry-state mirroring, reconciler sweeps) is automatic.Where to go next
- Brand Attestation Lifecycle — request → operator review → mint, step by step
- Merchants on Droplinked — the broader merchant-side narrative
- DeFi Lender Onboarding — the other side of the marketplace
- EAS Schemas overview — developer reference (UIDs, ABI, read examples)