How does DCC Framework-1.0 evaluate CeFi versus DeFi stablecoin yield?
M1C splits into two sub-modules with distinct deterministic criteria. M1C-CeFi evaluates centralised platforms on reserve quality, regulatory accounting, yield commitment, liquidity, and jurisdiction. M1C-DeFi evaluates on-chain protocols on protocol security (0.40 weight, composite of audit depth and battle test), governance risk, yield transparency, liquidity, and peg stability. Both sub-modules feed into the same 0-to-100 risk score and risk-band output. The criteria differ because the input data each surface produces is structurally different — on-chain telemetry for DeFi, disclosed reserves and counterparty data for CeFi. Outputs are scenario analytics for independent analysis.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
How is stablecoin depeg trajectory factored into DCC Framework-1.0?
Peg stability is a model-derived criterion in M1C built from 90-day daily peg readings. The depeg trajectory state machine tracks magnitude (cumulative basis-point deviation) and persistence (consecutive readings outside tolerance). A depeg exceeding 1.5% on any reading triggers a forced HIGH RISK band classification, regardless of other criterion scores. A depeg exceeding 2% places the peg-stability criterion at its floor bucket value. The state machine is deterministic — same time-series produces the same output — and is published in the framework. The result is a scenario output for independent analysis.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
How does DCC Framework-1.0 evaluate Aave and Compound?
Aave's and Compound's M1C-DeFi risk scores are computed across protocol security (0.40 weight — composite of audit depth and battle-test history), governance risk (admin-key control and formal-action posture), yield transparency, liquidity (TVL adjusted by the TVL quality discount), and peg stability of the underlying assets. Each criterion maps to deterministic input buckets disclosed in the methodology. DCC Framework-1.0 applies the same criteria, weights, and bucket definitions to both protocols, producing independent scores for each. Outputs are scenario analytics for independent analysis. Current scores are published on the DCC yield board.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
What is audit depth, and how does DCC Framework-1.0 weight it for DeFi protocols?
Audit depth is a deterministic sub-criterion inside protocol security (the 0.40-weight criterion in M1C-DeFi). It captures the cumulative quality of independent smart-contract audits a protocol has undergone. Input buckets are published tiers — for example, tier1_multi_audits (multiple independent firms, current scope), through to no_audits or self-audit-only. Audit depth combines with battle-test history into a protocol_security composite. The composite value is then multiplied by 0.40 and entered into the overall M1C risk score. Audit depth is not a determinative indicator on its own; it is one deterministic input bucket within the published framework.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
What is the TVL quality discount, and how are the four tiers applied?
TVL quality discount is a deterministic adjustment applied to the headline total-value-locked figure before it enters the M1C liquidity criterion. The four tiers, published in DCC Framework-1.0, are: organic_sticky (0% discount — full TVL credited), moderate_incentivised (10% discount), heavily_incentivised (30% discount), and mercenary_dominated (50% discount). Tier assignment uses disclosed incentive-program data and historical TVL stickiness metrics. The discounted TVL feeds the liquidity bucket; raw TVL is never used. The model output is a scenario analytic for independent analysis and is published per-protocol on the DCC yield board.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
Why does immutability matter under DCC Framework-1.0 for DeFi protocol scoring?
Immutability is a deterministic sub-criterion inside governance risk in M1C-DeFi. It captures whether a protocol can be upgraded by an admin key, a multi-sig, a time-locked governance process, or is fully immutable. Published input buckets range from timelock_72h_plus (long timelock plus broad signer set) down to admin_key_controlled (single-key upgrade authority). Immutability combines with formal-action posture into the governance risk criterion score. A protocol that scores well on protocol security but holds an unrestricted admin key carries a distinct structural risk indicator — this is a published deterministic output, not an advisory determination.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
What is the ALGO cap, and why does DCC Framework-1.0 disclose it unprompted?
The ALGO cap is a hard-cap rule in DCC Framework-1.0: any stablecoin classified as algorithmic (peg maintained by an on-chain mechanism rather than off-chain reserves) has its final M1C risk score capped at 20 — placing it inside the HIGH RISK band regardless of other criterion scores. The cap exists because algorithmic peg mechanisms carry a structural risk indicator that the standard M1C criterion weights do not fully reflect. The framework discloses the cap unprompted for any protocol it applies to so that consumers of the score can see the override explicitly. The output is a scenario analytic for independent analysis.
DCC · DCC Framework-1.0 · digitalcreditcompass.com · Risk analytics outputs for independent analysis. Not investment advice.
