Use ERC-XXX syntax (#4730)

Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
Co-authored-by: ernestognw <ernestognw@gmail.com>

GUIDELINES.md

@@ -115,7 +115,7 @@ In addition to the official Solidity Style Guide we have a number of other conve
   }
   ```
 
-  Some standards (e.g. ERC20) use present tense, and in those cases the
+  Some standards (e.g. ERC-20) use present tense, and in those cases the
   standard specification is used.
   
 * Interface names should have a capital I prefix.

certora/specs/ERC20FlashMint.spec

@@ -4,7 +4,7 @@ import "methods/IERC3156FlashLender.spec";
 import "methods/IERC3156FlashBorrower.spec";
 
 methods {
-    // non standard ERC3156 functions
+    // non standard ERC-3156 functions
     function flashFeeReceiver() external returns (address) envfree;
 
     // function summaries below

contracts/access/IAccessControl.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev External interface of AccessControl declared to support ERC165 detection.
+ * @dev External interface of AccessControl declared to support ERC-165 detection.
  */
 interface IAccessControl {
     /**

contracts/access/extensions/IAccessControlDefaultAdminRules.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IAccessControl} from "../IAccessControl.sol";
 
 /**
- * @dev External interface of AccessControlDefaultAdminRules declared to support ERC165 detection.
+ * @dev External interface of AccessControlDefaultAdminRules declared to support ERC-165 detection.
  */
 interface IAccessControlDefaultAdminRules is IAccessControl {
     /**

contracts/access/extensions/IAccessControlEnumerable.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IAccessControl} from "../IAccessControl.sol";
 
 /**
- * @dev External interface of AccessControlEnumerable declared to support ERC165 detection.
+ * @dev External interface of AccessControlEnumerable declared to support ERC-165 detection.
  */
 interface IAccessControlEnumerable is IAccessControl {
     /**

contracts/finance/README.adoc

@@ -5,7 +5,7 @@ NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/
 
 This directory includes primitives for financial systems:
 
-- {VestingWallet} handles the vesting of Ether and ERC20 tokens for a given beneficiary. Custody of multiple tokens can
+- {VestingWallet} handles the vesting of Ether and ERC-20 tokens for a given beneficiary. Custody of multiple tokens can
   be given to this contract, which will release the token to the beneficiary following a given, customizable, vesting
   schedule.
 

contracts/finance/VestingWallet.sol

@@ -9,7 +9,7 @@ import {Context} from "../utils/Context.sol";
 import {Ownable} from "../access/Ownable.sol";
 
 /**
- * @dev A vesting wallet is an ownable contract that can receive native currency and ERC20 tokens, and release these
+ * @dev A vesting wallet is an ownable contract that can receive native currency and ERC-20 tokens, and release these
  * assets to the wallet owner, also referred to as "beneficiary", according to a vesting schedule.
  *
  * Any assets transferred to this contract will follow the vesting schedule as if they were locked from the beginning.
@@ -94,7 +94,7 @@ contract VestingWallet is Context, Ownable {
 
     /**
      * @dev Getter for the amount of releasable `token` tokens. `token` should be the address of an
-     * IERC20 contract.
+     * {IERC20} contract.
      */
     function releasable(address token) public view virtual returns (uint256) {
         return vestedAmount(token, uint64(block.timestamp)) - released(token);

contracts/governance/IGovernor.sol

@@ -158,13 +158,13 @@ interface IGovernor is IERC165, IERC6372 {
 
     /**
      * @notice module:core
-     * @dev Name of the governor instance (used in building the ERC712 domain separator).
+     * @dev Name of the governor instance (used in building the EIP-712 domain separator).
      */
     function name() external view returns (string memory);
 
     /**
      * @notice module:core
-     * @dev Version of the governor instance (used in building the ERC712 domain separator). Default: "1"
+     * @dev Version of the governor instance (used in building the EIP-712 domain separator). Default: "1"
      */
     function version() external view returns (string memory);
 
@@ -254,7 +254,7 @@ interface IGovernor is IERC165, IERC6372 {
     /**
      * @notice module:user-config
      * @dev Delay, between the proposal is created and the vote starts. The unit this duration is expressed in depends
-     * on the clock (see EIP-6372) this contract uses.
+     * on the clock (see ERC-6372) this contract uses.
      *
      * This can be increased to leave time for users to buy voting power, or delegate it, before the voting of a
      * proposal starts.
@@ -267,7 +267,7 @@ interface IGovernor is IERC165, IERC6372 {
     /**
      * @notice module:user-config
      * @dev Delay between the vote start and vote end. The unit this duration is expressed in depends on the clock
-     * (see EIP-6372) this contract uses.
+     * (see ERC-6372) this contract uses.
      *
      * NOTE: The {votingDelay} can delay the start of the vote. This must be considered when setting the voting
      * duration compared to the voting delay.

contracts/governance/README.adoc

@@ -44,9 +44,9 @@ Other extensions can customize the behavior or interface in multiple ways.
 
 In addition to modules and extensions, the core contract requires a few virtual functions to be implemented to your particular specifications:
 
-* <<Governor-votingDelay-,`votingDelay()`>>: Delay (in EIP-6372 clock) since the proposal is submitted until voting power is fixed and voting starts. This can be used to enforce a delay after a proposal is published for users to buy tokens, or delegate their votes.
-* <<Governor-votingPeriod-,`votingPeriod()`>>: Delay (in EIP-6372 clock) since the proposal starts until voting ends.
-* <<Governor-quorum-uint256-,`quorum(uint256 timepoint)`>>: Quorum required for a proposal to be successful. This function includes a `timepoint` argument (see EIP-6372) so the quorum can adapt through time, for example, to follow a token's `totalSupply`.
+* <<Governor-votingDelay-,`votingDelay()`>>: Delay (in ERC-6372 clock) since the proposal is submitted until voting power is fixed and voting starts. This can be used to enforce a delay after a proposal is published for users to buy tokens, or delegate their votes.
+* <<Governor-votingPeriod-,`votingPeriod()`>>: Delay (in ERC-6372 clock) since the proposal starts until voting ends.
+* <<Governor-quorum-uint256-,`quorum(uint256 timepoint)`>>: Quorum required for a proposal to be successful. This function includes a `timepoint` argument (see ERC-6372) so the quorum can adapt through time, for example, to follow a token's `totalSupply`.
 
 NOTE: Functions of the `Governor` contract do not include access control. If you want to restrict access, you should add these checks by overloading the particular functions. Among these, {Governor-_cancel} is internal by default, and you will have to expose it (with the right access control mechanism) yourself if this function is needed.
 

contracts/governance/extensions/GovernorVotes.sol

@@ -28,8 +28,8 @@ abstract contract GovernorVotes is Governor {
     }
 
     /**
-     * @dev Clock (as specified in EIP-6372) is set to match the token's clock. Fallback to block numbers if the token
-     * does not implement EIP-6372.
+     * @dev Clock (as specified in ERC-6372) is set to match the token's clock. Fallback to block numbers if the token
+     * does not implement ERC-6372.
      */
     function clock() public view virtual override returns (uint48) {
         try token().clock() returns (uint48 timepoint) {
@@ -40,7 +40,7 @@ abstract contract GovernorVotes is Governor {
     }
 
     /**
-     * @dev Machine-readable description of the clock as specified in EIP-6372.
+     * @dev Machine-readable description of the clock as specified in ERC-6372.
      */
     // solhint-disable-next-line func-name-mixedcase
     function CLOCK_MODE() public view virtual override returns (string memory) {

contracts/governance/utils/Votes.sol

@@ -60,7 +60,7 @@ abstract contract Votes is Context, EIP712, Nonces, IERC5805 {
     }
 
     /**
-     * @dev Machine-readable description of the clock as specified in EIP-6372.
+     * @dev Machine-readable description of the clock as specified in ERC-6372.
      */
     // solhint-disable-next-line func-name-mixedcase
     function CLOCK_MODE() public view virtual returns (string memory) {

contracts/interfaces/IERC1271.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC1271 standard signature validation method for
+ * @dev Interface of the ERC-1271 standard signature validation method for
  * contracts as defined in https://eips.ethereum.org/EIPS/eip-1271[ERC-1271].
  */
 interface IERC1271 {

contracts/interfaces/IERC1363.sol

@@ -7,10 +7,10 @@ import {IERC20} from "./IERC20.sol";
 import {IERC165} from "./IERC165.sol";
 
 /**
- * @dev Interface of an ERC1363 compliant contract, as defined in the
- * https://eips.ethereum.org/EIPS/eip-1363[EIP].
+ * @dev Interface of an ERC-1363 compliant contract, as defined in the
+ * https://eips.ethereum.org/EIPS/eip-1363[ERC].
  *
- * Defines a interface for ERC20 tokens that supports executing recipient
+ * Defines a interface for ERC-20 tokens that supports executing recipient
  * code after `transfer` or `transferFrom`, or spender code after `approve`.
  */
 interface IERC1363 is IERC165, IERC20 {

contracts/interfaces/IERC1363Receiver.sol

@@ -14,8 +14,8 @@ interface IERC1363Receiver {
      */
 
     /**
-     * @notice Handle the receipt of ERC1363 tokens
-     * @dev Any ERC1363 smart contract calls this function on the recipient
+     * @notice Handle the receipt of ERC-1363 tokens
+     * @dev Any ERC-1363 smart contract calls this function on the recipient
      * after a `transfer` or a `transferFrom`. This function MAY throw to revert and reject the
      * transfer. Return of other than the magic value MUST result in the
      * transaction being reverted.

contracts/interfaces/IERC1363Spender.sol

@@ -14,8 +14,8 @@ interface IERC1363Spender {
      */
 
     /**
-     * @notice Handle the approval of ERC1363 tokens
-     * @dev Any ERC1363 smart contract calls this function on the recipient
+     * @notice Handle the approval of ERC-1363 tokens
+     * @dev Any ERC-1363 smart contract calls this function on the recipient
      * after an `approve`. This function MAY throw to revert and reject the
      * approval. Return of other than the magic value MUST result in the
      * transaction being reverted.

contracts/interfaces/IERC1820Implementer.sol

@@ -4,8 +4,8 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface for an ERC1820 implementer, as defined in the
- * https://eips.ethereum.org/EIPS/eip-1820#interface-implementation-erc1820implementerinterface[EIP].
+ * @dev Interface for an ERC-1820 implementer, as defined in the
+ * https://eips.ethereum.org/EIPS/eip-1820#interface-implementation-erc1820implementerinterface[ERC].
  * Used by contracts that will be registered as implementers in the
  * {IERC1820Registry}.
  */

contracts/interfaces/IERC1820Registry.sol

@@ -4,8 +4,8 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the global ERC1820 Registry, as defined in the
- * https://eips.ethereum.org/EIPS/eip-1820[EIP]. Accounts may register
+ * @dev Interface of the global ERC-1820 Registry, as defined in the
+ * https://eips.ethereum.org/EIPS/eip-1820[ERC]. Accounts may register
  * implementers for interfaces in this registry, as well as query support.
  *
  * Implementers may be shared by multiple accounts, and can also implement more
@@ -15,7 +15,7 @@ pragma solidity ^0.8.20;
  *
  * {IERC165} interfaces can also be queried via the registry.
  *
- * For an in-depth explanation and source code analysis, see the EIP text.
+ * For an in-depth explanation and source code analysis, see the ERC text.
  */
 interface IERC1820Registry {
     event InterfaceImplementerSet(address indexed account, bytes32 indexed interfaceHash, address indexed implementer);
@@ -80,32 +80,32 @@ interface IERC1820Registry {
     /**
      * @dev Returns the interface hash for an `interfaceName`, as defined in the
      * corresponding
-     * https://eips.ethereum.org/EIPS/eip-1820#interface-name[section of the EIP].
+     * https://eips.ethereum.org/EIPS/eip-1820#interface-name[section of the ERC].
      */
     function interfaceHash(string calldata interfaceName) external pure returns (bytes32);
 
     /**
-     * @notice Updates the cache with whether the contract implements an ERC165 interface or not.
+     * @notice Updates the cache with whether the contract implements an ERC-165 interface or not.
      * @param account Address of the contract for which to update the cache.
-     * @param interfaceId ERC165 interface for which to update the cache.
+     * @param interfaceId ERC-165 interface for which to update the cache.
      */
     function updateERC165Cache(address account, bytes4 interfaceId) external;
 
     /**
-     * @notice Checks whether a contract implements an ERC165 interface or not.
+     * @notice Checks whether a contract implements an ERC-165 interface or not.
      * If the result is not cached a direct lookup on the contract address is performed.
      * If the result is not cached or the cached value is out-of-date, the cache MUST be updated manually by calling
      * {updateERC165Cache} with the contract address.
      * @param account Address of the contract to check.
-     * @param interfaceId ERC165 interface to check.
+     * @param interfaceId ERC-165 interface to check.
      * @return True if `account` implements `interfaceId`, false otherwise.
      */
     function implementsERC165Interface(address account, bytes4 interfaceId) external view returns (bool);
 
     /**
-     * @notice Checks whether a contract implements an ERC165 interface or not without using or updating the cache.
+     * @notice Checks whether a contract implements an ERC-165 interface or not without using or updating the cache.
      * @param account Address of the contract to check.
-     * @param interfaceId ERC165 interface to check.
+     * @param interfaceId ERC-165 interface to check.
      * @return True if `account` implements `interfaceId`, false otherwise.
      */
     function implementsERC165InterfaceNoCache(address account, bytes4 interfaceId) external view returns (bool);

contracts/interfaces/IERC3156FlashBorrower.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC3156 FlashBorrower, as defined in
+ * @dev Interface of the ERC-3156 FlashBorrower, as defined in
  * https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].
  */
 interface IERC3156FlashBorrower {

contracts/interfaces/IERC3156FlashLender.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IERC3156FlashBorrower} from "./IERC3156FlashBorrower.sol";
 
 /**
- * @dev Interface of the ERC3156 FlashLender, as defined in
+ * @dev Interface of the ERC-3156 FlashLender, as defined in
  * https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].
  */
 interface IERC3156FlashLender {

contracts/interfaces/IERC4626.sol

@@ -7,7 +7,7 @@ import {IERC20} from "../token/ERC20/IERC20.sol";
 import {IERC20Metadata} from "../token/ERC20/extensions/IERC20Metadata.sol";
 
 /**
- * @dev Interface of the ERC4626 "Tokenized Vault Standard", as defined in
+ * @dev Interface of the ERC-4626 "Tokenized Vault Standard", as defined in
  * https://eips.ethereum.org/EIPS/eip-4626[ERC-4626].
  */
 interface IERC4626 is IERC20, IERC20Metadata {

contracts/interfaces/IERC4906.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IERC165} from "./IERC165.sol";
 import {IERC721} from "./IERC721.sol";
 
-/// @title EIP-721 Metadata Update Extension
+/// @title ERC-721 Metadata Update Extension
 interface IERC4906 is IERC165, IERC721 {
     /// @dev This event emits when the metadata of a token is changed.
     /// So that the third-party platforms such as NFT market could

contracts/interfaces/IERC777.sol

@@ -4,10 +4,10 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC777Token standard as defined in the EIP.
+ * @dev Interface of the ERC-777 Token standard as defined in the ERC.
  *
  * This contract uses the
- * https://eips.ethereum.org/EIPS/eip-1820[ERC1820 registry standard] to let
+ * https://eips.ethereum.org/EIPS/eip-1820[ERC-1820 registry standard] to let
  * token holders and recipients react to token movements by using setting implementers
  * for the associated interfaces in said registry. See {IERC1820Registry} and
  * {IERC1820Implementer}.

contracts/interfaces/IERC777Recipient.sol

@@ -4,12 +4,12 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC777TokensRecipient standard as defined in the EIP.
+ * @dev Interface of the ERC-777 Tokens Recipient standard as defined in the ERC.
  *
  * Accounts can be notified of {IERC777} tokens being sent to them by having a
  * contract implement this interface (contract holders can be their own
  * implementer) and registering it on the
- * https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].
+ * https://eips.ethereum.org/EIPS/eip-1820[ERC-1820 global registry].
  *
  * See {IERC1820Registry} and {IERC1820Implementer}.
  */

contracts/interfaces/IERC777Sender.sol

@@ -4,12 +4,12 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC777TokensSender standard as defined in the EIP.
+ * @dev Interface of the ERC-777 Tokens Sender standard as defined in the ERC.
  *
  * {IERC777} Token holders can be notified of operations performed on their
  * tokens by having a contract implement this interface (contract holders can be
  * their own implementer) and registering it on the
- * https://eips.ethereum.org/EIPS/eip-1820[ERC1820 global registry].
+ * https://eips.ethereum.org/EIPS/eip-1820[ERC-1820 global registry].
  *
  * See {IERC1820Registry} and {IERC1820Implementer}.
  */

contracts/interfaces/draft-IERC1822.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev ERC1822: Universal Upgradeable Proxy Standard (UUPS) documents a method for upgradeability through a simplified
+ * @dev ERC-1822: Universal Upgradeable Proxy Standard (UUPS) documents a method for upgradeability through a simplified
  * proxy whose upgrades are fully controlled by the current implementation.
  */
 interface IERC1822Proxiable {

contracts/interfaces/draft-IERC6093.sol

@@ -3,8 +3,8 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Standard ERC20 Errors
- * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC20 tokens.
+ * @dev Standard ERC-20 Errors
+ * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC-20 tokens.
  */
 interface IERC20Errors {
     /**
@@ -49,12 +49,12 @@ interface IERC20Errors {
 }
 
 /**
- * @dev Standard ERC721 Errors
- * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC721 tokens.
+ * @dev Standard ERC-721 Errors
+ * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC-721 tokens.
  */
 interface IERC721Errors {
     /**
-     * @dev Indicates that an address can't be an owner. For example, `address(0)` is a forbidden owner in EIP-20.
+     * @dev Indicates that an address can't be an owner. For example, `address(0)` is a forbidden owner in ERC-20.
      * Used in balance queries.
      * @param owner Address of the current owner of a token.
      */
@@ -107,8 +107,8 @@ interface IERC721Errors {
 }
 
 /**
- * @dev Standard ERC1155 Errors
- * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC1155 tokens.
+ * @dev Standard ERC-1155 Errors
+ * Interface of the https://eips.ethereum.org/EIPS/eip-6093[ERC-6093] custom errors for ERC-1155 tokens.
  */
 interface IERC1155Errors {
     /**

contracts/metatx/ERC2771Context.sol

@@ -6,10 +6,10 @@ pragma solidity ^0.8.20;
 import {Context} from "../utils/Context.sol";
 
 /**
- * @dev Context variant with ERC2771 support.
+ * @dev Context variant with ERC-2771 support.
  *
  * WARNING: Avoid using this pattern in contracts that rely in a specific calldata length as they'll
- * be affected by any forwarder whose `msg.data` is suffixed with the `from` address according to the ERC2771
+ * 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`
  * function only accessible if `msg.data.length == 0`.

contracts/metatx/ERC2771Forwarder.sol

@@ -10,7 +10,7 @@ import {Nonces} from "../utils/Nonces.sol";
 import {Address} from "../utils/Address.sol";
 
 /**
- * @dev A forwarder compatible with ERC2771 contracts. See {ERC2771Context}.
+ * @dev A forwarder compatible with ERC-2771 contracts. See {ERC2771Context}.
  *
  * This forwarder operates on forward requests that include:
  *

contracts/mocks/ERC165/ERC165InterfacesSupported.sol

@@ -27,7 +27,7 @@ contract SupportsInterfaceWithLookupMock is IERC165 {
 
     /**
      * @dev A contract implementing SupportsInterfaceWithLookup
-     * implement ERC165 itself.
+     * implement ERC-165 itself.
      */
     constructor() {
         _registerInterface(INTERFACE_ID_ERC165);

contracts/mocks/docs/ERC4626Fees.sol

@@ -7,7 +7,7 @@ import {ERC4626} from "../../token/ERC20/extensions/ERC4626.sol";
 import {SafeERC20} from "../../token/ERC20/utils/SafeERC20.sol";
 import {Math} from "../../utils/math/Math.sol";
 
-/// @dev ERC4626 vault with entry/exit fees expressed in https://en.wikipedia.org/wiki/Basis_point[basis point (bp)].
+/// @dev ERC-4626 vault with entry/exit fees expressed in https://en.wikipedia.org/wiki/Basis_point[basis point (bp)].
 abstract contract ERC4626Fees is ERC4626 {
     using Math for uint256;
 

contracts/proxy/Clones.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev https://eips.ethereum.org/EIPS/eip-1167[EIP 1167] is a standard for
+ * @dev https://eips.ethereum.org/EIPS/eip-1167[ERC-1167] is a standard for
  * deploying minimal proxy contracts, also known as "clones".
  *
  * > To simply and cheaply clone contract functionality in an immutable way, this standard specifies

contracts/proxy/ERC1967/ERC1967Proxy.sol

@@ -9,7 +9,7 @@ import {ERC1967Utils} from "./ERC1967Utils.sol";
 /**
  * @dev This contract implements an upgradeable proxy. It is upgradeable because calls are delegated to an
  * implementation address that can be changed. This address is stored in storage in the location specified by
- * https://eips.ethereum.org/EIPS/eip-1967[EIP1967], so that it doesn't conflict with the storage layout of the
+ * https://eips.ethereum.org/EIPS/eip-1967[ERC-1967], so that it doesn't conflict with the storage layout of the
  * implementation behind the proxy.
  */
 contract ERC1967Proxy is Proxy {
@@ -30,7 +30,7 @@ contract ERC1967Proxy is Proxy {
     /**
      * @dev Returns the current implementation address.
      *
-     * TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using
+     * TIP: To get this value clients can read directly from the storage slot shown below (specified by ERC-1967) using
      * the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call.
      * `0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc`
      */

contracts/proxy/ERC1967/ERC1967Utils.sol

@@ -9,7 +9,7 @@ import {StorageSlot} from "../../utils/StorageSlot.sol";
 
 /**
  * @dev This abstract contract provides getters and event emitting update functions for
- * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] slots.
+ * https://eips.ethereum.org/EIPS/eip-1967[ERC-1967] slots.
  */
 library ERC1967Utils {
     // We re-declare ERC-1967 events here because they can't be used directly from IERC1967.
@@ -64,7 +64,7 @@ library ERC1967Utils {
     }
 
     /**
-     * @dev Stores a new address in the EIP1967 implementation slot.
+     * @dev Stores a new address in the ERC-1967 implementation slot.
      */
     function _setImplementation(address newImplementation) private {
         if (newImplementation.code.length == 0) {
@@ -101,7 +101,7 @@ library ERC1967Utils {
     /**
      * @dev Returns the current admin.
      *
-     * TIP: To get this value clients can read directly from the storage slot shown below (specified by EIP1967) using
+     * TIP: To get this value clients can read directly from the storage slot shown below (specified by ERC-1967) using
      * the https://eth.wiki/json-rpc/API#eth_getstorageat[`eth_getStorageAt`] RPC call.
      * `0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103`
      */
@@ -110,7 +110,7 @@ library ERC1967Utils {
     }
 
     /**
-     * @dev Stores a new address in the EIP1967 admin slot.
+     * @dev Stores a new address in the ERC-1967 admin slot.
      */
     function _setAdmin(address newAdmin) private {
         if (newAdmin == address(0)) {
@@ -144,7 +144,7 @@ library ERC1967Utils {
     }
 
     /**
-     * @dev Stores a new beacon in the EIP1967 beacon slot.
+     * @dev Stores a new beacon in the ERC-1967 beacon slot.
      */
     function _setBeacon(address newBeacon) private {
         if (newBeacon.code.length == 0) {

contracts/proxy/README.adoc

@@ -9,12 +9,12 @@ Most of the proxies below are built on an abstract base contract.
 
 - {Proxy}: Abstract contract implementing the core delegation functionality.
 
-In order to avoid clashes with the storage variables of the implementation contract behind a proxy, we use https://eips.ethereum.org/EIPS/eip-1967[EIP1967] storage slots.
+In order to avoid clashes with the storage variables of the implementation contract behind a proxy, we use https://eips.ethereum.org/EIPS/eip-1967[ERC-1967] storage slots.
 
-- {ERC1967Utils}: Internal functions to get and set the storage slots defined in EIP1967.
-- {ERC1967Proxy}: A proxy using EIP1967 storage slots. Not upgradeable by default.
+- {ERC1967Utils}: Internal functions to get and set the storage slots defined in ERC-1967.
+- {ERC1967Proxy}: A proxy using ERC-1967 storage slots. Not upgradeable by default.
 
-There are two alternative ways to add upgradeability to an ERC1967 proxy. Their differences are explained below in <<transparent-vs-uups>>.
+There are two alternative ways to add upgradeability to an ERC-1967 proxy. Their differences are explained below in <<transparent-vs-uups>>.
 
 - {TransparentUpgradeableProxy}: A proxy with a built-in immutable admin and upgrade interface.
 - {UUPSUpgradeable}: An upgradeability mechanism to be included in the implementation contract.
@@ -26,7 +26,7 @@ A different family of proxies are beacon proxies. This pattern, popularized by D
 - {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.
 
-In this pattern, the proxy contract doesn't hold the implementation address in storage like an ERC1967 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.
+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.
 
 Outside the realm of upgradeability, proxies can also be useful to make cheap contract clones, such as those created by an on-chain factory contract that creates many instances of the same contract. These instances are designed to be both cheap to deploy, and cheap to call.
 
@@ -35,7 +35,7 @@ Outside the realm of upgradeability, proxies can also be useful to make cheap co
 [[transparent-vs-uups]]
 == Transparent vs UUPS Proxies
 
-The original proxies included in OpenZeppelin followed the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[Transparent Proxy Pattern]. While this pattern is still provided, our recommendation is now shifting towards UUPS proxies, which are both lightweight and versatile. The name UUPS comes from https://eips.ethereum.org/EIPS/eip-1822[EIP1822], which first documented the pattern.
+The original proxies included in OpenZeppelin followed the https://blog.openzeppelin.com/the-transparent-proxy-pattern/[Transparent Proxy Pattern]. While this pattern is still provided, our recommendation is now shifting towards UUPS proxies, which are both lightweight and versatile. The name UUPS comes from https://eips.ethereum.org/EIPS/eip-1822[ERC-1822], which first documented the pattern.
 
 While both of these share the same interface for upgrades, in UUPS proxies the upgrade is handled by the implementation, and can eventually be removed. Transparent proxies, on the other hand, include the upgrade and admin logic in the proxy itself. This means {TransparentUpgradeableProxy} is more expensive to deploy than what is possible with UUPS proxies.
 
@@ -48,13 +48,13 @@ By default, the upgrade functionality included in {UUPSUpgradeable} contains a s
 - Adding a flag mechanism in the implementation that will disable the upgrade function when triggered.
 - Upgrading to an implementation that features an upgrade mechanism without the additional security check, and then upgrading again to another implementation without the upgrade mechanism.
 
-The current implementation of this security mechanism uses https://eips.ethereum.org/EIPS/eip-1822[EIP1822] to detect the storage slot used by the implementation. A previous implementation, now deprecated, relied on a rollback check. It is possible to upgrade from a contract using the old mechanism to a new one. The inverse is however not possible, as old implementations (before version 4.5) did not include the `ERC1822` interface.
+The current implementation of this security mechanism uses https://eips.ethereum.org/EIPS/eip-1822[ERC-1822] to detect the storage slot used by the implementation. A previous implementation, now deprecated, relied on a rollback check. It is possible to upgrade from a contract using the old mechanism to a new one. The inverse is however not possible, as old implementations (before version 4.5) did not include the ERC-1822 interface.
 
 == Core
 
 {{Proxy}}
 
-== ERC1967
+== ERC-1967
 
 {{IERC1967}}
 

contracts/proxy/beacon/BeaconProxy.sol

@@ -12,7 +12,7 @@ import {ERC1967Utils} from "../ERC1967/ERC1967Utils.sol";
  *
  * The beacon address can only be set once during construction, and cannot be changed afterwards. It is stored in an
  * immutable variable to avoid unnecessary storage reads, and also in the beacon storage slot specified by
- * https://eips.ethereum.org/EIPS/eip-1967[EIP1967] so that it can be accessed externally.
+ * https://eips.ethereum.org/EIPS/eip-1967[ERC-1967] so that it can be accessed externally.
  *
  * CAUTION: Since the beacon address can never be changed, you must ensure that you either control the beacon, or trust
  * the beacon to not upgrade the implementation maliciously.

contracts/proxy/utils/UUPSUpgradeable.sol

@@ -42,9 +42,9 @@ abstract contract UUPSUpgradeable is IERC1822Proxiable {
 
     /**
      * @dev Check that the execution is being performed through a delegatecall call and that the execution context is
-     * a proxy contract with an implementation (as defined in ERC1967) pointing to self. This should only be the case
+     * a proxy contract with an implementation (as defined in ERC-1967) pointing to self. This should only be the case
      * for UUPS and transparent proxies that are using the current contract as their implementation. Execution of a
-     * function through ERC1167 minimal proxies (clones) would not normally pass this test, but is not guaranteed to
+     * function through ERC-1167 minimal proxies (clones) would not normally pass this test, but is not guaranteed to
      * fail.
      */
     modifier onlyProxy() {
@@ -62,7 +62,7 @@ abstract contract UUPSUpgradeable is IERC1822Proxiable {
     }
 
     /**
-     * @dev Implementation of the ERC1822 {proxiableUUID} function. This returns the storage slot used by the
+     * @dev Implementation of the ERC-1822 {proxiableUUID} function. This returns the storage slot used by the
      * implementation. It is used to validate the implementation's compatibility when performing an upgrade.
      *
      * IMPORTANT: A proxy pointing at a proxiable contract should not be considered proxiable itself, because this risks
@@ -90,7 +90,7 @@ abstract contract UUPSUpgradeable is IERC1822Proxiable {
 
     /**
      * @dev Reverts if the execution is not performed via delegatecall or the execution
-     * context is not of a proxy with an ERC1967-compliant implementation pointing to self.
+     * context is not of a proxy with an ERC-1967 compliant implementation pointing to self.
      * See {_onlyProxy}.
      */
     function _checkProxy() internal view virtual {
@@ -129,7 +129,7 @@ abstract contract UUPSUpgradeable is IERC1822Proxiable {
      * @dev Performs an implementation upgrade with a security check for UUPS proxies, and additional setup call.
      *
      * As a security check, {proxiableUUID} is invoked in the new implementation, and the return value
-     * is expected to be the implementation slot in ERC1967.
+     * is expected to be the implementation slot in ERC-1967.
      *
      * Emits an {IERC1967-Upgraded} event.
      */

contracts/token/ERC1155/ERC1155.sol

@@ -49,7 +49,7 @@ abstract contract ERC1155 is Context, ERC165, IERC1155, IERC1155MetadataURI, IER
      *
      * This implementation returns the same URI for *all* token types. It relies
      * on the token type ID substitution mechanism
-     * https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].
+     * https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the ERC].
      *
      * Clients calling this function must replace the `\{id\}` substring with the
      * actual token type ID.
@@ -263,7 +263,7 @@ abstract contract ERC1155 is Context, ERC165, IERC1155, IERC1155MetadataURI, IER
     /**
      * @dev Sets a new URI for all token types, by relying on the token type ID
      * substitution mechanism
-     * https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the EIP].
+     * https://eips.ethereum.org/EIPS/eip-1155#metadata[defined in the ERC].
      *
      * By this mechanism, any occurrence of the `\{id\}` substring in either the
      * URI or any of the values in the JSON file at said URI will be replaced by
@@ -394,7 +394,7 @@ abstract contract ERC1155 is Context, ERC165, IERC1155, IERC1155MetadataURI, IER
                 }
             } catch (bytes memory reason) {
                 if (reason.length == 0) {
-                    // non-ERC1155Receiver implementer
+                    // non-IERC1155Receiver implementer
                     revert ERC1155InvalidReceiver(to);
                 } else {
                     /// @solidity memory-safe-assembly
@@ -428,7 +428,7 @@ abstract contract ERC1155 is Context, ERC165, IERC1155, IERC1155MetadataURI, IER
                 }
             } catch (bytes memory reason) {
                 if (reason.length == 0) {
-                    // non-ERC1155Receiver implementer
+                    // non-IERC1155Receiver implementer
                     revert ERC1155InvalidReceiver(to);
                 } else {
                     /// @solidity memory-safe-assembly

contracts/token/ERC1155/IERC1155.sol

@@ -6,8 +6,8 @@ pragma solidity ^0.8.20;
 import {IERC165} from "../../utils/introspection/IERC165.sol";
 
 /**
- * @dev Required interface of an ERC1155 compliant contract, as defined in the
- * https://eips.ethereum.org/EIPS/eip-1155[EIP].
+ * @dev Required interface of an ERC-1155 compliant contract, as defined in the
+ * https://eips.ethereum.org/EIPS/eip-1155[ERC].
  */
 interface IERC1155 is IERC165 {
     /**

contracts/token/ERC1155/IERC1155Receiver.sol

@@ -11,7 +11,7 @@ import {IERC165} from "../../utils/introspection/IERC165.sol";
  */
 interface IERC1155Receiver is IERC165 {
     /**
-     * @dev Handles the receipt of a single ERC1155 token type. This function is
+     * @dev Handles the receipt of a single ERC-1155 token type. This function is
      * called at the end of a `safeTransferFrom` after the balance has been updated.
      *
      * NOTE: To accept the transfer, this must return
@@ -34,7 +34,7 @@ interface IERC1155Receiver is IERC165 {
     ) external returns (bytes4);
 
     /**
-     * @dev Handles the receipt of a multiple ERC1155 token types. This function
+     * @dev Handles the receipt of a multiple ERC-1155 token types. This function
      * is called at the end of a `safeBatchTransferFrom` after the balances have
      * been updated.
      *

contracts/token/ERC1155/README.adoc

@@ -1,11 +1,11 @@
-= ERC 1155
+= ERC-1155
 
 [.readme-notice]
 NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/token/erc1155
 
-This set of interfaces and contracts are all related to the https://eips.ethereum.org/EIPS/eip-1155[ERC1155 Multi Token Standard].
+This set of interfaces and contracts are all related to the https://eips.ethereum.org/EIPS/eip-1155[ERC-1155 Multi Token Standard].
 
-The EIP consists of three interfaces which fulfill different roles, found here as {IERC1155}, {IERC1155MetadataURI} and {IERC1155Receiver}.
+The ERC consists of three interfaces which fulfill different roles, found here as {IERC1155}, {IERC1155MetadataURI} and {IERC1155Receiver}.
 
 {ERC1155} implements the mandatory {IERC1155} interface, as well as the optional extension {IERC1155MetadataURI}, by relying on the substitution mechanism to use the same URI for all token types, dramatically reducing gas costs.
 
@@ -14,7 +14,7 @@ Additionally there are multiple custom extensions, including:
 * designation of addresses that can pause token transfers for all users ({ERC1155Pausable}).
 * destruction of own tokens ({ERC1155Burnable}).
 
-NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC1155 (such as <<ERC1155-_mint-address-uint256-uint256-bytes-,`_mint`>>) and expose them as external functions in the way they prefer.
+NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-1155 (such as <<ERC1155-_mint-address-uint256-uint256-bytes-,`_mint`>>) and expose them as external functions in the way they prefer.
 
 == Core
 

contracts/token/ERC1155/extensions/ERC1155Pausable.sol

@@ -7,7 +7,7 @@ import {ERC1155} from "../ERC1155.sol";
 import {Pausable} from "../../../utils/Pausable.sol";
 
 /**
- * @dev ERC1155 token with pausable token transfers, minting and burning.
+ * @dev ERC-1155 token with pausable token transfers, minting and burning.
  *
  * Useful for scenarios such as preventing trades until the end of an evaluation
  * period, or having an emergency switch for freezing all token transfers in the

contracts/token/ERC1155/extensions/ERC1155Supply.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {ERC1155} from "../ERC1155.sol";
 
 /**
- * @dev Extension of ERC1155 that adds tracking of total supply per id.
+ * @dev Extension of ERC-1155 that adds tracking of total supply per id.
  *
  * Useful for scenarios where Fungible and Non-fungible tokens have to be
  * clearly identified. Note: While a totalSupply of 1 might mean the

contracts/token/ERC1155/extensions/ERC1155URIStorage.sol

@@ -7,8 +7,8 @@ import {Strings} from "../../../utils/Strings.sol";
 import {ERC1155} from "../ERC1155.sol";
 
 /**
- * @dev ERC1155 token with storage based token URI management.
- * Inspired by the ERC721URIStorage extension
+ * @dev ERC-1155 token with storage based token URI management.
+ * Inspired by the {ERC721URIStorage} extension
  */
 abstract contract ERC1155URIStorage is ERC1155 {
     using Strings for uint256;

contracts/token/ERC1155/extensions/IERC1155MetadataURI.sol

@@ -7,7 +7,7 @@ import {IERC1155} from "../IERC1155.sol";
 
 /**
  * @dev Interface of the optional ERC1155MetadataExtension interface, as defined
- * in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[EIP].
+ * in the https://eips.ethereum.org/EIPS/eip-1155#metadata-extensions[ERC].
  */
 interface IERC1155MetadataURI is IERC1155 {
     /**

contracts/token/ERC1155/utils/ERC1155Holder.sol

@@ -7,7 +7,7 @@ import {IERC165, ERC165} from "../../../utils/introspection/ERC165.sol";
 import {IERC1155Receiver} from "../IERC1155Receiver.sol";
 
 /**
- * @dev Simple implementation of `IERC1155Receiver` that will allow a contract to hold ERC1155 tokens.
+ * @dev Simple implementation of `IERC1155Receiver` that will allow a contract to hold ERC-1155 tokens.
  *
  * IMPORTANT: When inheriting this contract, you must include a way to use the received tokens, otherwise they will be
  * stuck.

contracts/token/ERC20/ERC20.sol

@@ -23,12 +23,12 @@ import {IERC20Errors} from "../../interfaces/draft-IERC6093.sol";
  *
  * We have followed general OpenZeppelin Contracts guidelines: functions revert
  * instead returning `false` on failure. This behavior is nonetheless
- * conventional and does not conflict with the expectations of ERC20
+ * conventional and does not conflict with the expectations of ERC-20
  * applications.
  *
  * Additionally, an {Approval} event is emitted on calls to {transferFrom}.
  * This allows applications to reconstruct the allowance for all accounts just
- * by listening to said events. Other implementations of the EIP may not emit
+ * by listening to said events. Other implementations of the ERC may not emit
  * these events, as it isn't required by the specification.
  */
 abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
@@ -139,7 +139,7 @@ abstract contract ERC20 is Context, IERC20, IERC20Metadata, IERC20Errors {
      * @dev See {IERC20-transferFrom}.
      *
      * Emits an {Approval} event indicating the updated allowance. This is not
-     * required by the EIP. See the note at the beginning of {ERC20}.
+     * required by the ERC. See the note at the beginning of {ERC20}.
      *
      * NOTE: Does not update the allowance if the current allowance
      * is the maximum `uint256`.

contracts/token/ERC20/IERC20.sol

@@ -4,7 +4,7 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC20 standard as defined in the EIP.
+ * @dev Interface of the ERC-20 standard as defined in the ERC.
  */
 interface IERC20 {
     /**

contracts/token/ERC20/README.adoc

@@ -1,38 +1,38 @@
-= ERC 20
+= ERC-20
 
 [.readme-notice]
 NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/token/erc20
 
-This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-20[ERC20 Token Standard].
+This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-20[ERC-20 Token Standard].
 
-TIP: For an overview of ERC20 tokens and a walk through on how to create a token contract read our xref:ROOT:erc20.adoc[ERC20 guide].
+TIP: For an overview of ERC-20 tokens and a walk through on how to create a token contract read our xref:ROOT:erc20.adoc[ERC-20 guide].
 
-There are a few core contracts that implement the behavior specified in the EIP:
+There are a few core contracts that implement the behavior specified in the ERC:
 
-* {IERC20}: the interface all ERC20 implementations should conform to.
-* {IERC20Metadata}: the extended ERC20 interface including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> functions.
-* {ERC20}: the implementation of the ERC20 interface, including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> optional standard extension to the base interface.
+* {IERC20}: the interface all ERC-20 implementations should conform to.
+* {IERC20Metadata}: the extended ERC-20 interface including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> functions.
+* {ERC20}: the implementation of the ERC-20 interface, including the <<ERC20-name,`name`>>, <<ERC20-symbol,`symbol`>> and <<ERC20-decimals,`decimals`>> optional standard extension to the base interface.
 
 Additionally there are multiple custom extensions, including:
 
-* {ERC20Permit}: gasless approval of tokens (standardized as ERC2612).
+* {ERC20Permit}: gasless approval of tokens (standardized as ERC-2612).
 * {ERC20Burnable}: destruction of own tokens.
 * {ERC20Capped}: enforcement of a cap to the total supply when minting tokens.
 * {ERC20Pausable}: ability to pause token transfers.
-* {ERC20FlashMint}: token level support for flash loans through the minting and burning of ephemeral tokens (standardized as ERC3156).
+* {ERC20FlashMint}: token level support for flash loans through the minting and burning of ephemeral tokens (standardized as ERC-3156).
 * {ERC20Votes}: support for voting and vote delegation.
-* {ERC20Wrapper}: wrapper to create an ERC20 backed by another ERC20, with deposit and withdraw methods. Useful in conjunction with {ERC20Votes}.
-* {ERC4626}: tokenized vault that manages shares (represented as ERC20) that are backed by assets (another ERC20).
+* {ERC20Wrapper}: wrapper to create an ERC-20 backed by another ERC-20, with deposit and withdraw methods. Useful in conjunction with {ERC20Votes}.
+* {ERC4626}: tokenized vault that manages shares (represented as ERC-20) that are backed by assets (another ERC-20).
 
-Finally, there are some utilities to interact with ERC20 contracts in various ways:
+Finally, there are some utilities to interact with ERC-20 contracts in various ways:
 
 * {SafeERC20}: a wrapper around the interface that eliminates the need to handle boolean return values.
 
-Other utilities that support ERC20 assets can be found in codebase:
+Other utilities that support ERC-20 assets can be found in codebase:
 
-* ERC20 tokens can be timelocked (held tokens for a beneficiary until a specified time) or vested (released following a given schedule) using a {VestingWallet}.
+* ERC-20 tokens can be timelocked (held tokens for a beneficiary until a specified time) or vested (released following a given schedule) using a {VestingWallet}.
 
-NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as <<ERC20-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer.
+NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-20 (such as <<ERC20-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer.
 
 == Core
 

contracts/token/ERC20/extensions/ERC20FlashMint.sol

@@ -8,7 +8,7 @@ import {IERC3156FlashLender} from "../../../interfaces/IERC3156FlashLender.sol";
 import {ERC20} from "../ERC20.sol";
 
 /**
- * @dev Implementation of the ERC3156 Flash loans extension, as defined in
+ * @dev Implementation of the ERC-3156 Flash loans extension, as defined in
  * https://eips.ethereum.org/EIPS/eip-3156[ERC-3156].
  *
  * Adds the {flashLoan} method, which provides flash loan support at the token

contracts/token/ERC20/extensions/ERC20Pausable.sol

@@ -7,7 +7,7 @@ import {ERC20} from "../ERC20.sol";
 import {Pausable} from "../../../utils/Pausable.sol";
 
 /**
- * @dev ERC20 token with pausable token transfers, minting and burning.
+ * @dev ERC-20 token with pausable token transfers, minting and burning.
  *
  * Useful for scenarios such as preventing trades until the end of an evaluation
  * period, or having an emergency switch for freezing all token transfers in the

contracts/token/ERC20/extensions/ERC20Permit.sol

@@ -10,10 +10,10 @@ import {EIP712} from "../../../utils/cryptography/EIP712.sol";
 import {Nonces} from "../../../utils/Nonces.sol";
 
 /**
- * @dev Implementation of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in
- * https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].
+ * @dev Implementation of the ERC-20 Permit extension allowing approvals to be made via signatures, as defined in
+ * https://eips.ethereum.org/EIPS/eip-2612[ERC-2612].
  *
- * Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by
+ * Adds the {permit} method, which can be used to change an account's ERC-20 allowance (see {IERC20-allowance}) by
  * presenting a message signed by the account. By not relying on `{IERC20-approve}`, the token holder account doesn't
  * need to send a transaction, and thus is not required to hold Ether at all.
  */
@@ -34,7 +34,7 @@ abstract contract ERC20Permit is ERC20, IERC20Permit, EIP712, Nonces {
     /**
      * @dev Initializes the {EIP712} domain separator using the `name` parameter, and setting `version` to `"1"`.
      *
-     * It's a good idea to use the same `name` that is defined as the ERC20 token name.
+     * It's a good idea to use the same `name` that is defined as the ERC-20 token name.
      */
     constructor(string memory name) EIP712(name, "1") {}
 

contracts/token/ERC20/extensions/ERC20Votes.sol

@@ -8,7 +8,7 @@ import {Votes} from "../../../governance/utils/Votes.sol";
 import {Checkpoints} from "../../../utils/structs/Checkpoints.sol";
 
 /**
- * @dev Extension of ERC20 to support Compound-like voting and delegation. This version is more generic than Compound's,
+ * @dev Extension of ERC-20 to support Compound-like voting and delegation. This version is more generic than Compound's,
  * and supports token supply up to 2^208^ - 1, while COMP is limited to 2^96^ - 1.
  *
  * NOTE: This contract does not provide interface compatibility with Compound's COMP token.

contracts/token/ERC20/extensions/ERC20Wrapper.sol

@@ -7,11 +7,11 @@ import {IERC20, IERC20Metadata, ERC20} from "../ERC20.sol";
 import {SafeERC20} from "../utils/SafeERC20.sol";
 
 /**
- * @dev Extension of the ERC20 token contract to support token wrapping.
+ * @dev Extension of the ERC-20 token contract to support token wrapping.
  *
  * Users can deposit and withdraw "underlying tokens" and receive a matching number of "wrapped tokens". This is useful
  * in conjunction with other modules. For example, combining this wrapping mechanism with {ERC20Votes} will allow the
- * wrapping of an existing "basic" ERC20 into a governance token.
+ * wrapping of an existing "basic" ERC-20 into a governance token.
  */
 abstract contract ERC20Wrapper is ERC20 {
     IERC20 private immutable _underlying;

contracts/token/ERC20/extensions/ERC4626.sol

@@ -9,12 +9,12 @@ import {IERC4626} from "../../../interfaces/IERC4626.sol";
 import {Math} from "../../../utils/math/Math.sol";
 
 /**
- * @dev Implementation of the ERC4626 "Tokenized Vault Standard" as defined in
- * https://eips.ethereum.org/EIPS/eip-4626[EIP-4626].
+ * @dev Implementation of the ERC-4626 "Tokenized Vault Standard" as defined in
+ * https://eips.ethereum.org/EIPS/eip-4626[ERC-4626].
  *
- * This extension allows the minting and burning of "shares" (represented using the ERC20 inheritance) in exchange for
+ * This extension allows the minting and burning of "shares" (represented using the ERC-20 inheritance) in exchange for
  * underlying "assets" through standardized {deposit}, {mint}, {redeem} and {burn} workflows. This contract extends
- * the ERC20 standard. Any additional extensions included along it would affect the "shares" token represented by this
+ * the ERC-20 standard. Any additional extensions included along it would affect the "shares" token represented by this
  * contract and not the "assets" token which is an independent contract.
  *
  * [CAUTION]
@@ -72,7 +72,7 @@ abstract contract ERC4626 is ERC20, IERC4626 {
     error ERC4626ExceededMaxRedeem(address owner, uint256 shares, uint256 max);
 
     /**
-     * @dev Set the underlying asset contract. This must be an ERC20-compatible contract (ERC20 or ERC777).
+     * @dev Set the underlying asset contract. This must be an ERC20-compatible contract (ERC-20 or ERC-777).
      */
     constructor(IERC20 asset_) {
         (bool success, uint8 assetDecimals) = _tryGetAssetDecimals(asset_);
@@ -241,7 +241,7 @@ abstract contract ERC4626 is ERC20, IERC4626 {
      * @dev Deposit/mint common workflow.
      */
     function _deposit(address caller, address receiver, uint256 assets, uint256 shares) internal virtual {
-        // If _asset is ERC777, `transferFrom` can trigger a reentrancy BEFORE the transfer happens through the
+        // If _asset is ERC-777, `transferFrom` can trigger a reentrancy BEFORE the transfer happens through the
         // `tokensToSend` hook. On the other hand, the `tokenReceived` hook, that is triggered after the transfer,
         // calls the vault, which is assumed not malicious.
         //
@@ -268,7 +268,7 @@ abstract contract ERC4626 is ERC20, IERC4626 {
             _spendAllowance(owner, caller, shares);
         }
 
-        // If _asset is ERC777, `transfer` can trigger a reentrancy AFTER the transfer happens through the
+        // If _asset is ERC-777, `transfer` can trigger a reentrancy AFTER the transfer happens through the
         // `tokensReceived` hook. On the other hand, the `tokensToSend` hook, that is triggered before the transfer,
         // calls the vault, which is assumed not malicious.
         //

contracts/token/ERC20/extensions/IERC20Metadata.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IERC20} from "../IERC20.sol";
 
 /**
- * @dev Interface for the optional metadata functions from the ERC20 standard.
+ * @dev Interface for the optional metadata functions from the ERC-20 standard.
  */
 interface IERC20Metadata is IERC20 {
     /**

contracts/token/ERC20/extensions/IERC20Permit.sol

@@ -4,10 +4,10 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC20 Permit extension allowing approvals to be made via signatures, as defined in
- * https://eips.ethereum.org/EIPS/eip-2612[EIP-2612].
+ * @dev Interface of the ERC-20 Permit extension allowing approvals to be made via signatures, as defined in
+ * https://eips.ethereum.org/EIPS/eip-2612[ERC-2612].
  *
- * Adds the {permit} method, which can be used to change an account's ERC20 allowance (see {IERC20-allowance}) by
+ * Adds the {permit} method, which can be used to change an account's ERC-20 allowance (see {IERC20-allowance}) by
  * presenting a message signed by the account. By not relying on {IERC20-approve}, the token holder account doesn't
  * need to send a transaction, and thus is not required to hold Ether at all.
  *

contracts/token/ERC20/utils/SafeERC20.sol

@@ -9,7 +9,7 @@ import {Address} from "../../../utils/Address.sol";
 
 /**
  * @title SafeERC20
- * @dev Wrappers around ERC20 operations that throw on failure (when the token
+ * @dev Wrappers around ERC-20 operations that throw on failure (when the token
  * contract returns false). Tokens that return no value (and instead revert or
  * throw on failure) are also supported, non-reverting calls are assumed to be
  * successful.
@@ -20,7 +20,7 @@ library SafeERC20 {
     using Address for address;
 
     /**
-     * @dev An operation with an ERC20 token failed.
+     * @dev An operation with an ERC-20 token failed.
      */
     error SafeERC20FailedOperation(address token);
 

contracts/token/ERC721/ERC721.sol

@@ -12,7 +12,7 @@ import {IERC165, ERC165} from "../../utils/introspection/ERC165.sol";
 import {IERC721Errors} from "../../interfaces/draft-IERC6093.sol";
 
 /**
- * @dev Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC721] Non-Fungible Token Standard, including
+ * @dev Implementation of https://eips.ethereum.org/EIPS/eip-721[ERC-721] Non-Fungible Token Standard, including
  * the Metadata extension, but not including the Enumerable extension, which is available separately as
  * {ERC721Enumerable}.
  */
@@ -165,7 +165,7 @@ abstract contract ERC721 is Context, ERC165, IERC721, IERC721Metadata, IERC721Er
      * @dev Returns the owner of the `tokenId`. Does NOT revert if token doesn't exist
      *
      * IMPORTANT: Any overrides to this function that add ownership of tokens not tracked by the
-     * core ERC721 logic MUST be matched with the use of {_increaseBalance} to keep balances
+     * core ERC-721 logic MUST be matched with the use of {_increaseBalance} to keep balances
      * consistent with ownership. The invariant to preserve is that for any address `a` the value returned by
      * `balanceOf(a)` must be equal to the number of tokens such that `_ownerOf(tokenId)` is `a`.
      */
@@ -357,7 +357,7 @@ abstract contract ERC721 is Context, ERC165, IERC721, IERC721Metadata, IERC721Er
 
     /**
      * @dev Safely transfers `tokenId` token from `from` to `to`, checking that contract recipients
-     * are aware of the ERC721 standard to prevent tokens from being forever locked.
+     * are aware of the ERC-721 standard to prevent tokens from being forever locked.
      *
      * `data` is additional data, it has no specified format and it is sent in call to `to`.
      *

contracts/token/ERC721/IERC721.sol

@@ -6,7 +6,7 @@ pragma solidity ^0.8.20;
 import {IERC165} from "../../utils/introspection/IERC165.sol";
 
 /**
- * @dev Required interface of an ERC721 compliant contract.
+ * @dev Required interface of an ERC-721 compliant contract.
  */
 interface IERC721 is IERC165 {
     /**
@@ -56,7 +56,7 @@ interface IERC721 is IERC165 {
 
     /**
      * @dev Safely transfers `tokenId` token from `from` to `to`, checking first that contract recipients
-     * are aware of the ERC721 protocol to prevent tokens from being forever locked.
+     * are aware of the ERC-721 protocol to prevent tokens from being forever locked.
      *
      * Requirements:
      *
@@ -75,7 +75,7 @@ interface IERC721 is IERC165 {
     /**
      * @dev Transfers `tokenId` token from `from` to `to`.
      *
-     * WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC721
+     * WARNING: Note that the caller is responsible to confirm that the recipient is capable of receiving ERC-721
      * or else they may be permanently lost. Usage of {safeTransferFrom} prevents loss, though the caller must
      * understand this adds an external call which potentially creates a reentrancy vulnerability.
      *

contracts/token/ERC721/IERC721Receiver.sol

@@ -4,9 +4,9 @@
 pragma solidity ^0.8.20;
 
 /**
- * @title ERC721 token receiver interface
+ * @title ERC-721 token receiver interface
  * @dev Interface for any contract that wants to support safeTransfers
- * from ERC721 asset contracts.
+ * from ERC-721 asset contracts.
  */
 interface IERC721Receiver {
     /**

contracts/token/ERC721/README.adoc

@@ -1,13 +1,13 @@
-= ERC 721
+= ERC-721
 
 [.readme-notice]
 NOTE: This document is better viewed at https://docs.openzeppelin.com/contracts/api/token/erc721
 
-This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-721[ERC721 Non-Fungible Token Standard].
+This set of interfaces, contracts, and utilities are all related to the https://eips.ethereum.org/EIPS/eip-721[ERC-721 Non-Fungible Token Standard].
 
-TIP: For a walk through on how to create an ERC721 token read our xref:ROOT:erc721.adoc[ERC721 guide].
+TIP: For a walk through on how to create an ERC-721 token read our xref:ROOT:erc721.adoc[ERC-721 guide].
 
-The EIP specifies four interfaces:
+The ERC specifies four interfaces:
 
 * {IERC721}: Core functionality required in all compliant implementation.
 * {IERC721Metadata}: Optional extension that adds name, symbol, and token URI, almost always included.
@@ -22,15 +22,15 @@ OpenZeppelin Contracts provides implementations of all four interfaces:
 
 Additionally there are a few of other extensions:
 
-* {ERC721Consecutive}: An implementation of https://eips.ethereum.org/EIPS/eip-2309[ERC2309] for minting batchs of tokens during construction, in accordance with ERC721.
+* {ERC721Consecutive}: An implementation of https://eips.ethereum.org/EIPS/eip-2309[ERC-2309] for minting batchs of tokens during construction, in accordance with ERC-721.
 * {ERC721URIStorage}: A more flexible but more expensive way of storing metadata.
 * {ERC721Votes}: Support for voting and vote delegation.
-* {ERC721Royalty}: A way to signal royalty information following ERC2981.
+* {ERC721Royalty}: A way to signal royalty information following ERC-2981.
 * {ERC721Pausable}: A primitive to pause contract operation.
 * {ERC721Burnable}: A way for token holders to burn their own tokens.
-* {ERC721Wrapper}: Wrapper to create an ERC721 backed by another ERC721, with deposit and withdraw methods. Useful in conjunction with {ERC721Votes}.
+* {ERC721Wrapper}: Wrapper to create an ERC-721 backed by another ERC-721, with deposit and withdraw methods. Useful in conjunction with {ERC721Votes}.
 
-NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as <<ERC721-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer.
+NOTE: This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC-721 (such as <<ERC721-_mint-address-uint256-,`_mint`>>) and expose them as external functions in the way they prefer.
 
 == Core
 

contracts/token/ERC721/extensions/ERC721Burnable.sol

@@ -7,8 +7,8 @@ import {ERC721} from "../ERC721.sol";
 import {Context} from "../../../utils/Context.sol";
 
 /**
- * @title ERC721 Burnable Token
- * @dev ERC721 Token that can be burned (destroyed).
+ * @title ERC-721 Burnable Token
+ * @dev ERC-721 Token that can be burned (destroyed).
  */
 abstract contract ERC721Burnable is Context, ERC721 {
     /**

contracts/token/ERC721/extensions/ERC721Consecutive.sol

@@ -9,8 +9,8 @@ import {BitMaps} from "../../../utils/structs/BitMaps.sol";
 import {Checkpoints} from "../../../utils/structs/Checkpoints.sol";
 
 /**
- * @dev Implementation of the ERC2309 "Consecutive Transfer Extension" as defined in
- * https://eips.ethereum.org/EIPS/eip-2309[EIP-2309].
+ * @dev Implementation of the ERC-2309 "Consecutive Transfer Extension" as defined in
+ * https://eips.ethereum.org/EIPS/eip-2309[ERC-2309].
  *
  * This extension allows the minting of large batches of tokens, during contract construction only. For upgradeable
  * contracts this implies that batch minting is only available during proxy deployment, and not in subsequent upgrades.
@@ -37,7 +37,7 @@ abstract contract ERC721Consecutive is IERC2309, ERC721 {
     /**
      * @dev Batch mint is restricted to the constructor.
      * Any batch mint not emitting the {IERC721-Transfer} event outside of the constructor
-     * is non-ERC721 compliant.
+     * is non ERC-721 compliant.
      */
     error ERC721ForbiddenBatchMint();
 
@@ -94,7 +94,7 @@ abstract contract ERC721Consecutive is IERC2309, ERC721 {
      * - `batchSize` must not be greater than {_maxBatchSize}.
      * - The function is called in the constructor of the contract (directly or indirectly).
      *
-     * CAUTION: Does not emit a `Transfer` event. This is ERC721 compliant as long as it is done inside of the
+     * CAUTION: Does not emit a `Transfer` event. This is ERC-721 compliant as long as it is done inside of the
      * constructor, which is enforced by this function.
      *
      * CAUTION: Does not invoke `onERC721Received` on the receiver.

contracts/token/ERC721/extensions/ERC721Enumerable.sol

@@ -8,11 +8,11 @@ import {IERC721Enumerable} from "./IERC721Enumerable.sol";
 import {IERC165} from "../../../utils/introspection/ERC165.sol";
 
 /**
- * @dev This implements an optional extension of {ERC721} defined in the EIP that adds enumerability
+ * @dev This implements an optional extension of {ERC721} defined in the ERC that adds enumerability
  * of all the token ids in the contract as well as all token ids owned by each account.
  *
- * CAUTION: `ERC721` extensions that implement custom `balanceOf` logic, such as `ERC721Consecutive`,
- * interfere with enumerability and should not be used together with `ERC721Enumerable`.
+ * CAUTION: {ERC721} extensions that implement custom `balanceOf` logic, such as {ERC721Consecutive},
+ * interfere with enumerability and should not be used together with {ERC721Enumerable}.
  */
 abstract contract ERC721Enumerable is ERC721, IERC721Enumerable {
     mapping(address owner => mapping(uint256 index => uint256)) private _ownedTokens;

contracts/token/ERC721/extensions/ERC721Pausable.sol

@@ -7,7 +7,7 @@ import {ERC721} from "../ERC721.sol";
 import {Pausable} from "../../../utils/Pausable.sol";
 
 /**
- * @dev ERC721 token with pausable token transfers, minting and burning.
+ * @dev ERC-721 token with pausable token transfers, minting and burning.
  *
  * Useful for scenarios such as preventing trades until the end of an evaluation
  * period, or having an emergency switch for freezing all token transfers in the

contracts/token/ERC721/extensions/ERC721Royalty.sol

@@ -7,14 +7,14 @@ import {ERC721} from "../ERC721.sol";
 import {ERC2981} from "../../common/ERC2981.sol";
 
 /**
- * @dev Extension of ERC721 with the ERC2981 NFT Royalty Standard, a standardized way to retrieve royalty payment
+ * @dev Extension of ERC-721 with the ERC-2981 NFT Royalty Standard, a standardized way to retrieve royalty payment
  * information.
  *
  * Royalty information can be specified globally for all token ids via {ERC2981-_setDefaultRoyalty}, and/or individually
  * for specific token ids via {ERC2981-_setTokenRoyalty}. The latter takes precedence over the first.
  *
  * IMPORTANT: ERC-2981 only specifies a way to signal royalty information and does not enforce its payment. See
- * https://eips.ethereum.org/EIPS/eip-2981#optional-royalty-payments[Rationale] in the EIP. Marketplaces are expected to
+ * https://eips.ethereum.org/EIPS/eip-2981#optional-royalty-payments[Rationale] in the ERC. Marketplaces are expected to
  * voluntarily pay royalties together with sales, but note that this standard is not yet widely supported.
  */
 abstract contract ERC721Royalty is ERC2981, ERC721 {

contracts/token/ERC721/extensions/ERC721URIStorage.sol

@@ -9,7 +9,7 @@ import {IERC4906} from "../../../interfaces/IERC4906.sol";
 import {IERC165} from "../../../interfaces/IERC165.sol";
 
 /**
- * @dev ERC721 token with storage based token URI management.
+ * @dev ERC-721 token with storage based token URI management.
  */
 abstract contract ERC721URIStorage is IERC4906, ERC721 {
     using Strings for uint256;

contracts/token/ERC721/extensions/ERC721Votes.sol

@@ -7,7 +7,7 @@ import {ERC721} from "../ERC721.sol";
 import {Votes} from "../../../governance/utils/Votes.sol";
 
 /**
- * @dev Extension of ERC721 to support voting and delegation as implemented by {Votes}, where each individual NFT counts
+ * @dev Extension of ERC-721 to support voting and delegation as implemented by {Votes}, where each individual NFT counts
  * as 1 vote unit.
  *
  * Tokens do not count as votes until they are delegated, because votes must be tracked which incurs an additional cost

contracts/token/ERC721/extensions/ERC721Wrapper.sol

@@ -7,17 +7,17 @@ import {IERC721, ERC721} from "../ERC721.sol";
 import {IERC721Receiver} from "../IERC721Receiver.sol";
 
 /**
- * @dev Extension of the ERC721 token contract to support token wrapping.
+ * @dev Extension of the ERC-721 token contract to support token wrapping.
  *
  * Users can deposit and withdraw an "underlying token" and receive a "wrapped token" with a matching tokenId. This is
  * useful in conjunction with other modules. For example, combining this wrapping mechanism with {ERC721Votes} will allow
- * the wrapping of an existing "basic" ERC721 into a governance token.
+ * the wrapping of an existing "basic" ERC-721 into a governance token.
  */
 abstract contract ERC721Wrapper is ERC721, IERC721Receiver {
     IERC721 private immutable _underlying;
 
     /**
-     * @dev The received ERC721 token couldn't be wrapped.
+     * @dev The received ERC-721 token couldn't be wrapped.
      */
     error ERC721UnsupportedToken(address token);
 
@@ -63,7 +63,7 @@ abstract contract ERC721Wrapper is ERC721, IERC721Receiver {
     }
 
     /**
-     * @dev Overrides {IERC721Receiver-onERC721Received} to allow minting on direct ERC721 transfers to
+     * @dev Overrides {IERC721Receiver-onERC721Received} to allow minting on direct ERC-721 transfers to
      * this contract.
      *
      * In case there's data attached, it validates that the operator is this contract, so only trusted data

contracts/token/common/ERC2981.sol

@@ -16,7 +16,7 @@ import {IERC165, ERC165} from "../../utils/introspection/ERC165.sol";
  * fee is specified in basis points by default.
  *
  * IMPORTANT: ERC-2981 only specifies a way to signal royalty information and does not enforce its payment. See
- * https://eips.ethereum.org/EIPS/eip-2981#optional-royalty-payments[Rationale] in the EIP. Marketplaces are expected to
+ * https://eips.ethereum.org/EIPS/eip-2981#optional-royalty-payments[Rationale] in the ERC. Marketplaces are expected to
  * voluntarily pay royalties together with sales, but note that this standard is not yet widely supported.
  */
 abstract contract ERC2981 is IERC2981, ERC165 {

contracts/token/common/README.adoc

@@ -2,8 +2,8 @@
 
 Functionality that is common to multiple token standards.
 
-* {ERC2981}: NFT Royalties compatible with both ERC721 and ERC1155.
-** For ERC721 consider {ERC721Royalty} which clears the royalty information from storage on burn.
+* {ERC2981}: NFT Royalties compatible with both ERC-721 and ERC-1155.
+** For ERC-721 consider {ERC721Royalty} which clears the royalty information from storage on burn.
 
 == Contracts
 

contracts/utils/README.adoc

@@ -49,7 +49,7 @@ Because Solidity does not support generic types, {EnumerableMap} and {Enumerable
 
 This set of interfaces and contracts deal with https://en.wikipedia.org/wiki/Type_introspection[type introspection] of contracts, that is, examining which functions can be called on them. This is usually referred to as a contract's _interface_.
 
-Ethereum contracts have no native concept of an interface, so applications must usually simply trust they are not making an incorrect call. For trusted setups this is a non-issue, but often unknown and untrusted third-party addresses need to be interacted with. There may even not be any direct calls to them! (e.g. `ERC20` tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever). In these cases, a contract _declaring_ its interface can be very helpful in preventing errors.
+Ethereum contracts have no native concept of an interface, so applications must usually simply trust they are not making an incorrect call. For trusted setups this is a non-issue, but often unknown and untrusted third-party addresses need to be interacted with. There may even not be any direct calls to them! (e.g. ERC-20 tokens may be sent to a contract that lacks a way to transfer them out of it, locking them forever). In these cases, a contract _declaring_ its interface can be very helpful in preventing errors.
 
 {{IERC165}}
 

contracts/utils/StorageSlot.sol

@@ -12,7 +12,7 @@ pragma solidity ^0.8.20;
  *
  * The functions in this library return Slot structs that contain a `value` member that can be used to read or write.
  *
- * Example usage to set ERC1967 implementation slot:
+ * Example usage to set ERC-1967 implementation slot:
  * ```solidity
  * contract ERC1967 {
  *     bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

contracts/utils/cryptography/ECDSA.sol

@@ -95,7 +95,7 @@ library ECDSA {
     /**
      * @dev Overload of {ECDSA-tryRecover} that receives the `r` and `vs` short-signature fields separately.
      *
-     * See https://eips.ethereum.org/EIPS/eip-2098[EIP-2098 short signatures]
+     * See https://eips.ethereum.org/EIPS/eip-2098[ERC-2098 short signatures]
      */
     function tryRecover(bytes32 hash, bytes32 r, bytes32 vs) internal pure returns (address, RecoverError, bytes32) {
         unchecked {

contracts/utils/cryptography/EIP712.sol

@@ -8,14 +8,14 @@ import {ShortStrings, ShortString} from "../ShortStrings.sol";
 import {IERC5267} from "../../interfaces/IERC5267.sol";
 
 /**
- * @dev https://eips.ethereum.org/EIPS/eip-712[EIP 712] is a standard for hashing and signing of typed structured data.
+ * @dev https://eips.ethereum.org/EIPS/eip-712[EIP-712] is a standard for hashing and signing of typed structured data.
  *
  * The encoding scheme specified in the EIP requires a domain separator and a hash of the typed structured data, whose
  * encoding is very generic and therefore its implementation in Solidity is not feasible, thus this contract
  * does not implement the encoding itself. Protocols need to implement the type-specific encoding they need in order to
  * produce the hash of their typed data using a combination of `abi.encode` and `keccak256`.
  *
- * This contract implements the EIP 712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding
+ * This contract implements the EIP-712 domain separator ({_domainSeparatorV4}) that is used as part of the encoding
  * scheme, and the final step of the encoding to obtain the message digest that is then signed via ECDSA
  * ({_hashTypedDataV4}).
  *
@@ -55,7 +55,7 @@ abstract contract EIP712 is IERC5267 {
      * @dev Initializes the domain separator and parameter caches.
      *
      * The meaning of `name` and `version` is specified in
-     * https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP 712]:
+     * https://eips.ethereum.org/EIPS/eip-712#definition-of-domainseparator[EIP-712]:
      *
      * - `name`: the user readable name of the signing domain, i.e. the name of the DApp or the protocol.
      * - `version`: the current major version of the signing domain.

contracts/utils/cryptography/MessageHashUtils.sol

@@ -9,12 +9,12 @@ import {Strings} from "../Strings.sol";
  * @dev Signature message hash utilities for producing digests to be consumed by {ECDSA} recovery or signing.
  *
  * The library provides methods for generating a hash of a message that conforms to the
- * https://eips.ethereum.org/EIPS/eip-191[EIP 191] and https://eips.ethereum.org/EIPS/eip-712[EIP 712]
+ * https://eips.ethereum.org/EIPS/eip-191[ERC-191] and https://eips.ethereum.org/EIPS/eip-712[EIP 712]
  * specifications.
  */
 library MessageHashUtils {
     /**
-     * @dev Returns the keccak256 digest of an EIP-191 signed data with version
+     * @dev Returns the keccak256 digest of an ERC-191 signed data with version
      * `0x45` (`personal_sign` messages).
      *
      * The digest is calculated by prefixing a bytes32 `messageHash` with
@@ -37,7 +37,7 @@ library MessageHashUtils {
     }
 
     /**
-     * @dev Returns the keccak256 digest of an EIP-191 signed data with version
+     * @dev Returns the keccak256 digest of an ERC-191 signed data with version
      * `0x45` (`personal_sign` messages).
      *
      * The digest is calculated by prefixing an arbitrary `message` with
@@ -52,7 +52,7 @@ library MessageHashUtils {
     }
 
     /**
-     * @dev Returns the keccak256 digest of an EIP-191 signed data with version
+     * @dev Returns the keccak256 digest of an ERC-191 signed data with version
      * `0x00` (data with intended validator).
      *
      * The digest is calculated by prefixing an arbitrary `data` with `"\x19\x00"` and the intended
@@ -65,7 +65,7 @@ library MessageHashUtils {
     }
 
     /**
-     * @dev Returns the keccak256 digest of an EIP-712 typed data (EIP-191 version `0x01`).
+     * @dev Returns the keccak256 digest of an EIP-712 typed data (ERC-191 version `0x01`).
      *
      * The digest is calculated from a `domainSeparator` and a `structHash`, by prefixing them with
      * `\x19\x01` and hashing the result. It corresponds to the hash signed by the

contracts/utils/cryptography/SignatureChecker.sol

@@ -8,13 +8,13 @@ import {IERC1271} from "../../interfaces/IERC1271.sol";
 
 /**
  * @dev Signature verification helper that can be used instead of `ECDSA.recover` to seamlessly support both ECDSA
- * signatures from externally owned accounts (EOAs) as well as ERC1271 signatures from smart contract wallets like
+ * signatures from externally owned accounts (EOAs) as well as ERC-1271 signatures from smart contract wallets like
  * Argent and Safe Wallet (previously Gnosis Safe).
  */
 library SignatureChecker {
     /**
      * @dev Checks if a signature is valid for a given signer and data hash. If the signer is a smart contract, the
-     * signature is validated against that smart contract using ERC1271, otherwise it's validated using `ECDSA.recover`.
+     * signature is validated against that smart contract using ERC-1271, otherwise it's validated using `ECDSA.recover`.
      *
      * NOTE: Unlike ECDSA signatures, contract signatures are revocable, and the outcome of this function can thus
      * change through time. It could return true at block N and false at block N+1 (or the opposite).
@@ -28,7 +28,7 @@ library SignatureChecker {
 
     /**
      * @dev Checks if a signature is valid for a given signer and data hash. The signature is validated
-     * against the signer smart contract using ERC1271.
+     * against the signer smart contract using ERC-1271.
      *
      * NOTE: Unlike ECDSA signatures, contract signatures are revocable, and the outcome of this function can thus
      * change through time. It could return true at block N and false at block N+1 (or the opposite).

contracts/utils/introspection/ERC165.sol

@@ -8,7 +8,7 @@ import {IERC165} from "./IERC165.sol";
 /**
  * @dev Implementation of the {IERC165} interface.
  *
- * Contracts that want to implement ERC165 should inherit from this contract and override {supportsInterface} to check
+ * Contracts that want to implement ERC-165 should inherit from this contract and override {supportsInterface} to check
  * for the additional interface id that will be supported. For example:
  *
  * ```solidity

contracts/utils/introspection/ERC165Checker.sol

@@ -13,14 +13,14 @@ import {IERC165} from "./IERC165.sol";
  * what to do in these cases.
  */
 library ERC165Checker {
-    // As per the EIP-165 spec, no interface should ever match 0xffffffff
+    // As per the ERC-165 spec, no interface should ever match 0xffffffff
     bytes4 private constant INTERFACE_ID_INVALID = 0xffffffff;
 
     /**
      * @dev Returns true if `account` supports the {IERC165} interface.
      */
     function supportsERC165(address account) internal view returns (bool) {
-        // Any contract that implements ERC165 must explicitly indicate support of
+        // Any contract that implements ERC-165 must explicitly indicate support of
         // InterfaceId_ERC165 and explicitly indicate non-support of InterfaceId_Invalid
         return
             supportsERC165InterfaceUnchecked(account, type(IERC165).interfaceId) &&
@@ -34,7 +34,7 @@ library ERC165Checker {
      * See {IERC165-supportsInterface}.
      */
     function supportsInterface(address account, bytes4 interfaceId) internal view returns (bool) {
-        // query support of both ERC165 as per the spec and support of _interfaceId
+        // query support of both ERC-165 as per the spec and support of _interfaceId
         return supportsERC165(account) && supportsERC165InterfaceUnchecked(account, interfaceId);
     }
 
@@ -53,7 +53,7 @@ library ERC165Checker {
         // an array of booleans corresponding to interfaceIds and whether they're supported or not
         bool[] memory interfaceIdsSupported = new bool[](interfaceIds.length);
 
-        // query support of ERC165 itself
+        // query support of ERC-165 itself
         if (supportsERC165(account)) {
             // query support of each interface in interfaceIds
             for (uint256 i = 0; i < interfaceIds.length; i++) {
@@ -74,7 +74,7 @@ library ERC165Checker {
      * See {IERC165-supportsInterface}.
      */
     function supportsAllInterfaces(address account, bytes4[] memory interfaceIds) internal view returns (bool) {
-        // query support of ERC165 itself
+        // query support of ERC-165 itself
         if (!supportsERC165(account)) {
             return false;
         }
@@ -91,12 +91,12 @@ library ERC165Checker {
     }
 
     /**
-     * @notice Query if a contract implements an interface, does not check ERC165 support
+     * @notice Query if a contract implements an interface, does not check ERC-165 support
      * @param account The address of the contract to query for support of an interface
      * @param interfaceId The interface identifier, as specified in ERC-165
      * @return true if the contract at account indicates support of the interface with
      * identifier interfaceId, false otherwise
-     * @dev Assumes that account contains a contract that supports ERC165, otherwise
+     * @dev Assumes that account contains a contract that supports ERC-165, otherwise
      * the behavior of this method is undefined. This precondition can be checked
      * with {supportsERC165}.
      *

contracts/utils/introspection/IERC165.sol

@@ -4,8 +4,8 @@
 pragma solidity ^0.8.20;
 
 /**
- * @dev Interface of the ERC165 standard, as defined in the
- * https://eips.ethereum.org/EIPS/eip-165[EIP].
+ * @dev Interface of the ERC-165 standard, as defined in the
+ * https://eips.ethereum.org/EIPS/eip-165[ERC].
  *
  * Implementers can declare support of contract interfaces, which can then be
  * queried by others ({ERC165Checker}).
@@ -16,7 +16,7 @@ interface IERC165 {
     /**
      * @dev Returns true if this contract implements the interface defined by
      * `interfaceId`. See the corresponding
-     * https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[EIP section]
+     * https://eips.ethereum.org/EIPS/eip-165#how-interfaces-are-identified[ERC section]
      * to learn more about how these ids are created.
      *
      * This function call must use less than 30 000 gas.

docs/modules/ROOT/nav.adoc

@@ -8,11 +8,11 @@
 * xref:access-control.adoc[Access Control]
 
 * xref:tokens.adoc[Tokens]
-** xref:erc20.adoc[ERC20]
+** xref:erc20.adoc[ERC-20]
 *** xref:erc20-supply.adoc[Creating Supply]
-** xref:erc721.adoc[ERC721]
-** xref:erc1155.adoc[ERC1155]
-** xref:erc4626.adoc[ERC4626]
+** xref:erc721.adoc[ERC-721]
+** xref:erc1155.adoc[ERC-1155]
+** xref:erc4626.adoc[ERC-4626]
 
 * xref:governance.adoc[Governance]
 

docs/modules/ROOT/pages/access-control.adoc

@@ -43,7 +43,7 @@ Most software uses access control systems that are role-based: some users are re
 OpenZeppelin Contracts provides xref:api:access.adoc#AccessControl[`AccessControl`] for implementing role-based access control. Its usage is straightforward: for each role that you want to define,
 you will create a new _role identifier_ that is used to grant, revoke, and check if an account has that role.
 
-Here's a simple example of using `AccessControl` in an xref:erc20.adoc[`ERC20` token] to define a 'minter' role, which allows accounts that have it create new tokens:
+Here's a simple example of using `AccessControl` in an xref:erc20.adoc[ERC-20 token] to define a 'minter' role, which allows accounts that have it create new tokens:
 
 [source,solidity]
 ----
@@ -54,7 +54,7 @@ NOTE: Make sure you fully understand how xref:api:access.adoc#AccessControl[`Acc
 
 While clear and explicit, this isn't anything we wouldn't have been able to achieve with `Ownable`. Indeed, where `AccessControl` shines is in scenarios where granular permissions are required, which can be implemented by defining _multiple_ roles.
 
-Let's augment our ERC20 token example by also defining a 'burner' role, which lets accounts destroy tokens, and by using the `onlyRole` modifier:
+Let's augment our ERC-20 token example by also defining a 'burner' role, which lets accounts destroy tokens, and by using the `onlyRole` modifier:
 
 [source,solidity]
 ----
@@ -66,7 +66,7 @@ So clean! By splitting concerns this way, more granular levels of permission may
 [[granting-and-revoking]]
 === Granting and Revoking Roles
 
-The ERC20 token example above uses `_grantRole`, an `internal` function that is useful when programmatically assigning roles (such as during construction). But what if we later want to grant the 'minter' role to additional accounts?
+The ERC-20 token example above uses `_grantRole`, an `internal` function that is useful when programmatically assigning roles (such as during construction). But what if we later want to grant the 'minter' role to additional accounts?
 
 By default, **accounts with a role cannot grant it or revoke it from other accounts**: all having a role does is making the `hasRole` check pass. To grant and revoke roles dynamically, you will need help from the _role's admin_.
 
@@ -76,7 +76,7 @@ This mechanism can be used to create complex permissioning structures resembling
 
 Since it is the admin for all roles by default, and in fact it is also its own admin, this role carries significant risk. To mitigate this risk we provide xref:api:access.adoc#AccessControlDefaultAdminRules[`AccessControlDefaultAdminRules`], a recommended extension of `AccessControl` that adds a number of enforced security measures for this role: the admin is restricted to a single account, with a 2-step transfer procedure with a delay in between steps.
 
-Let's take a look at the ERC20 token example, this time taking advantage of the default admin role:
+Let's take a look at the ERC-20 token example, this time taking advantage of the default admin role:
 
 [source,solidity]
 ----
@@ -165,7 +165,7 @@ OpenZeppelin Contracts provides xref:api:access.adoc#AccessManager[`AccessManage
 
 In order to restrict access to some functions of your contract, you should inherit from the xref:api:access.adoc#AccessManaged[`AccessManaged`] contract provided along with the manager. This provides the `restricted` modifier that can be used to protect any externally facing function. Note that you will have to specify the address of the AccessManager instance (xref:api:access.adoc#AccessManaged-constructor-address-[`initialAuthority`]) in the constructor so the `restricted` modifier knows which manager to use for checking permissions.
 
-Here's a simple example of an xref:tokens.adoc#ERC20[`ERC20` token] that defines a `mint` function that is restricted by an xref:api:access.adoc#AccessManager[`AccessManager`]:
+Here's a simple example of an xref:tokens.adoc#ERC20[ERC-20 token] that defines a `mint` function that is restricted by an xref:api:access.adoc#AccessManager[`AccessManager`]:
 
 ```solidity
 include::api:example$access-control/AccessManagedERC20MintBase.sol[]

docs/modules/ROOT/pages/erc1155.adoc

@@ -1,17 +1,17 @@
-= ERC1155
+= ERC-1155
 
-ERC1155 is a novel token standard that aims to take the best from previous standards to create a xref:tokens.adoc#different-kinds-of-tokens[*fungibility-agnostic*] and *gas-efficient* xref:tokens.adoc#but_first_coffee_a_primer_on_token_contracts[token contract].
+ERC-1155 is a novel token standard that aims to take the best from previous standards to create a xref:tokens.adoc#different-kinds-of-tokens[*fungibility-agnostic*] and *gas-efficient* xref:tokens.adoc#but_first_coffee_a_primer_on_token_contracts[token contract].
 
-TIP: ERC1155 draws ideas from all of xref:erc20.adoc[ERC20], xref:erc721.adoc[ERC721], and https://eips.ethereum.org/EIPS/eip-777[ERC777]. If you're unfamiliar with those standards, head to their guides before moving on.
+TIP: ERC-1155 draws ideas from all of xref:erc20.adoc[ERC-20], xref:erc721.adoc[ERC-721], and https://eips.ethereum.org/EIPS/eip-777[ERC-777]. If you're unfamiliar with those standards, head to their guides before moving on.
 
 [[multi-token-standard]]
 == Multi Token Standard
 
-The distinctive feature of ERC1155 is that it uses a single smart contract to represent multiple tokens at once. This is why its xref:api:token/ERC1155.adoc#IERC1155-balanceOf-address-uint256-[`balanceOf`] function differs from ERC20's and ERC777's: it has an additional `id` argument for the identifier of the token that you want to query the balance of.
+The distinctive feature of ERC-1155 is that it uses a single smart contract to represent multiple tokens at once. This is why its xref:api:token/ERC1155.adoc#IERC1155-balanceOf-address-uint256-[`balanceOf`] function differs from ERC-20's and ERC-777's: it has an additional `id` argument for the identifier of the token that you want to query the balance of.
 
-This is similar to how ERC721 does things, but in that standard a token `id` has no concept of balance: each token is non-fungible and exists or doesn't. The ERC721 xref:api:token/ERC721.adoc#IERC721-balanceOf-address-[`balanceOf`] function refers to _how many different tokens_ an account has, not how many of each. On the other hand, in ERC1155 accounts have a distinct balance for each token `id`, and non-fungible tokens are implemented by simply minting a single one of them.
+This is similar to how ERC-721 does things, but in that standard a token `id` has no concept of balance: each token is non-fungible and exists or doesn't. The ERC-721 xref:api:token/ERC721.adoc#IERC721-balanceOf-address-[`balanceOf`] function refers to _how many different tokens_ an account has, not how many of each. On the other hand, in ERC-1155 accounts have a distinct balance for each token `id`, and non-fungible tokens are implemented by simply minting a single one of them.
 
-This approach leads to massive gas savings for projects that require multiple tokens. Instead of deploying a new contract for each token type, a single ERC1155 token contract can hold the entire system state, reducing deployment costs and complexity.
+This approach leads to massive gas savings for projects that require multiple tokens. Instead of deploying a new contract for each token type, a single ERC-1155 token contract can hold the entire system state, reducing deployment costs and complexity.
 
 [[batch-operations]]
 == Batch Operations
@@ -20,13 +20,13 @@ Because all state is held in a single contract, it is possible to operate over m
 
 In the spirit of the standard, we've also included batch operations in the non-standard functions, such as xref:api:token/ERC1155.adoc#ERC1155-_mintBatch-address-uint256---uint256---bytes-[`_mintBatch`].
 
-== Constructing an ERC1155 Token Contract
+== Constructing an ERC-1155 Token Contract
 
-We'll use ERC1155 to track multiple items in our game, which will each have their own unique attributes. We mint all items to the deployer of the contract, which we can later transfer to players. Players are free to keep their tokens or trade them with other people as they see fit, as they would any other asset on the blockchain!
+We'll use ERC-1155 to track multiple items in our game, which will each have their own unique attributes. We mint all items to the deployer of the contract, which we can later transfer to players. Players are free to keep their tokens or trade them with other people as they see fit, as they would any other asset on the blockchain!
 
 For simplicity, we will mint all items in the constructor, but you could add minting functionality to the contract to mint on demand to players.
 
-TIP: For an overview of minting mechanisms, check out xref:erc20-supply.adoc[Creating ERC20 Supply].
+TIP: For an overview of minting mechanisms, check out xref:erc20-supply.adoc[Creating ERC-20 Supply].
 
 Here's what a contract for tokenized items might look like:
 
@@ -59,7 +59,7 @@ Note that for our Game Items, Gold is a fungible token whilst Thor's Hammer is a
 
 The xref:api:token/ERC1155.adoc#ERC1155[`ERC1155`] contract includes the optional extension xref:api:token/ERC1155.adoc#IERC1155MetadataURI[`IERC1155MetadataURI`]. That's where the xref:api:token/ERC1155.adoc#IERC1155MetadataURI-uri-uint256-[`uri`] function comes from: we use it to retrieve the metadata uri.
 
-Also note that, unlike ERC20, ERC1155 lacks a `decimals` field, since each token is distinct and cannot be partitioned.
+Also note that, unlike ERC-20, ERC-1155 lacks a `decimals` field, since each token is distinct and cannot be partitioned.
 
 Once deployed, we will be able to query the deployer’s balance:
 [source,javascript]
@@ -114,7 +114,7 @@ For more information about the metadata JSON Schema, check out the https://githu
 
 NOTE: You'll notice that the item's information is included in the metadata, but that information isn't on-chain! So a game developer could change the underlying metadata, changing the rules of the game!
 
-TIP: If you'd like to put all item information on-chain, you can extend ERC721 to do so (though it will be rather costly) by providing a xref:utilities.adoc#base64[`Base64`] Data URI with the JSON schema encoded. You could also leverage IPFS to store the URI information, but these techniques are out of the scope of this overview guide
+TIP: If you'd like to put all item information on-chain, you can extend ERC-721 to do so (though it will be rather costly) by providing a xref:utilities.adoc#base64[`Base64`] Data URI with the JSON schema encoded. You could also leverage IPFS to store the URI information, but these techniques are out of the scope of this overview guide
 
 [[sending-to-contracts]]
 == Sending Tokens to Contracts
@@ -123,12 +123,12 @@ A key difference when using xref:api:token/ERC1155.adoc#IERC1155-safeTransferFro
 
 [source,text]
 ----
-ERC1155: transfer to non ERC1155Receiver implementer
+ERC-1155: transfer to non ERC-1155 Receiver implementer
 ----
 
-This is a good thing! It means that the recipient contract has not registered itself as aware of the ERC1155 protocol, so transfers to it are disabled to *prevent tokens from being locked forever*. As an example, https://etherscan.io/token/0xa74476443119A942dE498590Fe1f2454d7D4aC0d?a=0xa74476443119A942dE498590Fe1f2454d7D4aC0d[the Golem contract currently holds over 350k `GNT` tokens], worth multiple tens of thousands of dollars, and lacks methods to get them out of there. This has happened to virtually every ERC20-backed project, usually due to user error.
+This is a good thing! It means that the recipient contract has not registered itself as aware of the ERC-1155 protocol, so transfers to it are disabled to *prevent tokens from being locked forever*. As an example, https://etherscan.io/token/0xa74476443119A942dE498590Fe1f2454d7D4aC0d?a=0xa74476443119A942dE498590Fe1f2454d7D4aC0d[the Golem contract currently holds over 350k `GNT` tokens], worth multiple tens of thousands of dollars, and lacks methods to get them out of there. This has happened to virtually every ERC20-backed project, usually due to user error.
 
-In order for our contract to receive ERC1155 tokens we can inherit from the convenience contract xref:api:token/ERC1155.adoc#ERC1155Holder[`ERC1155Holder`] which handles the registering for us.  Though we need to remember to implement functionality to allow tokens to be transferred out of our contract:
+In order for our contract to receive ERC-1155 tokens we can inherit from the convenience contract xref:api:token/ERC1155.adoc#ERC1155Holder[`ERC1155Holder`] which handles the registering for us.  Though we need to remember to implement functionality to allow tokens to be transferred out of our contract:
 
 [source,solidity]
 ----

docs/modules/ROOT/pages/erc20-supply.adoc

@@ -1,10 +1,10 @@
-= Creating ERC20 Supply
+= Creating ERC-20 Supply
 
-In this guide, you will learn how to create an ERC20 token with a custom supply mechanism. We will showcase two idiomatic ways to use OpenZeppelin Contracts for this purpose that you will be able to apply to your smart contract development practice.
+In this guide, you will learn how to create an ERC-20 token with a custom supply mechanism. We will showcase two idiomatic ways to use OpenZeppelin Contracts for this purpose that you will be able to apply to your smart contract development practice.
 
-The standard interface implemented by tokens built on Ethereum is called ERC20, and Contracts includes a widely used implementation of it: the aptly named xref:api:token/ERC20.adoc[`ERC20`] contract. This contract, like the standard itself, is quite simple and bare-bones. In fact, if you try to deploy an instance of `ERC20` as-is it will be quite literally useless... it will have no supply! What use is a token with no supply?
+The standard interface implemented by tokens built on Ethereum is called ERC-20, and Contracts includes a widely used implementation of it: the aptly named xref:api:token/ERC20.adoc[`ERC20`] contract. This contract, like the standard itself, is quite simple and bare-bones. In fact, if you try to deploy an instance of `ERC20` as-is it will be quite literally useless... it will have no supply! What use is a token with no supply?
 
-The way that supply is created is not defined in the ERC20 document. Every token is free to experiment with its own mechanisms, ranging from the most decentralized to the most centralized, from the most naive to the most researched, and more.
+The way that supply is created is not defined in the ERC-20 document. Every token is free to experiment with its own mechanisms, ranging from the most decentralized to the most centralized, from the most naive to the most researched, and more.
 
 [[fixed-supply]]
 == Fixed Supply
@@ -37,7 +37,7 @@ Encapsulating state like this makes it safer to extend contracts. For instance,
 [[rewarding-miners]]
 == Rewarding Miners
 
-The internal xref:api:token/ERC20.adoc#ERC20-_mint-address-uint256-[`_mint`] function is the key building block that allows us to write ERC20 extensions that implement a supply mechanism.
+The internal xref:api:token/ERC20.adoc#ERC20-_mint-address-uint256-[`_mint`] function is the key building block that allows us to write ERC-20 extensions that implement a supply mechanism.
 
 The mechanism we will implement is a token reward for the miners that produce Ethereum blocks. In Solidity, we can access the address of the current block's miner in the global variable `block.coinbase`. We will mint a token reward to this address whenever someone calls the function `mintMinerReward()` on our token. The mechanism may sound silly, but you never know what kind of dynamic this might result in, and it's worth analyzing and experimenting with!
 
@@ -68,4 +68,4 @@ include::api:example$ERC20WithAutoMinerReward.sol[]
 [[wrapping-up]]
 == Wrapping Up
 
-We've seen how to implement a ERC20 supply mechanism: internally through `_mint`. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts.
+We've seen how to implement a ERC-20 supply mechanism: internally through `_mint`. Hopefully this has helped you understand how to use OpenZeppelin Contracts and some of the design principles behind it, and you can apply them to your own smart contracts.

docs/modules/ROOT/pages/erc20.adoc

@@ -1,13 +1,13 @@
-= ERC20
+= ERC-20
 
-An ERC20 token contract keeps track of xref:tokens.adoc#different-kinds-of-tokens[_fungible_ tokens]: any one token is exactly equal to any other token; no tokens have special rights or behavior associated with them. This makes ERC20 tokens useful for things like a *medium of exchange currency*, *voting rights*, *staking*, and more.
+An ERC-20 token contract keeps track of xref:tokens.adoc#different-kinds-of-tokens[_fungible_ tokens]: any one token is exactly equal to any other token; no tokens have special rights or behavior associated with them. This makes ERC-20 tokens useful for things like a *medium of exchange currency*, *voting rights*, *staking*, and more.
 
 OpenZeppelin Contracts provides many ERC20-related contracts. On the xref:api:token/ERC20.adoc[`API reference`] you'll find detailed information on their properties and usage.
 
 [[constructing-an-erc20-token-contract]]
-== Constructing an ERC20 Token Contract
+== Constructing an ERC-20 Token Contract
 
-Using Contracts, we can easily create our own ERC20 token contract, which will be used to track _Gold_ (GLD), an internal currency in a hypothetical game.
+Using Contracts, we can easily create our own ERC-20 token contract, which will be used to track _Gold_ (GLD), an internal currency in a hypothetical game.
 
 Here's what our GLD token might look like.
 
@@ -28,7 +28,7 @@ contract GLDToken is ERC20 {
 
 Our contracts are often used via https://solidity.readthedocs.io/en/latest/contracts.html#inheritance[inheritance], and here we're reusing xref:api:token/ERC20.adoc#erc20[`ERC20`] for both the basic standard implementation and the xref:api:token/ERC20.adoc#ERC20-name--[`name`], xref:api:token/ERC20.adoc#ERC20-symbol--[`symbol`], and xref:api:token/ERC20.adoc#ERC20-decimals--[`decimals`] optional extensions. Additionally, we're creating an `initialSupply` of tokens, which will be assigned to the address that deploys the contract.
 
-TIP: For a more complete discussion of ERC20 supply mechanisms, see xref:erc20-supply.adoc[Creating ERC20 Supply].
+TIP: For a more complete discussion of ERC-20 supply mechanisms, see xref:erc20-supply.adoc[Creating ERC-20 Supply].
 
 That's it! Once deployed, we will be able to query the deployer's balance:
 
@@ -60,7 +60,7 @@ How can this be achieved? It's actually very simple: a token contract can use la
 
 It is important to understand that `decimals` is _only used for display purposes_. All arithmetic inside the contract is still performed on integers, and it is the different user interfaces (wallets, exchanges, etc.) that must adjust the displayed values according to `decimals`. The total token supply and balance of each account are not specified in `GLD`: you need to divide by `10 ** decimals` to get the actual `GLD` amount.
 
-You'll probably want to use a `decimals` value of `18`, just like Ether and most ERC20 token contracts in use, unless you have a very special reason not to. When minting tokens or transferring them around, you will be actually sending the number `num GLD * (10 ** decimals)`.
+You'll probably want to use a `decimals` value of `18`, just like Ether and most ERC-20 token contracts in use, unless you have a very special reason not to. When minting tokens or transferring them around, you will be actually sending the number `num GLD * (10 ** decimals)`.
 
 NOTE: By default, `ERC20` uses a value of `18` for `decimals`. To use a different value, you will need to override the `decimals()` function in your contract.
 

docs/modules/ROOT/pages/erc4626.adoc

@@ -1,16 +1,16 @@
-= ERC4626
+= ERC-4626
 :stem: latexmath
 
-https://eips.ethereum.org/EIPS/eip-4626[ERC4626] is an extension of xref:erc20.adoc[ERC20] that proposes a standard interface for token vaults. This standard interface can be used by widely different contracts (including lending markets, aggregators, and intrinsically interest bearing tokens), which brings a number of subtleties. Navigating these potential issues is essential to implementing a compliant and composable token vault.
+https://eips.ethereum.org/EIPS/eip-4626[ERC-4626] is an extension of xref:erc20.adoc[ERC-20] that proposes a standard interface for token vaults. This standard interface can be used by widely different contracts (including lending markets, aggregators, and intrinsically interest bearing tokens), which brings a number of subtleties. Navigating these potential issues is essential to implementing a compliant and composable token vault.
 
-We provide a base implementation of ERC4626 that includes a simple vault. This contract is designed in a way that allows developers to easily re-configure the vault's behavior, with minimal overrides, while staying compliant. In this guide, we will discuss some security considerations that affect ERC4626. We will also discuss common customizations of the vault.
+We provide a base implementation of ERC-4626 that includes a simple vault. This contract is designed in a way that allows developers to easily re-configure the vault's behavior, with minimal overrides, while staying compliant. In this guide, we will discuss some security considerations that affect ERC-4626. We will also discuss common customizations of the vault.
 
 [[inflation-attack]]
 == Security concern: Inflation attack
 
 === Visualizing the vault
 
-In exchange for the assets deposited into an ERC4626 vault, a user receives shares. These shares can later be burned to redeem the corresponding underlying assets. The number of shares a user gets depends on the amount of assets they put in and on the exchange rate of the vault. This exchange rate is defined by the current liquidity held by the vault.
+In exchange for the assets deposited into an ERC-4626 vault, a user receives shares. These shares can later be burned to redeem the corresponding underlying assets. The number of shares a user gets depends on the amount of assets they put in and on the exchange rate of the vault. This exchange rate is defined by the current liquidity held by the vault.
 
 - If a vault has 100 tokens to back 200 shares, then each share is worth 0.5 assets.
 - If a vault has 200 tokens to back 100 shares, then each share is worth 2.0 assets.
@@ -195,7 +195,7 @@ stem:[\delta = 6], stem:[a_0 = 1], stem:[a_1 = 10^5]
 [[fees]]
 == Custom behavior: Adding fees to the vault
 
-In an ERC4626 vaults, fees can be captured during the deposit/mint and/or during the withdraw/redeem steps. In both cases it is essential to remain compliant with the ERC4626 requirements with regard to the preview functions.
+In an ERC-4626 vaults, fees can be captured during the deposit/mint and/or during the withdraw/redeem steps. In both cases it is essential to remain compliant with the ERC-4626 requirements with regard to the preview functions.
 
 For example, if calling `deposit(100, receiver)`, the caller should deposit exactly 100 underlying tokens, including fees, and the receiver should receive a number of shares that matches the value returned by `previewDeposit(100)`. Similarly, `previewMint` should account for the fees that the user will have to pay on top of share's cost.
 

docs/modules/ROOT/pages/erc721.adoc

@@ -1,12 +1,12 @@
-= ERC721
+= ERC-721
 
-We've discussed how you can make a _fungible_ token using xref:erc20.adoc[ERC20], but what if not all tokens are alike? This comes up in situations like *real estate*, *voting rights*, or *collectibles*, where some items are valued more than others, due to their usefulness, rarity, etc. ERC721 is a standard for representing ownership of xref:tokens.adoc#different-kinds-of-tokens[_non-fungible_ tokens], that is, where each token is unique.
+We've discussed how you can make a _fungible_ token using xref:erc20.adoc[ERC-20], but what if not all tokens are alike? This comes up in situations like *real estate*, *voting rights*, or *collectibles*, where some items are valued more than others, due to their usefulness, rarity, etc. ERC-721 is a standard for representing ownership of xref:tokens.adoc#different-kinds-of-tokens[_non-fungible_ tokens], that is, where each token is unique.
 
-ERC721 is a more complex standard than ERC20, with multiple optional extensions, and is split across a number of contracts. The OpenZeppelin Contracts provide flexibility regarding how these are combined, along with custom useful extensions. Check out the xref:api:token/ERC721.adoc[API Reference] to learn more about these.
+ERC-721 is a more complex standard than ERC-20, with multiple optional extensions, and is split across a number of contracts. The OpenZeppelin Contracts provide flexibility regarding how these are combined, along with custom useful extensions. Check out the xref:api:token/ERC721.adoc[API Reference] to learn more about these.
 
-== Constructing an ERC721 Token Contract
+== Constructing an ERC-721 Token Contract
 
-We'll use ERC721 to track items in our game, which will each have their own unique attributes. Whenever one is to be awarded to a player, it will be minted and sent to them. Players are free to keep their token or trade it with other people as they see fit, as they would any other asset on the blockchain!  Please note any account can call `awardItem` to mint items.  To restrict what accounts can mint items we can add xref:access-control.adoc[Access Control].
+We'll use ERC-721 to track items in our game, which will each have their own unique attributes. Whenever one is to be awarded to a player, it will be minted and sent to them. Players are free to keep their token or trade it with other people as they see fit, as they would any other asset on the blockchain!  Please note any account can call `awardItem` to mint items.  To restrict what accounts can mint items we can add xref:access-control.adoc[Access Control].
 
 Here's what a contract for tokenized items might look like:
 
@@ -36,9 +36,9 @@ contract GameItem is ERC721URIStorage {
 }
 ----
 
-The xref:api:token/ERC721.adoc#ERC721URIStorage[`ERC721URIStorage`] contract is an implementation of ERC721 that includes the metadata standard extensions (xref:api:token/ERC721.adoc#IERC721Metadata[`IERC721Metadata`]) as well as a mechanism for per-token metadata. That's where the xref:api:token/ERC721.adoc#ERC721-_setTokenURI-uint256-string-[`_setTokenURI`] method comes from: we use it to store an item's metadata.
+The xref:api:token/ERC721.adoc#ERC721URIStorage[`ERC721URIStorage`] contract is an implementation of ERC-721 that includes the metadata standard extensions (xref:api:token/ERC721.adoc#IERC721Metadata[`IERC721Metadata`]) as well as a mechanism for per-token metadata. That's where the xref:api:token/ERC721.adoc#ERC721-_setTokenURI-uint256-string-[`_setTokenURI`] method comes from: we use it to store an item's metadata.
 
-Also note that, unlike ERC20, ERC721 lacks a `decimals` field, since each token is distinct and cannot be partitioned.
+Also note that, unlike ERC-20, ERC-721 lacks a `decimals` field, since each token is distinct and cannot be partitioned.
 
 New items can be created:
 
@@ -72,8 +72,8 @@ This `tokenURI` should resolve to a JSON document that might look something like
 }
 ----
 
-For more information about the `tokenURI` metadata JSON Schema, check out the https://eips.ethereum.org/EIPS/eip-721[ERC721 specification].
+For more information about the `tokenURI` metadata JSON Schema, check out the https://eips.ethereum.org/EIPS/eip-721[ERC-721 specification].
 
 NOTE: You'll notice that the item's information is included in the metadata, but that information isn't on-chain! So a game developer could change the underlying metadata, changing the rules of the game! 
 
-TIP: If you'd like to put all item information on-chain, you can extend ERC721 to do so (though it will be rather costly) by providing a xref:utilities.adoc#base64[`Base64`] Data URI with the JSON schema encoded. You could also leverage IPFS to store the tokenURI information, but these techniques are out of the scope of this overview guide.
+TIP: If you'd like to put all item information on-chain, you can extend ERC-721 to do so (though it will be rather costly) by providing a xref:utilities.adoc#base64[`Base64`] Data URI with the JSON schema encoded. You could also leverage IPFS to store the tokenURI information, but these techniques are out of the scope of this overview guide.

docs/modules/ROOT/pages/governance.adoc

@@ -16,7 +16,7 @@ OpenZeppelin’s Governor system was designed with a concern for compatibility w
 
 === ERC20Votes & ERC20VotesComp
 
-The ERC20 extension to keep track of votes and vote delegation is one such case. The shorter one is the more generic version because it can support token supplies greater than 2^96, while the “Comp” variant is limited in that regard, but exactly fits the interface of the COMP token that is used by GovernorAlpha and Bravo. Both contract variants share the same events, so they are fully compatible when looking at events only.
+The ERC-20 extension to keep track of votes and vote delegation is one such case. The shorter one is the more generic version because it can support token supplies greater than 2^96, while the “Comp” variant is limited in that regard, but exactly fits the interface of the COMP token that is used by GovernorAlpha and Bravo. Both contract variants share the same events, so they are fully compatible when looking at events only.
 
 === Governor & GovernorStorage
 
@@ -40,7 +40,7 @@ In the rest of this guide, we will focus on a fresh deploy of the vanilla OpenZe
 
 === Token
 
-The voting power of each account in our governance setup will be determined by an ERC20 token. The token has to implement the ERC20Votes extension. This extension will keep track of historical balances so that voting power is retrieved from past snapshots rather than current balance, which is an important protection that prevents double voting.
+The voting power of each account in our governance setup will be determined by an ERC-20 token. The token has to implement the ERC20Votes extension. This extension will keep track of historical balances so that voting power is retrieved from past snapshots rather than current balance, which is an important protection that prevents double voting.
 
 ```solidity
 include::api:example$governance/MyToken.sol[]
@@ -52,7 +52,7 @@ If your project already has a live token that does not include ERC20Votes and is
 include::api:example$governance/MyTokenWrapped.sol[]
 ```
 
-NOTE: The only other source of voting power available in OpenZeppelin Contracts currently is xref:api:token/ERC721.adoc#ERC721Votes[`ERC721Votes`]. ERC721 tokens that don't provide this functionality can be wrapped into a voting tokens using a combination of xref:api:token/ERC721.adoc#ERC721Votes[`ERC721Votes`] and xref:api:token/ERC721Wrapper.adoc#ERC721Wrapper[`ERC721Wrapper`].
+NOTE: The only other source of voting power available in OpenZeppelin Contracts currently is xref:api:token/ERC721.adoc#ERC721Votes[`ERC721Votes`]. ERC-721 tokens that don't provide this functionality can be wrapped into a voting tokens using a combination of xref:api:token/ERC721.adoc#ERC721Votes[`ERC721Votes`] and xref:api:token/ERC721Wrapper.adoc#ERC721Wrapper[`ERC721Wrapper`].
 
 NOTE: The internal clock used by the token to store voting balances will dictate the operating mode of the Governor contract attached to it. By default, block numbers are used. Since v4.9, developers can override the xref:api:interfaces.adoc#IERC6372[IERC6372] clock to use timestamps instead of block numbers.
 
@@ -60,7 +60,7 @@ NOTE: The internal clock used by the token to store voting balances will dictate
 
 Initially, we will build a Governor without a timelock. The core logic is given by the Governor contract, but we still need to choose: 1) how voting power is determined, 2) how many votes are needed for quorum, 3) what options people have when casting a vote and how those votes are counted, and 4) what type of token should be used to vote. Each of these aspects is customizable by writing your own module, or more easily choosing one from OpenZeppelin Contracts.
 
-For 1) we will use the GovernorVotes module, which hooks to an IVotes instance to determine the voting power of an account based on the token balance they hold when a proposal becomes active. This module requires as a constructor parameter the address of the token. This module also discovers the clock mode (ERC6372) used by the token and applies it to the Governor.
+For 1) we will use the GovernorVotes module, which hooks to an IVotes instance to determine the voting power of an account based on the token balance they hold when a proposal becomes active. This module requires as a constructor parameter the address of the token. This module also discovers the clock mode (ERC-6372) used by the token and applies it to the Governor.
 
 For 2) we will use GovernorVotesQuorumFraction which works together with ERC20Votes to define quorum as a percentage of the total supply at the block a proposal’s voting power is retrieved. This requires a constructor parameter to set the percentage. Most Governors nowadays use 4%, so we will initialize the module with parameter 4 (this indicates the percentage, resulting in 4%).
 
@@ -100,7 +100,7 @@ A proposal is a sequence of actions that the Governor contract will perform if i
 
 === Create a Proposal
 
-Let’s say we want to create a proposal to give a team a grant, in the form of ERC20 tokens from the governance treasury. This proposal will consist of a single action where the target is the ERC20 token, calldata is the encoded function call `transfer(<team wallet>, <grant amount>)`, and with 0 ETH attached.
+Let’s say we want to create a proposal to give a team a grant, in the form of ERC-20 tokens from the governance treasury. This proposal will consist of a single action where the target is the ERC-20 token, calldata is the encoded function call `transfer(<team wallet>, <grant amount>)`, and with 0 ETH attached.
 
 Generally a proposal will be created with the help of an interface such as Tally or Defender. Here we will show how to create the proposal using Ethers.js.
 
@@ -172,7 +172,7 @@ await governor.execute(
 );
 ```
 
-Executing the proposal will transfer the ERC20 tokens to the chosen recipient. To wrap up: we set up a system where a treasury is controlled by the collective decision of the token holders of a project, and all actions are executed via proposals enforced by on-chain votes.
+Executing the proposal will transfer the ERC-20 tokens to the chosen recipient. To wrap up: we set up a system where a treasury is controlled by the collective decision of the token holders of a project, and all actions are executed via proposals enforced by on-chain votes.
 
 == Timestamp based governance
 
@@ -235,6 +235,6 @@ contract MyGovernor is Governor, GovernorCountingSimple, GovernorVotes, Governor
 
 === Disclaimer
 
-Timestamp based voting is a recent feature that was formalized in EIP-6372 and EIP-5805, and introduced in v4.9. At the time this feature is released, governance tooling such as https://www.tally.xyz[Tally] does not support it yet. While support for timestamps should come soon, users can expect invalid reporting of deadlines & durations. This invalid reporting by offchain tools does not affect the onchain security and functionality of the governance contract.
+Timestamp based voting is a recent feature that was formalized in ERC-6372 and ERC-5805, and introduced in v4.9. At the time this feature is released, governance tooling such as https://www.tally.xyz[Tally] does not support it yet. While support for timestamps should come soon, users can expect invalid reporting of deadlines & durations. This invalid reporting by offchain tools does not affect the onchain security and functionality of the governance contract.
 
 Governors with timestamp support (v4.9 and above) are compatible with old tokens (before v4.9) and will operate in "block number" mode (which is the mode all old tokens operate on). On the other hand, old Governor instances (before v4.9) are not compatible with new tokens operating using timestamps. If you update your token code to use timestamps, make sure to also update your Governor code.

docs/modules/ROOT/pages/tokens.adoc

@@ -24,8 +24,8 @@ In a nutshell, when dealing with non-fungibles (like your house) you care about
 
 Even though the concept of a token is simple, they have a variety of complexities in the implementation. Because everything in Ethereum is just a smart contract, and there are no rules about what smart contracts have to do, the community has developed a variety of *standards* (called EIPs or ERCs) for documenting how a contract can interoperate with other contracts.
 
-You've probably heard of the ERC20 or ERC721 token standards, and that's why you're here. Head to our specialized guides to learn more about these:
+You've probably heard of the ERC-20 or ERC-721 token standards, and that's why you're here. Head to our specialized guides to learn more about these:
 
- * xref:erc20.adoc[ERC20]: the most widespread token standard for fungible assets, albeit somewhat limited by its simplicity.
- * xref:erc721.adoc[ERC721]: the de-facto solution for non-fungible tokens, often used for collectibles and games.
- * xref:erc1155.adoc[ERC1155]: a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible and non-fungible tokens, along with batched operations for increased gas efficiency.
+ * xref:erc20.adoc[ERC-20]: the most widespread token standard for fungible assets, albeit somewhat limited by its simplicity.
+ * xref:erc721.adoc[ERC-721]: the de-facto solution for non-fungible tokens, often used for collectibles and games.
+ * xref:erc1155.adoc[ERC-1155]: a novel standard for multi-tokens, allowing for a single contract to represent multiple fungible and non-fungible tokens, along with batched operations for increased gas efficiency.

docs/modules/ROOT/pages/utilities.adoc

@@ -36,10 +36,10 @@ xref:api:utils.adoc#MerkleProof[`MerkleProof`] provides:
 [[introspection]]
 == Introspection
 
-In Solidity, it's frequently helpful to know whether or not a contract supports an interface you'd like to use. ERC165 is a standard that helps do runtime interface detection. Contracts provide helpers both for implementing ERC165 in your contracts and querying other contracts:
+In Solidity, it's frequently helpful to know whether or not a contract supports an interface you'd like to use. ERC-165 is a standard that helps do runtime interface detection. Contracts provide helpers both for implementing ERC-165 in your contracts and querying other contracts:
 
-* xref:api:utils.adoc#IERC165[`IERC165`] — this is the ERC165 interface that defines xref:api:utils.adoc#IERC165-supportsInterface-bytes4-[`supportsInterface`]. When implementing ERC165, you'll conform to this interface.
-* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract if you'd like to support interface detection using a lookup table in contract storage. You can register interfaces using xref:api:utils.adoc#ERC165-_registerInterface-bytes4-[`_registerInterface(bytes4)`]: check out example usage as part of the ERC721 implementation.
+* xref:api:utils.adoc#IERC165[`IERC165`] — this is the ERC-165 interface that defines xref:api:utils.adoc#IERC165-supportsInterface-bytes4-[`supportsInterface`]. When implementing ERC-165, you'll conform to this interface.
+* xref:api:utils.adoc#ERC165[`ERC165`] — inherit this contract if you'd like to support interface detection using a lookup table in contract storage. You can register interfaces using xref:api:utils.adoc#ERC165-_registerInterface-bytes4-[`_registerInterface(bytes4)`]: check out example usage as part of the ERC-721 implementation.
 * xref:api:utils.adoc#ERC165Checker[`ERC165Checker`] — ERC165Checker simplifies the process of checking whether or not a contract supports an interface you care about.
 * include with `using ERC165Checker for address;`
 * xref:api:utils.adoc#ERC165Checker-_supportsInterface-address-bytes4-[`myAddress._supportsInterface(bytes4)`]
@@ -53,7 +53,7 @@ contract MyContract {
     bytes4 private InterfaceId_ERC721 = 0x80ac58cd;
 
     /**
-     * @dev transfer an ERC721 token from this contract to someone else
+     * @dev transfer an ERC-721 token from this contract to someone else
      */
     function transferERC721(
         address token,
@@ -118,9 +118,9 @@ The `Enumerable*` structures are similar to mappings in that they store and remo
 
 xref:api:utils.adoc#Base64[`Base64`] util allows you to transform `bytes32` data into its Base64 `string` representation.
 
-This is especially useful for building URL-safe tokenURIs for both xref:api:token/ERC721.adoc#IERC721Metadata-tokenURI-uint256-[`ERC721`] or xref:api:token/ERC1155.adoc#IERC1155MetadataURI-uri-uint256-[`ERC1155`]. This library provides a clever way to serve URL-safe https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URIs/[Data URI] compliant strings to serve on-chain data structures.
+This is especially useful for building URL-safe tokenURIs for both xref:api:token/ERC721.adoc#IERC721Metadata-tokenURI-uint256-[`ERC-721`] or xref:api:token/ERC1155.adoc#IERC1155MetadataURI-uri-uint256-[`ERC-1155`]. This library provides a clever way to serve URL-safe https://developer.mozilla.org/docs/Web/HTTP/Basics_of_HTTP/Data_URIs/[Data URI] compliant strings to serve on-chain data structures.
 
-Here is an example to send JSON Metadata through a Base64 Data URI using an ERC721:
+Here is an example to send JSON Metadata through a Base64 Data URI using an ERC-721:
 
 [source, solidity]
 ----
@@ -147,7 +147,7 @@ contract My721Token is ERC721 {
         bytes memory dataURI = abi.encodePacked(
             '{',
                 '"name": "My721Token #', tokenId.toString(), '"',
-                // Replace with extra ERC721 Metadata properties
+                // Replace with extra ERC-721 Metadata properties
             '}'
         );
 

scripts/generate/templates/StorageSlot.js

@@ -21,7 +21,7 @@ pragma solidity ^0.8.20;
  *
  * The functions in this library return Slot structs that contain a \`value\` member that can be used to read or write.
  *
- * Example usage to set ERC1967 implementation slot:
+ * Example usage to set ERC-1967 implementation slot:
  * \`\`\`solidity
  * contract ERC1967 {
  *     bytes32 internal constant _IMPLEMENTATION_SLOT = 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;

test/governance/Governor.test.js

@@ -14,7 +14,7 @@ const { clockFromReceipt } = require('../helpers/time');
 const { expectRevertCustomError } = require('../helpers/customError');
 
 const { shouldSupportInterfaces } = require('../utils/introspection/SupportsInterface.behavior');
-const { shouldBehaveLikeEIP6372 } = require('./utils/EIP6372.behavior');
+const { shouldBehaveLikeERC6372 } = require('./utils/ERC6372.behavior');
 const { ZERO_BYTES32 } = require('@openzeppelin/test-helpers/src/constants');
 
 const Governor = artifacts.require('$GovernorMock');
@@ -84,7 +84,7 @@ contract('Governor', function (accounts) {
       });
 
       shouldSupportInterfaces(['ERC165', 'ERC1155Receiver', 'Governor']);
-      shouldBehaveLikeEIP6372(mode);
+      shouldBehaveLikeERC6372(mode);
 
       it('deployment check', async function () {
         expect(await this.mock.name()).to.be.equal(name);

test/governance/utils/EIP6372.behavior.js → test/governance/utils/ERC6372.behavior.js

@@ -1,7 +1,7 @@
 const { clock } = require('../../helpers/time');
 
-function shouldBehaveLikeEIP6372(mode = 'blocknumber') {
-  describe('should implement EIP6372', function () {
+function shouldBehaveLikeERC6372(mode = 'blocknumber') {
+  describe('should implement ERC6372', function () {
     beforeEach(async function () {
       this.mock = this.mock ?? this.token ?? this.votes;
     });
@@ -19,5 +19,5 @@ function shouldBehaveLikeEIP6372(mode = 'blocknumber') {
 }
 
 module.exports = {
-  shouldBehaveLikeEIP6372,
+  shouldBehaveLikeERC6372,
 };

test/governance/utils/Votes.behavior.js

@@ -6,7 +6,7 @@ const { fromRpcSig } = require('ethereumjs-util');
 const ethSigUtil = require('eth-sig-util');
 const Wallet = require('ethereumjs-wallet').default;
 
-const { shouldBehaveLikeEIP6372 } = require('./EIP6372.behavior');
+const { shouldBehaveLikeERC6372 } = require('./ERC6372.behavior');
 const {
   getDomain,
   domainType,
@@ -26,7 +26,7 @@ const buildAndSignDelegation = (contract, message, pk) =>
     .then(data => fromRpcSig(ethSigUtil.signTypedMessage(pk, { data })));
 
 function shouldBehaveLikeVotes(accounts, tokens, { mode = 'blocknumber', fungible = true }) {
-  shouldBehaveLikeEIP6372(mode);
+  shouldBehaveLikeERC6372(mode);
 
   const getWeight = token => web3.utils.toBN(fungible ? token : 1);
 

test/token/ERC20/extensions/ERC20Votes.test.js

@@ -38,7 +38,7 @@ contract('ERC20Votes', function (accounts) {
         this.votes = this.token;
       });
 
-      // includes EIP6372 behavior check
+      // includes ERC6372 behavior check
       shouldBehaveLikeVotes(accounts, [1, 17, 42], { mode, fungible: true });
 
       it('initial nonce is 0', async function () {

test/token/ERC721/extensions/ERC721Votes.test.js

@@ -26,7 +26,7 @@ contract('ERC721Votes', function (accounts) {
         this.votes = await artifact.new(name, symbol, name, version);
       });
 
-      // includes EIP6372 behavior check
+      // includes ERC6372 behavior check
       shouldBehaveLikeVotes(accounts, tokens, { mode, fungible: false });
 
       describe('balanceOf', function () {