Problem Statement: Reputation as Verifiable, Revocable, Privacy-Aware Infrastructure
Frames on-chain reputation as a credentialing pipeline, not a token airdrop: signed claims, soulbound issuance, revocation, expiry, ZK disclosure, dApp reads.
Problem statement
Design a protocol that awards reputation credentials to addresses that satisfy defined criteria — consistent on-time loan repayment, sustained DAO participation, verified contribution history — stores them on-chain, revokes them when behavior reverses, expires them on a policy schedule, and exposes them to dApps that gate access, rates, or governance weight on reputation. Optionally, holders must be able to prove a reputation predicate without linking every dApp interaction to one global identity.
This is not an NFT marketplace. A reputation credential is worthless unless four properties hold simultaneously: it is unforgable (only authorized issuers can create it), it is non-transferable (buying a badge must not buy the reputation), it is revocable and expirable (stale or misbehaved reputation must die), and it is readable at verifier latency (a lending dApp must check a score in one RPC call, not a research project).
Why the problem is distinctive
A fungible token system optimizes for transfer; a reputation system optimizes for the opposite. Every design axis inverts: minting must be gated by evidence rather than payment, custody must be locked to the subject, lifecycle must include destruction, and reads must carry freshness and issuer provenance. The attached brief requires criteria definition and proof, soulbound or revocable issuance, partial or time-based expiration, and dApp integration. The differentiators this answer adds are issuance concurrency control and cross-chain bridging of reputation, which most treatments skip.
The four architectural planes
- Evidence plane: off-chain and on-chain data sources (repayment ledgers, governance logs, contribution graphs), oracle feeds, and the criteria engine that turns raw events into eligibility proofs.
- Issuance plane: issuer registry with capabilities, claim inbox with idempotency, batch merkle root publication, soulbound token and attestation registries, revocation registry.
- Disclosure plane: ZK commitment and nullifier management, selective-disclosure proofs, per-context pseudonyms, and the verifier contracts and APIs that consume them.
- Consumption plane: indexer and subgraph projections, read gateway with freshness labels, SDKs, and cross-chain mirrors so dApps on other networks can verify without re-deriving trust.
A strong interview answer keeps these planes separate: the evidence plane may degrade without stopping reads of already-issued credentials, and the disclosure plane may be unavailable without invalidating a single issued badge.
Key Highlights
- •Reputation inverts token design: evidence-gated mint, locked custody, mandatory destruction, provenance-carrying reads.
- •Four planes: evidence, issuance, disclosure, consumption; each degrades independently.
- •Forgery resistance, non-transferability, revocability, and verifier latency are the four acceptance properties.
- •Issuance concurrency and cross-chain bridging are the neglected differentiators this design covers explicitly.
- •Every uncited scale or SLO number in this answer is an explicit design assumption, labeled as such.
Section Rescue Kit
Buzzwords to use:
Safe statements:
- "Let me separate evidence, issuance, disclosure, and consumption before choosing any contract or database."
- "Reputation is a credentialing problem with token mechanics, not a token problem with metadata."