Skip to content

Back to the catalog

arxiv.orgpaper

A Failure Mode Taxonomy and Severity Model for Ethereum Smart Contracts

A failure mode taxonomy and severity model for Ethereum smart contracts, by Fernando Richter Vidal, Naghmeh Ivaki and Nuno Laranjeiro (University of Coimbra). It classifies observable malfunctions rather than vulnerabilities, using root cause, violated security property, impact, affected component and nature (irreversible, transient or permanent). It was built in five iterations and checked against 94 OpenSCV entries and post-cutoff incidents. The CIPER severity model ranks failures.

TL;DR Proposes an outcome-based taxonomy of Ethereum smart contract failures and the CIPER severity model for ranking incidents.
Document

What it is

A preprint (arXiv 2610.41685v1, 30 October 2026, submitted to IEEE Transactions on Reliability) from the University of Coimbra that classifies how deployed Ethereum contracts observably fail, instead of which code flaws cause the failure. It gives each failure mode a standardized outcome-oriented name and description. It also derives CIPER, a five-level severity model that groups failure modes by observable impact. The iteration data, full taxonomy, saturation set and CIPER assignments are published as supplementary material (reference [18] in the paper).

How it works

The authors follow Nickerson et al.'s taxonomy development method, with the Kundisch et al. update to the ending conditions. Iteration 1 extracted 23 failure modes from a narrow Google Scholar literature search and started with two dimensions, affected component and impact. Iteration 2 added Security Property, grounded in the CIA triad (confidentiality, integrity, availability), with authenticity and non-repudiation as optional extra values. The final taxonomy has five dimensions: root cause, violated security property, impact (primary, secondary, other), affected component, and nature (irreversible, transient, permanent).

Validation is a three-part saturation exercise: a later systematic literature review, a mapping of every OpenSCV vulnerability effect to a failure mode, and post-cutoff incidents from public trackers. It produced no new failure modes or dimensions. The three authors made all coding decisions jointly and resolved disagreements by discussion, so there is no independent inter-rater check in the text provided.

What to do

The paper's practical use is as a shared vocabulary for incident reports and postmortems. Describe the observable malfunction, then record the five dimensions. Use the CIPER level to rank it. The argument is that one vulnerability can surface as different failures and one failure can have several root causes, so a vulnerability list cannot stand in for a failure list. To adopt the scheme, take the failure names and CIPER assignments from the supplementary material.

Caveats

The fetched text stops partway through Table II (iteration 2), so the names of the five CIPER levels, the final failure-mode count and the saturation results by source are not visible here. The construction search was self-described as narrow and initial. The comparison tables and the claim that no prior work combines these four properties are the authors' own. The scope is Ethereum only.

Organisations named here

  • IEEE Transactions on Reliability
  • University of Coimbra

Technologies named here

  • Ethereum
  • OpenSCV

Techniques named here

  • Failure classification by observable outcome
  • Nickerson taxonomy development method
  • Saturation check

Concepts named here

  • CIA triad
  • CIPER
  • CIPER level
  • Ending conditions
  • Failure mode taxonomy for Ethereum smart contracts
  • Failure versus vulnerability
  • Taxonomy dimensions