Back to Blog

Time: the missing layer in your blockchain risk model

by Dmytro Zap
11m

Intro

Crypto risk reputation lags the truth in both directions. Projects often become structurally safer after a public incident than peers that never had one. Other projects collapse weeks after a clean assessment.

Last week, every protocol using LayerZero's 1-of-1 DVN configuration carried elevated dependency risk: a single verifier signing off on cross-chain messages was the single point of failure that drained $292 million from Kelp DAO on April 18, 2026. On May 9, LayerZero ended support for 1-of-1 DVN configurations entirely, with new defaults moving to 5-of-5 verifiers, or 3-of-3 at minimum. The risk profile of roughly half of LayerZero's ~2,600 production applications shifted in a single weekend. Most static risk dashboards have not registered the change.

Time-related parameters are the missing layer in most crypto risk models. Without them, scores measure where projects were, not where they are.

Why does crypto risk reputation lag reality?

Crypto risk reputation lags reality because static risk scores answer a binary question (is the project exposed to a given risk factor, yes or no) without weighing how recent or stale the underlying evidence is. Every input to a risk score (audits, incident history, governance posture, team competency, and dependency exposure) has its half-life. Some signals decay in weeks; others compound over years. A model that checks for the presence or absence of each input without weighting its age is correct on the day it was generated and becomes increasingly wrong each day thereafter.

This works in two directions and is dangerous in both.

Stale-down reputation:
A project that suffered a public incident two years ago carries the reputational weight of that incident long after the operational lessons have been absorbed. The risk model keeps citing the original event as if no time has passed, missing the post-incident remediation, the new disclosure practices, the structural changes, and the risk management tools built since.

Stale-up reputation: 
A project that completed a clean assessment eighteen months ago carries the reputational weight of an audit done before code changes, new integrations, and current attack patterns made parts of that audit irrelevant. Many established risk scores still treat on-chain security as the flagship determinant of the score bracket. Today, operational and dependency vectors drain funds in roughly three cases out of four. A model fixated on smart contract audits is fighting the last war.

Both errors come from the same modeling failure: treating every input as if it has the same half-life. The score that doesn't distinguish those stale ups and downs is basically frozen in time. It ignores that the fresh score becomes less accurate every day. It also penalizes post-incident projects for an exploit that happened 8 years ago, even if today the project is called different and holds 99% of the new risk management structure.

 

How did MakerDAO go from Black Thursday to risk-management reference?

MakerDAO became one of the most rigorously risk-managed protocols in crypto specifically because Black Thursday (March 12, 2020) forced operational changes that competitors never had to make. The protocol was widely written off in the weeks following the incident. The structural changes that followed compounded over the next several years into the most defensible stablecoin risk architecture in DeFi. On CORE3's platform, SKY (the rebranded MakerDAO) currently ranks #2 by the lowest Probability of Loss.

Black Thursday was a near-shutdown event. On March 12, 2020, ETH fell roughly 43% in 24 hours. Network congestion spiked Ethereum gas prices to 50 to 100 times normal levels. MakerDAO's keeper bots, designed to bid on liquidated collateral, could not get their transactions processed. The auction system broke. One actor purchased approximately $6M of ETH for 1 DAI through zero-bid auctions. The protocol ended the day with somewhere between $5.5M and $8.3M in undercollateralized debt, and DAI lost its peg upward (a stablecoin trading above $1 is also a peg failure).

The public risk verdict was severe. A $28M class-action lawsuit was filed in April 2020. Vault holders organized for compensation. Multiple commentators wrote that the model was structurally broken. A naive risk score on April 1, 2020 would have downgraded MakerDAO sharply, and would have stayed downgraded for the next three years if the model had never updated.

What happened next:

The community held emergency governance calls, considered emergency shutdown, and instead executed a structured recapitalization through MKR debt auctions: new MKR was minted, sold for DAI, and the DAI was used to retire the bad debt. Auction parameters were overhauled (lot size raised from 50 ETH to 500 ETH, bid durations extended substantially). USDC was added as collateral to provide a hard peg anchor. Over the following eighteen months, the team introduced the Peg Stability Module, multi-collateral DAI, real-world asset collateral, and a formal risk framework with dedicated, named risk teams. The protocol later rebranded to Sky.

DAI/USDS is now one of the largest stablecoins by market cap and has not lost its peg materially through multiple subsequent market crashes (Terra collapse, Celsius bankruptcy, FTX collapse, March 2023 banking stress, October 2025 flash crash). The risk infrastructure built in the post-Black-Thursday response is referenced as a standard in DeFi risk circles.

The static reputational hit from Black Thursday, which a calendar-based risk model would have carried for years, was already obsolete by mid-2021. The project that looked dead in March 2020 was structurally one of the safest stablecoin operations in crypto by 2022. Only a time-aware risk model captures this.

Why did Nomad Bridge get drained $190M six weeks after a clean audit?

Nomad Bridge was drained of approximately $190 million on August 1, 2022, six weeks after a routine smart contract upgrade introduced a bug that caused the bridge to accept fake messages as legitimate. The contract had been audited by Quantstamp in May to June 2022, but the audit covered the code that was running before the upgrade, not the code that was running after. The risk score immediately before the exploit would have looked clean: recent audit by a reputable firm, growing TVL, no public incidents. The audit had effectively expired the day the upgrade shipped, except no risk model had marked it expired.

Nomad was a cross-chain bridge: it let users move tokens between different blockchains. To prevent fraud, every cross-chain message carried a cryptographic proof showing it came from a legitimate source. The bridge's smart contract on the destination chain checked the proof against a list of approved sources before processing the message and releasing the tokens.

On June 21, 2022, a routine code upgrade accidentally added a blank entry to the bridge's "approved sources" list. From that moment, any message that arrived with a blank proof (the easiest thing in the world to construct) matched the blank entry and was processed as legitimate. The bridge would release tokens to anyone who asked for them in the right format.

The bug remained exploitable in production for six weeks. Nomad's monitoring infrastructure was scoped to detect compromised private keys, not smart contract logic errors, so no alert was triggered. Everything else (code on GitHub, prior audit, TVL, governance, team) looked fine. The weakest link was the audit itself, which had gone stale the instant the June 21 upgrade shipped.

On August 1, 2022, one attacker discovered the bug and executed a transaction draining 100 WBTC (approximately $2.3M at the time). Within hours, hundreds of independent actors copied the original attacker's transaction, replaced the recipient address with their own, and replayed the exploit. By the end of the incident, approximately 300 different addresses had drained around $190M from the bridge. It was the first "crowd-looted" exploit in DeFi history.

The audit Nomad publicly pointed to had been performed on a version of the code that was no longer running. Quantstamp had even flagged a related concern before the upgrade (a finding labelled QSP-19, about empty messages being incorrectly treated as legitimate). The June 21 changes were not re-audited before they shipped. 

A risk score based on "recent audit by reputable firm + growing TVL + no public incidents" would have rated Nomad clean on July 31, 2022. By August 1, the same project was effectively dead. The score had not moved because the model had no mechanism for handling post-audit code drift.

How does CORE3 handle the time layer in Probability of Loss?

CORE3's Probability of Loss (PoL) is built around the assumption that risk moves. Every input has a refresh cadence (some weekly, some quarterly), every assessment has an expiry date, and the trajectory of the score is itself part of the assessment. PoL is not a one-time grade. It is a continuously updated measurement, and the shape of that measurement over time is one of the most credible long-term signals a project can build.

Three things follow from designing the score this way.

Refresh cadence is built in. Different inputs update on different schedules. Market and liquidity exposure metrics refresh weekly. Operational maturity and reputational metrics refresh on a longer cycle. Compliance and regulatory exposure refresh quarterly or whenever a material event happens. A project that ships meaningful changes does not have to wait a year for those changes to show up in the score; the score updates against the inputs that actually changed.

The audit decay rule is explicit and unforgiving. If a project upgrades on-chain code and does not re-audit that code, the audit's contribution to the score drops to zero. By the methodology, there is no audit, because the audit no longer describes what is running. This is exactly the gap the Nomad pattern lives in. A re-audit of the June 21 upgrade would have been required for the existing audit signal to still count.

The trajectory is the signal. The PoL value at a single moment is one data point. The shape of the PoL curve over the past several quarters carries far more information. A project that has been steadily improving its score (closing audit gaps, strengthening key management, publishing transparency reports, resolving incident debt) is sending a more credible long-term signal than a project with a slightly lower current score that has been flat for two years.

This changes what is possible for projects with imperfect histories. There is no permanent risk verdict, only the current measurement and the direction it is moving. Sky, post-Black-Thursday, currently sits at #2 in CORE3's PoL ranking despite carrying an incident in its public record. Any project willing to do the work can lead its category by trajectory, including memecoins, post-incident protocols, and projects that started with a poor first reading. The improving trajectory is what signals to institutions, users, and counterparties that a project is built for longevity and continuous defense, not for a single audit cycle followed by quiet drift.

How time influences digital asset due diligence?

Institutional crypto due diligence should treat any risk assessment as a perishable product. The MakerDAO pattern, the Nomad pattern, and the LayerZero policy shift all show that a score's age is itself a risk factor. Continuous monitoring beats annual review; trajectory beats snapshot; recent evidence beats accumulated reputation.

Three points of advice for blockchain risk assessment to account for time:

Firstly, stop running portfolio reviews on annual or quarterly cycles. Pull up each listed asset's PoL trajectory on CORE3 monthly and flag any protocol whose score has drifted more than X points in either direction since the last review. A project that suffered an incident two years ago and has shipped clean since is structurally different from a project that has been quiet but stagnant. 

Secondly, reprice coverage against the PoL slope, not the PoL level. Build trigger clauses into policies that adjust premiums when a covered protocol's trajectory crosses defined thresholds between renewal periods. Premiums priced from cumulative loss history miss the operational signal in how losses were resolved. 

Thirdly, run two screens on your portfolio this quarter. First, identify positions where reputation lags improving fundamentals: these are underwriting opportunities the market has not yet repriced. Second, identify positions whose trajectory has been silently degrading behind a still-strong static reputation: these are underwriting traps. Set automated alerts on every name you hold so trajectory shifts hit your inbox, not your post-mortem.

Bonus for projects themselves: Track your own PoL trajectory the way you track uptime. A multi-quarter improving slope is a credibility signal that no single audit, partnership, or press release can replicate. Resting on an old clean-audit reputation while code drifts accumulates undisclosed risk that will eventually surface, usually at the worst possible moment.

 

The bottom line

Looking bad does not mean being bad. Looking good does not mean being safe. A risk score that does not update is out of date the moment it is generated. CORE3 builds time into the Probability of Loss measurement so that the score moves with the project.

Before you accept any risk score, including ours, ask three questions: when was it last updated, against what evidence, and how is it moving. If your current risk vendor cannot answer all three on demand, you are not looking at a risk model. You are looking at a photograph. Pull your highest-conviction position up on CORE3 today and check the slope.