Docs fix spelling issues

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
 

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`

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.

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.