Skip to main content

Score Stability

Smart contract grades are designed to be stable. The contracts behind a mature protocol change rarely, so the grades anchored to those contracts stay put. A grade moves when one of a small set of events happens: a meaningful contract change, a change to the curated list of scored contracts, a documented methodology revision, or new audit or incident evidence. This page describes what triggers a re-evaluation, what does not, and what a flat grade actually means.

Why scores stay flat most of the time

A smart contract risk grade is anchored to the deployed code at scoring time. As long as the contracts Ozone scores do not change in a meaningful way, the grade should not move on its own. The dashboard tile carries a last-evaluated timestamp showing when the grade was last refreshed.

In practice, mature protocols upgrade their core contracts rarely. A grade that has not moved in weeks is the affirmative output of a check that ran on its scheduled cadence, found no material change to the scored contracts, and let the existing grade stand. The other way a grade moves is a documented methodology revision: when the rubric, score reductions, or capping ceilings are revised in a published, dated change, every grade in scope is recomputed at the same time. Methodology revisions are announced, never silent.

What triggers a re-evaluation

Four kinds of events cause Ozone to recompute a per-contract or per-protocol grade:

  • A code change on a scored contract: the runtime code at the contract's address has been replaced, or its forwarding target (for upgradeable proxies) has moved. The affected contract is re-graded against the same rubric.
  • A change to the curated list of scored contracts: the curated set gains or loses a contract for a protocol. The per-protocol grade is recomputed across the new set. Changes to the curated list are rare and are documented alongside the methodology.
  • A documented methodology revision: the rubric, the score reductions, or the capping ceilings are revised in a published change. Every grade in scope is recomputed at the same time. Revisions are infrequent in practice and are announced ahead of the recompute.
  • New audit or incident evidence: a new audit covers a previously sparse contract, a new public incident analog ties to a scored contract, or a new bounty posture is published. The affected per-contract grades are re-evaluated through the score reductions step.

Kinds of change we watch for

Ozone watches the scored contracts for the following structural changes:

Kind of changeWhat it means in plain languageScore impact
Deployed-code replacementThe runtime code at the contract's address has changedPer-contract grade recomputed against the same rubric
Upgrade-target rotationAn upgradeable proxy's implementation has moved to a different addressPer-contract grade recomputed; the new implementation is evaluated as if first-seen
Delegation marker appearingAn externally-owned wallet has been authorized to execute contract code on its own address via the EIP-7702 delegation pattern, putting contract logic behind a key that was not previously contract-controlledPer-contract grade recomputed; the delegation surface is treated as new code
Contract destructionThe address no longer holds executable codeForces re-evaluation; the contract is treated as removed from the per-protocol roll-up

When the system observes a change but cannot yet classify it, the affected contract enters a pending state on the dashboard. Classification is resolved by review before the grade is republished, so the dashboard never publishes an automated guess.

What does NOT trigger a re-evaluation

Several classes of activity are visible on chain but do not cause this dimension's grade to refresh.

The following sit outside Ozone's three risk dimensions today: role grants and revocations, parameter updates routed through a timelock, pause and unpause toggles, treasury movements, and governance votes that do not alter contract code. The following are covered by Market Risk: pool-level rate changes, fee changes, supply caps, and market activity such as utilization, liquidations, and deposits.

If a governance or admin event affects your exposure, it falls outside the dimensions Ozone currently scores; track it through the protocol's own governance surface. If the event changes the deployed code itself, the change-detection system picks it up through one of the triggers above.

How a re-evaluation travels

When a watched change is detected, the grade update proceeds through five steps:

  1. The change is observed on chain by the change-detection system.
  2. The change is categorized into one of the kinds above. If the classifier cannot resolve the category, the contract is held for review.
  3. The affected contract is re-graded against the same rubric: posture signals, adversarial-behavior tests, score reductions, capping conditions.
  4. The per-protocol grade is recomputed using the weighted geometric mean across all scored contracts for that protocol, including the newly re-graded one.
  5. The dashboard publishes the new per-contract grade, the new per-protocol grade, the updated tier band, and a fresh evaluation timestamp.

A re-evaluation does not always move the grade. A like-for-like upgrade can land at the same per-contract grade once the new code is re-evaluated; the grade stands and only the last-evaluated timestamp updates. Conversely, the curated list of scored contracts can be expanded or contracted: the per-protocol grade shifts mechanically through the aggregation even when no individual contract changed.

Detection is best-effort and runs on a regular cadence. The interval between an on-chain change landing and the grade reflecting it is measured in minutes, not hours. The dashboard is not a real-time alarm; it is a calibrated grade refreshed on a published cadence.

Coverage

Change-detection covers contracts deployed on Ethereum mainnet today. Coverage of additional networks (Base, Arbitrum, Optimism) is on the roadmap; until then, smart contract risk grades for protocols deployed on those networks rely on baseline scoring without the on-chain change-detection signal.

What you see on the dashboard

When a re-evaluation lands, three surfaces change on the dashboard:

  • The per-contract grade updates for the contract that changed, with its new number and tier chip.
  • The per-protocol grade updates if the per-contract change moved the weighted geometric mean.
  • The last-evaluated timestamp updates to show the new evaluation time.

If the watch is still pending classification, the affected contract carries a pending indicator until review resolves it. If all scored contracts for a protocol are deprecated, the dashboard shows a status note instead of a grade.

When the score does not move

A flat smart contract risk grade is positive evidence: the change-detection system ran, found nothing material in the contracts behind this position, and the existing grade stands. This is by design: the dashboard reflects the underlying contracts, and most of the time the underlying contracts are not moving.

Return to the Smart Contract Risk overview for how this dimension sits next to the others. When smart contract risk is flat, the Risk Dimensions breakdown shows which evidence families anchor the current grade, while Market Risk is the sibling where day-to-day change is part of the normal signal. For the canonical worked case of a grade that has stood since the baseline scoring run, read the Worked Example, which walks the three Maple v2 contracts that anchor this dimension's pilot. For where smart contract risk sits inside the broader Ozone composition, see How Ozone Scores Work.