Reputation on ChainRender — Complete Capability Guide

ChainRender can build fully on-chain reputation UI: apps that render an address's social graph (via EFP), delegated vouches and flags, credential and attestation status, and identity claims — as eth_call renders, honestly graded. This is the comprehensive reference for what ChainRender can and cannot do with reputation, and the honest boundaries.

The mental model: read + render reputation, never become the authority

ChainRender does two things for reputation, and deliberately not a third:

1. Render on-chain reputation — follows/tags/blocks, vouches, credential status, attestations, identity claims — as free view calls. No server, no indexer for the trustless parts; the data is read from the source's own contracts at render time.
2. Declare reputation actions — a button can carry a declared action to write a vouch or follow (governed by the capability envelope + action decoder), just like any other action.
3. It does NOT become a reputation oracle. ChainRender never mints a score, never ranks addresses, never blesses an attester, and never runs an owned identity registry. A reputation authority with an admin key is exactly the thing the platform exists to avoid. Reputation is read and rendered, never manufactured.

This is the same separation as DeFi (render prices, don't become a DEX) and RWA (display compliance, don't become the compliance authority).

What ChainRender can RENDER (the reputation surface)

Each resolver is immutable, ownerless, view-only, fail-closed: a reverting/missing source renders "unavailable" rather than breaking the page. Addresses are always caller-supplied — ChainRender blesses no list, attester, or issuer.

EFP — the on-chain social graph (Ethereum Follow Protocol)

EfpResolver reads EFP list ops on chain and replays them to answer a forward question about a caller-named list.

Forward reads are Grade A — a real on-chain read, recomputable by anyone via eth_call, bounded to a scan cap (a larger list renders "unavailable", never a partial). Follower counts and reverse lookups ("who follows X") are deliberately not offered on chain — they need a global reverse index no single contract holds. Those belong to the EFP indexer/API and must be graded off-chain (≤ C) and labeled — never surfaced as an on-chain fact.

Delegated address vouching (native, ownerless)

AddressAttestationRegistry is an ownerless registry where any attester vouches for (or flags) an address under a caller-chosen topic, with expiry and revocation — msg.sender is the attester; no owner, no admin. AddressReputationResolver renders it.

Each vouch record is an on-chain fact (READ_CHAIN), but its meaning is delegated to a mutable attester the consumer chose — so a reputation signal from it grades ≤ C (the dependency axis, the same as ERC-3643). There is no global score: rep-tally is "k/n" over your chosen attesters — change the set, change the answer. A topic is neutral to sign (trusted-builder or scammer both render).

Cross-source aggregate

ReputationAggregateResolver (rep-aggregate) composes many sources — EFP, vouches, EAS, ERC-725/735, or a future source — through a uniform adapter (IReputationSource) into a transparent k-of-n tally whose grade is capped at the weakest source. An A-grade EFP follow can never launder a C-grade vouch into trustlessness. Still no opaque number.

Attestations & credentials (existing)

• AttestationAdapter reads EAS: "subject X holds attestation Y from attester Z". See Data Sources.
• CredentialStatusRegistry + CredentialLifecycleResolver — issuer-bound KYC/accreditation lifecycle (VALID / EXPIRED / REVOKED / UNKNOWN). See RWA Capabilities.
• ZK selective-disclosure credentials (CredentialResolver, member-of-set, bound single-use). See Privacy & Credentials.

Identity naming (existing)

• ENS — EnsProfileResolver (forward-verified reverse resolution), records, ENS-v2/CCIP. The anchor most reputation UIs hang off. See ENS Names & Integration.

ERC-725Y / ERC-735 accounts

ERC-725Y is a generic on-chain key-value store; ERC-735 layers signed claims on top. It's the standard behind LUKSO Universal Profiles, but it is not LUKSO-specific — any EVM chain can host an ERC-725Y/735 account. ChainRender's stance is the same as everywhere: read it, don't become it.

• Read today (same-chain): an ERC-725Y data key or an ERC-735 claim is a view read — render it now with the generic staticread resolver (CallResolver), pointed at the account address and data key. CallResolver does a STATICCALL against a co-located contract (the chain the resolver is deployed on), so it reads ERC-725Y/735 accounts that exist on that same chain — Sepolia, Robinhood, or Arc today.
• LUKSO is not integrated as of now. LUKSO Universal Profiles live on the LUKSO chain (mainnet 42 / testnet 4201). An EVM STATICCALL is same-chain only, so a resolver on Sepolia/Robinhood/Arc cannot read a UP that exists only on LUKSO — it fails closed to "unavailable." Reading live LUKSO UPs would require ChainRender deployed on LUKSO (a clean additive future step, since LUKSO is a standard EVM chain), or an off-chain (≤ C) fetch. Neither ships today.
• Never deploy our own: an ERC-725 account is owner-controlled by design — deploying one would reinstall the admin key the platform refuses. The ownerless AddressAttestationRegistry is the on-brand equivalent for vouches.
• Grade: an ERC-725Y store / ERC-735 claim is an owned, mutable authority, so a rendered claim grades ≤ C (a faithful render of the owner's current data, not proof it's true) — exactly the ERC-3643 precedent.
• Planned: a dedicated Erc725ClaimResolver (a thin, read-only reader with LSP2 key vocabulary) is a natural additive follow-up; until then staticread covers same-chain reads.

The honest boundaries (read these)

• Follower counts are off-chain. The trustless EFP reads are the forward relationship and personalized bounded reads; global counts come from the indexer and must be graded ≤ C and labeled. A follower count never renders Grade A.
• Reputation is not truth. Every non-EFP-record signal rests on a mutable author (an attester, an issuer, an ERC-725 owner). A rendered badge is "the current claim of authority Y," never "this is true." Signals fail closed to unknown/unavailable, never a fabricated positive.
• No global score. Any aggregate is caller-defined, transparent, and capped by its weakest input. A hidden reputation number is off-limits on principle — marketing must never exceed what the code enforces.
• The source must exist on the target chain. EFP lives on Ethereum L1 / Base / Optimism; a resolver reads EFP where EFP is (the caller supplies chain + list), consistent with the caller-supplied-address convention.

What's NOT built (honest gaps)

• Erc725ClaimResolver — read ERC-725Y/735 claims with a typed LSP2 vocabulary (today: staticread).
• On-chain follower aggregation — not possible trustlessly; the EFP indexer path is the honest route (≤ C).
• A weighted aggregate — the shipped aggregate is unit k-of-n by design (transparent); weighting would be a later, still-caller-visible variant.

Trust grade for reputation apps

Built to evolve (immutability-safe)

Reputation is a moving space — EFP and ERC-725 will keep shipping capabilities. The suite is additive by design: a new or upgraded source plugs in as a new IReputationSource adapter address (the aggregate needs no change); a new EFP encoding ships as a new resolver (the shared EfpOps decoder is the single place it changes); new vouch semantics are just new topics (the registry's bytes32 topic is opaque). Deployed code is never edited — it is superseded additively. Full detail in the internal doc 149-reputation-resolvers.md (§"Extension & versioning").

Where to go next

• Resolvers — how the resolver mechanism works in general.
• RWA Capabilities — credential lifecycle, ERC-3643, Proof-of-Reserve.
• DeFi Capabilities — the sibling render+declare guide.
• Trust Signals & Lineage — attestations (vouch) + advisories (alert) for components.
• Privacy & Credentials — ZK selective-disclosure credentials.
• Reference: Integrations — every integration + library + SDK/skill/MCP at a glance.
• Reference: Resolver Catalog — every resolver + kind + args.