diff --git a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md
index 8800d8a835..5d2519cab2 100644
--- a/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md
+++ b/docs/docs/adrs/adr-005-cryptographic-equivocation-verification.md
@@ -32,7 +32,7 @@ from the last trusted header validators. The latter is the default method, as it
 Additionally, light clients are cross-checking new headers obtained from a primary with witnesses to ensure all nodes share the same state.
 
 A light client attack occurs when a Byzantine validator sends invalid headers to a light client.
-As the light client doesn't execute transactions, it can be deceived into trusting corrupted application states.
+As the light client doesn't execute transactions, it can be deceived into trusting corrupted application state transitions.
 For instance, if a light client receives header A from the primary and header `B` from the witness for the same block height `H`,
 and both headers are successfully verified, it indicates a light client attack.
 Note that it this case, either the primary and/or witness nodes are malicious.