Reputation Oracles Must Be Privacy-Preserving by Design

Public reputation graphs are trivial to game, rendering DAO voting and airdrops meaningless. Current solutions like Proof-of-Humanity are public ledgers of personal data.

• Sybil resistance requires privacy to prevent reverse-engineering of attestation graphs.
• Value extraction from public data leads to >90% inefficiency in incentive programs.
• Enables reputation laundering where bad actors can obfuscate their history.

Protocols like Semaphore, zkEmail, and Sismo allow users to prove traits (e.g., 'KYC'd', 'DAO member', 'credit score > X') without revealing the underlying data or identity.

• Enables selective disclosure for undercollateralized lending and private voting.
• Shifts trust from a central issuer to the cryptographic proof, creating a portable, private credential.
• ~500ms to generate a ZK proof on modern hardware, making it viable for real-time DeFi interactions.

GDPR, MiCA, and future regulations make public storage of personal financial data a non-starter. Institutions require privacy-preserving KYC/AML rails to participate.

• Privacy-by-design is a compliance requirement, not an optional feature.
• Enables institutional-grade DeFi with risk scoring without exposing portfolio or identity.
• Creates a regulatory moat for protocols that implement it correctly, as seen with Aztec and Mina.

Aggregating off-chain data into a public, on-chain score creates a permanent, linkable identity ledger. This enables:

• Sybil attacks via correlation: Link pseudonymous wallets to real-world identities, making reputation trivial to game.
• Regulatory targeting: Authorities can subpoena the oracle's data pipeline for KYC/AML enforcement on DeFi users.
• Discriminatory lending: Protocols could exclude wallets based on immutable, public transaction history.

A single entity controlling the reputation model and data ingestion becomes a critical failure point and censor.

• Single point of failure: A hack or legal attack on the oracle operator compromises the entire ecosystem's trust graph.
• Model manipulation: The operator can arbitrarily adjust scores to benefit favored protocols or users, corrupting the system.
• Vendor lock-in: Protocols become dependent on one provider's opaque methodology, stifling innovation and creating rent extraction.

Real-time reputation updates create a new frontier for maximal extractable value and targeted attacks.

• Frontrunning trust: Seers can exploit pending reputation changes (e.g., a score about to drop) to liquidate positions before the user can act.
• Ransom attacks: Adversaries could threaten to spam transactions or create false flags to damage a high-value wallet's score unless paid.
• Oracle delay arbitrage: Latency between off-chain computation and on-chain settlement creates predictable, exploitable windows.

The only viable architecture uses ZK-proofs to compute reputation off-chain and verify it on-chain, revealing nothing else.

• Selective disclosure: Users prove a score meets a threshold (e.g., >750) without revealing the exact number or underlying data.
• Data minimization: The oracle never sees raw personal data; computation happens client-side or in a trusted execution environment.
• Portability & composability: ZK proofs are verifiable by any contract, preventing vendor lock-in and enabling a competitive market for reputation models.

Decentralize the oracle's core functions to eliminate single points of control and data aggregation.

• Federated learning: Multiple nodes train a shared model on local data subsets; no single node has the complete dataset.
• Client-side scoring: Reputation algorithms run locally in the user's wallet; only the resulting attestation is submitted.
• Threshold cryptography: Reputation updates require a multi-signature from a decentralized set of guardians, preventing unilateral manipulation.

Mitigate MEV and extortion by introducing friction and unpredictability into the reputation update mechanism.

• Epoch-based updates: Reputation scores are updated at fixed, infrequent intervals (e.g., weekly), not in real-time.
• Randomized delays: The exact timestamp of an update within an epoch is unpredictable, preventing precise frontrunning.
• Update cooldowns: A wallet's score cannot be changed more than once per epoch, limiting the surface for spam-based attacks.