diff --git a/README.md b/README.md
index 4799b6376..28b509711 100644
--- a/README.md
+++ b/README.md
@@ -100,7 +100,7 @@ OpenZeppelin Contracts is made available under the MIT License, which disclaims
 
 ## Contribute
 
-OpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high quality software. Check out the [contribution guide](CONTRIBUTING.md)!
+OpenZeppelin Contracts exists thanks to its contributors. There are many ways you can participate and help build high-quality software. Check out the [contribution guide](CONTRIBUTING.md)!
 
 ## License
 
diff --git a/contracts/metatx/ERC2771ContextUpgradeable.sol b/contracts/metatx/ERC2771ContextUpgradeable.sol
index 7c8b6792c..c16fac131 100644
--- a/contracts/metatx/ERC2771ContextUpgradeable.sol
+++ b/contracts/metatx/ERC2771ContextUpgradeable.sol
@@ -9,7 +9,7 @@ import {Initializable} from "../proxy/utils/Initializable.sol";
 /**
  * @dev Context variant with ERC-2771 support.
  *
- * WARNING: Avoid using this pattern in contracts that rely in a specific calldata length as they'll
+ * WARNING: Avoid using this pattern in contracts that rely on a specific calldata length as they'll
  * be affected by any forwarder whose `msg.data` is suffixed with the `from` address according to the ERC-2771
  * specification adding the address size in bytes (20) to the calldata size. An example of an unexpected
  * behavior could be an unintended fallback (or another function) invocation while trying to invoke the `receive`
diff --git a/contracts/metatx/ERC2771ForwarderUpgradeable.sol b/contracts/metatx/ERC2771ForwarderUpgradeable.sol
index ee84f818b..be31b4613 100644
--- a/contracts/metatx/ERC2771ForwarderUpgradeable.sol
+++ b/contracts/metatx/ERC2771ForwarderUpgradeable.sol
@@ -252,7 +252,7 @@ contract ERC2771ForwarderUpgradeable is Initializable, EIP712Upgradeable, Nonces
      *
      * Requirements:
      *
-     * - The caller must have provided enough gas to forward with the call.
+     * - The caller must have provided enough gas to proceed with the call.
      * - The request must be valid (see {verify}) if the `requireValidRequest` is true.
      *
      * Emits an {ExecutedForwardRequest} event.
diff --git a/contracts/proxy/README.adoc b/contracts/proxy/README.adoc
index 1c4d0105c..3165fe0f6 100644
--- a/contracts/proxy/README.adoc
+++ b/contracts/proxy/README.adoc
@@ -19,12 +19,12 @@ There are two alternative ways to add upgradeability to an ERC-1967 proxy. Their
 - {TransparentUpgradeableProxy}: A proxy with a built-in immutable admin and upgrade interface.
 - {UUPSUpgradeable}: An upgradeability mechanism to be included in the implementation contract.
 
-CAUTION: Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM. Unless you want a lot of low level control, we recommend using the xref:upgrades-plugins::index.adoc[OpenZeppelin Upgrades Plugins] for Hardhat and Foundry.
+CAUTION: Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM. Unless you want a lot of low-level control, we recommend using the xref:upgrades-plugins::index.adoc[OpenZeppelin Upgrades Plugins] for Hardhat and Foundry.
 
-A different family of proxies are beacon proxies. This pattern, popularized by Dharma, allows multiple proxies to be upgraded to a different implementation in a single transaction.
+A different family of proxies is beacon proxies. This pattern, popularized by Dharma, allows multiple proxies to be upgraded to a different implementation in a single transaction.
 
 - {BeaconProxy}: A proxy that retrieves its implementation from a beacon contract.
-- {UpgradeableBeacon}: A beacon contract with a built in admin that can upgrade the {BeaconProxy} pointing to it.
+- {UpgradeableBeacon}: A beacon contract with a built-in admin that can upgrade the {BeaconProxy} pointing to it.
 
 In this pattern, the proxy contract doesn't hold the implementation address in storage like an ERC-1967 proxy. Instead, the address is stored in a separate beacon contract. The `upgrade` operations are sent to the beacon instead of to the proxy contract, and all proxies that follow that beacon are automatically upgraded.