Blockchain reputation system development

Development of Blockchain Reputation System

Reputation in Web3 — one of unsolved problems. In Web2 reputation is centralized: Uber rating stored at Uber, Amazon reviews belong to Amazon. Switching platforms resets history. Blockchain reputation should solve this: verifiable, portable, censorship-resistant. But implementing it correctly is significantly more complex than seems.

Reputation System Models

Attestation-based Reputation

Most common approach — reputation as set of attestations (confirmations) from other participants or protocols. EAS (Ethereum Attestation Service) — standard infrastructure for this.

Attestation in EAS — signed record: "attester X claims that subject Y has property Z". Property Z defined by schema — structured data registered on-chain.

// Schema for developer reputation
// "address developer, uint8 skill_level, bool verified_audit, string project_ref"

// Attestation looks like:
{
    schemaUID: bytes32("..."),
    recipient: address("developer"),
    attester: address("protocol or DAO"),
    data: abi.encode(developer, skill_level, verified_audit, project_ref),
    time: block.timestamp,
    revocable: true
}

On-chain attestation — public and verifiable. Off-chain attestation (via EAS off-chain) — cheaper, but requires storage outside network (IPFS, Arweave).

Core vs Derived Reputation

Important architectural concept: core signals (primary data) vs derived scores (aggregate estimates).

Core signals — specific measurable facts:

• Number of successful transactions over N months
• TVL under management (for DeFi positions)
• Wallet age
• Attestations from verified sources
• Gitcoin Passport score
• Lens Protocol follower count

Derived scores — aggregation of core signals into numeric rating. Problem: aggregation formula — political decision, and its centralized change retroactively changes reputation. Solution: store core signals on-chain, aggregation do off-chain (upgradeable) or through governance.

Token-based Reputation (SBT)

Soulbound Tokens (EIP-5192, EIP-4973) — non-transferable tokens bound to address. Cannot buy, sell, transfer — only earn.

interface IERC5192 {
    event Locked(uint256 tokenId);
    event Unlocked(uint256 tokenId);
    function locked(uint256 tokenId) external view returns (bool);
}

contract ReputationSBT is ERC721, IERC5192 {
    mapping(uint256 => bool) private _locked;
    
    function _beforeTokenTransfer(
        address from,
        address to,
        uint256 tokenId,
        uint256 batchSize
    ) internal override {
        // Allow only mint (from == 0) and burn (to == 0)
        require(from == address(0) || to == address(0), "Soulbound: non-transferable");
    }
    
    function locked(uint256 tokenId) external view override returns (bool) {
        return _locked[tokenId];
    }
}

SBT works well for discrete credentials (completed audit, participated in governance). Poorly — for continuous metrics (rating constantly changes).

Key Technical Problems

Sybil Resistance

Main attack on reputation systems — creating multiple addresses to inflate reputation. Protection requires binding to something scarce: biometrics (WorldCoin), social graph (Proof of Humanity), PoW-like work (BrightID).

For most projects: combination of minimal on-chain age (wallet older 6 months), minimal activity threshold, and optional social verification (ENS domain, Twitter/X verification).

Privacy: Public Reputation as DoS

Fully public on-chain reputation — problem. Knowing address, can see entire action history. For business-critical data unacceptable.

Solutions:

• ZK attestations: prove reputation > threshold without revealing exact score. Circom/snarkjs schema, Noir — modern DSL.
• Pseudonymous attestations: attestation bound to pseudonymous identifier, not main wallet. Connection between pseudonym and real wallet known only to user.
• Selective disclosure: Verifiable Credentials (W3C standard) with ZK proof — reveal only needed claim.

Cross-chain Reputation

Reputation on Ethereum not visible to contract on Polygon without bridge. Solutions:

• Off-chain indexer + Merkle proof: index all attestations, build Merkle tree, user presents proof on any chain.
• LayerZero message: reputation contract on Ethereum sends state through LayerZero to other chains.
• Self Protocol / Lens Protocol: cross-chain reputation primitives with ready infrastructure.

Aggregation and Weights

Reputation score — weighted sum of signals. Example model:

Logarithmic scaling prevents domination by large holders. Cap on each signal — no single point of manipulation.

Decay Function

Reputation should reflect current behavior, not just past. Temporal decay:

function getDecayedScore(score: number, lastActivityTimestamp: number): number {
  const daysSinceActivity = (Date.now() / 1000 - lastActivityTimestamp) / 86400;
  const decayFactor = Math.exp(-daysSinceActivity / HALF_LIFE_DAYS); // exponential decay
  return score * decayFactor;
}

HALF_LIFE_DAYS — system parameter. 180 days: after 6 months inactive reputation halves.

Integration with Existing Protocols

Gitcoin Passport — aggregator of Web2/Web3 identity signals (GitHub, Twitter, ENS, POAP). Passport issues score as Stamp-based reputation. API for check: GET https://api.scorer.gitcoin.co/registry/score/{scorer_id}/{address}.

Lens Protocol — on-chain social graph. Followers, publications, mirrors — all on-chain on Polygon. Subscription to Lens profile as reputation signal.

POAP — Proof of Attendance Protocol. NFT for participation in real and virtual events. POAP collection — indirect signal of community activity.

Guild.xyz — role-based access through reputation conditions. Guild integration allows adding reputation gate without custom development.

System Architecture

[Core Signals Layer]
  On-chain: transaction history, token holdings, SBTs
  Off-chain: ENS, social graphs, POAP, Gitcoin Passport

[Attestation Layer]
  EAS on-chain attestations (schemas + records)
  Off-chain EAS (signed, stored in IPFS)

[Aggregation Layer]
  Off-chain indexer (The Graph subgraph)
  Score calculation service (updatable algorithm)
  ZK proof generation (for privacy-preserving queries)

[Consumer Layer]
  On-chain: smart contract queries (Merkle proof or oracle)
  Off-chain: REST API, GraphQL
  Frontend: reputation display components

Development Process

Phase 1 — Architecture (1-2 weeks): define core signals, EAS attestation schemas, privacy model, cross-chain requirements.

Phase 2 — Core Contracts (2-3 weeks): EAS schemas, SBT contracts (if needed), on-chain aggregation if required.

Phase 3 — Indexer and API (2-3 weeks): The Graph subgraph for event indexing, score calculation service, REST/GraphQL API.

Phase 4 — ZK Layer (2-4 weeks, if needed): Circom schemas for privacy-preserving proofs, verifier contracts.

Phase 5 — Frontend (1-2 weeks): reputation dashboard, attestation UI, integration with consumer dApps.

Full production-ready system with privacy layer and cross-chain support — 3-4 months development. MVP with basic attestations and API — 4-6 weeks.