Research on traditional software in the wild suggests that code age can carry meaningful information about security: mature, unchanged code tends to be less vulnerable, while recent and extensive code changes are associated with more bugs (Ozment & Schechter, 2006; Shin et al., 2011; Alexopoulos et al., 2022; Meneely et al., 2013). Because ossification means bone formation in biology, it is sometimes used to describe solidifying code in computer science.

On blockchains like Ethereum, code age can be an even stronger signal because smart contracts are public, live in an economically adversarial environment, and often directly secure substantial amounts of extractable value. We are therefore measuring code ossification as the accumulation of evidence that code has matured by successfully securing value over time.

L2BEAT watches projects onchain using our disco update monitor, a crawler that regularly queries smart contract code and state and notifies us about changes. To measure ossification, we define a perimeter of critical smart contracts and state for a given project and reset the project’s 🦴-clock each time a critical upgrade or change is recorded. Since we also measure TVS per project over time, we can combine this data for some powerful new metrics.

We do not aim to feed you random scores though, so let us introduce the evidence backing our ossification score. The 0-100 🦴-score is directly based on an open dataset of blockchain hacks that we are collecting and plan to maintain. Each incident in the dataset is reviewed for its mechanism, the age of the vulnerable configuration or source code, and its loss in USD. This allows us to generate a curve for the 🦴-score and gives it practical meaning:

a score of 67 means that 67% of hacks with a loss of >$1k targeted younger code

But vulnerable public code alone will not be exploited unless there is something to gain. Bones harden with regular strain, so we publish the ossification score in the context of a TVS integral, the battle-tested exposure. Similarly to e.g. watt-hours in physics, its dollar-years measure the dollar-time that the project’s code withstood since its last critical change. This boosts projects with a low 🦴-score like Arbitrum or Base, revealing that their young code is likely under much more scrutiny than the code of projects with lower TVS or a lower ‘bounty’.

‘Value secured’ is something we have been watching for a while, and we know that not all value locked is automatically secured by smart contract code. This is why we manually opt-in projects to the ossification metrics.

Amazing, so ossification = security, right? No. Although we are approaching security metrics, the new ossification metrics do not measure:

• capability, or if and how a smart contract can change (this is why we show you the exit window on the ossification summary page)
• audits of the code (although we are working on adding this)
• quantitative code churn (although we are working on adding this)
• anything that does not have to do with onchain code (e.g. key compromise)

We are aware that very few projects are actually ossified today, but this is the reason we built this. Just like we like to incentivize decentralization with our stages and risk frameworks, the ossification score can incentivize elegant, permissionless, robust and timeless architecture for essential blockchain applications. Finally, here is every reviewed exploit in the dataset — hover a dot to see the incident behind it:

Visit the L2BEAT ossification summary or the updated figures in the dataset repo.