diff --git a/incentivization.md b/incentivization.md
index 6d583d3..3cff8be 100644
--- a/incentivization.md
+++ b/incentivization.md
@@ -71,14 +71,14 @@ See also: https://rfc.vac.dev/spec/17/
 
 In the i13n context, we can't prove whether a message has indeed been broadcast in the past.
 Instead, we use RLN proofs as a proxy metric.
-A valid RLN proof signifies that the message has been generated by a node with an active membership during a particular eposh.
+A valid RLN proof signifies that the message has been generated by a node with an active membership during a particular epoch.
 TODO: make sure the above is correct: what exactly does RLN prove?
 
 ## Deviations from the desired behavior
 
 There are multiple ways for a node to deviate from the desired behavior.
-TODO: are we talking only about the server here, or should also discuss client (e.g., DoS)?
-### Slow response
+We look at potential misbehavior from the server side and from the client side separately.
+### Server: Slow response
 The server takes too long to respond.
 Possible reasons:
 - the server is offline accidentally;
@@ -86,7 +86,7 @@ Possible reasons:
 - the server is malicious and deliberately delays the response;
 - the server doesn't have some of the relevant messages and tries to request them from other nodes.
 
-### Incomplete response
+### Server: Incomplete response
 A relevant message is missing from the response.
 Possible explanations:
 - the server didn't receive the message when it was broadcast;
@@ -96,15 +96,25 @@ Contrary to blockchains, Relay doesn't have consensus over relayed messages.
 Therefore, it's impossible to distinguish between the two scenarios above.
 TODO: given this fact, what's the best we can aim for?
 
-### Irrelevant response
+### Server: Irrelevant response
 The response contains a message that is not relevant.
 There are two scenarios here depending on whether RLN proofs are enforced.
 If RLN is not enforced, a server may insert any number or irrelevant messages into the response.
 If RLN is enforced, a server can only do so as long as it has a valid membership to generate the respective proofs.
-This doesn't eliminate the attackbut limits its consequences.
+This doesn't eliminate the attack but limits its consequences.
 
 TODO: what are the powers of a malicious server when it comes to generating proofs for irrelevant messages? Can the server generate proofs for past epochs?
 
+### Client: Too many requests
+The client sends many request to the server within a short period of time.
+This may be seen as a DoS attack.
+
+### Client: Request is too large
+The client sends a response that incurs excessive expenses on the server.
+For example, the request covers a very long period in history, or, more generically,
+a period that contains many messages.
+This may also be seen as a DoS attack.
+
 ## Privacy considerations
 
 Light protocols, in general, have weaker privacy properties than P2P protocols.