Merge branch 'master' into add_getRoleMembers_method

.github/ISSUE_TEMPLATE/bug_report.md

@@ -10,7 +10,7 @@ about: Report a bug in OpenZeppelin Contracts
 
 **💻 Environment**
 
-<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Truffle, Remix, etc. -->
+<!-- Tell us what version of OpenZeppelin Contracts you're using, and how you're using it: Hardhat, Remix, etc. -->
 
 **📝 Details**
 

.github/workflows/checks.yml

@@ -34,8 +34,6 @@ jobs:
       - uses: actions/checkout@v4
       - name: Set up environment
         uses: ./.github/actions/setup
-      - name: Compile contracts # TODO: Remove after migrating tests to ethers
-        run: npm run compile
       - name: Run tests and generate gas report
         run: npm run test
       - name: Check linearisation of the inheritance graph
@@ -64,8 +62,6 @@ jobs:
           cp -rnT contracts lib/openzeppelin-contracts/contracts
       - name: Transpile to upgradeable
         run: bash scripts/upgradeable/transpile.sh
-      - name: Compile contracts # TODO: Remove after migrating tests to ethers
-        run: npm run compile
       - name: Run tests
         run: npm run test
       - name: Check linearisation of the inheritance graph
@@ -94,8 +90,6 @@ jobs:
       - uses: actions/checkout@v4
       - name: Set up environment
         uses: ./.github/actions/setup
-      - name: Compile contracts # TODO: Remove after migrating tests to ethers
-        run: npm run compile
       - name: Run coverage
         run: npm run coverage
       - uses: codecov/codecov-action@v3

.gitignore

@@ -29,15 +29,9 @@ npm-debug.log
 # local env variables
 .env
 
-# truffle build directory
-build/
-
 # macOS
 .DS_Store
 
-# truffle
-.node-xmlhttprequest-*
-
 # IntelliJ IDE
 .idea
 

README.md

@@ -14,7 +14,7 @@
 
 :mage: **Not sure how to get started?** Check out [Contracts Wizard](https://wizard.openzeppelin.com/) — an interactive smart contract generator.
 
-:building_construction: **Want to scale your decentralized application?** Check out [OpenZeppelin Defender](https://openzeppelin.com/defender) — a secure platform for automating and monitoring your operations.
+:building_construction: **Want to scale your decentralized application?** Check out [OpenZeppelin Defender](https://openzeppelin.com/defender) — a mission-critical developer security platform to code, audit, deploy, monitor, and operate with confidence.
 
 > [!IMPORTANT]
 > OpenZeppelin Contracts uses semantic versioning to communicate backwards compatibility of its API and storage layout. For upgradeable contracts, the storage layout of different major versions should be assumed incompatible, for example, it is unsafe to upgrade from 4.9.3 to 5.0.0. Learn more at [Backwards Compatibility](https://docs.openzeppelin.com/contracts/backwards-compatibility).
@@ -23,7 +23,7 @@
 
 ### Installation
 
-#### Hardhat, Truffle (npm)
+#### Hardhat (npm)
 
 ```
 $ npm install @openzeppelin/contracts

contracts/governance/extensions/GovernorTimelockAccess.sol

@@ -35,6 +35,9 @@ import {Time} from "../../utils/types/Time.sol";
  * mitigate this attack vector, the governor is able to ignore the restrictions claimed by the `AccessManager` using
  * {setAccessManagerIgnored}. While permanent denial of service is mitigated, temporary DoS may still be technically
  * possible. All of the governor's own functions (e.g., {setBaseDelaySeconds}) ignore the `AccessManager` by default.
+ *
+ * NOTE: `AccessManager` does not support scheduling more than one operation with the same target and calldata at
+ * the same time. See {AccessManager-schedule} for a workaround.
  */
 abstract contract GovernorTimelockAccess is Governor {
     // An execution plan is produced at the moment a proposal is created, in order to fix at that point the exact

contracts/governance/extensions/GovernorTimelockCompound.sol

@@ -16,7 +16,7 @@ import {SafeCast} from "../../utils/math/SafeCast.sol";
  *
  * Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus,
  * the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be
- * inaccessible.
+ * inaccessible from a proposal, unless executed via {Governor-relay}.
  */
 abstract contract GovernorTimelockCompound is Governor {
     ICompoundTimelock private _timelock;

contracts/governance/extensions/GovernorTimelockControl.sol

@@ -11,7 +11,7 @@ import {SafeCast} from "../../utils/math/SafeCast.sol";
 /**
  * @dev Extension of {Governor} that binds the execution process to an instance of {TimelockController}. This adds a
  * delay, enforced by the {TimelockController} to all successful proposal (in addition to the voting duration). The
- * {Governor} needs the proposer (and ideally the executor) roles for the {Governor} to work properly.
+ * {Governor} needs the proposer (and ideally the executor and canceller) roles for the {Governor} to work properly.
  *
  * Using this model means the proposal will be operated by the {TimelockController} and not by the {Governor}. Thus,
  * the assets and permissions must be attached to the {TimelockController}. Any asset sent to the {Governor} will be
@@ -21,9 +21,6 @@ import {SafeCast} from "../../utils/math/SafeCast.sol";
  * risky, as it grants them the ability to: 1) execute operations as the timelock, and thus possibly performing
  * operations or accessing funds that are expected to only be accessible through a vote, and 2) block governance
  * proposals that have been approved by the voters, effectively executing a Denial of Service attack.
- *
- * NOTE: `AccessManager` does not support scheduling more than one operation with the same target and calldata at
- * the same time. See {AccessManager-schedule} for a workaround.
  */
 abstract contract GovernorTimelockControl is Governor {
     TimelockController private _timelock;

contracts/proxy/README.adoc

@@ -19,7 +19,7 @@ There are two alternative ways to add upgradeability to an ERC-1967 proxy. Their
 - {TransparentUpgradeableProxy}: A proxy with a built-in immutable admin and upgrade interface.
 - {UUPSUpgradeable}: An upgradeability mechanism to be included in the implementation contract.
 
-CAUTION: Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM. Unless you want a lot of low level control, we recommend using the xref:upgrades-plugins::index.adoc[OpenZeppelin Upgrades Plugins] for Truffle and Hardhat.
+CAUTION: Using upgradeable proxies correctly and securely is a difficult task that requires deep knowledge of the proxy pattern, Solidity, and the EVM. Unless you want a lot of low level control, we recommend using the xref:upgrades-plugins::index.adoc[OpenZeppelin Upgrades Plugins] for Hardhat and Foundry.
 
 A different family of proxies are beacon proxies. This pattern, popularized by Dharma, allows multiple proxies to be upgraded to a different implementation in a single transaction.
 

docs/modules/ROOT/pages/governance.adoc

@@ -32,7 +32,7 @@ When using a timelock with your Governor contract, you can use either OpenZeppel
 
 https://www.tally.xyz[Tally] is a full-fledged application for user owned on-chain governance. It comprises a voting dashboard, proposal creation wizard, real time research and analysis, and educational content.
 
-For all of these options, the Governor will be compatible with Tally: users will be able to create proposals, visualize voting power and advocates, navigate proposals, and cast votes. For proposal creation in particular, projects can also use Defender Admin as an alternative interface.
+For all of these options, the Governor will be compatible with Tally: users will be able to create proposals, see voting periods and delays following xref:api:interfaces.adoc#IERC6372[IERC6372], visualize voting power and advocates, navigate proposals, and cast votes. For proposal creation in particular, projects can also use https://docs.openzeppelin.com/defender/module/actions#transaction-proposals-reference[Defender Transaction Proposals] as an alternative interface.
 
 In the rest of this guide, we will focus on a fresh deploy of the vanilla OpenZeppelin Governor features without concern for compatibility with GovernorAlpha or Bravo.
 
@@ -102,7 +102,7 @@ A proposal is a sequence of actions that the Governor contract will perform if i
 
 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.
+Generally a proposal will be created with the help of an interface such as Tally or https://docs.openzeppelin.com/defender/module/actions#transaction-proposals-reference[Defender Proposals]. Here we will show how to create the proposal using Ethers.js.
 
 First we get all the parameters necessary for the proposal action.
 
@@ -235,6 +235,6 @@ contract MyGovernor is Governor, GovernorCountingSimple, GovernorVotes, Governor
 
 === Disclaimer
 
-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.
+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, some governance tooling may not support it yet. Users can expect invalid reporting of deadlines & durations if the tool is not able to interpret the ERC6372 clock. 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/index.adoc

@@ -13,7 +13,7 @@ IMPORTANT: OpenZeppelin Contracts uses semantic versioning to communicate backwa
 [[install]]
 === Installation
 
-==== Hardhat, Truffle (npm)
+==== Hardhat (npm)
 
 ```console
 $ npm install @openzeppelin/contracts

docs/modules/ROOT/pages/utilities.adoc

@@ -186,16 +186,15 @@ contract Box is Multicall {
 }
 ----
 
-This is how to call the `multicall` function using Truffle, allowing `foo` and `bar` to be called in a single transaction:
+This is how to call the `multicall` function using Ethers.js, allowing `foo` and `bar` to be called in a single transaction:
 [source,javascript]
 ----
 // scripts/foobar.js
 
-const Box = artifacts.require('Box');
-const instance = await Box.new();
+const instance = await ethers.deployContract("Box");
 
 await instance.multicall([
-    instance.contract.methods.foo().encodeABI(),
-    instance.contract.methods.bar().encodeABI()
+    instance.interface.encodeFunctionData("foo"),
+    instance.interface.encodeFunctionData("bar")
 ]);
 ----

docs/modules/ROOT/pages/wizard.adoc

@@ -4,7 +4,7 @@
 Not sure where to start? Use the interactive generator below to bootstrap your
 contract and learn about the components offered in OpenZeppelin Contracts.
 
-TIP: Place the resulting contract in your `contracts` directory in order to compile it with a tool like Hardhat or Truffle. Consider reading our guide on xref:learn::developing-smart-contracts.adoc[Developing Smart Contracts] for more guidance!
+TIP: Place the resulting contract in your `contracts` or `src` directory in order to compile it with a tool like Hardhat or Foundry. Consider reading our guide on xref:learn::developing-smart-contracts.adoc[Developing Smart Contracts] for more guidance!
 
 ++++
 <script async src="https://wizard.openzeppelin.com/build/embed.js"></script>

hardhat.config.js

@@ -55,7 +55,6 @@ const argv = require('yargs/yargs')()
     },
   }).argv;
 
-require('@nomiclabs/hardhat-truffle5'); // deprecated
 require('@nomicfoundation/hardhat-toolbox');
 require('@nomicfoundation/hardhat-ethers');
 require('hardhat-ignore-warnings');

hardhat/env-contract.js

@@ -15,27 +15,4 @@ extendEnvironment(hre => {
     const filteredSignersAsPromise = originalGetSigners().then(signers => signers.slice(1));
     hre.ethers.getSigners = () => filteredSignersAsPromise;
   }
-
-  // override hre.contract
-  const originalContract = hre.contract;
-  hre.contract = function (name, body) {
-    originalContract.call(this, name, accounts => {
-      let snapshot;
-
-      before(async function () {
-        // reset the state of the chain in between contract test suites
-        // TODO: this should be removed when migration to ethers is over
-        const { takeSnapshot } = require('@nomicfoundation/hardhat-network-helpers');
-        snapshot = await takeSnapshot();
-      });
-
-      after(async function () {
-        // reset the state of the chain in between contract test suites
-        // TODO: this should be removed when migration to ethers is over
-        await snapshot.restore();
-      });
-
-      body(accounts.slice(1));
-    });
-  };
 });