polkamarkets-js 3.4.0 → 3.4.2

package/lib/openzeppelin-contracts.git/docs/config.js

@@ -1,21 +0,0 @@
-const path = require('path');
-const fs = require('fs');
-
-/** @type import('solidity-docgen/dist/config').UserConfig */
-module.exports = {
-  outputDir: 'docs/modules/api/pages',
-  templates: 'docs/templates',
-  exclude: ['mocks'],
-  pageExtension: '.adoc',
-  pages: (_, file, config) => {
-    // For each contract file, find the closest README.adoc and return its location as the output page path.
-    const sourcesDir = path.resolve(config.root, config.sourcesDir);
-    let dir = path.resolve(config.root, file.absolutePath);
-    while (dir.startsWith(sourcesDir)) {
-      dir = path.dirname(dir);
-      if (fs.existsSync(path.join(dir, 'README.adoc'))) {
-        return path.relative(sourcesDir, dir) + config.pageExtension;
-      }
-    }
-  },
-};

package/lib/openzeppelin-contracts.git/docs/modules/ROOT/nav.adoc

@@ -1,23 +0,0 @@
-* xref:index.adoc[Overview]
-* xref:wizard.adoc[Wizard]
-* xref:extending-contracts.adoc[Extending Contracts]
-* xref:upgradeable.adoc[Using with Upgrades]
-
-* xref:releases-stability.adoc[Releases & Stability]
-
-* xref:access-control.adoc[Access Control]
-
-* xref:tokens.adoc[Tokens]
-** xref:erc20.adoc[ERC20]
-*** xref:erc20-supply.adoc[Creating Supply]
-** xref:erc721.adoc[ERC721]
-** xref:erc777.adoc[ERC777]
-** xref:erc1155.adoc[ERC1155]
-
-* xref:governance.adoc[Governance]
-
-* xref:crosschain.adoc[Crosschain]
-
-* xref:utilities.adoc[Utilities]
-
-* xref:subgraphs::index.adoc[Subgraphs]

package/lib/openzeppelin-contracts.git/docs/modules/ROOT/pages/access-control.adoc

@@ -1,217 +0,0 @@
-= Access Control
-
-Access control—that is, "who is allowed to do this thing"—is incredibly important in the world of smart contracts. The access control of your contract may govern who can mint tokens, vote on proposals, freeze transfers, and many other things. It is therefore *critical* to understand how you implement it, lest someone else https://blog.openzeppelin.com/on-the-parity-wallet-multisig-hack-405a8c12e8f7[steals your whole system].
-
-[[ownership-and-ownable]]
-== Ownership and `Ownable`
-
-The most common and basic form of access control is the concept of _ownership_: there's an account that is the `owner` of a contract and can do administrative tasks on it. This approach is perfectly reasonable for contracts that have a single administrative user.
-
-OpenZeppelin Contracts provides xref:api:access.adoc#Ownable[`Ownable`] for implementing ownership in your contracts.
-
-[source,solidity]
-----
-// contracts/MyContract.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/access/Ownable.sol";
-
-contract MyContract is Ownable {
-    function normalThing() public {
-        // anyone can call this normalThing()
-    }
-
-    function specialThing() public onlyOwner {
-        // only the owner can call specialThing()!
-    }
-}
-----
-
-By default, the xref:api:access.adoc#Ownable-owner--[`owner`] of an `Ownable` contract is the account that deployed it, which is usually exactly what you want.
-
-Ownable also lets you:
-
-* xref:api:access.adoc#Ownable-transferOwnership-address-[`transferOwnership`] from the owner account to a new one, and
-* xref:api:access.adoc#Ownable-renounceOwnership--[`renounceOwnership`] for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.
-
-WARNING: Removing the owner altogether will mean that administrative tasks that are protected by `onlyOwner` will no longer be callable!
-
-Note that *a contract can also be the owner of another one*! This opens the door to using, for example, a https://gnosis-safe.io[Gnosis Safe], an https://aragon.org[Aragon DAO], or a totally custom contract that _you_ create.
-
-In this way you can use _composability_ to add additional layers of access control complexity to your contracts. Instead of having a single regular Ethereum account (Externally Owned Account, or EOA) as the owner, you could use a 2-of-3 multisig run by your project leads, for example. Prominent projects in the space, such as https://makerdao.com[MakerDAO], use systems similar to this one.
-
-[[role-based-access-control]]
-== Role-Based Access Control
-
-While the simplicity of _ownership_ can be useful for simple systems or quick prototyping, different levels of authorization are often needed. You may want for an account to have permission to ban users from a system, but not create new tokens. https://en.wikipedia.org/wiki/Role-based_access_control[_Role-Based Access Control (RBAC)_] offers flexibility in this regard.
-
-In essence, we will be defining multiple _roles_, each allowed to perform different sets of actions. An account may have, for example, 'moderator', 'minter' or 'admin' roles, which you will then check for instead of simply using `onlyOwner`. This check can be enforced through the `onlyRole` modifier. Separately, you will be able to define rules for how accounts can be granted a role, have it revoked, and more.
-
-Most software uses access control systems that are role-based: some users are regular users, some may be supervisors or managers, and a few will often have administrative privileges.
-
-[[using-access-control]]
-=== Using `AccessControl`
-
-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:tokens.adoc#ERC20[`ERC20` token] to define a 'minter' role, which allows accounts that have it create new tokens:
-
-[source,solidity]
-----
-// contracts/MyToken.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/access/AccessControl.sol";
-import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
-
-contract MyToken is ERC20, AccessControl {
-    // Create a new role identifier for the minter role
-    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
-
-    constructor(address minter) ERC20("MyToken", "TKN") {
-        // Grant the minter role to a specified account
-        _grantRole(MINTER_ROLE, minter);
-    }
-
-    function mint(address to, uint256 amount) public {
-        // Check that the calling account has the minter role
-        require(hasRole(MINTER_ROLE, msg.sender), "Caller is not a minter");
-        _mint(to, amount);
-    }
-}
-----
-
-NOTE: Make sure you fully understand how xref:api:access.adoc#AccessControl[`AccessControl`] works before using it on your system, or copy-pasting the examples from this guide.
-
-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:
-
-[source,solidity]
-----
-// contracts/MyToken.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/access/AccessControl.sol";
-import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
-
-contract MyToken is ERC20, AccessControl {
-    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
-    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");
-
-    constructor(address minter, address burner) ERC20("MyToken", "TKN") {
-        _grantRole(MINTER_ROLE, minter);
-        _grantRole(BURNER_ROLE, burner);
-    }
-
-    function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
-        _mint(to, amount);
-    }
-
-    function burn(address from, uint256 amount) public onlyRole(BURNER_ROLE) {
-        _burn(from, amount);
-    }
-}
-----
-
-So clean! By splitting concerns this way, more granular levels of permission may be implemented than were possible with the simpler _ownership_ approach to access control. Limiting what each component of a system is able to do is known as the https://en.wikipedia.org/wiki/Principle_of_least_privilege[principle of least privilege], and is a good security practice. Note that each account may still have more than one role, if so desired.
-
-[[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?
-
-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_.
-
-Every role has an associated admin role, which grants permission to call the `grantRole` and `revokeRole` functions. A role can be granted or revoked by using these if the calling account has the corresponding admin role. Multiple roles may have the same admin role to make management easier. A role's admin can even be the same role itself, which would cause accounts with that role to be able to also grant and revoke it.
-
-This mechanism can be used to create complex permissioning structures resembling organizational charts, but it also provides an easy way to manage simpler applications. `AccessControl` includes a special role, called `DEFAULT_ADMIN_ROLE`, which acts as the **default admin role for all roles**. An account with this role will be able to manage any other role, unless `_setRoleAdmin` is used to select a new admin role.
-
-Let's take a look at the ERC20 token example, this time taking advantage of the default admin role:
-
-[source,solidity]
-----
-// contracts/MyToken.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/access/AccessControl.sol";
-import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
-
-contract MyToken is ERC20, AccessControl {
-    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
-    bytes32 public constant BURNER_ROLE = keccak256("BURNER_ROLE");
-
-    constructor() ERC20("MyToken", "TKN") {
-        // Grant the contract deployer the default admin role: it will be able
-        // to grant and revoke any roles
-        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
-    }
-
-    function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
-        _mint(to, amount);
-    }
-
-    function burn(address from, uint256 amount) public onlyRole(BURNER_ROLE) {
-        _burn(from, amount);
-    }
-}
-----
-
-Note that, unlike the previous examples, no accounts are granted the 'minter' or 'burner' roles. However, because those roles' admin role is the default admin role, and _that_ role was granted to `msg.sender`, that same account can call `grantRole` to give minting or burning permission, and `revokeRole` to remove it.
-
-Dynamic role allocation is often a desirable property, for example in systems where trust in a participant may vary over time. It can also be used to support use cases such as https://en.wikipedia.org/wiki/Know_your_customer[KYC], where the list of role-bearers may not be known up-front, or may be prohibitively expensive to include in a single transaction.
-
-[[querying-privileged-accounts]]
-=== Querying Privileged Accounts
-
-Because accounts might <<granting-and-revoking, grant and revoke roles>> dynamically, it is not always possible to determine which accounts hold a particular role. This is important as it allows to prove certain properties about a system, such as that an administrative account is a multisig or a DAO, or that a certain role has been removed from all users, effectively disabling any associated functionality.
-
-Under the hood, `AccessControl` uses `EnumerableSet`, a more powerful variant of Solidity's `mapping` type, which allows for key enumeration. `getRoleMemberCount` can be used to retrieve the number of accounts that have a particular role, and `getRoleMember` can then be called to get the address of each of these accounts.
-
-```javascript
-const minterCount = await myToken.getRoleMemberCount(MINTER_ROLE);
-
-const members = [];
-for (let i = 0; i < minterCount; ++i) {
-    members.push(await myToken.getRoleMember(MINTER_ROLE, i));
-}
-```
-
-== Delayed operation
-
-Access control is essential to prevent unauthorized access to critical functions. These functions may be used to mint tokens, freeze transfers or perform an upgrade that completely changes the smart contract logic. While xref:api:access.adoc#Ownable[`Ownable`] and xref:api:access.adoc#AccessControl[`AccessControl`] can prevent unauthorized access, they do not address the issue of a misbehaving administrator attacking their own system to the prejudice of their users.
-
-This is the issue the xref:api:governance.adoc#TimelockController[`TimelockController`] is addressing.
-
-The xref:api:governance.adoc#TimelockController[`TimelockController`] is a proxy that is governed by proposers and executors. When set as the owner/admin/controller of a smart contract, it ensures that whichever maintenance operation is ordered by the proposers is subject to a delay. This delay protects the users of the smart contract by giving them time to review the maintenance operation and exit the system if they consider it is in their best interest to do so.
-
-=== Using `TimelockController`
-
-By default, the address that deployed the xref:api:governance.adoc#TimelockController[`TimelockController`] gets administration privileges over the timelock. This role grants the right to assign proposers, executors, and other administrators.
-
-The first step in configuring the xref:api:governance.adoc#TimelockController[`TimelockController`] is to assign at least one proposer and one executor. These can be assigned during construction or later by anyone with the administrator role. These roles are not exclusive, meaning an account can have both roles.
-
-Roles are managed using the xref:api:access.adoc#AccessControl[`AccessControl`] interface and the `bytes32` values for each role are accessible through the `ADMIN_ROLE`, `PROPOSER_ROLE` and `EXECUTOR_ROLE` constants.
-
-There is an additional feature built on top of `AccessControl`: giving the executor role to `address(0)` opens access to anyone to execute a proposal once the timelock has expired. This feature, while useful, should be used with caution.
-
-At this point, with both a proposer and an executor assigned, the timelock can perform operations.
-
-An optional next step is for the deployer to renounce its administrative privileges and leave the timelock self-administered. If the deployer decides to do so, all further maintenance, including assigning new proposers/schedulers or changing the timelock duration will have to follow the timelock workflow. This links the governance of the timelock to the governance of contracts attached to the timelock, and enforce a delay on timelock maintenance operations.
-
-WARNING: If the deployer renounces administrative rights in favour of timelock itself, assigning new proposers or executors will require a timelocked operation. This means that if the accounts in charge of any of these two roles become unavailable, then the entire contract (and any contract it controls) becomes locked indefinitely.
-
-With both the proposer and executor roles assigned and the timelock in charge of its own administration, you can now transfer the ownership/control of any contract to the timelock.
-
-TIP: A recommended configuration is to grant both roles to a secure governance contract such as a DAO or a multisig, and to additionally grant the executor role to a few EOAs held by people in charge of helping with the maintenance operations. These wallets cannot take over control of the timelock but they can help smoothen the workflow.
-
-=== Minimum delay
-
-Operations executed by the xref:api:governance.adoc#TimelockController[`TimelockController`] are not subject to a fixed delay but rather a minimum delay. Some major updates might call for a longer delay. For example, if a delay of just a few days might be sufficient for users to audit a minting operation, it makes sense to use a delay of a few weeks, or even a few months, when scheduling a smart contract upgrade.
-
-The minimum delay (accessible through the xref:api:governance.adoc#TimelockController-getMinDelay--[`getMinDelay`] method) can be updated by calling the xref:api:governance.adoc#TimelockController-updateDelay-uint256-[`updateDelay`] function. Bear in mind that access to this function is only accessible by the timelock itself, meaning this maintenance operation has to go through the timelock itself.

package/lib/openzeppelin-contracts.git/docs/modules/ROOT/pages/crosschain.adoc

@@ -1,210 +0,0 @@
-= Adding cross-chain support to contracts
-
-If your contract is targeting to be used in the context of multichain operations, you may need specific tools to identify and process these cross-chain operations.
-
-OpenZeppelin provides the xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] abstract contract, that includes dedicated internal functions.
-
-In this guide, we will go through an example use case: _how to build an upgradeable & mintable ERC20 token controlled by a governor present on a foreign chain_.
-
-== Starting point, our ERC20 contract
-
-Let's start with a small ERC20 contract, that we bootstrapped using the https://wizard.openzeppelin.com/[OpenZeppelin Contracts Wizard], and extended with an owner that has the ability to mint. Note that for demonstration purposes we have not used the built-in `Ownable` contract.
-
-[source,solidity]
-----
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.4;
-
-import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
-import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
-import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
-
-contract MyToken is Initializable, ERC20Upgradeable, UUPSUpgradeable {
-    address public owner;
-
-    modifier onlyOwner() {
-        require(owner == _msgSender(), "Not authorized");
-        _;
-    }
-
-    /// @custom:oz-upgrades-unsafe-allow constructor
-    constructor() initializer {}
-
-    function initialize(address initialOwner) initializer public {
-        __ERC20_init("MyToken", "MTK");
-        __UUPSUpgradeable_init();
-
-        owner = initialOwner;
-    }
-
-    function mint(address to, uint256 amount) public onlyOwner {
-        _mint(to, amount);
-    }
-
-    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {
-    }
-}
-----
-
-This token is mintable and upgradeable by the owner of the contract.
-
-== Preparing our contract for cross-chain operations.
-
-Let's now imagine that this contract is going to live on one chain, but we want the minting and the upgrading to be performed by a xref:governance.adoc[`governor`] contract on another chain.
-
-For example, we could have our token on xDai, with our governor on mainnet, or we could have our token on mainnet, with our governor on optimism
-
-In order to do that, we will start by adding xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] to our contract. You will notice that the contract is now abstract. This is because `CrossChainEnabled` is an abstract contract: it is not tied to any particular chain and it deals with cross-chain interactions in an abstract way. This is what enables us to easily reuse the code for different chains. We will specialize it later by inheriting from a chain-specific implementation of the abstraction.
-
-```diff
- import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
-+import "@openzeppelin/contracts-upgradeable/crosschain/CrossChainEnabled.sol";
-
--contract MyToken is Initializable, ERC20Upgradeable, UUPSUpgradeable {
-+abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, CrossChainEnabled {
-```
-
-Once that is done, we can use the `onlyCrossChainSender` modifier, provided by `CrossChainEnabled` in order to protect the minting and upgrading operations.
-
-```diff
--    function mint(address to, uint256 amount) public onlyOwner {
-+    function mint(address to, uint256 amount) public onlyCrossChainSender(owner) {
-
--    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {
-+    function _authorizeUpgrade(address newImplementation) internal override onlyCrossChainSender(owner) {
-```
-
-This change will effectively restrict the mint and upgrade operations to the `owner` on the remote chain.
-
-== Specializing for a specific chain
-
-Once the abstract cross-chain version of our token is ready we can easily specialize it for the chain we want, or more precisely for the bridge system that we want to rely on.
-
-This is done using one of the many `CrossChainEnabled` implementations.
-
-For example, if our token is on xDai, and our governor on mainnet, we can use the https://docs.tokenbridge.net/amb-bridge/about-amb-bridge[AMB] bridge available on xDai at https://blockscout.com/xdai/mainnet/address/0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59[0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59]
-
-[source,solidity]
-----
-[...]
-
-import "@openzeppelin/contracts-upgradeable/crosschain/amb/CrossChainEnabledAMB.sol";
-
-contract MyTokenXDAI is
-    MyTokenCrossChain,
-    CrossChainEnabledAMB(0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59)
-{}
-----
-
-If the token is on Ethereum mainnet, and our governor on Optimism, we use the Optimism https://community.optimism.io/docs/protocol/protocol-2.0/#l1crossdomainmessenger[CrossDomainMessenger] available on mainnet at https://etherscan.io/address/0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1[0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1].
-
-[source,solidity]
-----
-[...]
-
-import "@openzeppelin/contracts-upgradeable/crosschain/optimismCrossChainEnabledOptimism.sol";
-
-contract MyTokenOptimism is
-    MyTokenCrossChain,
-    CrossChainEnabledOptimism(0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1)
-{}
-----
-
-== Mixing cross domain addresses is dangerous
-
-When designing a contract with cross-chain support, it is essential to understand possible fallbacks and the security assumption that are being made.
-
-In this guide, we are particularly focusing on restricting access to a specific caller. This is usually done (as shown above) using `msg.sender` or `_msgSender()`. However, when going cross-chain, it is not just that simple. Even without considering possible bridge issues, it is important to keep in mind that the same address can correspond to very different entities when considering a multi-chain space. EOA wallets can only execute operations if the wallet's private-key signs the transaction. To our knowledge this is the case in all EVM chains, so a cross-chain message coming from such a wallet is arguably equivalent to a non-cross-chain message by the same wallet. The situation is however very different for smart contracts.
-
-Due to the way smart contract addresses are computed, and the fact that smart contracts on different chains live independent lives, you could have two very different contracts live at the same address on different chains. You could imagine two multisig wallets with different signers using the same address on different chains. You could also see a very basic smart wallet live on one chain at the same address as a full-fledged governor on another chain. Therefore, you should be careful that whenever you give permissions to a specific address, you control with chain this address can act from.
-
-== Going further with access control
-
-In the previous example, we have both an `onlyOwner()` modifier and the `onlyCrossChainSender(owner)` mechanism. We didn't use the xref:access-control.adoc#ownership-and-ownable[`Ownable`] pattern because the ownership transfer mechanism in includes is not designed to work with the owner being a cross-chain entity. Unlike xref:access-control.adoc#ownership-and-ownable[`Ownable`], xref:access-control.adoc#role-based-access-control[`AccessControl`] is more effective at capturing the nuances and can effectively be used to build cross-chain-aware contracts.
-
-Using xref:api:access.adoc#AccessControlCrossChain[`AccessControlCrossChain`] includes both the xref:api:access.adoc#AccessControl[`AccessControl`] core and the xref:api:crosschain.adoc#CrossChainEnabled[`CrossChainEnabled`] abstraction. It also includes some binding to make role management compatible with cross-chain operations.
-
-In the case of the `mint` function, the caller must have the `MINTER_ROLE` when the call originates from the same chain. If the caller is on a remote chain, then the caller should not have the `MINTER_ROLE`, but the "aliased" version (`MINTER_ROLE ^ CROSSCHAIN_ALIAS`). This mitigates the danger described in the previous section by strictly separating local accounts from remote accounts from a different chain. See the xref:api:access.adoc#AccessControlCrossChain[`AccessControlCrossChain`] documentation for more details.
-
-
-```diff
- import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
- import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
-+import "@openzeppelin/contracts-upgradeable/access/AccessControlCrossChainUpgradeable.sol";
-
--abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, CrossChainEnabled {
-+abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, UUPSUpgradeable, AccessControlCrossChainUpgradeable {
-
--    address public owner;
--    modifier onlyOwner() {
--        require(owner == _msgSender(), "Not authorized");
--        _;
--    }
-
-+    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
-+    bytes32 public constant UPGRADER_ROLE = keccak256("UPGRADER_ROLE");
-
-     function initialize(address initialOwner) initializer public {
-         __ERC20_init("MyToken", "MTK");
-         __UUPSUpgradeable_init();
-+        __AccessControl_init();
-+        _grantRole(_crossChainRoleAlias(DEFAULT_ADMIN_ROLE), initialOwner); // initialOwner is on a remote chain
--        owner = initialOwner;
-     }
-
--    function mint(address to, uint256 amount) public onlyCrossChainSender(owner) {
-+    function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
-
--    function _authorizeUpgrade(address newImplementation) internal override onlyCrossChainSender(owner) {
-+    function _authorizeUpgrade(address newImplementation) internal override onlyRole(UPGRADER_ROLE) {
-```
-
-This results in the following, final, code:
-
-[source,solidity]
-----
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.4;
-
-import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
-import "@openzeppelin/contracts-upgradeable/access/AccessControlCrossChainUpgradeable.sol";
-import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
-import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
-
-abstract contract MyTokenCrossChain is Initializable, ERC20Upgradeable, AccessControlCrossChainUpgradeable, UUPSUpgradeable {
-    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
-    bytes32 public constant UPGRADER_ROLE = keccak256("UPGRADER_ROLE");
-
-    /// @custom:oz-upgrades-unsafe-allow constructor
-    constructor() initializer {}
-
-    function initialize(address initialOwner) initializer public {
-        __ERC20_init("MyToken", "MTK");
-        __AccessControl_init();
-        __UUPSUpgradeable_init();
-
-        _grantRole(_crossChainRoleAlias(DEFAULT_ADMIN_ROLE), initialOwner); // initialOwner is on a remote chain
-    }
-
-    function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
-        _mint(to, amount);
-    }
-
-    function _authorizeUpgrade(address newImplementation) internal onlyRole(UPGRADER_ROLE) override {
-    }
-}
-
-import "@openzeppelin/contracts-upgradeable/crosschain/amb/CrossChainEnabledAMB.sol";
-
-contract MyTokenXDAI is
-    MyTokenCrossChain,
-    CrossChainEnabledAMB(0x75Df5AF045d91108662D8080fD1FEFAd6aA0bb59)
-{}
-
-import "@openzeppelin/contracts-upgradeable/crosschain/optimismCrossChainEnabledOptimism.sol";
-
-contract MyTokenOptimism is
-    MyTokenCrossChain,
-    CrossChainEnabledOptimism(0x25ace71c97B33Cc4729CF772ae268934F7ab5fA1)
-{}
-----

package/lib/openzeppelin-contracts.git/docs/modules/ROOT/pages/crowdsales.adoc

@@ -1,11 +0,0 @@
-= Crowdsales
-
-All crowdsale-related contracts were removed from the OpenZeppelin Contracts library on the https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-beta-release/2256[v3.0.0 release] due to both a decline in their usage and the complexity associated with migrating them to Solidity v0.6.
-
-They are however still available on the v2.5 release of OpenZeppelin Contracts, which you can install by running:
-
-```console
-$ npm install @openzeppelin/contracts@v2.5
-```
-
-Refer to the https://docs.openzeppelin.com/contracts/2.x/crowdsales[v2.x documentation] when working with them.

package/lib/openzeppelin-contracts.git/docs/modules/ROOT/pages/drafts.adoc

@@ -1,19 +0,0 @@
-= Drafts
-
-All draft contracts were either moved into a different directory or removed from the OpenZeppelin Contracts library on the https://forum.openzeppelin.com/t/openzeppelin-contracts-v3-0-beta-release/2256[v3.0.0 release].
-
-* `ERC20Migrator`: removed.
-* xref:api:token/ERC20.adoc#ERC20Snapshot[`ERC20Snapshot`]: moved to `token/ERC20`.
-* `ERC20Detailed` and `ERC1046`: removed.
-* `TokenVesting`: removed. Pending a replacement that is being discussed in https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1214[`#1214`].
-* xref:api:utils.adoc#Counters[`Counters`]: moved to xref:api:utils.adoc[`utils`].
-* xref:api:utils.adoc#Strings[`Strings`]: moved to xref:api:utils.adoc[`utils`].
-* xref:api:utils.adoc#SignedSafeMath[`SignedSafeMath`]: moved to xref:api:utils.adoc[`utils`].
-
-Removed contracts are still available on the v2.5 release of OpenZeppelin Contracts, which you can install by running:
-
-```console
-$ npm install @openzeppelin/contracts@v2.5
-```
-
-Refer to the xref:2.x@contracts:api:drafts.adoc[v2.x documentation] when working with them.