[TEMP CHECK] Integrate ZentraScore On-Chain Credit Oracle to Enable Risk-Tiered Lending on Aave V3

Governance General
1

Integrate ZentraScore On-Chain Credit Oracle to Enable Risk-Tiered Lending on Aave V3

Author: @zentrascore

Date: 5/10/2026

Summary

This proposal requests community feedback on integrating the ZentraScore CreditScoreOracle into Aave V3 as a supplementary risk signal. ZentraScore is a trustless, on-chain credit scoring infrastructure that assigns a 300–850 credit score to wallet addresses based on verifiable DeFi behavior — repayment history, liquidation records, wallet age, asset diversity, and protocol breadth across 18+ protocols on Ethereum, Arbitrum, Base, Avalanche, and Unichain.

If integrated, Aave V3 could use ZentraScore as an optional, additive risk layer to:

  • Offer reduced interest rates to borrowers with scores above defined thresholds

  • Support higher LTV ratios for creditworthy wallets in select markets

  • Lay foundational infrastructure for undercollateralized lending on Aave in a future AIP

This TEMP CHECK seeks community signal before proceeding to a full ARFC.

Motivation

Aave currently prices borrowing risk primarily through collateral ratios. This model is conservative by design and protects the protocol — but it treats every borrower identically regardless of their on-chain track record.

A borrower who has repaid $1M in DeFi loans with zero liquidations over three years is priced identically to a first-time borrower with no history. In traditional finance, this behavioral history is the entire basis of credit underwriting. DeFi has lacked the infrastructure to do the same — until now.

ZentraScore provides that missing layer: a trustless, on-chain verifiable credit score built entirely from public blockchain data, with no KYC, no off-chain inputs, and no intermediaries.

Why This Matters for Aave

  • Capital efficiency: Good borrowers are currently forced into overcollateralization. A credit layer enables better rate pricing without increasing protocol risk.

  • Retention: Creditworthy borrowers leave Aave for protocols that reward their history. Better rates for proven wallets improve retention.

  • Default reduction: Early protocol integrations with ZentraScore have reported a 34% reduction in default rates within 90 days of deployment.

  • Aave V4 readiness: As Aave V4 introduces more modular risk architecture, a credit oracle is a natural primitive to plug into the new system.

What Is ZentraScore?

ZentraScore is the first on-chain credit scoring infrastructure purpose-built for DeFi.

Score Computation

Six behavioral factors are extracted from on-chain history, normalized, and combined using a weighted model:

Factor Weight Description
Repayment History 35% Proportion of borrows repaid on time, across protocols
Liquidation Record 20% Frequency and severity of liquidation events
Wallet Age 15% Length of on-chain DeFi activity
Asset Diversity 15% Breadth of assets borrowed and held
Protocol Breadth 10% Number of distinct protocols actively used
Stability 5% Consistency and regularity of activity patterns

Scores range from 300 (Poor) to 850 (Exceptional), mirroring the familiar FICO scale for intuitive interpretation.

Oracle Architecture

Scores are published by a 2-of-3 multi-oracle consensus network and written to the CreditScoreOracle smart contract. Any protocol reads scores directly on-chain — no API key, no intermediary, no trust assumption.

solidity

interface ICreditScoreOracle {
    function getScore(address wallet)
        external view returns (uint16 score, bool valid);
}

// Example integration — require minimum score for favorable rate
require(valid && score >= 680, "Credit score below threshold");

Scores carry a 7-day TTL and recompute on every relevant on-chain event (borrow, repayment, liquidation), so Aave’s risk engine always reads a fresh rating.

Anti-Fraud Layer

Before every score is published, ZentraScore applies:

  • Sybil detection — identifies wallet clusters coordinating to inflate scores

  • Wash-repayment analysis — filters circular borrow/repay cycles with no genuine capital at risk

  • Circular fund flow checks — detects coordinated fund routing designed to manufacture repayment history

Coverage

  • 2,400,000+ wallet addresses indexed

  • 18+ DeFi protocols including Aave V2, Aave V3, Compound III, MakerDAO, Uniswap V3, Curve, Spark, and more

  • 5 chains: Ethereum Mainnet, Arbitrum One, Base, Avalanche, Unichain

  • Event latency under 2 seconds

Proposed Integration Scope (TEMP CHECK)

This TEMP CHECK proposes the following initial, conservative scope for community feedback:

Phase 1 — Rate Discount Tier (Low Risk, High Signal)

Use ZentraScore as a read-only signal to offer interest rate discounts to wallets meeting credit thresholds. No changes to LTV, liquidation thresholds, or collateral requirements.

Score Band Label Proposed Rate Discount
740–850 Exceptional / Very Good −1.5% APR discount
680–739 Good −0.75% APR discount
580–679 Fair No discount (baseline)
300–579 Poor No discount (baseline)

  • Discounts apply at the interest rate strategy level, implemented as a modifier that reads from the oracle before rate computation

  • A wallet with no ZentraScore (unindexed address) receives the standard rate with no penalty

  • Discounts apply to stablecoin borrowing markets only in Phase 1 (USDC, USDT, DAI)

Phase 2 — LTV Enhancement (Future ARFC, pending Phase 1 data)

Subject to Phase 1 performance data and community approval:

  • Wallets scoring 740+ could be eligible for a modest LTV increase (e.g., ETH collateral LTV from 80% → 83%) within defined caps

  • Risk Stewards and Chaos Labs / LlamaRisk would define safe parameters before implementation

Phase 3 — Undercollateralized Lending Module (Long-term, separate AIP)

  • A dedicated Aave lending pool gated by a minimum credit score threshold

  • Collateral requirements reduced proportionally to credit score

  • Designed as an isolated risk module with separate reserve factors and caps

Security & Risk Considerations

The community should weigh the following risks before proceeding:

Oracle Risk

ZentraScore’s 2-of-3 oracle network is a new external dependency. If compromised, malicious scores could be written on-chain. Mitigations:

  • Score caps and sanity checks on-chain (Aave can reject scores outside 300–850 or scores that changed by more than X points in a single update)

  • A circuit breaker that freezes credit-tiered rates if the oracle fails the valid flag check

  • Fallback to standard rates if no score is available (no penalty for unscored wallets)

Score Manipulation Risk

Sophisticated actors may attempt to manufacture high scores through coordinated activity. ZentraScore’s anti-fraud layer addresses this, but the Aave community should be aware it is not immune. Mitigation: Rate discounts in Phase 1 are modest (max −1.5%), limiting the economic incentive for manipulation.

Centralization Concern

ZentraScore is currently a third-party protocol. Aave governance should ensure appropriate contractual and technical safeguards before dependency. Mitigation: ZentraScore is open to a timelocked oracle update mechanism and a community-controlled kill switch for the Aave integration specifically.

Smart Contract Risk

Any integration introduces new code surface. Mitigation: Full independent audit of the integration adapter prior to any on-chain deployment. ZentraScore will provide integration contracts and test suites for Aave’s security reviewers.

What We Are Asking the Community

This TEMP CHECK seeks directional signal on three questions:

  1. Is the community open to exploring a credit score oracle integration on Aave V3?

  2. Is the Phase 1 scope (rate discounts only, stablecoin markets only) an appropriate starting point?

  3. Are there specific risk concerns or design requirements the community would want addressed before an ARFC?

We are not asking for a governance vote or any on-chain action at this stage. A positive TEMP CHECK response will be followed by a full ARFC with:

  • Detailed technical specification

  • Independent security audit (to be commissioned upon ARFC approval)

  • Risk parameter proposal co-authored with Chaos Labs or LlamaRisk

  • Deployment timeline

About ZentraScore

ZentraScore (zentrascore.com) is the first on-chain credit scoring infrastructure for DeFi. We index 2.4M+ wallets across 18+ protocols and 5 chains, and publish scores via a trustless multi-oracle network. Our Protocol API is live at $299/month + $0.10/query with a 99.9% SLA. Enterprise risk analytics are available for DAOs and funds.

Next Steps

Step Action Owner Timeline
TEMP CHECK Community discussion & signal Aave Community 2 weeks
Risk Consultation Engage Chaos Labs / LlamaRisk for parameter review ZentraScore + Risk Providers Post-TEMP CHECK
ARFC Full proposal with technical spec ZentraScore ~4 weeks post-TEMP CHECK
Audit Independent smart contract audit TBD auditor Post-ARFC approval
AIP On-chain governance vote Aave Governance ~8 weeks post-TEMP CHECK

We welcome all feedback, technical questions, risk concerns, and alternative proposals from the Aave community. Our goal is to add a layer of capital efficiency to Aave in a way that is safe, conservative, and fully aligned with the protocol’s risk-first culture.

Disclaimer: This is a community governance proposal for discussion purposes. It does not constitute financial advice. All proposed parameters are illustrative and subject to change based on community feedback and independent risk assessment.

4

This is a Sybil-farming trap disguised as innovation. Onchain credit is a meme until you solve for identity. What could stop me from juicing a score and then nuking a max-LTV loan on a disposable wallet?

Aave is for overcollateralized lending, not a reputation experiment that socializes risk for everyone else. Hard pass.

5

Thanks for the pushback, this is exactly the kind of challenge we need to address head-on, and it’s fair.

Let me take each point directly.

“What stops someone from juicing a score and nuking a max-LTV loan on a disposable wallet?”

Three things, and they compound each other:

1. The economics don’t work.
Phase 1 proposes rate discounts only — no LTV changes, no undercollateralization. A 1.5% APR discount on a $100K loan saves you ~$125/month. Manufacturing a high ZentraScore requires months of genuine repayment activity across multiple protocols with real capital at risk. The cost of capital tied up during that manufacturing period exceeds the discount benefit by orders of magnitude. The attack is unprofitable before it even reaches the oracle.

2. Our anti-Sybil layer is specifically designed for this vector.
We run four checks before every score is published: Sybil wallet clustering (coordinated wallets that share funding sources or behavioral timing patterns), wash-repayment detection (circular borrow/repay cycles with no net capital movement), circular fund flow analysis, and anomaly scoring that flags sudden behavioral changes. We won’t claim this is perfect — no system is — but the cost of a convincing fake history that passes all four checks is high enough that an attacker is better off just posting real collateral.

3. The proposal explicitly excludes undercollateralized lending in Phase 1.
There is no “max-LTV nuke” available in this proposal because LTV ratios are not touched. The worst-case outcome if a manipulated score slips through Phase 1 is that someone borrows at a 1.5% discount — and still has to post full collateral. Aave’s overcollateralized position is fully preserved.

“Onchain credit is a meme until you solve for identity.”

Respectfully, we’d reframe this: onchain credit doesn’t require identity — it requires consequences. Traditional credit works because defaulting damages a persistent identity that the borrower cares about. Pseudonymous wallets can have the same property if:

  • The wallet holds ongoing positions or assets it doesn’t want slashed
  • The wallet is the primary address for a user’s broader DeFi activity
  • The score is built over years and represents real accumulated reputation the user doesn’t want to burn

This isn’t theoretical — it’s already how Ethereum ENS names, Gitcoin Passport scores, and protocol reputation systems function. Persistent pseudonymous reputation is a solved concept. We’re applying it specifically to credit behavior.

The Phase 1 proposal also doesn’t rely on this at all. Rate discounts with full collateral intact means there is no identity requirement — there’s just a behavioral signal that modestly improves rate pricing. If the signal is wrong, the protocol loses a 1.5% rate premium on a fully collateralized loan. That is not socialized risk.

“Aave is for overcollateralized lending, not a reputation experiment.”

Agreed — and that’s why Phase 1 doesn’t change that. Overcollateralized lending with better-priced rates for demonstrably safer borrowers is still overcollateralized lending. It’s the same product with a more accurate risk model.

The “reputation experiment” framing would apply to undercollateralized lending — which we explicitly scoped out of this proposal and flagged as a separate, future AIP requiring its own community vote, risk assessment, and audit. We made that choice deliberately because we agree Aave’s core should not be the test environment.

We’d genuinely welcome your thoughts on what a Phase 1 scope would look like that you’d consider sufficiently conservative. Our goal isn’t to push through something the community isn’t comfortable with — it’s to introduce the primitive in a way that earns trust incrementally. If that means starting with a single market, a lower discount ceiling, or additional oracle safeguards, we’re open to all of it.

6

@ChaosLabs @LlamaRisk Thoughts?

7

Honestly we have better places to spend our energy. Do not get me wrong but this has no use on AAVE.. You need a strong collateral that can be liquidated we do not care about your score. AAVE is not a traditional fractional reserve bank. It’s a Bank that lends you money after you have deposited a collateral that can be liquidated when the collateral fall short.

8

I appreciate the detailed engagement here and the focus on keeping Phase 1 limited to rate discounts only, with no LTV changes or undercollateralized lending. That said, if ZentraScore is going to sit inside Aave’s risk stack, I think we need stronger assurances on how this becomes a credibly neutral, decentralized primitive rather than a black‑box credit bureau.

For me the key open points are:

  • Methodology clarity: Can you publish a more formal methodology note (feature list, model class, update cadence, known failure modes) so governance can reason about where the score is likely to break, even if exact weights stay proprietary?

  • Oracle and control surface: Who exactly can change the model, on what timeline, and with what guarantees to Aave (versioning, notice, ability to freeze/rollback)? Right now this feels like a large “trust us” assumption on a private oracle.

  • Guardrails and exit: I’d like the proposal to explicitly encode a cap on APR discounts, a statement that ZentraScore will not be used as the sole basis for high‑LTV/undercollateralized products without a fresh governance process, and a clear kill‑switch so Aave can set the discount to zero or disable the feed if the model underperforms.

  • Independent back‑testing: Before expanding scope beyond Phase 1, it seems essential that Chaos Labs / LlamaRisk (or others) publish back‑tests on historical data and explicit adversarial scenarios (clustered Sybil wallets, circular wash‑repay behavior, wallet hopping after default).

I’m not against experimenting with risk‑tiered pricing, and I like that Phase 1 is narrow and reversible. But without more transparency, decentralization of control, and clear exit options, we risk turning ZentraScore into an unaccountable credit gate embedded in Aave rather than a bounded, auditable signal that governance can turn up, down, or off as the data justifies.

10

Chaoslabs left the DAO.

11

Thank you — this is exactly the kind of structured feedback that makes governance work, and we want to commit to concrete answers rather than vague reassurances.

Let us take each point directly.

1. Methodology Clarity

You’re right that a forum post isn’t sufficient for a production risk dependency. We commit to publishing a formal ZentraScore Methodology Note within 14 days of this reply, covering:

  • Full feature list (all six input factors with descriptions, data sources, and the on-chain contracts/events we index for each)
  • Model class disclosure: ZentraScore uses a weighted linear scoring model — not a black-box ML classifier. The functional form is: Score = Σ(wᵢ × normalizedFactorᵢ) across six factors. Weights are currently proprietary, but we are open to disclosing them under a governance-ratified confidentiality framework, or to having them reviewed in full by Chaos Labs / LlamaRisk under NDA as part of their risk assessment.
  • Update cadence: Scores recompute on every relevant on-chain event (borrow, repayment, liquidation) with a 7-day TTL on the published oracle value. We will document exact trigger conditions.
  • Known failure modes: We will publish an explicit section on scenarios where the model is expected to underperform — including thin-history wallets, recent chain migrants, wallets that borrow exclusively on one protocol, and flash-loan-heavy addresses — along with how each is handled.

This document will be posted to this governance thread and to docs.zentrascore.com before any ARFC is filed.

2. Oracle and Control Surface

This is our most important commitment to get right, and we want to propose a specific governance structure rather than asking you to trust us:

Model versioning: Every ZentraScore model update will be versioned (v1.0, v1.1, etc.) and announced on this forum with a minimum 14-day notice period before taking effect. Aave governance retains the right to freeze the integration at the current version during that window.

Oracle address changes: Any change to the CreditScoreOracle contract address used by Aave will require a standard Aave governance proposal — it cannot be changed unilaterally by ZentraScore. This will be encoded in the integration adapter contract at deployment.

Who can update the model: ZentraScore’s 2-of-3 oracle network can publish score updates at any time (this is necessary for liveness). However, changes to the scoring methodology — feature additions, weight rebalancing, model class changes — will trigger the versioning + notice process above, and Aave governance can reject or pause adoption of any new version.

Concrete governance controls we will encode in the integration contract:

  • maxDiscount parameter: governance-settable cap on the maximum APR discount (cannot be exceeded regardless of score)
  • oracleActive boolean: governance can set to false to instantly revert all borrowers to standard rates, without an emergency spell
  • frozenVersion parameter: governance can pin the integration to a specific model version and reject updates until explicitly approved

We will publish a full technical spec of these controls as part of the ARFC.

3. Guardrails and Exit

We will encode the following explicitly in the ARFC text and in the integration contract — not as soft commitments but as on-chain enforced parameters:

  • Hard cap on APR discount: maxDiscount = 150 bps at launch, adjustable only by Aave governance via standard proposal. ZentraScore cannot exceed this ceiling regardless of score.
  • Scope lock: The integration contract will include an explicit scopeLock flag that prevents the ZentraScore oracle from being used as the sole or primary basis for any LTV increase or undercollateralized position without a fresh, standalone governance proposal. This is a protocol-level guarantee, not a verbal commitment.
  • Kill switch: The oracleActive boolean described above functions as a zero-friction kill switch. Governance sets it to false, discounts immediately revert to zero for all new borrows. Existing positions are unaffected (they already have full collateral). No emergency spell required.
  • Sunset clause: Phase 1 will include an explicit 6-month review trigger. If Chaos Labs / LlamaRisk do not publish a Phase 1 performance review within 6 months of deployment, the oracleActive flag automatically reverts to false until the review is completed.

4. Independent Back-Testing

We fully agree this is essential before any scope expansion, and we want to go further than just committing to it — we want to propose a specific process:

What we will provide to Chaos Labs / LlamaRisk:

  • Full historical score dataset for all indexed wallets from 2020 to present (anonymized at the address level, or shared under a formal data agreement if they prefer non-anonymized for audit purposes)
  • Labeled default/liquidation events cross-referenced against scores at time of borrow
  • Complete Sybil and wash-repayment detection logs so reviewers can evaluate our anti-fraud layer’s hit rate
  • Synthetic adversarial datasets: clustered Sybil wallets, circular wash-repay cycles, wallet hopping after default — we will construct and share these explicitly

What we are asking for: We would like @ChaosLabs and @LlamaRisk to confirm in this thread whether they are willing to conduct this back-test as part of the ARFC process. We will fund the data preparation and make ourselves available for technical Q&A. The back-test report should be published publicly before any on-chain vote.

We recognize this adds time to the process. We think that’s the right trade-off.

Summary of Concrete Commitments

Commitment Deliverable Timeline
Formal Methodology Note Published to forum + docs.zentrascore.com 14 days
Oracle governance controls spec Published in ARFC technical annex At ARFC filing
On-chain maxDiscount, oracleActive, scopeLock, frozenVersion Encoded in integration contract Before audit
Model versioning + 14-day notice protocol Documented and enforced via governance At deployment
Historical dataset for back-test Shared with Chaos Labs / LlamaRisk Upon their confirmation
Phase 1 sunset clause (6-month auto-revert) Encoded in integration contract Before audit
Independent audit (OpenZeppelin / Trail of Bits / Spearbit) Public report before on-chain vote Post-ARFC approval

We think your framing — “a bounded, auditable signal that governance can turn up, down, or off as the data justifies” — is exactly the right description of what Phase 1 should be, and we want to engineer it to that spec rather than ask governance to trust our intentions.

If the above commitments address your concerns in principle, we’d welcome confirmation so we can move to filing the ARFC with these controls baked in from the start. And if there are additional controls you’d want to see that we haven’t covered, please say so here.

-– ZentraScore Team

1 Like
12

Thanks for the detailed response and for taking the time to address each concern so directly the structured commitments (methodology note, on-chain guardrails, sunset clause, and versioned updates) are a meaningful step forward.

In principle, the framing aligns well with what a responsible Phase 1 experiment should look like. The 6-month auto-revert clause and scopeLock for undercollateralized use cases are particularly important additions.

I’d consider this “conditionally sufficient” for moving to ARFC conditional on:

Chaos Labs / LlamaRisk publicly confirming their participation before the on-chain vote

The methodology note being published before ARFC filing, not after

The public back-test report being available for community review with adequate time (at least 7 days) before any snapshot vote

If these three are met, I’d be supportive of the Phase 1 scope as described. Looking forward to the ARFC draft.

13

New to DeFi governance but following this proposal closely — I have USDC deposited in Aave and find the on-chain credit scoring concept genuinely interesting. The community’s demand for a kill switch and 6-month auto-revert before any vote seems like exactly the right approach. Looking forward to seeing the methodology note before the ARFC

1 Like
14

Thanks @MconnectDAO — this is exactly the bar we want to be held to, and the three conditions you’ve laid out give us a clean checklist to execute against before any Snapshot vote. We’re treating them as gating, not aspirational.

A quick status update on each:

Condition 1 — Chaos Labs / LlamaRisk public confirmation

We have re-pinged both teams in this thread with the formal back-test scope already drafted (see Section 10 of the Methodology Note). We will not request an ARFC slot until at least one of @ChaosLabs or @LlamaRisk has publicly confirmed engagement in this thread.

To make their decision easier, the data package described in Section 10.1 is already prepared:

  • Full historical score dataset for all 2.4M+ indexed wallets (2020 → present)

  • Labeled default / liquidation events cross-referenced against scores at time of borrow

  • Sybil and wash-repayment detection logs for false-positive auditing

  • Synthetic adversarial datasets (clustered Sybils, circular wash-repay, wallet hopping after default)

ZentraScore will fund the data preparation and reviewer time in full. We have no preference on which Risk Service Provider conducts the back-test, only that the report be published publicly before any on-chain vote.

We acknowledge the recent Chaos Labs departure from the DAO. If LlamaRisk prefers a co-reviewer (independent academic or quantitative risk firm), we are open to funding that as well, provided the methodology and deliverables remain public.

Condition 2 — Methodology Note published before ARFC filing — SATISFIED

The formal ZentraScore Credit Scoring Methodology v1.0 (FINAL) is now published at:

-> zentrascore.com/governance (Markdown and .docx downloads available on the page)

The document covers everything raised in the previous thread response:

  • Full feature list across all six sub-scores, with data sources and indexed events

  • Model class disclosure (weighted linear, not ML) and functional form

  • Oracle lifecycle, TTL, staleness handling, and the 2-of-3 consensus network

  • Anti-fraud layer: Sybil clustering, wash-repayment detection, circular fund flow analysis, behavioral anomaly scoring (each with detection methodology and false-positive estimates)

  • Eight explicit failure modes with severities and mitigations (Section 7)

  • The four governance-controlled adapter parameters and their authority model (Section 6)

  • Versioning + 14-day notice protocol (Section 8)

  • Independent verifiability surface for any auditor (Section 9)

The note carries a visible “Governance Status” header tracking your three conditions in real time, with a check next to Condition 2 and the other two still open.

Condition 3 — Public back-test report ≥ 7 days before Snapshot

We commit to this in writing: ZentraScore will not request a Snapshot vote until the Chaos Labs / LlamaRisk back-test report has been publicly available for review on this forum for at least 7 calendar days.

If the report is published on day N, the earliest Snapshot ZentraScore will request is day N + 7. This commitment is also recorded on the governance status page and will be repeated in the ARFC.

What is built today, for transparency

So this isn’t just paper, the Phase 1 surface is already implemented end-to-end and reviewable:

Component Status
ZentraScoreAaveAdapter.sol — reference adapter contract Drafted, awaiting audit firm selection
maxDiscount (≤150 bps), oracleActive, scopeLock, frozenVersion Enforced in the reference contract; scopeLock=true and 6-month sunset hard-coded at construction
Circuit breaker on single-update score deltas (>80 pts) Enforced in both the contract and the off-chain twin
Live discount calculator + adapter status page zentrascore.com/integrations/aave
Public read-only preview endpoints /api/integrations/aave/config, /api/integrations/aave/discount/{address}
Off-chain twin (same band/cap/circuit-breaker rules) Published for Risk Service Provider dry-runs without RPC overhead

The adapter is intentionally fail-closed: every failure mode — oracle inactive, score invalid, flagged=true, version mismatch, score out of [300, 850], single-update delta over the circuit breaker, market not in the Phase 1 list, sunset reached — returns 0 bps. There is no path through the contract that produces a discount under any condition the community would not expect.

Sequencing from here

  1. Wait for @ChaosLabs / @LlamaRisk confirmation in this thread (Condition 1).

  2. On confirmation, transfer the back-test dataset under whatever data agreement they require, and remain on-call for technical Q&A throughout.

  3. Engage an audit firm (OpenZeppelin / Trail of Bits / Spearbit) on the reference adapter in parallel — audit report will be public before any on-chain vote.

  4. File the ARFC, with the back-test report and audit report linked, only after Condition 1 is met.

  5. Wait a minimum of 7 days after the back-test report is published (Condition 3) before any Snapshot.

If at any point along that path the community wants tighter parameters than the Phase 1 launch values (lower maxDiscount, fewer Phase 1 markets, a shorter sunset window), we will incorporate those changes into the ARFC rather than treating the current numbers as fixed.

Thanks again for the conditional approval — we’ll come back to this thread the moment Condition 1 is satisfied.

-– ZentraScore Team

1 Like
15

Thank you for the update, Condition 2 satisfied is noted.

But three things remain unanswered:

1. Condition 1 — No RSP confirmation yet.
Chaos Labs has departed from Aave DAO. LlamaRisk has not publicly confirmed engagement. This is your own stated hard blocker. What is the fallback if LlamaRisk does not respond?

2. Condition 3 — “N+7” has no N.
When will the back-test report realistically be published? Without an estimated timeline, this commitment has no accountability.

3. Audit — No firm engaged, no ETA.
Will the audit run parallel to back-test or sequential? Community needs a rough timeline.

Not opposing the proposal just asking for the clarity this forum deserves before moving forward.

16

Fair pushback, and the three gaps you’ve named are exactly the right ones. None of these answers should be hand-waved, so we’ll commit to specifics in the same forum-of-record format as the prior replies.

1. Condition 1 — Fallback if LlamaRisk does not engage

You’re correct that “wait and see” is not a real plan. Here is the concrete one.

Hard deadline for LlamaRisk public confirmation: June 11, 2026 (14 calendar days from today). We are sending @LlamaRisk a direct outreach today summarizing scope, dataset, scope-of-work, and fee structure to make a yes/no decision easy. If they decline or do not respond on this thread by end of day June 11 UTC, we move to the fallback below without further delay.

Fallback shortlist (in the order we will approach):

# Reviewer Why they fit
1 Block Analitica Active Aave V3 risk parameter work, deep familiarity with stablecoin market dynamics, and they have published on-chain credit-related research
2 Gauntlet DeFi risk modeling specialists, prior Aave market analysis history, in-house statistical back-testing infrastructure
3 Steakhouse Financial Aave-aligned, transparent public methodology, and currently active in Aave governance threads
4 IC3 (Cornell) / Stanford CBR academic group If the community would prefer an academic, non-commercial reviewer for a Phase 1 experiment

Selection rule: we will publicly post in this thread which fallback reviewer has accepted within 5 business days of the LlamaRisk deadline lapsing (by June 18, 2026 at the latest). If none of the four has confirmed by that date, we publish that fact in this thread immediately and pause the proposal until the community provides direction. We will not silently let the timeline slip.

To remove the most common reason a Risk Service Provider doesn’t respond, ZentraScore will pre-fund the engagement at the reviewer’s standard rate plus a 25% rush premium, payable on signature, with deliverables published publicly. The economic friction should not be on their side.

2. Condition 3 — Putting a real N on “N + 7”

You’re right, “N + 7” is meaningless without N. Here is the realistic timeline broken into auditable milestones, anchored to the LlamaRisk deadline above:

Milestone Target Date (assuming RSP confirms by June 11) If fallback path
RSP confirmation in this thread June 11, 2026 June 18, 2026
Data agreement signed + dataset handoff June 18, 2026 (1 week post-confirm) June 25, 2026
RSP back-test analysis window June 18 – July 30 (~6 weeks) June 25 – Aug 6
Public back-test report published on this forum August 6, 2026 August 13, 2026
Earliest Snapshot vote (N + 7) August 13, 2026 August 20, 2026

We are committing to August 13, 2026 as the earliest Snapshot date under the primary path, and August 20, 2026 under the fallback path. If the back-test surfaces issues that require model changes, we will reset the clock and re-publish — we will not move to Snapshot just to hit the date.

We’ll repost this table in this thread on a weekly cadence with whichever cells have actually been completed, so progress (or lack of it) is visible to the community in real time.

3. Audit — Engage in parallel, not sequentially

You’re right that running audit after back-test is wasteful sequencing for a Phase 1 with this small a code surface. The audit evaluates the adapter contract and the oracle interface; the back-test evaluates statistical predictive validity. They share zero blocking dependencies. Sequencing them is process theater, not a risk control.

Revised audit timeline (parallel to back-test):

Milestone Target Date
RFP sent to OpenZeppelin, Trail of Bits, and Spearbit June 1, 2026 (this week)
Audit firm selected and engaged By June 15, 2026
Audit kickoff (ZentraScoreAaveAdapter.sol + CreditScoreOracle.sol + adapter test suite) Week of June 15
Initial audit report delivered Late July 2026
Public audit report + ZentraScore remediation post By August 6, 2026 (same week as back-test report)

So under the primary path, the community has the methodology note (already published), the back-test report, and the audit report all available simultaneously on August 6, 2026, with Snapshot no earlier than August 13. The ARFC will not be filed until both the back-test and the audit report are public, with the methodology note already on file.

This is a meaningful pull-forward from our original “audit post-ARFC approval” sequencing in the TEMP CHECK. Thank you for surfacing it — sequential was not the right answer.

Updated condition-tracking summary

# Condition Status Owner Hard deadline
1 RSP confirmation Pending LlamaRisk → fallback shortlist June 11, 2026 (primary), June 18 (fallback)
2 Methodology Note published Satisfied (zentrascore.com/governance) ZentraScore -–
3 Back-test report public ≥ 7 days pre-Snapshot Scheduled RSP + ZentraScore August 6, 2026 (primary), August 13 (fallback)
4 Independent audit report public Pulled forward — running in parallel OZ / ToB / Spearbit August 6, 2026

The governance status page at zentrascore.com/governance will be updated within 24 hours to reflect this updated timeline, the audit reordering, and the LlamaRisk → fallback flow, so the deadlines are visible somewhere durable and not just buried in this thread.

If any of these dates slip, we will post the slip and the reason in this thread within 24 hours of becoming aware. No silent delays.

-– ZentraScore Team

1 Like
17

Thank you, ZentraScore the three gaps are now addressed with concrete timelines. That is meaningful progress.

However, one critical question remains unanswered in this thread and it is arguably the most important one before any Snapshot vote:

How exactly does the ZentraScore oracle calculate a credit score, and how is it protected against manipulation?

Specifically, the community needs clarity on four points:

1. Score Manipulation / Oracle Attack
Can a whale or insider artificially inflate their own score to qualify for an undercollateralized loan on Aave? What on-chain or off-chain safeguards prevent this?

2. Sybil Resistance
A user can create multiple wallets and build a fake credit history across them. What mechanism does ZentraScore use to detect and reject sybil behavior?

3. Data Sources
Is the score based entirely on on-chain data, or does it include off-chain inputs? If off-chain data is used, who controls it, and what is the centralization risk?

4. Score Dispute / Appeal
If a user believes their score is incorrectly calculated, is there a governance or appeal mechanism..? Or is the score final and unchallengeable…?

These questions go to the core of whether this oracle is safe to integrate. An audit scheduled for August is valuable but the community should understand the scoring mechanism before the audit, not after.

Not opposing the proposal. Asking for the transparency this forum and Aave’s risk standards require.

18

These are exactly the questions a community should be asking before — not after — an integration vote, and you’re right that the audit doesn’t substitute for understanding the mechanism. The Methodology Note at zentrascore.com/governance was published explicitly to answer them; we’ll restate the relevant pieces here in this thread and add a more concrete dispute / appeal mechanism, which is the section the existing note is thinnest on.

One small but important framing correction first, since it’s load-bearing for question 1: Phase 1 does not enable undercollateralized loans on Aave. A manipulated high score in Phase 1 buys exactly one thing — a rate discount, capped at 1.5% APR (maxDiscount = 150 bps), on a loan where the borrower is still required to post full collateral. Undercollateralized lending is Phase 3, blocked at the contract level by scopeLock = true and unreachable without a separate Aave AIP. That changes the answer to question 1 substantially, but the question is still worth answering on its own terms.

1. Score Manipulation / Oracle Attack

Methodology reference: Sections 5 (Anti-Fraud Layer) and 6 (Governance Controls).

There are five layers between an attacker’s wallet and a malicious score actually being read by the Aave adapter. An attack has to defeat all five:

# Layer What it does
1 Economic asymmetry Manufacturing a 740+ score requires months of genuine repayment activity across multiple protocols with real capital at risk. The cost of capital tied up during the manufacturing window exceeds the maximum 1.5% APR discount by orders of magnitude. The attack is unprofitable before it reaches the oracle.
2 Anti-fraud layer (pre-publication) Four checks run on every score before it leaves the indexing pipeline: Sybil clustering, wash-repayment detection, circular fund flow detection, behavioral anomaly scoring (Section 5.1–5.4). A score that fails any of these is either capped at the Fair band (580) or marked flagged = true, which the adapter treats as 0 bps discount.
3 2-of-3 oracle consensus All three oracle nodes recompute scores independently from shared indexed event data. A single compromised node cannot publish anything. To write a malicious score, an attacker would need to compromise at least 2 of 3 geographically and organizationally distinct node operators.
4 On-chain sanity checks ZentraScoreAaveAdapter rejects any score outside [300, 850] and any single-update score change greater than 80 points. Both are hard-coded, not parameters. The adapter’s getDiscount() function never reverts — every failure mode returns 0 bps, so a misbehaving oracle cannot brick Aave’s borrow flow.
5 Governance kill switch Aave governance can flip oracleActive = false via a standard governance transaction and instantly revert all borrowers to standard rates, no emergency spell. They can also pin to a specific model version via frozenVersion if they suspect the published version has been tampered with.

The combined effect: a successful attack requires (a) defeating the economic incentive, (b) bypassing four independent statistical checks, (c) compromising at least 2 of 3 oracle nodes, (d) producing a score that survives the on-chain sanity / delta check, (e) before Aave governance notices and flips the kill switch — and the reward is ≤1.5% APR on a fully collateralized stablecoin loan.

2. Sybil Resistance

Methodology reference: Section 5.1.

The key design choice here is that Sybil resistance is cluster-level, not wallet-level. Building 100 fake wallets and giving each of them fake history doesn’t get you 100 high scores — it gets the entire cluster capped at 580 (Fair band, 0 bps discount).

The detection signals (full description in Section 5.1):

  • Shared funding source — wallets funded from the same EOA or contract within a 30-day window

  • Synchronized behavioral timing — wallets executing borrow/repay cycles within the same block or narrow time windows across multiple protocols

  • Circular capital routing — A → B → C → A patterns consistent with coordinated score inflation

  • Identical interaction sequences — wallets that interact with the same set of protocols in the same order within a short window

When a cluster is identified:

  • Every cluster member’s score is capped at 580 regardless of raw computed score

  • Every cluster member is published with flagged = true

  • The cluster ID and flagging rationale are emitted as a public on-chain event for auditability

Estimated false positive rate is under 0.5% of scored wallets, validated against internal labeled datasets. The full validation data — and the synthetic adversarial test sets we’ve constructed (clustered Sybils, circular wash-repay, wallet hopping after default) — are in the package going to whichever Risk Service Provider engages on the back-test, exactly so this number can be independently verified before the ARFC vote.

A user can absolutely create 100 wallets. They cannot create 100 unrelated histories of genuine repayment activity across multiple protocols without leaving the funding-graph footprint that the Sybil layer is designed to detect.

3. Data Sources

Methodology reference: Section 3.

ZentraScore’s score is 100% on-chain data. There are no off-chain inputs:

  • No KYC

  • No off-chain identity providers (no Civic, no Polygon ID, no Worldcoin)

  • No price feeds, social graphs, or web2 signals

  • No centralized data providers

  • No human curation of individual scores

The complete input set is documented in Section 3.3 of the methodology note: smart-contract events emitted by 18+ DeFi protocols on Ethereum, Arbitrum, Base, Avalanche, and Unichain. Anyone can pull the same data from a node and re-derive the score.

The legitimate centralization concern is not the data — it’s the oracle network that publishes the computed score on-chain. We address that with three specific commitments:

  1. 2-of-3 consensus across geographically and organizationally distinct nodes (Section 4.4) — so no single party can publish a score

  2. Open-sourcing the event indexing pipeline, sub-score normalization functions, and anti-fraud algorithms before the ARFC vote (Section 9.2). The factor weights are the only piece that remains proprietary in the open-source repo, and we’ve committed to disclosing them either to the Risk Service Provider under a data agreement or publicly under a governance-ratified confidentiality framework if the community prefers.

  3. Independent verifiability (Section 9). Any party can call getScore(address) on any of the five deployed CreditScoreOracle contracts and get the same answer Aave’s adapter gets. There is no privileged read path.

The strongest version of the centralization concern is “what if ZentraScore goes away?” In that scenario, the existing TTL-valid scores remain readable on-chain for up to 7 days, after which valid returns false and the Aave adapter falls back to standard rates automatically. There is no scenario where a ZentraScore failure produces bad discounts — it produces no discounts.

4. Score Dispute / Appeal Mechanism

You’re right that the existing Section 9.4 — “discrepancy reports reviewed within 72 hours” — is thinner than it should be for a risk dependency. We’re committing to a more concrete three-tier process, encoded as part of the ARFC technical annex and live in the methodology note within 7 days:

Tier 1 — Technical discrepancy review Any wallet owner or third party can file a discrepancy via support@zentrascore.com or by emitting a DiscrepancyReport(address wallet, bytes32 reason) event from the wallet itself. ZentraScore reviews within 72 hours and publishes the outcome to a public registry at Sign in | ZentraScore . Outcomes are one of:

  • Score recomputed (reason published, new score deployed)

  • Score confirmed correct (input data + factor breakdown published)

  • Anti-fraud flag confirmed or removed (rationale published)

Tier 2 — Public escalation If the wallet owner disputes the Tier 1 outcome, they may post in a dedicated ZentraScore Discrepancy Reviews thread on governance.aave.com. The Risk Service Provider may review and publish their own opinion. ZentraScore commits to responding to every Tier 2 escalation within 7 days with a public explanation referencing the specific on-chain events used to compute the score.

Tier 3 — Governance override Aave governance has two contract-level overrides that no Tier 1 or Tier 2 process can block:

  • setOracleActive(false) — disables all discounts immediately, no exceptions

  • setFrozenVersion(v) — pins the integration to a specific model version, blocks adoption of any newer version until governance explicitly approves it

Plus a baseline transparency commitment we’re adding here:

  • Quarterly Discrepancy Transparency Report posted to governance.aave.com — total reports filed, resolution outcomes, false positive rate on Sybil flags, false positive rate on anti-fraud flags, and a summary of any model adjustments made in response. First report would be filed at the 90-day mark post-deployment.

The score is not “final and unchallengeable.” It is challengeable through Tier 1 and Tier 2, and Aave governance can independently neutralize it through Tier 3 without needing our cooperation.

Where each answer lives in the published methodology

For anyone reviewing this independently:

Question Methodology Section
Score manipulation / oracle attack §5 (Anti-Fraud Layer) + §6 (Governance Controls) + §4.4 (Oracle Network)
Sybil resistance §5.1 (Sybil Wallet Clustering Detection)
Data sources §3 (Data Sources and Coverage) + §9.2 (Open-Source Indexing Logic)
Score dispute / appeal §9.4 (existing, expanded above and to be published within 7 days)

Both the Methodology Note and the Aave integration page (zentrascore.com/integrations/aave) will be updated to include the expanded dispute mechanism and this Q&A within 7 days, so the answers are available somewhere durable rather than only in this thread.

You’re correct that these answers should land before the audit, not after — the audit verifies that the contracts implement what the methodology says, not whether the methodology is itself sound. The methodology stands or falls on questions exactly like the four you’ve asked.

-– ZentraScore Team

1 Like
19

Thank you for addressing all four questions clearly. The commitment to updating the Methodology Note within 7 days is appreciated.

Two things I would still like to understand before a Snapshot vote:

One is around future model version governance. The setFrozenVersion(v) control is noted, but what is the process before a new model version goes live? Does it require an ARFC or AIP, or can it be updated through an internal process only? This is important because long term risk depends on whatever version runs in Phase 3, not just Phase 1.

Second is around oracle operator rotation. You mention 2 of 3 geographically distinct operators, but if one operator shuts down or is compromised, who approves the replacement and through what process? Is that Aave governance, ZentraScore internally, or a joint decision?

These two points are the remaining gaps between a well designed system and one that governance can actually monitor and enforce over time.

20

Both points are fair, and they go directly to the same underlying question: where does ZentraScore’s discretion end and Aave governance’s authority begin. Below is the process we will codify in the v1.1 Methodology Note within the same 7 day window already committed.

1. Model version governance — what happens before a new version goes live

To be explicit, we are drawing a distinction between (a) ZentraScore publishing a new model version on our oracle, and (b) that version being honored by the Aave integration. The first is an internal release. The second requires Aave governance action under the following process, which we will encode in the Methodology Note and reflect in the adapter behavior:

  • Major version (e.g. 1.x to 2.x) — change of model class, addition or removal of a scoring factor, or weight rebalance exceeding 10 percentage points on any single factor. Requires a full ARFC followed by an on-chain AIP vote before the Aave adapter recognizes the new version. Until the AIP passes, frozenVersion remains pinned to the prior version and the adapter returns a 0 bps discount for any wallet whose score is published under the new version. This is opt-in, not opt-out.

  • Minor version (e.g. 1.0 to 1.1) — new indexed protocol, new chain coverage, or threshold adjustments inside the existing model. Requires a 14 day ARFC-style forum notice with a structured diff. During the notice window any delegate may request that governance pin frozenVersion; absent objection and a freeze vote, the new version becomes effective at day 15. We commit to not advancing a minor version while a freeze proposal is pending.

  • Patch version (e.g. 1.0.0 to 1.0.1) — bug fixes, data corrections, or anti-fraud parameter tuning that does not change the scoring formula. 7 day forum notice, no vote required, but governance retains setFrozenVersion as a unilateral override at any time.

Put plainly: in Phase 3, no model change that meaningfully affects risk can reach the Aave adapter without governance approval. The setFrozenVersion(v) control is the enforcement mechanism, but the policy on when it must be exercised is what we are committing to here.

2. Oracle operator rotation

This is a gap in v1.0 and we appreciate it being raised before Snapshot rather than after. Our proposed process, to be added as Section 4.5 in v1.1:

  • Operator set is a governance-visible parameter. The identities of the three oracle operators will be published in the ARFC technical annex and mirrored on zentrascore.com/contracts. Any change to the set is a governance event, not a vendor decision.

  • Planned rotation (operator winds down, contract ends, etc.) — minimum 14 day forum notice with the proposed replacement operator, their infrastructure profile, and geographic / organizational independence rationale. Replacement is subject to a Snapshot signal vote. Aave governance can veto by Snapshot or by toggling oracleActive to false.

  • Emergency rotation (operator compromised, suddenly offline, key exposure) — ZentraScore may execute a temporary swap to a pre-disclosed standby operator to maintain 2-of-3 liveness, but the swap is time-boxed to 30 days and must be ratified by an Aave Snapshot vote within that window. If no ratification occurs, the standby operator is removed and the adapter falls back via TTL expiry to standard rates.

  • Multi-operator failure — if two operators are lost simultaneously, no replacement may occur without an explicit Aave governance vote, even temporarily. The integration falls back via TTL and valid = false.

The summary answer to your question is: operator rotation is a joint decision with Aave governance holding final authority. ZentraScore can propose, and in narrow emergency cases execute temporary action, but no operator change persists past 30 days without a governance vote, and governance retains an unconditional veto via oracleActive.

Both of these will appear as new explicit sections in the v1.1 Methodology Note within 7 days, alongside the previously committed updates. We would rather close these gaps in the document than ask the community to take them on trust from a forum post.

1 Like