TextBox

# Automating Source Code Refactoring in the Classroom

Eman Abdullah AlOmar  Stevens Institute of TechnologyHobokenUnited States
<EMAIL_ADDRESS>,  Mohamed Wiem Mkaouer  Rochester Institute of
TechnologyRochesterUnited States<EMAIL_ADDRESS>and  Ali Ouni  ETS Montreal,
University of QuebecMontreal, QuebecCanada<EMAIL_ADDRESS>
###### Abstract.

Refactoring is the practice of improving software quality without altering its
external behavior. Developers intuitively refactor their code for multiple
purposes, such as improving program comprehension, reducing code complexity,
dealing with technical debt, and removing code smells. However, no prior
studies have exposed the students to an experience of the process of
antipatterns detection and refactoring correction, and provided students with
toolset to practice it. To understand and increase the awareness of
refactoring concepts, in this paper, we aim to reflect on our experience with
teaching refactoring and how it helps students become more aware of bad
programming practices and the importance of correcting them via refactoring.
This paper discusses the results of an experiment in the classroom that
involved carrying out various refactoring activities for the purpose of
removing antipatterns using JDeodorant, an Eclipse plugin that supports
antipatterns detection and refactoring. The results of the quantitative and
qualitative analysis with 171 students show that students tend to appreciate
the idea of learning refactoring and are satisfied with various aspects of the
JDeodorant plugin’s operation. Through this experiment, refactoring can turn
into a vital part of the computing educational plan. We envision our findings
enabling educators to support students with refactoring tools tuned towards
safer and trustworthy refactoring.

refactoring, antipattern, quality, software engineering, education

††ccs: Software and its engineering Software maintenance tools††ccs: Software
and its engineering Maintaining software

##  1\. Introduction

Design antipatterns are symptoms of poor choices at the software architecture
level. These bad programming practices typically violate object-oriented
design principles, such as Single Responsibility and Law of Demeter. The
existence of these design antipatterns often leads to the degradation of
software architectures, making them difficult to understand, reuse, and
evolve. It is important to note that these antipatterns are different from
coding errors, and do not directly lead to compiler or logical faults, but
various studies have demonstrated how the existence of antipatterns makes the
code significantly more prone to errors (Bessghaier et al., 2021; Khomh et
al., 2009; Khomh et al., 2012).

Two popular examples of design antipatterns are God Class and Feature Envy.
The first characterizes classes that are abnormally large and monopolize most
of the system’s behavior by controlling a significant number of other coupled
classes. Decomposing this class is trivial to sustain the modular design of
the system. The second is related to methods that heavily rely on methods and
attributes that are outside of its class more than those inside it. This is a
symptom of a misplaced method that needs to be moved to a class to make it
more cohesive.

To cope with these antipatterns, refactoring has emerged as a de-facto
practice to improve software quality through the removal of antipatterns
(Cunningham, 1992). Refactoring is the art of improving source code internal
design, without altering its external behavior (Fowler et al., 1999; AlOmar et
al., 2021).

Several studies have proposed methods for teaching code refactoring through
the identification of duplicate and dead code, and bad naming conventions
(Keuning et al., 2021; Haendler et al., 2019a; Keuning et al., 2020; Haendler
et al., 2019b). While these techniques play a role in improving the student’s
understanding of refactoring, it is critical to expose students to deeper
design-level antipatterns that are frequently found even in well-engineered
projects (Palomba et al., 2018), and harder to fix (Bavota et al., 2015). For
instance, early exposure to God Classes and Feature Envies would help reduce
their prevalence in the future.

Therefore, the goal of this paper is to increase awareness of bad programming
practices, i.e., design-level antipatterns, and the importance of correcting
them through the application of appropriate refactoring operations. Hence, we
perform a series of assignments where students are asked to reason over how to
refactor the God Class and Feature Envy design antipatterns. We chose these
specific antipatterns on the basis of their frequent refactoring by developers
in various systems111Based on tool usage statistics:
https://users.encs.concordia.ca/ nikolaos/.”.

We report our experience using JDeodorant (Tsantalis et al., 2018), an
integrated development environment (IDE) plugin, to support students in
finding suitable refactorings. We chose JDeodorant because it is widely used
by researchers as the state-of-the-art benchmark to assess the precision of
refactoring techniques. JDeodorant is also widely adopted by practitioners to
improve their systems’ design.

We adopted the reflective learning strategy when designing the refactoring
assignments (Brockbank and McGill, 2007). In fact, we follow Ash and Clayton’s
DEAL model (Ash and Clayton, 2009) as we aim to let students first construct
and describe an initial refactoring solution before examining other candidate
solutions recommended by JDeodorant, to finally articulate on the difference
between their solution and the ones recommended by the tool. We executed these
assignments in undergraduate and graduate software engineering courses at two
universities222Hidden for double-blind review.. We analyzed 171 student
refactoring submissions in terms of two dimensions. The first dimension is
empirical, as we assess the quality of students’ refactored code in contrast
with JDeodorant’s, to extract any knowledge gap. This dimension’s outcome
reveals how God class antipattern tends to be harder for students to refactor,
compared to Feature Envy, and how the use of JDeodorant has facilitated the
correction of these hard instances. The second dimension is qualitative, where
we survey students to sense their feedback on the tool’s usefulness,
usability, and functionality. The results of the survey show that the vast
majority of students (87% responses) found the plugin to be useful, and
usable, and were satisfied with its operation. Finally, we reflect on the
importance of reinforcing software design principles and patterns. Therefore,
we foresee students’ usage of JDeodorant as an opportunity to raise awareness
of the detection of antipatterns and their correction measures.

This paper contributes to the broad adoption of refactoring by (i) designing
practical assignments that first challenge students’ abilities to refactor
design-level problems, then second provide them with candidate solutions to
reason over and choose based on their potential impact on quality, and (ii)
reporting the experience of using the JDeodorant plugin. This experiment
enabled instructors to design personalized, hands-on assignments and support
students in learning how to use refactoring features in the IDE. It also
achieves another learning objective, since a recent study has shown that
developers rarely use the built-in IDE features when refactoring their code,
increasing the error proneness of their changes (Golubev et al., 2021). As
part of this paper’s contributions, we provide the assignment description, the
tool documentation, and statistical tests for educators to replicate and
extend (JDe, [n. d.]).

##  2\. JDeodorant Workflow

JDeodorant (Tsantalis et al., 2018) stands as one of the popular refactoring
tools that have been provided as an Eclipse and IntelliJ IDEA plugins. It
automatically detects antipatterns, including Feature Envy, State Checking,
Type Checking, Long Method, God Class, Duplicate Code, and Refused Bequest,
and for each detected antipattern, it offers its correction by providing a
list of candidate refactorings that developers have to choose from.
Developers, are then responsible for choosing the most adequate refactoring
operations according to their design choices and preferences.

To illustrate the workflow of JDeodorant, we choose to fix the Feature Envy
antipattern that may exist in the
Gantt333https://github.com/bardsoftware/ganttproject project. We open the
Gantt project using the Eclipse IDE, with JDeodorant already installed as a
plugin. Then, we enable the plugin by clicking on Bad Smells in the menu bar
(Step 1), and then we click on Feature Envy. To identify all instances of this
antipattern, the plugin internally parses all the project methods to generate
their corresponding Abstract Syntax Tree (AST) representations, which in turn
allows the tool to determine whether a method matches the pattern of a Feature
Envy antipattern. Once the detection process is done, all Feature Envy
instances are shown in the plugin view (Step 2), along with their
corresponding refactoring suggestions (Step 3). For example, as can be seen in
Figure 1, the createFrame method, with 55 lines of code, and located in the
class CharHeaderImpl, is flagged as a Feature Envy. The plugin also proposed a
couple of candidate Move Method Refactorings for us to choose from. If we
choose to fix the creatFrame method by selecting the first refactoring
suggestion, the plugin displays the method being refactored (Step 4), and
internally calls the Move Method built-in feature inside Eclipse. This feature
initiates the refactoring process by opening a preview window (Step 5). This
window shows the original code of the createFrame method, side by side with a
preview of refactored code, which would show the result of moving createFrame
to another class. If we confirm the refactoring, it will automatically be
applied to the source code.

Figure 1. JDeodorant workflow.

##  3\. Experimental Setup

###  3.1. Teaching Context and Participants

The study is performed in courses taught at 2 universities444Hidden for
double-blind review. Details will be added upon the paper’s acceptance.. The
courses cover various concepts related to software analysis and testing, along
with practical tools, widely used in the open-source community. Students were
also given several hands-on assignments in topics including software quality
metrics, code refactoring, bug management, unit and mutation testing, and
technical debt. Before conducting the experiment, students acquired the
necessary background by learning the following concepts: (1) code quality
(teaching quality and how to measure it), (2) design antipatterns (teaching
violations of design principles, and their detections rules), and (3) code
refactoring (teaching refactoring recipes and operations). The experiment’s
assignments constituted 7.5% of the final grade. It was due 14 days each after
the concepts were taught.

###  3.2. Assignments Content and Format

We adopt Ash and Clayton’s reflection model by gathering evidence (refactored
code) that can be examined to identify any gaps in the state of refactoring
practice (inability to correct certain antipatterns), with the intent to
improve it (provide alternative correction mediums).

Initially, students are asked to analyze one version of a Java software system
of their choice approved by the instructor to ensure its eligibility based on
popularity, besides making sure it correctly compiles since JDeodorant
requires it. The rationale behind giving students the choice of project, is to
let them choose one that they are comfortable with, and fits into their
interests. For students who do not want to search for a project, they are
given a list that the instructor has already curated. We selected these
projects (JDe, [n. d.]) because they contain the antipatterns that we are
interested in. We conduct our experiments through two assignments: In the
first assignment, students are asked to fix the two antipatterns (i.e., God
Class and ii) Feature Envy) and provide a sequence of refactoring operations
that will fix multiple instances of these antipatterns. The submissions to
this assignment constitute the Manual Refactoring. In the second assignment,
students are asked to set up and run JDeodorant to analyze the chosen project
production code. Upon running JDeodorant, students are required to choose at
least 2 antipatterns instances from 2 different antipatterns types supported
by the tool (4 in total), and then analyze JDeodorant recommendations to
choose the potential refactoring operations to fix them. Since JDeodorant
gives many recommendations on how to fix the same antipatterns instance, based
on the students’ understanding of problems’ symptoms, they would need to
reason when choosing the code changes that remove the smells while fitting
properly in the system’s design. The submissions to this assignment constitute
the Assisted Refactoring. In summary, the students followed these steps:

  1. (1)

Manually fix the detected antipatterns types: (i) God Class, and (ii) Feature
Envy.

  2. (2)

Provide a sequence of refactoring operations that will fix multiple instances
of those antipatterns (i.e., Manual Refactoring).

  3. (3)

Justify the choices regarding refactoring decisions for each fixed antipattern
type.

  4. (4)

Install the Eclipse plug-in for JDeodorant.

  5. (5)

Run JDeodorant on a project of students’ choice and select 2 instances of each
of the 2 following antipatterns types: (i) God Class, and (ii) Feature Envy.

  6. (6)

Look at the refactoring recommendations by JDeodorant, and choose which ones
to be executed. Students keep refactoring until processing all their chosen
smell instances.

  7. (7)

Report the findings: chosen antipattern instances, chosen refactoring
operations and results (i.e., Assisted Refactoring).

  8. (8)

Add to the report a concise comment about the experience with JDeodorant
(Optional).

Students were evaluated based on two aspects, (1) concept understanding:
assessment of students’ ability to apply the right refactoring to fix
antipatterns; (2) program analysis: assessment of whether students are able to
execute refactoring and verify the preserved behavior. Students were not
evaluated on their perception of the code, to avoid any cognitive bias that
may occur under the pressure of being graded. Also, we anonymized the
feedback, and made it optional, to only collect information from students who
were serious about it, which will increase the magnitude of provided
experience. Despite it being not mandatory, the majority of students (96.07%)
chose to complete it.

The assignment was performed over four consecutive semesters. 171 students,
primarily from computer science (CS) and software engineering (SE) majors,
were enrolled during these semesters, and completed assignments.

###  3.3. Data Analysis

We analyzed the responses to open-ended questions to create a comprehensive
high-level list of themes by adopting a thematic analysis approach based on
guidelines provided by Cruzes et al.  (Cruzes and Dyba, 2011). Thematic
analysis is one of the most used methods in Software Engineering literature
(Silva et al., 2016; AlOmar et al., 2022, 2023). This is a technique for
identifying and recording patterns (or themes) within a collection of
descriptive labels, which we call codes. For each response, we proceeded with
the analysis using the following steps: i) Initial reading of the survey
responses; ii) Generating initial codes (i.e., labels) for each response; iii)
Translating codes into themes, sub-themes, and higher-order themes; iv)
Reviewing the themes to find opportunities for merging; v) Defining and naming
the final themes, and creating a model of higher-order themes and their
underlying evidence. The above-mentioned steps were performed independently by
two authors. One author performed the labeling of students’ comments
independently from the other author who was responsible for reviewing the
currently drafted themes. By the end of each iteration, the authors met and
refined the themes.

##  4\. Results

(a) Impact of Manual Refactoring on God Class Distribution

(b) Impact of Assisted Refactoring on God Class Distribution

(c) Impact of Manual Refactoring on Feature Envy Distribution

(d) Impact of Assisted Refactoring on Feature Envy Distribution

Figure 2. Boxplots of (a) God Class, and (b) Feature Envy antipattern
instances addressed by students. Figure 3. Feature Envy example from the Log4J
project (Log, [n. d.]).

###  4.1. Quantitative Analysis

Table 1. Statistical test.

Antipattern Approach Impact p-value Cliff’s delta ($\delta$) God Class Manual
+ve 0.01 0.05 (Negligible) Assisted +ve 1.89e-161 0.76 (Large) Feature Envy
Manual +ve 2.22e-06 0.19 (Small) Assisted +ve 1.46e-161 0.76 (Large)

To show the effectiveness of JDeodorant in educating students about better-
making design decisions, we count the number of God Class, and Feature Envy
antipatterns before and after refactoring, initially when students refactored
the antipatterns manually (referred to as Manual Refactoring), and then when
students refactored the antipatterns based on JDeodorant recommendations
(referred to as Assisted Refactoring). Figure 2 reports the box plots
depicting the distribution of each group value, clustered by the two above-
mentioned antipatterns. We used the Wilcoxon test (Wilcoxon, 1945) to test the
significance of the difference between the group’s values. This non-parametric
test checks continuous or ordinal data for a significant difference between
two dependent groups. Our hypothesis is formulated to test whether the
antipattern after the refactoring group is significantly lower than the values
of the antipatterns before the refactoring group. The difference is considered
statistically significant if the p-value is less than 0.05. Furthermore, we
used Cliff’s delta ($\delta$) effect size to estimate the magnitude of the
differences. Regarding its interpretation, we follow the guidelines reported
by (Grissom and Kim, 2005): Negligible for $\mid\delta\mid<0.147$; Small for
$0.147\leq\mid\delta\mid<0.33$; Medium for $0.33\leq\mid\delta\mid<0.474$; and
Large for $\mid\delta\mid\geq 0.474$.

The count of corrected antipatterns was done manually by the authors. Since
the complete list of students’ submissions is too large to examine manually,
we selected a statistically significant sample for our analysis and annotated
62 submissions. This quantity roughly equates to a sample size with a
confidence level of 95%, with a margin of error of 10%. As can be seen in
Figure 2, antipatterns (i.e., God Class and Feature Envy) before refactoring
are larger than the antipatterns after refactoring. While the difference was
statistically significant (0.011 and 2.22e-0 for God Class and Feature Envy,
respectively), the magnitude of the difference is negligible and small for God
Class and Feature Envy, respectively. We conjecture that although there is
quality improvement as the number of antipatterns decreased, there were many
instances where students’ Manual Refactorings could not remove certain
antipatterns, particularly the God Classes instances. However,  assisted
refactoring also had a positive impact on quality, as the number of
antipatterns (i.e., God Class and Feature Envy) before refactoring is greater
than the antipatterns after refactoring (1.89e-161 and 1.46e-161 for God Class
and  feature envy, respectively). However, the main difference lies in the
magnitude of the difference (Cliff Delta), which was large for the Assisted
Refactoring, according to Table 1. We conclude that JDeodorant’s assistance
was beneficial in improving students’ design decisions. Figure 3 shows an
example of a Feature Envy design antipattern from one of the student’s
submissions. The CategoryNodeEditor class has a method called
getDisplayedProperties that seems overly interested in the properties of the
CategoryNode class. The method getDisplayedProperties calls many methods from
CategoryNode class more than its own class methods (Coupling = 6). This
indicates that the method should belong to the CategoryNode class instead.
When the student applied the Move Method refactoring, as recommended by
JDeodorant, the Feature Envy antipattern was removed, along with a decrease in
the system’s overall coupling.

Observation. Not all antipatterns are easily refactorable. It is important to
note that despite students’ efforts to remove antipatterns, our analysis of
Manual Refactoring code shows how many instances of antipatterns existed after
the refactoring session. In particular, God Classes are difficult to refactor,
as the magnitude of the difference is negligible in Table 1. Previous research
has demonstrated how God classes tend to be hard to fix in industry (Anquetil
et al., 2019). So, we emphasize the importance of raising students’ awareness,
as a preventive measure, to avoid creating God classes.

Table 2. Student’s insight about the usefulness, usability and functionality
of the tool.

Theme Sub-theme Example (Excerpts from a related student’s comment) Usefulness
Efficiency JDeodorant is undoubtedly a very convenient tool for developers, he
can easily fix various code smells and improve the development efficiency of
developers. Quality It can help to prioritize refactoring instances by
selecting them based on their number of methods and attributes they have. It
also gives more details about classes and have an insight of the impact of
refactoring. Automation Overall my experience with the plugin was good. It
takes most of the refactoring work and basically automates it. Awareness The
product seemed to work well. Additionally, its ability to tell what
refactoring to do and actually perform it seems super helpful, and more
helpful if I actually knew what I was doing when refactoring. Experience My
experience with JDeodorant was quite pleasant. It simplified the process of
addressing flaws in the code and for someone with limited software engineering
experience related to code smells it was very informative. Usability Graphical
design the very intuitive graphical design of the plugin (for instance, doing
things such as highlighting code that it changes in green) makes such reviews
far simpler than alternative approaches may provide. Preview I particularly
liked IntelliJ’s display showing side-by-side diffs of what changed; it made
it clear what was changing, which in turn made it easier to interpret why the
tool was suggesting the change. Visualization The JDeodorant version for
eclipse provides the visual context/flow chart containing the breakdown of the
bad smells and the highlighted code. That proved to be very beneficial during
the refactoring process, especially with god class. Documentation It is also
an automated process, which is User friendly and it gives guidelines for the
usage and it also pre-evaluates the refactoring. Functionality Design
antipatterns I found that jDeodorant did a great job at detecting any issues
that were found. Refactoring I am happy I picked a smaller project to work on,
it is significantly easier to see the effects of the changes. Most of the
refactoring that was suggested were various kinds of extraction, mostly
methods. Recommendation Quality It would have been nicer if the project
checked for refactorings again automatically after applying one instead of the
user needing to use it. Design antipatterns I am really impressed with how
this tool can detect the code smells and suggest refactoring to solve the
problems. However, […], it can only detect three types of code smells. Many
software has a wide range of other code smells not only (long method, god
class, feature envy) which are not possible to detect using this tool.
Refactoring some of it’s suggestion of the refactoring is incompleted, the
suggestion name and logic detection has missed some part of the code. So I
feel this tool can only use as an quick reference in the code quality review
Testing Its hard to find if refactoring did break any of the feature or
functionality remains the same even after refactoring.

Observation. Understanding the impact of refactoring on quality is challenging
for students. Although both refactoring sessions aim to improve quality,
students realize, when they compare their manual refactoring with the assisted
one, that not all refactorings can be equally beneficial to design quality.
For instance, the process of extracting multiple classes, to remove a God
Class antipattern, will eventually increase the number of classes per package,
which is also considered an increase in system complexity according to the CK
quality metrics (Chidamber and Kemerer, 1994). Thus, students need to consider
these trade-offs as they make their choices. In this context, quality gate
tools, such as Understand555https://scitools.com/ and
SonarQube666https://sonarqube.org can be deployed to measure the quality
before and after the application of refactoring. This might strengthen
students’ understanding of writing well-structured code and raise their
confidence to perform the recommended refactoring.

###  4.2. Qualitative Analysis

In Table 2, we report the main thoughts, comments, and suggestions about the
overall impression of the usefulness, usability, functionality, and
recommendation of the tool, according to the conducted labeling. Figure 4
shows the percentages of students’ insight. As can be seen, the
‘Functionality’ and ‘Usefulness’ categories had the highest number of
responses, with a response ratio of 34.6% and 32.1%, respectively. The
category ‘Recommendation’ was the third most popular category with 21.8%,
followed by ‘Usability’, which had a ratio of 11.5%. This finding indicates
what students mainly care about when using the tool. Table 2 presents samples
of the students’ comments to illustrate their impression of each theme.

Usefulness. Generally, the respondents found the plugin to be useful in
regards to five main aspects: efficiency, quality, automation, awareness, and
experience. 40 out of 171 students commented that JDeodorant is very intuitive
to use and was quite efficient to find refactoring opportunities, and
convenient for developers who would not have to examine and refactor
antipatterns manually. 30 students communicated that eliminating antipatterns
assists in increasing its readability while reducing its coupling and
complexity, which helps improve overall code quality. A few students revealed
that the tool’s ability to identify antipatterns within a selected file allows
them to only correct errors in a specific location/file of their interest,
instead of inspecting the entire project. Further, two students commented that
the tool aids less experienced developers in identifying the antipatterns when
updating a source file that they are not necessarily familiar with.
Additionally, a group of students mentioned that the tool helps less
experienced and novice developers in writing well-structured code.

Usability. Based on the feedback provided by the students, the key areas in
usability related to the graphical design, preview, visualization, and
documentation. Five students pointed out the graphical design of the plugin is
intuitive, especially the IntelliJ IDEA’s display feature showing side-by-side
diffs of what changed. This preview feature makes it clear what was changing
and why the tool was suggesting the change. Other comments also stated the
importance of the preview feature, which allows them to foresee the impact of
the change without actually performing it. Two students reported the useful
feature of antipattern visualization as a flow chart, as it allows locating
the hot areas in code that encapsulate a large set of smells. Lastly, the
documentation of the plugin is written and easy to follow.

Functionality. According to the students’ feedback about the tool’s functional
features, 34.6% of the students’ comments show a couple of appreciation for
the supported antipatterns by the tool, and how this feature helps in better
understanding the concepts in a real-world scenario. Additionally, the
students commented on their ability to practice a variety type of refactoring
operations according to their removal of the antipatterns.

Recommendation. From the students’ feedback, we have also extracted
suggestions to improve the tool’s features. 21.8% of the students’ comments
show a couple of suggested changes as a recommendation or refactoring support
to be made to the tool’s operation or UI. We found out the students pointed
out some of the recommendations related to quality, antipatterns, refactoring,
and testing. Students recommend the tool to perform a sanity check after
performing the application of refactoring, support more antipatterns, perform
the complete application of refactoring, and perform testing in order to check
the behavior preservation of code transformation after refactoring.

Functionality 34.6% Usefulness 32.1% Recommendation 21.8% Usability 11.5%
Figure 4. Students’ perception about the refactoring tool.

##  5\. Reflections

Reflection #1: Raising the awareness of antipatterns and their refactoring
strategies. Previous studies (Smith et al., 2006; Stoecklin et al., 2007; Abid
et al., 2015; Izu et al., 2022; López et al., 2014) have proposed different
methods to teach refactoring, but did not provide students with toolset to
practice it. It is still a manual process that might contribute in a limited
way in the long run. However, if students learn how to automate refactoring,
it helps them to better refactor the code while preserving the behavior and
making the code less prone to error. Further, in education, there are many
concepts related to design principles that are taught in the classroom, such
as SOLID and GRASP. However, the responses that we received from students,
have shown the importance of covering design anti-patterns, and bad
programming practices avoidance in curricula, as these topics are generally
less popular, compared to design patterns. In many CS and SE curricula,
instructors highlight software quality when teaching good programming
practices and design patterns. This assignment complements it by revealing how
deviation from best practices can lead to poor design choices that negatively
impact the source code. Similarly to teaching blueprints of design patterns,
students should also be exposed early to quality concerns and encouraged to
improve the design of their own code. Moreover, one of the noteworthy points
is that using the tool in the assignment helps less experienced and novice
coders to write well-structured code. To further raise awareness, educators
can include empirical evidence to enhance students’ understanding of
refactoring and antipatterns concepts and so students providing low-quality
code can be convinced that these concepts help improve the quality of software
systems.

Reflection #2: Reinforcing software engineering principles and good
development practices. Studies have shown how group-based project artifacts
tend to be purposely over-engineered complex models as a means to showcase the
ability to design complex systems (Colbeck et al., 2000; Berland et al.,
2013). Through this assignment, students would realize that over-engineered
systems tend to contain more design anti-patterns, and therefore simplifying
them is necessary for their code to become easier to maintain in the future.
According to students’ insights, we believe that instructors need to highlight
the desirable properties of refactoring tools (e.g., quality improvement,
developer perception, automated testing, etc). Future educators and
researchers are encouraged to revisit existing refactoring tools so that
students can gain more confidence in using them. Moreover, since the classical
definition of refactoring focuses on behavior preservation of the applied
transformation, instructors might consider pointing out some behavior
preservation strategies (e.g., (AlOmar et al., 2021)) and explore their
potential in assessing the correctness of the refactored code (e.g., for the
context of JDeodorant, the students can run unit tests to verify that the
applied refactoring was behaviorally preserved).

##  6\. Related Work

Smith et al. and Stoecklin et al. (Smith et al., 2006; Stoecklin et al., 2007)
introduced an incremental approach by focusing on lessons from an innovative
pedagogical approach to teaching refactoring, such as self-documenting code
and better recognizing code. The authors conclude that refactoring can become
an integral component of the computer science curriculum by reinforcing
software engineering principles. Rabb (Raab, 2012) introduced
CodeSmellExplorer to familiarize users with good coding practices by
visualizing an interactive graph network of antipatterns and connected
refactorings. Lobez et al. (López et al., 2014) described e-activities for
teaching refactoring by following Bloom’s taxonomy (i.e., proposing activities
to help with understanding a concept, applying refactorings in the context of
and synthesizing of the use of refactorings in open source projects). Elezi et
al. (Elezi et al., 2016) proposed a gamification system that tracks and
rewards refactorings during development. Haendler and Neumann (Haendler and
Neumann, 2019) explored the challenges of designing serious games for
refactoring on real-world code artifacts. Specifically, they proposed a game
design where students can compete either against a predefined benchmark
(technical debt) or against each other. In a follow-up work, Haendler et al.
(Haendler et al., 2019b, a) developed an interactive tutoring system for
training software refactoring. Keuning et al. (Keuning et al., 2020, 2021) to
teach students to refactor functionally correct code. More recently, Izu et
al. (Izu et al., 2022) proposed a lab-based resource to help novices identify
and refactor antipatterns when writing conditional statements. Although there
are recent studies that explored refactoring practice in education in a
general context, to the best of our knowledge, no prior studies have exposed
the students to the process of detecting bad programming practices, and
correcting them through applying suitable refactorings.

##  7\. Conclusion and Future Work

In this study, we performed an experiment to understand how students perform
the application of refactoring. Specifically, we demonstrate running an
assignment about using the tool JDeodorant to refactor antipatterns. Overall,
the participants rated various aspects of the plugin highly, while also
providing valuable ideas for future development. We envision our findings
enabling educators to support students with refactoring tools tuned towards
safer refactoring. Future work in this area includes investigating students’
understanding of refactoring using various real-world applications in a
semester-long course project. This offers the opportunity for students to
choose a refactoring-related topic.

## References

  * (1)
  * JDe ([n. d.]) [n. d.].  https://anonymousresearchersubmission.github.io/SIGCSE2023_JDeodorant/.
  * Log ([n. d.]) [n. d.].  https://github.com/apache/logging-log4j2.
  * Abid et al. (2015) Shamsa Abid, Hamid Abdul Basit, and Naveed Arshad. 2015\.  Reflections on teaching refactoring: A tale of two projects. In _Proceedings of the 2015 ACM Conference on Innovation and Technology in Computer Science Education_. 225–230.
  * AlOmar et al. (2023) Eman Abdullah AlOmar, Salma Abdullah AlOmar, and Mohamed Wiem Mkaouer. 2023.  On the use of static analysis to engage students with software quality improvement: An experience with pmd.  _arXiv preprint arXiv:2302.05554_ (2023).
  * AlOmar et al. (2022) Eman Abdullah AlOmar, Moataz Chouchen, Mohamed Wiem Mkaouer, and Ali Ouni. 2022.  Code Review Practices for Refactoring Changes: An Empirical Study on OpenStack.  (2022), 1–13.
  * AlOmar et al. (2021) Eman Abdullah AlOmar, Mohamed Wiem Mkaouer, Christian Newman, and Ali Ouni. 2021.  On preserving the behavior in software refactoring: A systematic mapping study.  _Information and Software Technology_ (2021), 106675.
  * Anquetil et al. (2019) Nicolas Anquetil, Anne Etien, Gaelle Andreo, and Stéphane Ducasse. 2019.  Decomposing god classes at siemens. In _2019 IEEE International Conference on Software Maintenance and Evolution (ICSME)_. IEEE, 169–180.
  * Ash and Clayton (2009) Sarah L Ash and Patti H Clayton. 2009.  Generating, deepening, and documenting learning: The power of critical reflection in applied learning.  (2009).
  * Bavota et al. (2015) Gabriele Bavota, Andrea De Lucia, Massimiliano Di Penta, Rocco Oliveto, and Fabio Palomba. 2015\.  An experimental investigation on the innate relationship between quality and refactoring.  _Journal of Systems and Software_ 107 (2015), 1–14.
  * Berland et al. (2013) Leema K Berland, Taylor H Martin, Pat Ko, Stephanie Baker Peacock, Jennifer J Rudolph, and Chris Golubski. 2013.  Student learning in challenge-based engineering curricula.  _Journal of Pre-College Engineering Education Research (J-PEER)_ 3, 1 (2013), 5.
  * Bessghaier et al. (2021) Narjes Bessghaier, Ali Ouni, and Mohamed Wiem Mkaouer. 2021\.  A longitudinal exploratory study on code smells in server side web applications.  _Software Quality Journal_ 29, 4 (2021), 901–941.
  * Brockbank and McGill (2007) Anne Brockbank and Ian McGill. 2007.  _Facilitating reflective learning in higher education_.  McGraw-Hill Education (UK).
  * Chidamber and Kemerer (1994) Shyam R Chidamber and Chris F Kemerer. 1994.  A metrics suite for object oriented design.  _IEEE Transactions on software engineering_ 20, 6 (1994), 476–493.
  * Colbeck et al. (2000) Carol L Colbeck, Susan E Campbell, and Stefani A Bjorklund. 2000\.  Grouping in the dark: What college students learn from group projects.  _The Journal of Higher Education_ 71, 1 (2000), 60–83.
  * Cruzes and Dyba (2011) Daniela S Cruzes and Tore Dyba. 2011.  Recommended steps for thematic synthesis in software engineering. In _2011 international symposium on empirical software engineering and measurement_. IEEE, 275–284.
  * Cunningham (1992) Ward Cunningham. 1992\.  The WyCash portfolio management system.  _ACM SIGPLAN OOPS Messenger_ 4, 2 (1992), 29–30.
  * Elezi et al. (2016) Leonard Elezi, Sara Sali, Serge Demeyer, Alessandro Murgia, and Javier Pérez. 2016.  A game of refactoring: Studying the impact of gamification in software refactoring. In _Proceedings of the Scientific Workshop Proceedings of XP2016_. 1–6.
  * Fowler et al. (1999) Martin Fowler, Kent Beck, John Brant, William Opdyke, and don Roberts. 1999.  _Refactoring: Improving the Design of Existing Code_.  Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA.  http://dl.acm.org/citation.cfm?id=311424
  * Golubev et al. (2021) Yaroslav Golubev, Zarina Kurbatova, Eman Abdullah AlOmar, Timofey Bryksin, and Mohamed Wiem Mkaouer. 2021\.  One thousand and one stories: a large-scale survey of software refactoring. In _Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering_. 1303–1313.
  * Grissom and Kim (2005) Robert J Grissom and John J Kim. 2005.  _Effect sizes for research : a broad practical approach_.  Mahwah, N.J. ; London : Lawrence Erlbaum Associates.  Formerly CIP.
  * Haendler and Neumann (2019) Thorsten Haendler and Gustaf Neumann. 2019.  Serious refactoring games. In _Proceedings of the 52nd Hawaii International Conference on System Sciences_.
  * Haendler et al. (2019a) Thorsten Haendler, Gustaf Neumann, and Fiodor Smirnov. 2019a.  An interactive tutoring system for training software refactoring.  _Instructor_ 1 (2019), 4.
  * Haendler et al. (2019b) Thorsten Haendler, Gustaf Neumann, and Fiodor Smirnov. 2019b.  RefacTutor: an interactive tutoring system for software refactoring. In _International Conference on Computer Supported Education_. Springer, 236–261.
  * Izu et al. (2022) Cruz Izu, Paul Denny, and Sayoni Roy. 2022.  A Resource to Support Novices Refactoring Conditional Statements. In _Proceedings of the 27th ACM Conference on on Innovation and Technology in Computer Science Education Vol. 1_. 344–350.
  * Keuning et al. (2020) Hieke Keuning, Bastiaan Heeren, and Johan Jeuring. 2020\.  Student refactoring behaviour in a programming tutor. In _Koli Calling’20: Proceedings of the 20th Koli Calling International Conference on Computing Education Research_. 1–10.
  * Keuning et al. (2021) Hieke Keuning, Bastiaan Heeren, and Johan Jeuring. 2021\.  A tutoring system to learn code refactoring. In _Proceedings of the 52nd ACM Technical Symposium on Computer Science Education_. 562–568.
  * Khomh et al. (2009) Foutse Khomh, Massimiliano Di Penta, and Yann-Gael Gueheneuc. 2009\.  An exploratory study of the impact of code smells on software change-proneness. In _2009 16th Working Conference on Reverse Engineering_. IEEE, 75–84.
  * Khomh et al. (2012) Foutse Khomh, Massimiliano Di Penta, Yann-Gaël Guéhéneuc, and Giuliano Antoniol. 2012\.  An exploratory study of the impact of antipatterns on class change-and fault-proneness.  _Empirical Software Engineering_ 17, 3 (2012), 243–275.
  * López et al. (2014) Carlos López, Jesús M Alonso, Raúl Marticorena, and Jesús M Maudes. 2014.  Design of e-activities for the learning of code refactoring tasks. In _2014 International Symposium on Computers in Education (SIIE)_. IEEE, 35–40.
  * Palomba et al. (2018) Fabio Palomba, Gabriele Bavota, Massimiliano Di Penta, Fausto Fasano, Rocco Oliveto, and Andrea De Lucia. 2018.  On the diffuseness and the impact on maintainability of code smells: a large scale empirical investigation.  _Empirical Software Engineering_ 23, 3 (2018), 1188–1221.
  * Raab (2012) Felix Raab. 2012\.  CodeSmellExplorer: Tangible exploration of code smells and refactorings. In _2012 IEEE Symposium on Visual Languages and Human-Centric Computing (VL/HCC)_. IEEE, 261–262.
  * Silva et al. (2016) Danilo Silva, Nikolaos Tsantalis, and Marco Tulio Valente. 2016\.  Why We Refactor? Confessions of GitHub Contributors. In _Proceedings of the 2016 24th ACM SIGSOFT International Symposium on Foundations of Software Engineering_ (Seattle, WA, USA) _(FSE 2016)_. ACM, New York, NY, USA, 858–870.  https://doi.org/10.1145/2950290.2950305
  * Smith et al. (2006) Suzanne Smith, Sara Stoecklin, and Catharina Serino. 2006\.  An innovative approach to teaching refactoring. In _Proceedings of the 37th SIGCSE technical symposium on Computer science education_. 349–353.
  * Stoecklin et al. (2007) Sara Stoecklin, Suzanne Smith, and Catharina Serino. 2007\.  Teaching students to build well formed object-oriented methods through refactoring.  _ACM SIGCSE Bulletin_ 39, 1 (2007), 145–149.
  * Tsantalis et al. (2018) Nikolaos Tsantalis, Theodoros Chaikalis, and Alexander Chatzigeorgiou. 2018.  Ten years of JDeodorant: Lessons learned from the hunt for smells. In _2018 IEEE 25th international conference on software analysis, evolution and reengineering (SANER)_. IEEE, 4–14.
  * Wilcoxon (1945) Frank Wilcoxon. 1945\.  Individual comparisons by ranking methods.  _Biometrics bulletin_ 1, 6 (1945), 80–83.


# From Social Engineering to Quantum Threats: Safeguarding User Wallets with
FailSafe

Gennady “Ari” Medvinsky  Benjamin Livshits

###### Abstract

While cryptocurrencies have been rapidly gaining adoption, secure wallet
interactions are still elusive for many users, which frequently leads to loss
of funds. Here we propose an approach to securing interactions with
cryptocurrency wallets for end-users. The approach called FailSafe consists of
several defence-in-depth measures that can be applied near-term as well as a
tool called qMig for aiding eventual quantum migration.

###### keywords:

blockchain , wallets , system security

††journal: Blockchain: Research and Applications

[1]organization=Eleos Labs,

[2]organization=Imperial College London

##  1 Introduction

In Web2, most users have a certain degree of familiarity with threats to their
online accounts, be those of financial nature or pertaining to other services
like social media. Frequently, the attacker focuses on user credentials and
account takeover. Password compromises can be achieved through a dictionary
attack, taking advantage of a poorly chosen secret, or through many forms of
phishing and social engineering attacks, enticing the user to share their
credentials. With the password compromised, the attacker can then extract
whatever value is associated with the account, or use that account to perform
some form of escalation to compromise further accounts. According to recent
surveys [24], the following best online security practices remain a challenge
for both end-users and IT professionals alike.

Usability issues around security have some parallels in Web3. For instance,
phishing attacks can vary from tricking the user to disclose their private
key, to obtaining a signature that grants permission for potentially unlimited
fund transfer. Flawed but popular open-source software can generate vanity
blockchain addresses (i.e, Profanity [13]), but in the process makes it
trivial for the attacker to compute the corresponding private key.

Most products in this space are built with relatively standalone threat models
in mind. For example, hardware wallet solutions tend to mainly focus on having
an air gap with less trusted software components. Threat intelligence products
like Chainalysis provide an insight into the counter-party risk. Users are
left to devise their own threat mitigation strategies through some combination
of these products. This approach not only puts an undue burden on the user,
but may leave users exposed to web3 threats in unforeseen ways.

Figure 1: Timeline of a Transaction.

###  1.1 Defence-in-Depth

FailSafe is an anti-theft Web3 wallet companion system that is focused on
protecting the end to end web3 transaction journey. FailSafe is built using
the defence-in-depth principle: it offers a multilayered set of security
mechanisms, with built-in redundancy, designed to minimise the loss of user
assets even under the worst-case circumstances (disclosure of the user’s
private key, or a compromised insider within a trusted system).

FailSafe takes every opportunity to protect the user’s assets across the
lifecycle of a transaction: from initial user engagement phase with the dApp,
to the point it is committed on chain. At the outset, on enrollment, FailSafe
helps the user to reduce risk by moving the majority of assets to the user’s
cold wallet address that does not partake in regular web3 transactions; this
is not unlike what custody solutions do; however, up til now, this practice
has been unavailable to retail users.

According to a recent study [26] of ERC-20 token usage patterns, 60% of all
users grant unlimited transfer approvals to dApps, 22% of which are considered
to be at high risk of their approved tokens being stolen. By moving the
majority of assets to the user’s cold wallet, these assets are no longer
exposed to the above risk.

FBR | counter-party risk
---|---
FIS | mempool operations
qMig | quantum migration
Figure 2: Layers of protection in FailSafe.

FailSafe, automatically maintains the user desired balance ratio between the
hot and cold wallet addresses, preserving the de-risked security posture over
time. Once the user engages with a dApp, the FailSafe Blockchain
Reconnaissance (FBR) service is used to obtain the risk score for the counter-
party’s web3 address.

If FailSafe software is in the code path, fraudulent transactions are outright
blocked. Otherwise, the next layer of protection is the FailSafe Interceptor
Service (FIS), which monitors pending transactions submitted to the
blockchain’s memory pool. If the transaction counter-party has a high risk
score (based on a call to FBR) , FIS is capable of submitting another
transaction that is executed ahead of the attacker’s, moving the funds at risk
into the user’s cold storage address before the attacker’s transaction is
executed.

###  1.2 Forward Security

FailSafe defence-in-depth approach is forward-looking — it lays the groundwork
for safeguarding the user’s crypto against newly-emerging threats.

Advances in quantum computing hardware have made significant strides,
propelled by the nation-state quantum computing race with a number of
different R&D centres, reaching significant computing benchmarks and
milestones (see: Google’s Quantum Supremacy [8] and IBM Quantum System One
[7]).

When viewed from the lens of cryptography, it presents a unique problem. While
Shor’s algorithm published in 1994 [25], could theoretically break certain
algorithms used for digital signatures (i.e., ECDSA), it requires a
sufficiently powerful quantum computer to do it. With recent advances, the
time window to reach this milestone has been shrinking (see Global Risk
Institute’s 2022 report [23]).

The situation is especially dire for the Ethereum ecosystem (this includes EVM
compatible networks, like Polygon, Binance Smart Chain, Avalanche, and many
others). The current version of Ethereum lacks cryptographic agility.
Externally-owned addresses (user wallets) use ECDSA with no other option built
in (see the quantum threats section for a more in-depth discussion).
Furthermore, by design, externally owned addresses are commonly re-used,
giving an attacker with future quantum hardware a longer time window to derive
the private key via the earlier record of transaction signatures.

Once wallet signatures are no longer cryptographically trustworthy, the
inability to establish rightful custody over web3 assets will pose a barrier
to bridging assets to a quantum-safe network (e.g., QRL [6]) or future
versions of quantum-safe, EVM-compatible blockchains.

As part of the FailSafe project, the Quantum Migration Tool (qMig) was
developed to future-proof against this outcome. Prior to the quantum
inflection point, qMig enables users to construct and record a future intent
to transfer tokens, in case the quantum inflection point occurs and ECDSA
signature by itself can not be trusted. The security of this intent is rooted
in cryptography that is not susceptible to quantum attacks. The integration of
FailSafe with qMig, records the necessary proofs automatically, requiring no
additional effort by the end user, as detailed in Section 3.3.

Figure 3: FailSafe architecture.

##  2 Web3 Threats to Your Crypto

The private key that corresponds to the user’s wallet address controls the
transfer of value on the public ledger, be it in the form of tokens or native
cryptocurrency. To capture this key, a potential attacker has a range of
possible options; the reader is referred to Mirza et. al. for more details
[22]:

  * 1.

Theft of private keys: with the knowledge of the private key, the attacker can
send a transaction for every token and native currency associated with the
address, transferring the assets to the attacker’s own address. Any staked
tokens in third party systems can be withdrawn and transferred to the
attacker’s address. There are numerous examples of this in the wild:
fraudsters often pose as customer support convincing users to install a fake
wallet software that captures and shares the user’s passphrase with the
attacker. Some of the recent bridge hacks have the same culprit as well [28].

  * 2.

Obtaining user’s authorization: through sociael engineering and confusing Web3
wallet user experiences, the attacker convinces the user to sign a transaction
that can be crafted to transfer funds out of the wallet [26].

  * 3.

Compromise of third-party smart contracts: Exploit smart contract
vulnerabilities and then drain user assets that temporarily reside under the
contract address ownership (there are numerous examples of bridge hacks that
fall into this category).

###  2.1 Designing with Operator Error in Mind

From recent trends in Web3 attacks, it is clear that the human factor plays a
central role. Users might be lured into violating one or more best security
practices without knowing – in the case of the Profanity bug hack, vanity Web3
addresses were generated that made it possible for attackers to derive the
private key. Once the system is configured into a secure state, over time it
is likely that the security posture will decay, if it requires regular end-
user effort to upkeep.

In a recent $8M exploit, users were lured into installing an unofficial update
of a popular web3 wallet. It is suspected that the fake wallet update involved
users re-entering the seed phrase (giving the attacker full access to the
victim’s crypto assets). The FailSafe threat model is designed with these
seemingly game over scenarios in mind. In the later part of this section, we
introduce how the defense-in-depth principle is applied throughout the life-
cycle of a transaction, and how the application of FailSafe multi-layered
defenses minimises losses from the type of incidents noted above.

###  2.2 Defence-in-depth and the Lifecycle of a Transaction

FailSafe is built on the defence-in-depth principle: a multilayered set of
security mechanisms, with built in redundancy, designed to minimise loss of
user assets even in the worst case circumstances (e.g., user is tricked into
giving away the wallet’s passphrase). A summary is shown in Figure 2.

To better understand how this works, let’s take a closer look at the life-
cycle of a transaction: from initial user engagement phase with the dApp, to
the point it becomes part of a permanent record on a public ledger (as
illustrated in Figure 1).

Each phase below presents both an opportunity for the attacker, as well as a
chance to employ a countermeasure.

Defence 1: de-risk Web3 Asset Positions: Before engaging with the user, the
attacker has an opportunity to learn a great deal from the public ledger,
fine-tuning targets of interest, based on type and value of owned assets. From
the public ledger, the attacker’s bot can compile a list of addresses and
corresponding owned tokens on selected EVM blockchains, customising the attack
as needed.

On the flipside, during this phase, the user has a chance to de-risk and
remove the majority of owned assets entirely beyond the attacker’s reach. By
enrolling in theFailSafe automated cold storage feature, the vast majority of
assets are re-balanced, to be owned by the user’s wallet address that does not
partake in regular web3 transactions.

Just as importantly,FailSafe is designed to maintain this security posture
over time. With little to no imposition on the user,FailSafe automatically
maintains the asset balance ratio between the hot and cold wallet, subject to
the user’s high level instructions. Access to cold storage is safeguarded via
a multi-signature contract, the corresponding private keys are protected under
a unique orchestration of Amazon’s Nitro Enclaves and Google’s Confidential
Compute with cloud hardware. Just as importantly,FailSafe is designed to
maintain this security posture over time. With little to no imposition on the
user,FailSafe automatically maintains the asset balance ratio between the hot
and cold wallet, subject to the user’s high level instructions. Access to cold
storage is safeguarded via a multi-signature contract, the corresponding
private keys are protected under a unique orchestration of Amazon’s Nitro
Enclaves and Google’s Confidential Compute with cloud hardware security
modules (HSM); it is designed to withstand insider threat/compromise (Figure 3
illustrates the overall architecture and described in more detail in the later
section below).

Defence 2: FailSafe Blockchain Reconnaissance: First contact with the
attacker:. As noted earlier, the attacker’s goal at this point is either to
directly learn the user’s private key, or convince the user to sign a
transaction of the attacker’s choice. A myriad of tried and tested social
engineering attacks are available, and just as in the Web2 world, even if
rejected by 99

At this stage, a FailSafe user is protected by several countermeasures. When
the user encounters the attacker’s dApp, if the user is using a client that is
directly integrated with FailSafe Blockchain Reconnaissance (FBR) service
(e.g., like a FailSafe Chrome extension or a proxy RPC URL), the attacker’s
request is likely to be rejected outright. The FBR maintains an up-to-date
database of black listed addresses; this includes sanctioned addresses,
fraudulent/rug-pull contracts. Risk profiles are also constructed based on
historical as well real time transaction driven behaviour anomalies/patterns.

Defence 3: FailSafe Interceptor Service: Fortune is on the attacker’s side
thus far: The victim proceeded without leveraging FBR, being lured into
sharing the seed phrase or signing a transaction of the attacker’s choice. At
this point all that remains is to submit the transaction so that its effect
will be reflected as part of the next block of the public ledger. The attacker
may choose to submit to any participating network node to be queued up with
other pending transactions in the public memory pool (the holding area used to
prioritise, and order proposed transactions for the next block on the ledger).

At this stage, the FailSafe Interceptor Service (FIS) is on standby. While
monitoring a low latency stream of ingress mempool transactions, FIS filters
for transactions thatFailSafe users partake in. Once detected the counterparty
address is passed to FBR. If a threat is detected, FIS attempts to make the
attacker’s transaction revert. It should be noted that FIS intervention may
also be triggered by transaction policy limits that are part of the
user’sFailSafe configuration (e.g., max value allowed to be transferred in a
given time period, etc.).

To intercept, FIS submits a new transaction into the pool that transfers the
assets in play to another address owned by the user (e.g., the cold wallet
address). Most importantly this new transaction will have a slightly higher
gas price than that being paid by the attacker, which results in being placed
ahead of the attacker’s transaction, in the execution order. When it comes
time to execute the attacker’s transaction, it will revert and not become part
of the ledger as the user will have an insufficient balance at that point. The
same principle applies to NFTs (ERC-721).

To improve the odds, the attacker may choose to pay a transaction fee premium
and bypass the global memory pool altogether through so-called “private
transactions.” These are aggregated in bulk via intermediaries and included by
miners in the next mined block) on the blockchain.

To close down this avenue to fraudsters and apply the above techniques, we are
exploring an “exceptions list” mechanism, where end-users will be able to add
their own web3 address to this list. Mempool service providers such as
BloxRoute would then filter out private transaction requests where the source
address is a member of this list.

Additionally, throughout the life-cycle of the transaction the user is alerted
with real-time push message notification and further advice on possible next
remediation steps.

Summary: Defences 1–3 provide the elements of defence-in-depth that the
FailSafe approach rests on.

Figure 4: Timeline and approach of qMig. Figure 5: Generating incognito
transfer intent. Figure 6: Verifying incognito transfer intent.

##  3 FailSafe Architecture

Figure 3 presents a high level view of the overall FailSafe system
architecture. Starting at the top, as part of the enrollment process, a
factory contract is used to deploy a dedicated user instance of the multi-
signature FailSafe contract. As illustrated in the figure, each operation
supported by the contract may require one or more independently controlled
keys for an authorization before a given operation is executed. For instance,
in the example illustrated in the figure, the withdrawal operation (from the
contract to the enrolled hot wallet key), requires three independent
signatures.

To call the FailSafe contract’s $\mathtt{{intercept}}$ and
$\mathtt{{rebalance}}$ methods, both the FailSafe Interceptor Service and
Assets Balancer Service use the dedicated enclave for signing, while access to
private keys are subject to the above restrictions. In the Multi-Sig FailSafe
contract these operations are configured to require a single signature since
the assets are being shifted between addresses under the user control, based
on a prior user consented to configuration. In contrast, an administrative
operation (e.g., updated ratio of hot/cold asset balances) or asset
withdrawal, requires multiple independently controlled key signatures. With
FailSafe, a user enrolls in the AWS Cognito Identity management system which
supports multi-factor authentication (MFA).

The user’s Cognito account ID is mapped to the user’s FailSafe Account.
Similar to the intercept and rebalance private keys, the private key
representing a given user’s authentication factor has a corresponding key
protected by Nitro Enclave/KMS (this is supported via Cognito identity
pool/lambda function authentication flow). To mitigate against worst-case
insider attacks, the user has another authentication factor enrolled and
protected by a secondary, independent cloud (GCP), which offers similar key
isolation and protection environment via Confidential Compute + KMS with
cryptographic attestation proofs.

Next, let’s consider how the keys for these operations are managed and
protected. As an example, let’s consider the intercept key which, as described
in the previous section, is required for moving funds from the user’s hot
wallet address to the user’s FailSafe contract in the event that a pending
fraudulent transaction is detected in the memory pool. As illustrated in
Figure 3, in the cloud, at rest the intercept key is only only preserved in an
encrypted form. It is encrypted under the data encryption key that resides in
the AWS KMS/Cloud HSM (hardware security module).

The FailSafe system leverages the AWS Nitro Enclave + KMS security
architecture. The request to decrypt the intercept key is fulfilled by KMS if
1) the request comes from the expected IAM identity; 2) the request is made
from the target Nitro enclave. AWS Nitro Enclave is a hardened, isolated
execution environment; cryptographic attestation is used to prove to KMS the
enclave’s identity and the code running in the enclave.

###  3.1 Forward Security in FailSafe

As part of the FailSafe project, the Quantum Migration Tool was developed to
address future platform level threats to the user’s web3 assets. This section
examines the threats stemming from quantum computing to EVM based blockchains.
We then present the design of the quantum migration tool and its role in the
overall architecture of the FailSafe system.

###  3.2 Quantum Threats to EVM-based Blockchains

Shor’s Algorithm [25] makes it possible for a sufficiently powerful quantum
computer to break the ECDSA algorithm. That is, starting from a transaction
signed with an ECDSA private key, one can extract the public key and then
derive the private key. This is the ultimate game over condition, as the
attacker can then transfer any balance associated with the external owned
account (EOA) at will.

In contrast, quantum computers pose no such (known) threat to hashing
algorithms. Grover’s algorithm [14] (aka quantum search algorithm), reduces
the search for collisions in Keccak-256 (Ethereum’s hash algorithm) from
$2^{2}56$ to $2^{1}28,$ which is less efficient than some generic collision
search algorithms. (A quick peek ahead: this hashing resilience to quantum
attacks will play a key role in our approach).

For the underlying cryptography, the National Institute of Standards and
Technology (NIST) initiated a standardisation effort for quantum resilient
signature schemes, and is currently evaluating a number of candidate schemes.
All of these come with their own set of trade-offs, particularly when compared
with key size, speed and re-use of the same key pair by the EVM family of
blockchains [27].

In terms of the threat timeline, (i.e, how long until quantum hardware is
capable of breaking ECDSA), estimates vary between experts. Many believe the
threat is still in the distant future (e.g., Vitalik was famously quoted
comparing quantum computing advances to going from hydrogen bombs to
harnessing nuclear fusion).

For a systematic approach, the Global Risk Institute conducts an annual survey
on the threat timeline of leading subject matter experts. According to its
2022 report, the “likelihood” estimates have been trending upwards from
initial surveys. Nearly 25% of respondents estimated a 50% chance for the
threat to materialise within a 10-year time window in light of recent advances
(i.e., Google’s Quantum Supremacy and IBM Quantum System One) and the nation
state competition (aka “quantum race”) with high levels of funding. The
inevitable question, much like the plight of global warming, is not a question
of “if” — it’s a question of “when.”

####  3.2.1 On ECDSA Key Re-use

Networks where the common pattern is to reuse the same key pair across
different transactions (like the EVM family of blockchains) face a greater
risk, once quantum attacks become feasible. The attacker has a longer time
window to derive the private key via the earlier record of transaction
signatures. However, using new ECDSA key pairs per-transaction, may only offer
some temporary relief; once quantum attacks become sufficiently fast, an
attacker could derive the private key and front-run a targeted transaction.

####  3.2.2 Account Abstraction as a Path to Sunseting ECDSA on Ethereum?

A future version of Ethereum is expected to support an account abstraction, a
unified representation of an account (rather than the two types that exist
today; a smart contract account, and an externally owned account (EOA) with a
corresponding ECDSA private key). The most recent account abstraction proposal
under consideration is EIP-4337 [4]. Among its features is a representation of
an account as a smart contract wallet with cryptographic agility for
submitting requests (referred to as $\mathtt{{UserOperations}}$) to the
wallet. $\mathtt{{UserOperations}}$ can be signed using a quantum safe
signature scheme. Under this proposal, after a network upgrade, the current
user base with quantum vulnerable EOAs “can individually upgrade their wallets
to quantum-safe ones,” as noted by Vitalik.

In the event of a quantum attack breakthrough, the user-dependent upgrade
strategy might mean a large number of unconverted accounts. Addresses with
prior transaction history would be at highest risk. On Ethereum, by design,
externally owned addresses are commonly re-used. Addresses with a prior
transaction history, the ECDSA public key can then be readily retrieved.

If the quantum attack breakthrough occurs while any significant portion of
EOAs haven’t been upgraded yet, any subsequent transactions signed with ECDSA
(including upgrade to quantum resilient wallet) would be suspect: is it the
attacker or the key rightful owner performing the operation? By comparison,
this dilemma is more severe than the Ethereum rollback debate after the 2016
DAO exploit [5] (which resulted in a hard fork, and two chains going forward,
Ethereum and Ethereum classic).

To address this problem, a path rooted in cryptographic based trust is needed
even when the algorithm authorising the majority of today’s transactions is
compromised (i.e., in a scenario where users need to migrate their web3 assets
to a forked version of the chain, where UserOperations only use quantum
resilient algorithms).

###  3.3 Quantum Migration Tool (qMig)

####  3.3.1 Assumptions and Goals

  * 1.

The quantum inflection point (quantum attack breakthrough) may occur when the
large majority of web3 assets and transactions are done on blockchains reliant
on ECDSA.

  * 2.

Web3 tokens (ERC-20, ERC-721, etc.) are only allowed to be bridged (e.g., via
LayerZero) to a quantum-resilient network, if and only if these assets have
not been hijacked via ECDSA compromise. That is, this transfer must be based
on a cryptographic scheme that remains secure even after the above quantum
inflection point occurs.

  * 3.

While users could reduce their own exposure to the attack by not reusing the
same address across transactions, it is not a prerequisite for using qMig.
qMig should prevent movement of stolen funds, while supporting EOAs with prior
transaction history.

####  3.3.2 The Workings of qMig

Step 1: The qMig approach is illustrated with a timeline shown in Figure 4.
The blue phase represents a time period when quantum attacks on ECDSA are
still not feasible. In this period, the qMig contract enables users to
construct and record a future intent to transfer tokens, in case the quantum
inflection point occurs and ECDSA signature by itself can not be trusted. The
security of this intent will be rooted in cryptography that is not susceptible
to quantum attacks. Figure 5 illustrates how this works. To call
qMig.$\mathtt{{registerTransferIntent()}}$, the client creates a transfer
intent source structure that includes source EOA ($\mathtt{{from}}$ field),
the chain ID for this EOA and its future destination counterpart. So for
example, the source address 0x1739…3c75, may own USDC (ERC-20 token) on chain
ID 1 (Ethereum mainnet). An updated bridge contract (e.g., LayerZero), will be
able to utilise this information, to verify that the destination address was
authorised by 0x1739…3c75, prior to the inflection point.

As shown in Figure 5, the client must sign the transfer intent source with the
ECDSA private key that corresponds to the EOA source address in the structure
(this linkage is verified at a later stage, if transfer is initiated in step
3).

The signed output is fed into Keccak-256 hash function, the resulting digest
is referred to as incognito transfer intent in the above figure. This digest
is stored in a hash table by $\mathtt{{registerTransferIntent()}}$ method
along with the corresponding block height (e.g., $\mathtt{{16316192}}$) ,
preserving a record on the blockchain of when the intent was registered.
Please note:

  * 1.

The hash of the signature rather than the signature itself is persisted so
that a public key of EOA can not be extracted. Moreover the wallet address
used to sign the request for calling $\mathtt{{registerTransferIntent()}}$ is
recommended to be different from the source EOA, to avoid leaving a record of
the ECDSA public key.

  * 2.

The Keccak-256 function is assumed to be resilient to finding collisions based
on quantum hardware.

  * 3.

After the inflection point, the recorded block height along with the hash over
the signature will serve as proof that source EOA authorised the transfer to
the target destination address and not the attacker’s address. The ledger
record shows that this was captured, prior to the quantum breakthrough when
the attacker could derive the ECDSA private key.

Step 2: ECDSA is compromised (the quantum inflection point of Figure 5). For
every token contract prepared for this scenario, its token administrator sets
the block height in the bridge contract, representing a point when quantum
computing attacks on ECDSA are effective. If this value is set, a new
authorization policy takes effect for all further transfer of assets over the
bridge to a quantum safe network. It is described in step 3. Note that the
bridge contract’s administrative functionality should be protected by a
secondary, quantum-resilient signature (e.g., CRYSTALS-Dilithium [9]).

Step 3: Represented as the red phase in Figure 5. In this phase, users can
transfer tokens to a quantum-resilient blockchain, subject to the following
restrictions, to avoid stolen funds from being transferred:

  * 1.

The destination address was authorised by the source address from step 1. That
is, at some point prior to the inflection point, the user needs to call
$\mathtt{{registerTransferIntent()}}$. The bridge contract can verify this by
calling the $\mathtt{{verifyTransferIntent()}}$ method exposed by the qMig
contract. To achieve this, the client will build and sign the transfer intent
source (shown in figure 6, and then will pass the raw signature (transfer
intent sig) in conjunction with the transfer request to the bridge contract.
The bridge contract calls $\mathtt{{verifyTransferIntent()}}$, passing the
source and destination info, the raw signature (transfer intent sig) as well
as the blockchain height value (the inflection point set in step 2).

$\mathtt{{verifyTransferIntent()}}$ performs verification through a process
shown in Figure 5. It uses the public key from the transfer intent sig to
cryptographically verify the signed data and confirm the signer’s address
matches the source address in the transfer intent source structure, thus
confirming that it was the source that authorised the destination address.
Next, is the look up to check that the qMig contract has a record of the
target intent. Just like in step 1, the transfer intent sig is passed to
Keccak-256, to compute the incognito transfer intent digest. This value is
then looked up in a hash table of all recorded transfer intents. If found, the
returned block height must be less than the block height passed in by the
bridge contract:

        Ψrequire (intentBlockHeight  < inflectionPointBlockHeight,
    ΨΨ’’Intent to transfer registered after the quantum inflection point!’’)

  * 2.

The next key requirement to address is that this mechanism must prevent any
potentially stolen assets (due to ECDSA compromise) from being bridged to the
quantum-safe blockchain. The source address in the transfer intent could have
funds obtained illicitly from others via ECDSA compromise, sometime after
quantum inflection point. To address this, the amount permitted to transfer
for a given source address is the balance at quantum inflection point (block
height set in step 2), subtract from the sum total of all withdraws since that
block number (up to the most recent block). The above can be augmented to
allow for transfers from addresses that were explicitly authorised by the
destination addresses to source address prior to the inflection point (using
the same mechanism).

###  3.4 Combining FailSafe and qMig

The qMig approach is a low friction means for users to prepare for accelerated
breakthroughs in quantum hardware based attacks. The user can continue to
conduct business on today’s networks, while setting up a path to migrate
assets to a quantum safe network if needed. The intent to transfer can be
implemented and recorded on a qMig contract on today’s chains. It is also
feasible to build out bridging support to an existing quantum ready network
like QVL in the near term. The same infrastructure is then applicable to
quantum safe versions of EVM networks once they become available.

Users enrolled into the FailSafe system are afforded the quantum threat
protections developed as part of the qMig tool. This is facilitated in two
steps. As part of wallet address enrollment in the user’s FailSafe contract
shown in Figure 3, a separate call is made by the client to register an
incognito transfer intent with the quantum migration proofs contract (as
described in the previous section). Secondly, as part of the enrollment
transaction, the user’s FailSafe contract calls the qMig contract, registering
an intent to transfer funds from the FailSafe contract to one or more user
wallet addresses registered with the contract.

After the quantum inflection point, during the bridging of assets to a quantum
resilient network, the qMig contract can then take into account any transfers
from the contract back to the wallet. To prevent fraudulent transfers due to
ECDSA cryptography compromise, recall that the amount permitted to transfer
for a given source address is the balance at quantum inflection point,
subtract from the sum total of all withdraws since that block number (up to
the most recent block) and adjusted for any other transfer intents to the
source address that were registered prior to the inflection point.

##  4 Related Work

###  4.1 Wallet Security

Below we describe some of the recent academic work focusing on wallet
security, although the reader is referred to industrial
reports111https://www.continuumloop.com/wp-content/uploads/2022/02/The-
Current-and-Future-State-of-Digital-
Wallets-v1.0-FINAL.pdf,222https://www.mdpi.com/2076-3417/12/21/11180/pdf,333https://go.sensortower.com/rs/351-RWH-315/images/state-
of-crypto-apps-in-europe-2022.pdf.

Karantias [17] provides the first definition of a cryptocurrency wallet, which
they model in a client-server paradigm. The authors categorize wallets based
on whether they work for transparent or private cryptocurrencies, what trust
assumptions they require, their performance and their communication overhead.
For each type of wallet the authors provide a description of its client and
server protocols. They explore superlight wallets and describe their
difference to superlight clients that have appeared in recent literature.The
paper demonstrates how new wallet protocols can be produced by combining
concepts from existing protocols. Finally, the paper evaluates the performance
and security characteristics of all wallet protocols and compare them.

By analyzing source code, bytecode, and execution traces, di Angelo et al.
[10] derive usage scenarios and patterns. The authors discuss methods for
identifying wallet contracts in a semi-automatic manner by looking at the
deployed bytecodes and the on-chain interaction patterns. The authors extract
blueprints for wallets and compile a ground truth. Furthermore, the paper
differentiates characteristics of wallets in use, and group them into several
types. The paper provides numbers and temporal perspectives regarding the
creation and use of wallets. For the 40 identified wallet blueprints, the
authors compile detailed profiles. The authors analyze the data of the
Ethereum main chain up to block 11,500,000, mined on December 22, 2020.

###  4.2 Usable Security for Blockchain Users

Issues related to usable security in the cryprocurrency space are not
particularly well understood, although some studies are starting to appear.

Specifically, Froehlich et al [11] provide a literature survey focusing on
usable privacy and security for cryptocurrency, although a lot of the focus
has been around user’s perceptions of privacy in light of anonymization that
can be accomplished through address clustering or more subtle attacks around
mixers and and privacy-friendly chains like Monero. We expect that new reports
will start to appear in the near future, focusing on end-user interactions,
for instance [16].

Mangipudi et al. [20] look at mental models around wallet usage. This work
presents a data-driven investigation into the perceptions of cryptocurrency
users towards multi-device wallets today, using a survey of 255 crypto-wallet
users. Their results revealed two significant groups of participants: Newbies
and Non-newbies. These two groups statistically significantly differ in their
usage of crypto-wallets. However, both of these groups were concerned with the
possibility of their keys getting compromised and yet are unfamiliar with the
guarantees offered by multi-device wallets. After educating the participants
about the more secure multi-device wallets, around 70% of the participants
preferred them; However, almost one-third of participants were still not
comfortable using them. The qualitative analysis revealed a gap between the
actual security guarantees and mental models for these participants: they were
afraid that using multi-device wallets will result in losing control over keys
(and in effect funds) due to the distribution of key shares. Moreover,
considerations about the threat model further affected their preferences,
signifying a need for contextualizing default settings.

Min et al. [21] attempt to portray DApp users through large-scale Ethereum
data, seeking to present an understanding of the data aspects of users in the
blockchain scenario beyond surveys and interviews.They built a series of
datasets labeled with DApp name and extracted information about each address
to enrich the data dimension. We then visualized and analyzed the user profile
dataset from several aspects and explored methodologies to divide user groups.
The authors propose a way to use the number of interactions by the categories
of DApp as cluster input and classify the addresses with SOM network. After
that, they separated active addresses into four groups according to the
purpose and frequency of use and discuss the differences between them and
their sensitivity to the market. In addition, the paper gives examples of how
to use transactional data. The authors combine the results of their analysis
with previous research studies to summarize the profile of DApp users and
examine user motivations, values, and the current DApp market.

Ghesmati et al. [12] focus on how well end-users understand privacy guarantees
in the blockchain space. They conducted a study on user perception and
preference on Bitcoin privacy, investigating different add-on privacy
techniques in Bitcoin as well as their implementation in practice. The authors
showed the difference between users’ preferences and the implementation of
privacy techniques in practice. Most users preferred privacy coins rather than
add-on techniques in Bitcoin. The results show that participants are more
likely to accept delays rather than extra fees to achieve anonymity in
Bitcoin. The participants also preferred indistinguishable privacy techniques
rather than being flagged by monitoring tools. Therefore, important questions
are raised as current privacy wallets offer CoinJoin transactions with equal-
sized output that are distinguishable in the blockchain. They show that users
who prefer better privacy are not likely to use Bitcoin, and they favor
embedding built-in privacy features in Bitcoin.

Korir et al. [18] focus on the prevalence of decentralized identify
approaches. There is a growing expectation that political and technical
initiatives towards digital identity will gather pace in the foreseeable
future. However, user perspectives have not been a driving force in shaping
those ongoing initiatives. The findings of this study point to the dominance
of paper/card-based identity methods for online identity verification and a
large gap between identity verification today and what it might be in the
foreseeable future. The results suggest that technical narratives might not be
a compelling driving force for future uptake and that, as previous work in
identity management has highlighted, the user proposition should receive
further thought. What seems most salient to drive adoption is the existence of
supporting (infra)structures, the appeal of the list of available verifiers,
and the low complexity of using a new identity wallet tool.

Mai et al. [19] explores user perceptions and misconceptions of cryptocurrency
users ($N$ = 29) enriched with drawing and card assignment tasks. Although the
study focused on Bitcoin and Ethereum, the findings can be further useful for
improving the security and privacy of a large body of (existing or future)
altcoins which also build on the blockchain technology. The paper points out
that flaws and inconsistencies in user mental models of cryptocurrency systems
expose users to security and privacy risks when using current cryptocurrency
tools. These risks include money loss, fraud, or deanonymization. Most
importantly, the paper revealed major misconceptions related to the
functionality and management of cryptographic keys which are not compensated
by the cryptocurrency tools. The findings explain why cryptocurrency users
fail to manage their private keys securely and, as a result, frequently fall
victim to money loss and fraud. Furthermore, users think that the blockchain
is encrypted or oblivious, which prevents them from taking measures to
safeguard their privacy. Another interesting result was that many participants
were not aware of the fact that the amount of mining fees can be actively
selected to influence the transaction speed. They proposed several concrete
enhancements to state-of-theart cryptocurrency tools (e.g., wallets or
exchanges) with the purpose of protecting users with misconceptions from
security and privacy threats. Among others, the paper suggests suggest
automation of key generation, management, and back-up as much as possible.
With this work, the authors create a foundation for improving the usability of
state-of-the-art cryptocurrency management tools to prevent security and
privacy breaches.

A recent report by Wang et. al.[26] highlights some of the common usage
practices around Web3 wallets and provides compelling motivation for FailSafe.
In this paper, the authors present the first in-depth study of quantifying the
risk of unlimited approval of ERC20 tokens on Ethereum. The study proposes a
fully-automatic approach to detect the approval transactions, and reveals the
high prevalence (60%) of unlimited approval in the ecosystem. The authors
conduct an investigation to reveal the security issues involved in interacting
with 31 UIs (22 DApps and 9 wallets) to send approval transactions.

The result shows that only a few UIs provide explanatory understandings (10%)
and flexibility (16%) for users to mitigate the risk of unlimited approval.
Furthermore, the paper performs a user behavior analysis to characterize five
modes of user behaviors and formalize the good practice to use approved
tokens. The result reveals that users (0.2% of user behaviors) barely follow
the good practice towards mitigating the risks of unlimited approval. Finally,
the paper discusses two existing solutions attempting to address the trade-off
between convenience and security of unlimited approval, and provide possible
suggestions.

###  4.3 Quantum-resistant Blockchains

Post-quantum cryptography (required for quantum resilient blockchains), is
being standardized by the National Institute of Standards and Technology
(NIST). The NIST standardization effort for quantum resilient signature
schemes, and is currently evaluating a number of candidate schemes (CRYSTALS-
Dilithium, FALCON & SPHINCS). All of these come with their own set of trade-
offs, particularly when compared with key size, speed, and re-use of the same
key pair by the EVM family of blockchains [27].

A future version of Ethereum is expected to support an account abstraction, a
unified representation of an account (rather than the two types that exist
today; a smart contract account, and an externally owned account (EOA) with a
corresponding ECDSA private key). The account abstraction model also aims to
provide cryptographic agility, which would allow for post quantum safe
signature algorithms.

  * 1.

The account abstraction architecture undergone several different iterations.
The first proposal dates back to 2016 with EIP-86 [1]. It was primarily
focused on converting all accounts into contracts, with a more flexible
security model than the current version of Ethereum (i.e., support for
multisig and a framework to specify alternative signature algorithms, beyond
ECDSA).

  * 2.

The next version of account abstraction was proposed in EIP-2938 [2]. Which
was in part motivated by gas efficiency and introduced new transaction types
and corresponding new opcodes. Next, EIP 3074 [3] proposed a mechanism by
which an externally owned account can delegate control to a smart contract,
enabling delegation of fees for block chain transactions.

  * 3.

The most recent account abstraction proposal under consideration is EIP-4337
[4]. Among its features is a representation of an account as a smart contract
wallet with cryptographic agility for submitting requests (referred to as
$\mathtt{{UserOperations}}$) to the wallet. $\mathtt{{UserOperations}}$ can be
signed using a quantum safe signature scheme. Under this proposal, after a
network upgrade, the current user base with quantum vulnerable EOAs “can
individually upgrade their wallets to quantum-safe ones,” as noted by Vitalik.

In the event of a quantum attack breakthrough, the user-dependent upgrade
strategy might mean a large number of unconverted accounts. Addresses with
prior transaction history would be at highest risk. On Ethereum, by design,
externally owned addresses are commonly re-used. Addresses with a prior
transaction history, the ECDSA public key can then be readily retrieved.

If the quantum attack breakthrough occurs while any significant portion of
EOAs haven’t been upgraded yet, any subsequent transactions signed with ECDSA
(including upgrade to quantum resilient wallet) would be suspect: is it the
attacker or the key rightful owner performing the operation? By comparison,
this dilemma is more severe than the Ethereum rollback debate after the 2016
DAO exploit [5] (which resulted in a hard fork, and two chains going forward,
Ethereum and Ethereum classic).

A notable effort to build an entirely new quantum resilient blockchain is
Quantum Resistant Ledger (QRL) [6], which uses XMSS [15] signatures. An
affiliated project, EnQlave, is a wallet implemented as an Ethereum smart
contract that uses a secondary signature (XMSS), resilient to quantum attacks;
the scheme relies on a Merkle tree of cryptographic hashes. The idea is to
transfer your tokens into this quantum resilient vault as a means to mitigate
future unexpected events (i.e., a successful quantum attack).

While this mechanism is useful to protect individual EOA, it does not deal
with the resulting fallout of such an attack: a loss of confidence in a system
rooted in cryptographic trust. Any further transaction signed with an ECDSA
key would be suspect. Business as usual on a network in this state would
likely cease. In case of such an event, there is a need for a mechanism that
can securely move assets that belong to their rightful owner (rather than the
attacker) to a quantum-resilient network.

##  5 Conclusions

FailSafe provides a set of safety and protection mechanisms that are built for
a user base that does not necessarily follow best security practices at all
times. FailSafe avoids over reliance on any single defence mechanism, if one
is bypassed, next one is inline to help minimise losses. This approach spans
across the entire lifecycle of a Web3 transaction, from de-risking Web 3 asset
positions (via auto-rebalancing asset to cold storage) to intercepting the
attacker’s transaction via the blockchain mempool, if all other defences
failed.

Similarly, with FailSafe ’s forward-security, the risk to the user’s Web 3
assets are reduced even if the underlying cryptographic based trust is
compromised.

## References

  * [1] Abstraction of transaction origin and signature.  https://github.com/ethereum/EIPs/blob/master/EIPS/eip-86.md.
  * [2] Account abstraction.  https://eips.ethereum.org/EIPS/eip-2938.
  * [3] EIP-3074: Auth and authcall opcodes.  https://eips.ethereum.org/EIPS/eip-3074.
  * [4] ERC-4337: Account abstraction using alt mempool.  https://eips.ethereum.org/EIPS/eip-4337.
  * [5] Ethereum Classic (ETC) Definition, History, Future.  https://www.investopedia.com/terms/e/ethereum-classic.asp.
  * [6] QRL: The quantum resistant ledger.  https://www.theqrl.org/.
  * [7] IBM quantum computing, systems technology.  https://www.ibm.com/quantum/systems, 10 2015.
  * [8] Frank Arute, Kunal Arya, and et. al.  Quantum supremacy using a programmable superconducting processor.  Nature, 574, 2019.
  * [9] Information Technology Laboratory Computer Security Division.  Announcing PQC Candidates to be Standardized, Plus Fourth Round Candidates, CSRC.  https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4, March 2022.
  * [10] Monika di Angelo and Gernot Salzer.  Characteristics of wallet contracts on Ethereum.  2020\.
  * [11] Michael Froehlich, Franz Waltenberger, Ludwig Trotter, Florian Alt, and Albrecht Schmidt.  Blockchain and cryptocurrency in human computer interaction: A systematic literature review and research agenda.  In Designing Interactive Systems Conference. ACM, June 2022.
  * [12] Simin Ghesmati, Walid Fdhila, and Edgar R. Weippl.  User-perceived privacy in blockchain.  IACR Cryptol. ePrint Arch., 2022, 2022.
  * [13] Amber Group.  Exploiting the profanity flaw.  https://medium.com/amber-group/exploiting-the-profanity-flaw-e986576de7ab, 09 2022.
  * [14] Lov K. Grover.  A fast quantum mechanical algorithm for database search.  In Proceedings of the Annual ACM symposium on Theory of Computing, 1996.
  * [15] Aneas Huelsing, Denis Butin, Stefan-Lukas Gazdag, Joost Rijneveld, and Aziz Mohaisen.  XMSS: eXtended Merkle Signature Scheme.  Request for Comments RFC 8391, Internet Engineering Task Force, May 2018\.
  * [16] Feng Jin, Jingwei Li, and Yi Xue.  Preferring stablecoin over dollar: Evidence from a survey of Ethereum platform traders.  Journal of International Money and Finance, 131, 2023.
  * [17] Kostis Karantias.  SoK: A taxonomy of cryptocurrency wallets.  Cryptology ePrint Archive, 2020.
  * [18] Maina Korir, Simon Parkin, and Paul Dunphy.  An empirical study of a decentralized identity wallet: Usability, security, and perspectives on user control.  In Symposium on Usable Privacy and Security (SOUPS), August 2022\.
  * [19] Alexandra Mai, Katharina Pfeffer, Matthias Gusenbauer, Edgar Weippl, and Katharina Krombholz.  User mental models of cryptocurrency systems - a grounded theory approach.  In Symposium on Usable Privacy and Security (SOUPS 2020). USENIX Association, August 2020.
  * [20] Easwar Vivek Mangipudi, Udit Desai, Mohsen Minaei, Mainack Mondal, and Aniket Kate.  Uncovering impact of mental models towards adoption of multi-device crypto-wallets.  Cryptology ePrint Archive, 2022.
  * [21] Tian Min and Wei Cai.  Portrait of decentralized application users: an overview based on large-scale ethereum data.  CCF Transactions on Pervasive Computing and Interaction, 4(2), 2022\.
  * [22] Mohammad Mirza, Akif Ozer, and Umit Karabiyik.  Mobile cyber forensic investigations of web3 wallets on Android and iOS.  Applied Sciences, 12, 11 2022.
  * [23] Michele Mosca and Marco Piani.  2022 quantum threat timeline report.  https://globalriskinstitute.org/publication/2022-quantum-threat-timeline-report/.
  * [24] Kelly Sheridan.  Users have risky security habits, but security pros aren’t much better.  https://www.darkreading.com/operations/users-have-risky-security-habits-but-security-pros-aren-t-much-better, 02 2020.
  * [25] Peter W. Shor.  Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer.  SIAM Journal on Computing, 26(5), October 1997.
  * [26] Dabao Wang, Hang Feng, Siwei Wu, Yajin Zhou, Lei Wu, and Xingliang Yuan.  Penny wise and pound foolish: Quantifying the risk of unlimited approval of ERC20 tokens on ethereum.  In 25th International Symposium on Research in Attacks, Intrusions and Defenses, RAID, 2022.
  * [27] Bas Westerbaan.  NIST’s pleasant post-quantum surprise.  http://blog.cloudflare.com/nist-post-quantum-surprise/, July 2022\.
  * [28] Jiashuo Zhang, Jianbo Gao, Yue Li, Ziming Chen, Zhi Guan, and Zhong Chen.  Xscope: Hunting for cross-chain bridge attacks.  https://arxiv.org/abs/2208.07119, 2022.