ClariQ Risk Methodology

A Deterministic, Fact-Gated Framework for DeFi Vault Risk Assessment

Document: Public Methodology Whitepaper Version: 1.0 (Draft) Date: 2026-07-09 Audience: Integration engineering teams and compliance officers evaluating ClariQ as an embedded risk layer

1. Purpose and Scope

This document describes how ClariQ produces risk scores for DeFi yield vaults and protocols: what the scores mean, what inputs they are computed from, how those inputs are verified before they are allowed to influence a score, and — just as importantly — what the system refuses to do when it does not have enough verified information.

It is written for two readers. The first is an engineering lead deciding whether ClariQ's scores are sound enough to embed in a product surface. The second is a compliance or risk officer who must be able to defend, internally and to regulators, a decision to rely on a third-party risk signal. For both readers, the central claims of this document are the same:

1. Scoring is deterministic. A ClariQ score is the output of a pure, versioned rules function applied to a structured set of verified facts. The same facts and the same engine version always produce the same score. There is no statistical model, no human judgment call, and no language model anywhere in the scoring path.
2. Facts are gated before they can affect scores. AI assistance is used to find and draft candidate facts from primary sources, but no AI-derived fact can influence a production score until a human reviewer has accepted it through an auditable review process.
3. Missing information is never papered over. When the system lacks the verified facts required to score a position, it reports a Pending state rather than an estimated score. When a specific safety check cannot be evaluated because its underlying facts are not yet collected, that check reports "not applicable / not evaluated" — never a false "passed."

This document describes the system as built and running today. Capabilities that are designed but not yet live are explicitly labeled as roadmap items in Section 9, and are excluded from all other sections.

2. Design Principles

2.1 Determinism over judgment

Most risk assessments in DeFi are either manual analyst write-ups or opaque model outputs. Both are difficult for a relying party to audit: the first cannot be reproduced, and the second cannot be explained. ClariQ takes a third path: the scoring engine is a pure function. It reads no network, no database, no environment, and no system clock. Every input it consumes is present in a versioned facts document; every output can be regenerated bit-for-bit from that document and the engine version recorded alongside the score.

Practical consequences for a relying party:

• Reproducibility. Given the facts snapshot and engine version attached to any score, the score can be recomputed and verified independently.
• Explainability. Every score decomposes into eight named factor scores plus an explicit list of triggered, cleared, and not-evaluated safety conditions. There is no residual "model said so."
• Change control. Scores can only change for two reasons: the underlying facts changed, or the engine version changed. Both are recorded. Engine logic changes are versioned releases, not silent drift.

2.2 Facts before scores

The engine is deliberately the simple part of the system. The hard part — and the part where errors would be dangerous — is establishing that the inputs are true. ClariQ therefore separates the system into a facts pipeline (which gathers and verifies inputs) and a scoring engine (which mechanically converts verified inputs into scores). The boundary between them is a schema: the engine will only score a facts document that satisfies its required-field contract, and the pipeline will only emit facts that have passed its verification gates.

2.3 Honesty about ignorance

A risk score that silently substitutes assumptions for missing data is worse than no score, because it manufactures false confidence precisely where risk is least understood. ClariQ's engine enforces a completeness contract: if the required facts for a target are not all present and verified, the engine returns no numeric score at all. The product surfaces this as Pending (or, while collection is actively in progress, Processing). This is a deliberate product decision: users and integrators will sometimes see "Pending" where a competitor would show a number. We consider that a feature.

2.4 Independence

ClariQ is never paid by the protocols or vaults it rates. There is no "pay to be rated," no "pay to improve a rating," and no sponsorship relationship with any rated entity. Ratings are impersonal: the same score for a given vault is shown to every user, and scores are statements about the instrument, not personalized investment advice. This posture is structural, not aspirational — the issuer-pays model is, in our assessment, a disqualifying conflict of interest for a risk rating business, and we have declined to build revenue mechanisms that depend on it.

3. What a Score Means

3.1 Scale semantics

ClariQ scores are expressed on a risk-native scale from 1.0 to 5.0, where lower is safer:

• 1.0 represents the safest achievable profile — a battle-tested, conservatively governed instrument with strong verified evidence across all factors.
• 5.0 represents the riskiest profile the framework expresses.
• Scores are reported to two decimal places and are bounded to this range by construction.

The overall score is a fixed weighted combination of the eight factor scores described in Section 4, subject to the kill-switch floor described in Section 5. Each factor is itself scored on the same 1-to-5, lower-is-safer scale, so the decomposition is directly interpretable: a vault with an overall score driven by a poor Technical Security factor tells a different story from one driven by Systemic Exposure, and the breakdown makes that visible.

3.2 What a score is not

• It is not a prediction of returns, and it is not investment advice.
• It is not a probability of loss. It is an ordinal, evidence-based assessment of risk posture relative to the framework's criteria.
• It is not a guarantee. A low-risk score means the verified evidence available to us shows a strong risk posture; it does not mean loss is impossible.
• It is not personalized. Every user of every surface sees the same score for the same instrument.

3.3 Scoring scope and fallback

Scores are computed at the most specific level for which complete verified facts exist. When vault-level facts are complete, the vault is scored on its own facts. When vault-level facts are incomplete but the underlying protocol's facts are complete, the engine may score at protocol scope — and when it does, the result is explicitly labeled as a protocol-scope score, with the missing vault-level fields enumerated in the result. When neither is complete, the result is Pending. The scope of every score is recorded in its output; a protocol-fallback score is never presented as a vault-specific one.

4. The Eight Risk Factors

Every scored instrument is assessed across eight named factors. Each factor has a defined scope — a "primary home" rule ensures each underlying signal is scored in exactly one factor, so no single weakness is double-counted across the framework. The factors and their weights are fixed and versioned; the numeric weights themselves, and the precise scoring bands within each factor, are part of ClariQ's proprietary quantitative specification (see Section 8).

1. Technical Security. The security posture of the smart contracts themselves: source-code verification, the count and quality tier of independent security audits, upgradeability architecture (immutable vs. proxy-upgradable), timelock protections on privileged operations, administrative key control structure, and the instrument's exploit history. Contracts that are unverified, unaudited, or controlled by a single externally-owned key are treated as severe findings in this factor (and can independently trigger kill-switch conditions — see Section 5).

2. Financial Health. The economic soundness of the instrument: total value locked as a depth-and-scrutiny signal, utilization, and the composition of the advertised yield. Yield composition is decomposed into real yield (fees and interest actually generated), token-emission incentives, and speculative components, using sourced per-pool data where the upstream providers publish it. Where a sourced decomposition is unavailable, the engine does not fabricate a split — it does not manufacture an emissions-versus-real breakdown, and the emissions composition for that instrument should be treated as unverified rather than as a finding. Where a sourced decomposition is present, yield structures dominated by emissions or speculative components score worse than equivalent structures generating real yield.

3. Operational Maturity. The human and governance layer: whether the team is publicly identified (doxxed), the governance structure (DAO or otherwise), and the discipline of administrative controls. Anonymous teams with weak audit coverage represent a materially different operational risk than identified teams under decentralized governance, and the factor scores accordingly.

4. Systemic Exposure. Dependency and contagion risk: what the instrument is built on top of, and what fails if those layers fail. This factor evaluates dependency depth, with explicit handling for layered restaking structures — each additional layer of receipt tokens (LST/LRT stacking) raises the factor's floor, reflecting compounding slashing and depeg exposure. Custodial and wrapped-asset control risk is also assessed here as its primary home.

5. Complexity. Strategy complexity as an independent risk dimension: the number of protocols composed in the strategy, use of leverage and liquidation-bearing positions, and the degree of active management required. Simple single-protocol lending positions and multi-protocol leveraged loops are distinguished even when both look healthy on every other factor, because complexity expands the surface for both technical failure and operator error.

6. Frontend / Interface. The risk that users are harmed through the interface layer rather than the contracts: hosting and DNS posture, and — critically — a permanent scar rule for instruments whose frontends have been successfully attacked. A frontend compromise with user losses imposes a lasting floor on this factor's score; the floor deepens with the magnitude of losses and with repeated incidents. Interfaces do not get a clean slate by relaunching.

7. Legal / Regulatory. Regulatory exposure of the instrument and its operators: recognized licensing or registration where applicable, sanctions exposure, and regulatory-action history. A strong legal posture can improve this factor, but the framework enforces a structural limit: no protocol can achieve the framework's best-possible legal score purely on formal credentials — a recognition that DeFi legal risk is never fully extinguished by a license.

8. Chain / L2. The risk contributed by the settlement layer itself. Ethereum mainnet is treated as the reference safest environment. Instruments on L2s and alternative chains are assessed on the maturity of the rollup (including its independently published decentralization stage), sequencer architecture, and bridge control structure. Chain-level risk also carries its own dedicated set of kill-switch conditions (Section 5).

Factor scores combine into the overall score through fixed, versioned weights. The weighting was validated empirically during framework development — including testing and rejecting proposed re-weightings that produced no fitness improvement — and does not change without a versioned framework release.

5. Kill Switches: Conditions That Floor the Score

Weighted averages have a known failure mode: a catastrophic single weakness can be diluted by strength elsewhere. History is explicit on this point — instruments have collapsed totally while carrying top-tier audits, identified founders, and polished interfaces, because one fatal economic or structural flaw outweighed everything else.

ClariQ addresses this with kill switches: a set of 13 named conditions (eight general conditions, plus five chain/L2-specific conditions) that are evaluated on every scoring run, independently of the factor mathematics. If any kill switch is triggered, the overall score is floored deep in the high-risk band, regardless of how well the instrument performs on the eight factors. A vault with five tier-1 audits and a billion dollars of TVL that is controlled by a single externally-owned key does not get partial credit; it gets floored.

The general conditions cover, qualitatively: single-key administrative control; unverified contract source; absence of any credible security audit; reliance on proprietary or unverifiable oracle infrastructure; sustained depeg behavior in algorithmic-stable structures; recent unremediated exploit history (with a recency window — a fully reimbursed exploit ages out of kill-switch status over time, while an unreimbursed one does not); upgradable contracts holding substantial value without adequate timelock protection; and fatally weak financial structure as measured by the Financial Health factor itself, evaluated after factor scoring. The chain-level conditions cover early-stage rollup decentralization, centrally controlled bridges, censorship posture, closed-source chain infrastructure, and insufficient chain operating history.

The precise numeric thresholds for each condition are part of the proprietary quantitative specification (Section 8).

Three properties of the kill-switch layer matter for a relying party:

• Every condition reports an explicit status on every score: Triggered, Clear, or Not Applicable. "Not Applicable" means the facts required to evaluate that condition are not yet collected for that instrument — the system reports that it did not check, rather than falsely reporting a pass. This is a deliberate honesty guarantee: a safety check that silently always-passes is the most dangerous class of false negative a risk system can produce, and ClariQ's engine is built to make that state visible instead of hiding it.
• Kill switches are evaluated deterministically from the same verified facts as the factors, using the facts' recorded collection timestamp (never the wall clock) for any time-based condition — so kill-switch outcomes are exactly as reproducible as the scores themselves.
• The triggered set is part of the output. An integrator receives not just a floored score but the named condition(s) that floored it, suitable for display or for downstream policy logic.

6. The Facts Pipeline

6.1 Sources

Scores are computed from a structured facts document assembled per instrument. Facts are drawn from:

• On-chain and contract-level data: contract verification status, upgradeability and proxy architecture, timelock configuration, administrative control structure, via block explorers and source-verification services.
• Protocol and market data: TVL, utilization, APY and its base/reward decomposition, from established public aggregators and protocol-native APIs.
• Audit and security registries: curated records of security audits (with quality tiering), bug bounties, and incident history.
• Governance and team information: governance structure, team identification status.
• Chain-level data: rollup stage assessments, bridge and sequencer architecture, for non-mainnet deployments.
• An identity registry: canonical instrument identity across chains and protocols, so that facts collected under one representation of a vault are correctly attached to the same instrument everywhere it appears.

6.2 AI-assisted fact-finding, human-gated fact promotion

Assembling qualitative facts — audit inventories, incident histories, governance details — across hundreds of instruments is research work, and ClariQ uses AI assistance to do it at scale: automated assessment runs read primary sources and produce candidate facts with citations.

The critical control is what happens next. Candidate facts do not affect scores. They enter a review feed, where each proposed fact is examined by a human reviewer against its cited evidence. Only on explicit acceptance is a fact promoted into the curated fact registry that feeds the scoring engine. Every promotion records what was promoted, from which review item, by whom, and when — producing a per-fact audit trail from source citation through human acceptance to score impact.

The scoring engine itself never invokes an AI model. The division of labor is strict: AI drafts and cites; humans verify and promote; deterministic rules score. A relying party's exposure to AI error is therefore bounded by the human review gate, not by model behavior.

6.3 The no-fabrication policy

The pipeline enforces, as code rather than convention, a policy that production scoring paths never fabricate data:

• Facts documents that fail the engine's required-field contract are not scored; the instrument shows Pending.
• Placeholder or schema-default values are tagged with their provenance, and the completeness gate rejects them as if absent.
• Where an upstream source cannot provide a decomposition (for example, the real-versus-emissions yield split), the engine does not fabricate one; the missing breakdown is treated as unverified rather than filled with an invented assumption.
• Kill-switch conditions without backing facts report Not Applicable, as described in Section 5.

6.4 Freshness and re-scoring

Facts documents carry their collection timestamp, and scores are recomputed from current facts rather than cached indefinitely; time-sensitive logic (such as exploit-recency windows) is anchored to the facts' collection time so that a score remains reproducible from its snapshot. Stale or incomplete data results in Pending/Processing states rather than silently aging scores.

7. Governance of the Methodology

The methodology itself is under formal change control:

• The engine is versioned. Every score records the engine version that produced it. Scoring logic changes ship as new engine versions, with the previous behavior reproducible from the prior version.
• Changes go through a written proposal process. Modifications to factors, weights, or kill-switch logic are proposed, evaluated (including empirical validation where applicable), and explicitly accepted or rejected before implementation; the registry of proposals and their dispositions is maintained internally.
• The engine is regression-tested against golden fixtures. A suite of reference instruments — from a deliberately pristine profile through deliberately fatal ones — is scored on every change, with a required monotonicity property: better evidence must never produce a worse score, and known-fatal profiles must trigger their kill switches. The full automated risk test suite must pass before any engine version is released.
• Internal parity auditing. ClariQ conducts internal audits comparing the live engine against the canonical methodology documentation, and treats divergence as defects to be fixed or roadmap items to be labeled — this whitepaper reflects the audited, as-built state.

8. Proprietary Specification and Enterprise Access

The qualitative framework — the eight factors, their scopes, the kill-switch conditions, the honesty guarantees, and the pipeline controls — is public and is described in this document. The quantitative specification — the numeric factor weights, per-factor scoring bands, and kill-switch trigger thresholds — is proprietary. Weights and thresholds exist, are fixed, and are versioned; they are not disclosed publicly.

Enterprise integration partners with a compliance need to review the full quantitative specification — including exact weights, thresholds, scoring band definitions, and the change history of each — may obtain it under NDA as part of an enterprise engagement. This tiering exists so that relying parties who must defend the methodology internally can inspect it completely, while limiting the surface for score-gaming by rated entities.

9. Roadmap (Designed, Not Yet Live)

In keeping with this document's as-built discipline, the following are explicitly not part of the current production system, and no section above should be read as claiming them:

• Expanded qualitative fact collection. The engine already consumes optional fact groups covering protocol maturity, dependency structure, strategy classification, frontend posture, and legal/regulatory status; production collection adapters for these groups are being brought online incrementally. Until an instrument's optional groups are populated, the affected factors score at their neutral baseline — never at a fabricated value — which compresses differentiation on those factors for that instrument.
• Oracle-architecture facts. The proprietary-oracle-reliance kill-switch condition currently reports Not Applicable for most instruments, pending a dedicated oracle-architecture fact source.
• Peg-history facts. The algorithmic-stable depeg kill-switch condition is presently evaluated by an interim heuristic derived from an instrument's yield structure, not by direct peg-history facts; for instruments outside that heuristic's narrow trigger it reports Clear rather than Not Applicable. Dedicated peg-history fact sourcing is planned to replace this heuristic so the condition reports Not Applicable when it genuinely cannot be evaluated, consistent with the honesty guarantee in Section 5.
• Graduated exploit rehabilitation. The exploit kill switch currently applies its recency window; a finer-grained rehabilitation schedule (post-mortem quality, re-audit, bounty posture) is designed but requires fact types not yet collected.
• Asset-type-specialized scoring for tokens, wrapped assets, and staked assets beyond the current vault/protocol treatment.
• Public API access. ClariQ does not currently offer a public scoring API; integration access is by direct engagement.

Roadmap items ship as versioned engine and pipeline releases and will be reflected in future revisions of this document.

10. Summary for the Relying Party

A ClariQ score is: a number on a fixed 1-to-5, lower-is-safer scale; computed by a pure, versioned, regression-tested rules engine; from facts that were either mechanically collected from primary sources or human-approved through an audited review gate; decomposable into eight named factors under a no-double-counting rule; subject to 13 named kill-switch conditions that floor the score on any single fatal finding and that report honestly when they could not be evaluated; and withheld entirely — shown as Pending — whenever the verified evidence is insufficient to compute it.

ClariQ is not paid by the entities it rates, shows the same impersonal score to everyone, and treats "we don't know yet" as an acceptable answer and "we made it up" as a prohibited one.

Questions about this methodology, requests for the full quantitative specification under NDA, or integration inquiries should be directed to ClariQ.

Version 1.0 (Draft) — 2026-07-09. This document describes the production system as of its date. Material methodology changes will be published as revised versions of this document.