ZentraScore Credit Scoring Methodology

ZentraScore is the first trustless, on-chain credit scoring infrastructure purpose-built for decentralized finance. This document constitutes ZentraScore's formal methodology disclosure, prepared in response to Aave governance community feedback requesting greater transparency before the ZentraScore integration proposal advances to an ARFC.

ZentraScore uses a weighted linear scoring model. It is not a black-box machine learning classifier. All input data is fully on-chain and publicly verifiable by any party. There are no off-chain data sources, no identity inputs, and no private oracle feeds.

This document covers the following:

• The complete feature list — all six scoring factors, their data sources, and normalization methods
• The model architecture — the functional form, weight structure, and scoring range
• The oracle lifecycle — update cadence, trigger events, TTL, and staleness handling
• The anti-fraud and anti-manipulation layer — Sybil detection, wash-repayment analysis, and anomaly scoring
• Known failure modes — explicit scenarios where the model is expected to underperform, with mitigations
• Governance controls — the on-chain parameters Aave governance will control in Phase 1
• Versioning and change management — the notice and freeze process for any model updates
• Independent verifiability — how any party can audit ZentraScore's outputs

This document is versioned at v1.0 and will be updated in advance of any material methodology change, following the versioning protocol described in Section 8.

2.1 Score Range and Functional Form

ZentraScore assigns wallet addresses a score in the range 300 to 850, mirroring the familiar FICO scale for intuitive interpretation. The functional form is a weighted linear combination of six normalized sub-scores:

Final Score = 300 + 550 × Σ(wᵢ × normalizedFactorᵢ)

where:
  300                    = minimum score floor
  550                    = score range (300 to 850)
  wᵢ                     = weight for factor i (Σ wᵢ = 1.0)
  normalizedFactorᵢ      = sub-score for factor i, range [0.0, 1.0]

Each normalizedFactor is computed independently from on-chain data and then scaled to [0, 1] before entering the final formula. The linear model is intentional: it is transparent, auditable, and produces no hidden interactions between variables that could be exploited by sophisticated actors.

Weight disclosure: ZentraScore's factor weights are currently proprietary. We commit to making them available for full review by Chaos Labs and LlamaRisk under a formal data agreement as part of the ARFC risk assessment process. We are also open to disclosing them publicly under a governance-ratified confidentiality framework if the community determines this is necessary for the integration to proceed.

2.2 Scoring Factors

The table below documents all six scoring factors, their relative weights, data sources, and what each factor measures. No additional hidden factors exist beyond those listed below.

2.3 Score Bands and Aave Phase 1 Rate Discounts

The following table shows the score band definitions and the proposed APR discount structure for Aave V3 Phase 1. These discounts apply to USDC stablecoin borrowing markets only and represent a hard ceiling enforced by the maxDiscount governance parameter described in Section 6.

3.1 Indexed Protocols

ZentraScore indexes on-chain events from the following protocols. Coverage is as of v1.0 (May 2026). New protocol additions constitute a non-breaking change and are announced on the governance forum with 14 days notice.

• Aave V2 and V3 — all active markets on Ethereum, Arbitrum, Base, Avalanche
• Compound II and Compound III (all active Comets)
• MakerDAO / SparkLend — DSS core and Spark lending markets
• Uniswap V3 — LP position and fee data used for asset diversity signal only
• Curve Finance — gauge and pool interactions for asset diversity signal
• Morpho — Morpho Blue and Morpho Aave optimizer
• Balancer V2 and V3
• Euler Finance V1 (historical data) and V2
• Exactly Protocol
• Silo Finance
• Radiant Capital
• Venus Protocol (BNB Chain — imported into cross-chain score)
• Benqi (Avalanche)
• Seamless Protocol (Base)
• Moonwell (Base)
• Additional protocols: subject to a published onboarding checklist; new additions announced with 14 days notice

3.2 Indexed Chains

• Ethereum Mainnet
• Arbitrum One
• Base
• Avalanche C-Chain
• Unichain

All five chains are indexed in real time. Cross-chain history is aggregated at the wallet address level using deterministic address matching (same private key = same address on all EVM chains). There is no bridging of scores between chains — history is pooled, not transferred.

3.3 Indexed Events

The following smart contract events are indexed as scoring triggers. This list is exhaustive for v1.0 and constitutes the complete set of on-chain data inputs to the model.

Aave V3:        Borrow(), Repay(), LiquidationCall(), Supply(), Withdraw()
Compound III:   Supply(), Withdraw(), AbsorbDebt(), BuyCollateral()
MakerDAO:       Frob() [CDP operations], Bite() [liquidations]
SparkLend:      Borrow(), Repay(), LiquidationCall()
Morpho Blue:    Borrow(), Repay(), Liquidate(), SupplyCollateral()
Uniswap V3:     IncreaseLiquidity(), DecreaseLiquidity() [LP only, not swaps]
Curve:          AddLiquidity(), RemoveLiquidity() [gauge deposits only]

Events that are explicitly excluded from scoring: flash loans (same-block borrow and repay), MEV bot activity identified by known bot address lists, internal protocol accounting events, and governance voting actions.

3.4 Minimum Activity Threshold

A wallet must meet all of the following criteria before a score is published to the oracle. Wallets below threshold return valid = false:

• At least 180 days of verifiable DeFi activity (first indexed event to present)
• At least 3 distinct borrow-and-repay cycles across any indexed protocol
• At least 1 indexed interaction in the last 365 days (liveness check)

Wallets that fail the minimum threshold are not penalized — they simply receive no score, and any protocol reading the oracle receives valid = false, triggering the fallback to standard rates. There is no "bad" score for new wallets.

4.1 Score Computation Pipeline

The following describes the complete lifecycle of a score from on-chain event detection to oracle publication:

1. On-chain event detected (e.g. Repay() on Aave V3)
   • Indexer picks up event via WebSocket subscription (<2 seconds)
2. Affected wallet identified from event calldata
   • Full borrow/repay history for wallet fetched from indexed database
3. All six sub-scores recomputed from raw event history
   • Flash loan filter applied at this stage
   • Minimum activity threshold re-evaluated
4. Anti-fraud checks run (see Section 5)
   • If anomaly detected: score update paused, last valid score retained
   • If Sybil flag raised: score capped and flagged field set to true
5. Final score submitted to 2-of-3 oracle consensus network
   • All three oracle nodes compute independently from shared indexed data
   • Consensus requires agreement from at least 2 of 3 nodes
6. Agreed score written to CreditScoreOracle contract on-chain
   • TTL set to 7 days from publication timestamp
   • score (uint16), valid (bool), flagged (bool), version (bytes32) published
7. Protocol reads score synchronously at time of borrow
   • If valid == false OR TTL expired: fallback to standard rates
   • If flagged == true: score treated as Fair band (no discount)

4.2 Oracle Interface

The CreditScoreOracle contract exposes the following interface. Any protocol may call getScore() synchronously at any time:

interface ICreditScoreOracle {
    // Returns the current published score for a wallet address
    // score:   300-850 (0 if unscored or TTL expired)
    // valid:   false if wallet is unscored, TTL expired, or oracle offline
    // flagged: true if score is under active anti-fraud review
    // version: current model version hash (compare against frozenVersion)
    function getScore(address wallet)
        external view
        returns (
            uint16  score,
            bool    valid,
            bool    flagged,
            bytes32 version
        );
}

4.3 TTL and Staleness

Every published score carries a 7-day Time-To-Live (TTL). After 7 days without a refresh event, valid automatically returns false and the Aave adapter falls back to standard rates for new borrows. Existing borrowing positions are not affected by TTL expiry — rate discounts lock in at origination time for the duration of the loan.

Exception: liquidation events trigger an immediate score recompute and oracle republication, bypassing the standard TTL. A wallet that is liquidated will have its score updated within 2 seconds of the on-chain event, even if its previous score was published moments earlier.

4.4 Oracle Network

ZentraScore operates a 2-of-3 oracle consensus network. The three nodes are operated by geographically and organizationally distinct infrastructure providers. Score publication requires cryptographic agreement from at least 2 of 3 nodes.

If any single node goes offline, the network continues functioning normally. If 2 or more nodes go offline simultaneously, score updates cannot be published. In this scenario:

• Existing TTL-valid scores continue to be readable for up to 7 days
• After TTL expiry, valid returns false and Aave adapter falls back to standard rates
• No incorrect or manipulated score can be published without 2-of-3 consensus

ZentraScore commits to publishing oracle node uptime metrics monthly on governance.aave.com for the duration of the Phase 1 integration.

ZentraScore applies four independent anti-manipulation checks to every score before publication. These checks are designed to make the cost of manufacturing a fraudulent high score exceed any economic benefit available in Phase 1 (rate discounts only, full collateral required).

5.1 Sybil Wallet Clustering Detection

ZentraScore builds a directed graph of fund flows across all indexed wallets on all five chains. Wallet clusters are identified using the following signals:

• Shared funding source: wallets funded from the same EOA or contract within a 30-day window
• Synchronized behavioral timing: wallets that execute borrow/repay cycles within the same block or within narrow time windows across multiple protocols
• Circular capital routing: wallet A funds wallet B funds wallet C in a pattern consistent with coordinated score inflation
• Identical interaction sequences: wallets that interact with the same set of protocols in the same order within a short time period

When a cluster is identified, the cluster's scores are capped at the Fair band (580) regardless of their raw computed scores, and the flagged field is set to true. Cluster membership and flagging rationale are logged to a public on-chain event for auditability.

False positive rate: We estimate the current false positive rate for Sybil detection at under 0.5% of scored wallets, based on internal validation against labeled datasets. We will share this validation data with Chaos Labs and LlamaRisk as part of the back-test process.

5.2 Wash-Repayment Detection

Wash repayment refers to circular borrow/repay cycles where the net capital genuinely at risk is near zero. Detection method:

• For every borrow event, the indexer traces the destination of borrowed funds for up to 5 hops
• If borrowed funds are routed back to the same wallet or a first-degree cluster wallet within 14 days, the repayment cycle is classified as a wash
• Wash repayment cycles are down-weighted to 10% of their face value in the Repayment History factor
• A wallet where more than 60% of repayment volume is classified as wash activity receives a Repayment History sub-score of zero

Minimum genuine capital at risk threshold: Repayment cycles where the borrowed funds remain outside the originating wallet for less than 1 block are excluded entirely from scoring (flash loan filter).

5.3 Circular Fund Flow Detection

Circular fund flow detection catches more sophisticated routing designed to manufacture repayment history across seemingly unrelated wallets. The detection algorithm:

• Builds a weighted directed graph of all fund transfers between indexed wallets
• Runs cycle detection (DFS-based) on the graph to identify closed loops
• Flags cycles where the aggregate loan volume in the loop exceeds 10× the external capital entering the loop
• Penalizes all wallets participating in a flagged cycle proportionally to their share of loop volume

5.4 Behavioral Anomaly Scoring

Behavioral anomaly detection flags sudden changes inconsistent with a wallet's historical pattern:

• Score increase greater than 100 points within any 30-day window triggers a manual review hold
• During the hold, the oracle continues to publish the last valid pre-anomaly score with flagged = true
• Reviews are completed within 72 hours; if the anomaly is explained by genuine new activity, the updated score is published and flagged reverts to false
• If the anomaly is consistent with manipulation, the Sybil cap is applied

All four of the following parameters are encoded in the ZentraScore integration adapter contract and are controllable exclusively by Aave governance via standard governance proposals. ZentraScore has no ability to modify these parameters unilaterally after deployment.

6.1 Aave Integration Adapter Architecture

contract ZentraScoreAaveAdapter {
    ICreditScoreOracle public oracle;
    uint16  public maxDiscount;    // bps, e.g. 150 = 1.5%
    bool    public oracleActive;   // master kill switch
    bool    public scopeLock;      // prevents LTV use without new governance vote
    bytes32 public frozenVersion;  // pin to specific model version

    // Called by Aave interest rate strategy at borrow time
    function getDiscount(address borrower)
        external view returns (uint16 discountBps)
    {
        if (!oracleActive) return 0;
        (uint16 score, bool valid, bool flagged, bytes32 version) =
            oracle.getScore(borrower);
        if (!valid || flagged) return 0;
        if (frozenVersion != bytes32(0) && version != frozenVersion) return 0;
        uint16 raw = _scoreToDiscount(score);
        return raw > maxDiscount ? maxDiscount : raw;
    }

    // All setter functions require onlyGovernance modifier
    function setOracleActive(bool active)   external onlyGovernance { ... }
    function setMaxDiscount(uint16 bps)     external onlyGovernance { ... }
    function setScopeLock(bool locked)      external onlyGovernance { ... }
    function setFrozenVersion(bytes32 v)    external onlyGovernance { ... }
}

6.2 Sunset Clause

Phase 1 includes an automatic sunset provision. If Chaos Labs or LlamaRisk do not publish a Phase 1 performance review within 180 days of mainnet deployment, the oracleActive flag automatically reverts to false until the review is completed and governance votes to reactivate. This is encoded at the contract level, not as a soft commitment.

The following table documents scenarios where ZentraScore is expected to underperform. We consider transparent disclosure of failure modes to be essential for Aave governance to make an informed decision about the integration. This section is not exhaustive — it covers the failure modes we are aware of as of v1.0.

8.1 Version Numbering

ZentraScore uses semantic versioning for all methodology changes:

• Major version (e.g. 1.x to 2.x): Change to the scoring model class, addition or removal of a scoring factor, or weight rebalancing exceeding 10 percentage points on any single factor. Requires 30-day governance notice and explicit Aave governance vote to adopt.
• Minor version (e.g. 1.0 to 1.1): Addition of a new indexed protocol, new chain support, or threshold adjustments within the existing model. Requires 14-day governance notice. Aave governance may freeze at current version using frozenVersion parameter.
• Patch version (e.g. 1.0.0 to 1.0.1): Bug fixes, data correction, or anti-fraud parameter tuning with no impact on the scoring formula. Requires 7-day governance notice.

8.2 Notification Process

All methodology changes will be announced on governance.aave.com in a dedicated ZentraScore methodology thread at least 14 days before taking effect (30 days for major versions). The notification will include:

• A summary of what is changing and why
• The new version number and effective date
• A diff-style comparison of the old and new methodology for the affected sections
• An assessment of expected impact on existing scores (directional, not wallet-level)

Aave governance may respond to any notification by setting frozenVersion to the current version, blocking adoption of the new version for Aave's integration until governance explicitly approves it.

8.3 Version Log

A public version changelog is maintained at zentrascore.com/changelog and mirrored to a public GitHub repository. All versions are immutably recorded.

9.1 Public Oracle Contracts

The CreditScoreOracle contract is deployed and verified on all five indexed chains. Any party may call getScore(address) on-chain at any time to verify the published score for any wallet. Contract addresses will be published in the ARFC technical annex and maintained at zentrascore.com/contracts.

9.2 Open-Source Indexing Logic

ZentraScore commits to open-sourcing the event indexing and sub-score normalization logic on GitHub prior to the ARFC vote. This includes:

• The complete event indexing pipeline (which events are captured and how)
• The normalization functions for each of the six sub-scores
• The anti-fraud detection algorithms (Sybil, wash-repayment, circular fund flow, anomaly)
• The minimum activity threshold logic

The factor weights will not be publicly disclosed in the open-source repository but will be made available to Chaos Labs and LlamaRisk under a formal data agreement. We are open to governance directing us to disclose weights publicly if the community determines this is necessary.

9.3 Score Explorer

Any wallet's ZentraScore can be looked up at zentrascore.com, which displays the overall score, the sub-score breakdown for all six factors, the factors that most positively and negatively affect the score, and a flag if the wallet is under anti-fraud review.

9.4 Discrepancy & Dispute Mechanism

In response to community feedback (Aave forum, May 2026), the discrepancy process has been expanded into a formal three-tier dispute mechanism. Every reported discrepancy and its outcome is logged to a public registry at zentrascore.com/discrepancies. The score is not final and unchallengeable.

Tier 1 — Technical discrepancy review

Any wallet owner or third party may file a discrepancy via support@zentrascore.com or by emitting a DiscrepancyReport(address wallet, bytes32 reason) event from the wallet itself. ZentraScore commits to a Tier 1 review SLA of 72 hours, with the outcome published publicly at /discrepancies. Outcomes are one of:

• Score recomputed — reason and the corrected score are published, and the new score is propagated to the oracle.
• Score confirmed correct — the input data and the factor breakdown are published so the reporter can audit the calculation themselves.
• Anti-fraud flag confirmed or removed — the rationale and the cluster ID (if applicable) are published.

Tier 2 — Public escalation

If the wallet owner disputes the Tier 1 outcome, they may escalate by posting in a dedicated ZentraScore Discrepancy Reviews thread on governance.aave.com. The Risk Service Provider may post their own opinion on any Tier 2 escalation. ZentraScore commits to responding to every Tier 2 escalation within 7 days, referencing the specific on-chain events used to compute the disputed score so the response is independently verifiable.

Tier 3 — Aave governance override

Two contract-level overrides are available to Aave governance without requiring ZentraScore's cooperation:

• setOracleActive(false) — disables all ZentraScore-driven discounts immediately. No emergency spell, no exceptions.
• setFrozenVersion(v) — pins the integration to a specific model version, blocking adoption of any newer version until governance explicitly approves it.

Quarterly Discrepancy Transparency Report

ZentraScore commits to publishing a quarterly Discrepancy Transparency Report to the Aave governance forum for the duration of the Phase 1 integration. Each report includes:

• Total Tier 1 reports filed and resolution outcomes
• Median and 95th-percentile time-to-resolution against the 72-hour SLA
• False-positive rate on Sybil flags and other anti-fraud flags, with adversarial-test validation data
• Tier 2 escalations and how each was resolved
• Any model adjustments made in response to discrepancies

The first report will be filed at the 90-day mark post-deployment.

10.1 Data Available for Independent Review

ZentraScore will provide the following datasets to Chaos Labs and LlamaRisk upon their confirmation of engagement for the Phase 1 back-test:

• Full historical score dataset for all 2.4M+ indexed wallets from protocol genesis to May 2026
• Labeled default and liquidation events cross-referenced against wallet scores at time of borrow (to test score predictive validity)
• Complete Sybil detection and wash-repayment logs to allow evaluation of anti-fraud hit rates and false positive rates
• Synthetic adversarial test datasets: clustered Sybil wallets, circular wash-repay cycles, wallet hopping after default — constructed by ZentraScore and shared for reviewer validation

10.2 Requested Back-Test Scope

We request that Chaos Labs and LlamaRisk evaluate the following specific questions as part of their Phase 1 back-test:

• Does ZentraScore at launch (740+ threshold) predict lower default rates than the general Aave borrower population over 90-day, 180-day, and 365-day windows?
• What is the estimated proportion of Aave's active borrower base that would qualify for each discount band?
• What is the estimated maximum adversarial score manipulation cost under Phase 1 (rate discounts only, 150 bps cap)?
• Are there specific collateral asset markets or borrower segments where the model is expected to perform less reliably?

ZentraScore requests that Chaos Labs and LlamaRisk confirm their willingness to conduct this back-test on the Aave governance forum in response to this methodology note. We will fund all data preparation costs and make ourselves available for technical Q&A throughout the review.

The following table summarizes all commitments made to Aave governance, including those made in the forum response to community feedback on the TEMP CHECK. All on-chain commitments will be encoded in the integration contract before audit.