diff --git a/SemSEpaper/exercises.pdf b/SemSEpaper/exercises.pdf
index 0d5eac0..1acc309 100644
Binary files a/SemSEpaper/exercises.pdf and b/SemSEpaper/exercises.pdf differ
diff --git a/SemSEpaper/exercises.tex b/SemSEpaper/exercises.tex
index 4220649..12145c2 100644
--- a/SemSEpaper/exercises.tex
+++ b/SemSEpaper/exercises.tex
@@ -215,8 +215,14 @@ The contract has a manager mapping, which should be used as a stack.
 The developer has added the \texttt{setNextManager} function, which should set the top of the stack to the latest user as a manager.
 The issue is that the function is implemented in such a way, that the stack would not grow, but the first element would always be overwritten - this arises from the fact that the memory slot
 of the managers mapping does not point to the memory address on the top of the stack, but instead to the base of it.
-The function is then using this slot address directly, without calculating any offset, overwriting the base of the stack.
+The function is then using this slot address directly, without calculating any offset, overwriting the base of the stack. If social engineeering is applied, an attacker can persuade the
+owner to set them as a manager, which would result in the weakness being exploited directly and the owner giving up their own management rights.
+\subsection{Consequences}
 
+The consequences of exploiting an arbitrary storage access weakness can be of different types and severity.
+An attacker may gain read-write access to private contract data, which should only be accessible to owners, maintainers etc.
+They may also exploit the contract to circumvent authorization checks and drain the contract funds.
+%TODO: can we expand this?
 
 \section{Vulnerable contracts in literature}