diff --git a/docs/common-patterns.rst b/docs/common-patterns.rst
index 766f8f35e..a76f61c18 100644
--- a/docs/common-patterns.rst
+++ b/docs/common-patterns.rst
@@ -55,7 +55,7 @@ you receive the funds of the person who is now the richest.
         function withdraw() public {
             uint amount = pendingWithdrawals[msg.sender];
             // Remember to zero the pending refund before
-            // sending to prevent re-entrancy attacks
+            // sending to prevent reentrancy attacks
             pendingWithdrawals[msg.sender] = 0;
             payable(msg.sender).transfer(amount);
         }
diff --git a/docs/security-considerations.rst b/docs/security-considerations.rst
index 0a86a8d59..4b524cbbd 100644
--- a/docs/security-considerations.rst
+++ b/docs/security-considerations.rst
@@ -47,7 +47,7 @@ local variables and state variables marked ``private``.
 Using random numbers in smart contracts is quite tricky if you do not want
 block builders to be able to cheat.
 
-Re-Entrancy
+Reentrancy
 ===========
 
 Any interaction from a contract (A) with another contract (B) and any transfer
@@ -97,7 +97,7 @@ as it uses ``call`` which forwards all remaining gas by default:
         }
     }
 
-To avoid re-entrancy, you can use the Checks-Effects-Interactions pattern as
+To avoid reentrancy, you can use the Checks-Effects-Interactions pattern as
 demonstrated below:
 
 .. code-block:: solidity
@@ -119,11 +119,11 @@ demonstrated below:
 The Checks-Effects-Interactions pattern ensures that all code paths through a contract complete all required checks
 of the supplied parameters before modifying the contract's state (Checks); only then it makes any changes to the state (Effects);
 it may make calls to functions in other contracts *after* all planned state changes have been written to
-storage (Interactions). This is a common foolproof way to prevent *re-entrancy attacks*, where an externally called
+storage (Interactions). This is a common foolproof way to prevent *reentrancy attacks*, where an externally called
 malicious contract is able to double-spend an allowance, double-withdraw a balance, among other things, by using logic that calls back into the
 original contract before it has finalized its transaction.
 
-Note that re-entrancy is not only an effect of Ether transfer but of any
+Note that reentrancy is not only an effect of Ether transfer but of any
 function call on another contract. Furthermore, you also have to take
 multi-contract situations into account. A called contract could modify the
 state of another contract you depend on.
@@ -429,7 +429,7 @@ should be the very last step in any function.
 
 Early contracts delayed some effects and waited for external function
 calls to return in a non-error state. This is often a serious mistake
-because of the re-entrancy problem explained above.
+because of the reentrancy problem explained above.
 
 Note that, also, calls to known contracts might in turn cause calls to
 unknown contracts, so it is probably better to just always apply this pattern.