Methodology

How the score actually works.

Not a whitepaper pitch — the real weights, the real aggregation logic, and the real edge cases this model has already been tested against. If you can't follow the math from public ledger data to the number on screen, it isn't transparent, no matter what it claims.

1. Two scores, not one

A human wallet and an autonomous AI agent fail in different ways, so they get different models instead of one score forced to fit both.

  • Wallet Score — for human-controlled or institutional wallets. 300–850 scale, deliberately matched to the FICO range so lenders and users share an intuitive reference point.
  • Agent Reliability Index (ARI) — for autonomous AI agents. 0–1000 scale, chosen to be visually distinct so nobody mistakes an agent's rating for a human credit score, which it isn't measuring at all.

Both are computed and published the same way (sections 3–4 below); only the input features and weights differ.

2. Two layers, and why the split matters

Layer 1 — deterministic, on-chain-computable

Anything calculable directly from ledger data with fixed arithmetic, no model required: repayment rates, account age, utilization ratios, completion percentages. Fully reproducible by anyone — a lender, an auditor, the wallet owner — which is what makes disputes fast instead of a 30-day black box. Most of the score's weight lives here, on purpose.

Layer 2 — pattern detection, ML-assisted

A smaller set of signals that genuinely need a model: detecting sybil wallet clusters, coordinated collusion rings, behavior that looks like gaming Layer 1. Runs off-chain on staked node infrastructure with outputs attested on-chain — but never the majority of the final score. A number that depends mostly on an opaque model is the black box this exists to replace.

3. Wallet Score — features and weights

FactorWeightWhat it measures
Repayment history35%On-time repayment rate across vault loans, recency- and severity-weighted — a default 3 months ago hurts more than one 3 years ago.
Utilization / leverage20%Current borrowed amount vs. collateral posted, and leverage exposure through AMM LP positions.
Account longevity & consistency15%Wallet age, and whether activity is steady vs. a long-dormant wallet suddenly active — a classic sybil/rental pattern.
Depth of on-chain activity10%Breadth of protocol interaction, escrow and payment-channel completion history.
Credential status10%Whether the wallet has attached a Permissioned Domain / KYC Credential — verified identity reduces the model's uncertainty.
Inquiry velocity10%
(negative)
New loan applications in a short window — the on-chain equivalent of "too many recent inquiries."

This mirrors a traditional credit score's shape deliberately — lenders and borrowers already have intuitions about what "35% weight on payment history" means.

4. Agent Reliability Index — features and weights

FactorWeightWhat it measures
Obligation completion rate40%% of committed payments settled on time, across distinct counterparties.
Counterparty diversity15%Breadth of distinct counterparties — an agent that only "succeeds" against a handful of related wallets is a red flag.
Dispute / reversal rate15%% of transactions later disputed or reversed by a counterparty.
Operator credential10%Whether the agent's operator has attached a verifiable Credential — accountability behind the agent, not just its own track record.
Responsiveness / uptime10%Whether the agent settles within its committed window, not merely eventually.
Tenure10%How long this agent identity has operated with consistent behavior.

The weighting choice that matters most: counterparty diversity and dispute rate together carry 30%, specifically because "completed 10,000 payments" means nothing if all 10,000 were against wallets the same operator controls. This is the model's first line of defense against an agent gaming its own score.

5. How the score actually gets computed

No single node computes "the" score. A rotating quorum of staked node operators independently compute the score for a given wallet from the same on-chain data, then submit their result. The published score is a trimmed median of those submissions — deliberately unweighted by stake — with outlier submissions beyond a tolerance band dropped before the median is taken, so a single node (or a small colluding group) can't move the number by submitting an extreme value.

A correction, found while prototyping this: the original design specified a stake-weighted median. Building and testing it showed that's an active vulnerability — if the outlier-detection reference point is itself stake-weighted, a single well-capitalized node can pull that reference point toward its own submission, at which point every honest node looks like the outlier and gets excluded, inverting the entire protection. A plain one-node-one-vote median doesn't have this failure mode (closer to how established oracle networks like Chainlink actually aggregate price feeds). Stake still matters — it's the bond at risk under slashing — it just no longer determines how much a submission counts toward the answer.

6. Explainability: reason codes, not a black box

Every score ships with the top factors that moved it away from a neutral baseline, in plain language — the same function as the "adverse action" reason codes bureaus are legally required to provide in some jurisdictions, generated transparently instead of grudgingly. A factor is only ever labeled positive when it's genuinely near-max, and negative factors are ranked by actual weighted drag on the score — not a flat cutoff, which produced a real bug caught while building this (a wallet with a recent default could get that factor mislabeled "positive" just because the rest of its history pulled the average up).

7. Cold start: new wallets and new agents

A wallet or agent with no history isn't scored at either extreme. It gets a neutral, thin-file baseline — for the Wallet Score, roughly the 580–600 range: below "prime" but not "high risk," explicitly labeled THIN_FILE rather than presented as an ordinary low score. Two fast-tracks out: attaching a Permissioned Domain Credential, or completing a small, fully-collateralized "starter" loan — the on-chain equivalent of a secured credit card.

8. Sybil resistance

The model's most important failure mode to design against gets three independent defenses:

  1. Funding-source analysis. Funding that traces to a centralized exchange withdrawal is a materially different signal than funding that traces to another thin-file wallet — the classic sybil-ring pattern.
  2. Graph clustering (Layer 2). Node operators run clustering analysis across the wallet graph for coordinated behavior — shared funding sources, synchronized timing, circular payments — and a detected cluster caps every member's score.
  3. Economics. Manipulating a score only pays off if the improved loan terms are worth more than the capital and time needed to fake the history — cluster detection specifically targets the cheap version of that attack.

None of this makes sybil attacks impossible — no on-chain credit model anywhere has solved that completely. It's designed to make the cheap, obvious version expensive, and to keep the honest majority of the score (Layer 1, deterministic) auditable regardless.

9. Model governance and validation

Node operators run a governance-approved model version, published and versioned, with a defined adoption window for updates. Any proposed new version must clear a backtest against a held-out historical dataset — which wallets/agents actually defaulted — before going to a governance vote, maintained by independent auditors rather than the node operators grading their own homework.

Two commitments worth stating plainly: validation tracks predicted score against actual repayment outcomes over time, published periodically rather than asserted. Fairness — on-chain behavior mostly avoids the protected-class proxies that plague some traditional models, but "mostly avoids" isn't "guaranteed to," and a real deployment needs a genuine disparate-impact review before scoring humans in any jurisdiction with fair-lending law.

The exact feature weights above, the outlier tolerance band, the thin-file baseline range, and the backtest pass criteria are reasonable starting points that need real historical data and a proper economic/ML review before they're treated as final — this page shows the model is coherent and defensible in shape, not that these specific numbers are permanent. This is a concept design under active development, not a whitepaper, a security offering, investment advice, or a solicitation. Nothing here should be treated as final until reviewed against real data, an independent model audit, and legal counsel on fair-lending and consumer-reporting obligations.