zScore Docs
  • Core
    • What is zScore
    • How It Works
    • Operational Mechanics
  • For Operators
    • Mainnet
      • Quickstart (Mainnet)
      • Registration (Mainnet)
Powered by GitBook
On this page
  • Onchain Components
  • Score Types
  • Integration Guide
  • Off-chain Components
  1. Core

Operational Mechanics

Onchain Components

The system consists of four main components:

  1. ZCreditScore Contract - Manages real-world credit scores

  2. ZScore Contract - Handles onchain reputation scores

  3. ScoreRegistry - Manages cross-chain score synchronization

  4. Reclaim Protocol Integration - Verifies real-world data

Scores are available on Base and Ethereum mainnet.

Score Types

Real World Scores

Traditional credit scores verified through the ZK proofs via Reclaim Protocol. These scores use cryptographic proof verification to maintain the safety of the user's identity.

zScore

Onchain reputation metrics based on protocol interactions. These are updated through a Merkle proof, on a scheduled basis every 6 hours, and synchronization then occurs cross-chain via LayerZero messaging. Users can also set their real-world scores via API to be in a mapping to be easily read by other contracts.

Integration Guide

Adding Real World Scores

  1. Contract Interface:

sfunction reclaimCreditScore(
    Reclaim.Proof memory proof,
    bytes32 userHash
) external payable
  1. Implementation Steps:

    • Generate Reclaim proof

    • Calculate user hash

    • Submit transaction with required gas

    • Monitor for success events

  2. Required Parameters:

    • Proof structure containing:

      • User address

      • Score value

      • Provider information

    • User hash for verification

Adding zScores

  1. Contract Interface:

function setUserScore(
    address user,
    uint256 score,
    bytes calldata proof
) external payable
  1. Implementation Steps:

    • Obtain Merkle proof

    • Verify user address

    • Submit score update

    • Monitor cross-chain sync

  2. Required Parameters:

    • User's Ethereum address

    • User's zScore

    • Merkle proof containing score data

Onchain Footprint

AVS should provide a comprehensive list of all deployed smart contracts, including:

  • Contract addresses, along with their purposes and what business logic they contain

  • Interaction flow between contracts

  • Upgrade mechanisms (if upgradable)

  • Explain how the contracts integrate with EigenLayer core protocol features

  • Completed public audit

Off-chain Components

  • Execution Service

    • NestJS server that processes wallet transactions and computes scores

    • Uses AWS SQS for job management and worker coordination

    • Worker nodes process transactions with configurable concurrency limits

    • Submits computed Merkle roots to operator network for validation

  • Operator Network

    • Decentralized nodes that validate score computations

    • Each operator stakes ETH through EigenLayer for security

    • Operators fetch transaction data from the database for score verification

    • Uses BLS signatures for efficient consensus aggregation

    • Validation process:

      • Randomly sample 3 wallets from computed scores

      • Recompute scores for sampled wallets

      • Compare against submitted Merkle root

      • Sign approval if verification succeeds

  • RocksDB Database

    • Stores wallet transaction history and computed scores

    • Indexed by wallet address → network → protocol

    • Maintains Merkle tree of all valid scores

    • Updates every 6 hours with new transaction data

  • Cross-chain Communication

    • Attestation center aggregates operator signatures

    • Upon 2/3 consensus, submits Merkle root to L1

    • Layer Zero handles cross-chain message propagation

    • Score Registry contracts sync across all supported chains

  • Consensus Resolution

    • Requires 2/3 of total staked voting power for root updates

    • Failed validations trigger automatic recomputation

    • Operators slashed for incorrect validations

    • System remains in previous state if consensus fails

PreviousHow It WorksNextMainnet

Last updated 2 months ago