polkamarkets-js 3.4.1 → 3.4.3

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

@@ -1,63 +0,0 @@
-= Contracts
-
-*A library for secure smart contract development.* Build on a solid foundation of community-vetted code.
-
- * Implementations of standards like xref:erc20.adoc[ERC20] and xref:erc721.adoc[ERC721].
- * Flexible xref:access-control.adoc[role-based permissioning] scheme.
- * Reusable xref:utilities.adoc[Solidity components] to build custom contracts and complex decentralized systems.
-
-== Overview
-
-[[install]]
-=== Installation
-
-```console
-$ npm install @openzeppelin/contracts
-```
-
-OpenZeppelin Contracts features a xref:releases-stability.adoc#api-stability[stable API], which means your contracts won't break unexpectedly when upgrading to a newer minor version.
-
-[[usage]]
-=== Usage
-
-Once installed, you can use the contracts in the library by importing them:
-
-[source,solidity]
-----
-// contracts/MyNFT.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-
-contract MyNFT is ERC721 {
-    constructor() ERC721("MyNFT", "MNFT") {
-    }
-}
-----
-
-TIP: If you're new to smart contract development, head to xref:learn::developing-smart-contracts.adoc[Developing Smart Contracts] to learn about creating a new project and compiling your contracts.
-
-To keep your system secure, you should **always** use the installed code as-is, and neither copy-paste it from online sources, nor modify it yourself. The library is designed so that only the contracts and functions you use are deployed, so you don't need to worry about it needlessly increasing gas costs.
-
-[[security]]
-== Security
-
-Please report any security issues you find via our https://www.immunefi.com/bounty/openzeppelin[bug bounty program on Immunefi] or directly to security@openzeppelin.org.
-
-[[next-steps]]
-== Learn More
-
-The guides in the sidebar will teach about different concepts, and how to use the related contracts that OpenZeppelin Contracts provides:
-
-* xref:access-control.adoc[Access Control]: decide who can perform each of the actions on your system.
-* xref:tokens.adoc[Tokens]: create tradable assets or collectibles, like the well known xref:erc20.adoc[ERC20] and xref:erc721.adoc[ERC721] standards.
-* xref:utilities.adoc[Utilities]: generic useful tools, including non-overflowing math, signature verification, and trustless paying systems.
-
-The xref:api:token/ERC20.adoc[full API] is also thoroughly documented, and serves as a great reference when developing your smart contract application. You can also ask for help or follow Contracts' development in the https://forum.openzeppelin.com[community forum].
-
-Finally, you may want to take a look at the https://blog.openzeppelin.com/guides/[guides on our blog], which cover several common use cases and good practices. The following articles provide great background reading, though please note, some of the referenced tools have changed as the tooling in the ecosystem continues to rapidly evolve.
-
-* https://blog.openzeppelin.com/the-hitchhikers-guide-to-smart-contracts-in-ethereum-848f08001f05[The Hitchhiker’s Guide to Smart Contracts in Ethereum] will help you get an overview of the various tools available for smart contract development, and help you set up your environment.
-* https://blog.openzeppelin.com/a-gentle-introduction-to-ethereum-programming-part-1-783cc7796094[A Gentle Introduction to Ethereum Programming, Part 1] provides very useful information on an introductory level, including many basic concepts from the Ethereum platform.
-* For a more in-depth dive, you may read the guide https://blog.openzeppelin.com/designing-the-architecture-for-your-ethereum-application-9cec086f8317[Designing the architecture for your Ethereum application], which discusses how to better structure your application and its relationship to the real world.

package/lib/openzeppelin-contracts-upgradeable.git/docs/modules/ROOT/pages/releases-stability.adoc

@@ -1,85 +0,0 @@
-= New Releases and API Stability
-
-Developing smart contracts is hard, and a conservative approach towards dependencies is sometimes favored. However, it is also very important to stay on top of new releases: these may include bug fixes, or deprecate old patterns in favor of newer and better practices.
-
-Here we describe when you should expect new releases to come out, and how this affects you as a user of OpenZeppelin Contracts.
-
-[[release-schedule]]
-== Release Schedule
-
-OpenZeppelin Contracts follows a <<versioning-scheme, semantic versioning scheme>>.
-
-We aim for a new minor release every 1 or 2 months.
-
-[[minor-releases]]
-=== Release Candidates
-
-Before every release, we publish a feature-frozen release candidate. The purpose of the release candidate is to have a period where the community can review the new code before the actual release. If important problems are discovered, several more release candidates may be required. After a week of no more changes to the release candidate, the new version is published.
-
-[[major-releases]]
-=== Major Releases
-
-After several months or a year a new major release may come out. These are not scheduled, but will be based on the need to release breaking changes such as a redesign of a core feature of the library (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/pulls/2112[access control] in 3.0). Since we value stability, we aim for these to happen infrequently (expect no less than six months between majors). However, we may be forced to release one when there are big changes to the Solidity language.
-
-[[api-stability]]
-== API Stability
-
-On the https://github.com/OpenZeppelin/openzeppelin-contracts/releases/tag/v2.0.0[OpenZeppelin Contracts 2.0 release], we committed ourselves to keeping a stable API. We aim to more precisely define what we understand by _stable_ and _API_ here, so users of the library can understand these guarantees and be confident their project won't break unexpectedly.
-
-In a nutshell, the API being stable means _if your project is working today, it will continue to do so after a minor upgrade_. New contracts and features will be added in minor releases, but only in a backwards compatible way.
-
-[[versioning-scheme]]
-=== Versioning Scheme
-
-We follow https://semver.org/[SemVer], which means API breakage may occur between major releases (which <<release-schedule, don't happen very often>>).
-
-[[solidity-functions]]
-=== Solidity Functions
-
-While the internal implementation of functions may change, their semantics and signature will remain the same. The domain of their arguments will not be less restrictive (e.g. if transferring a value of 0 is disallowed, it will remain disallowed), nor will general state restrictions be lifted (e.g. `whenPaused` modifiers).
-
-If new functions are added to a contract, it will be in a backwards-compatible way: their usage won't be mandatory, and they won't extend functionality in ways that may foreseeable break an application (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1512[an `internal` method may be added to make it easier to retrieve information that was already available]).
-
-[[internal]]
-==== `internal`
-
-This extends not only to `external` and `public` functions, but also `internal` ones: many contracts are meant to be used by inheriting them (e.g. `Pausable`, `PullPayment`, `AccessControl`), and are therefore used by calling these functions. Similarly, since all OpenZeppelin Contracts state variables are `private`, they can only be accessed this way (e.g. to create new `ERC20` tokens, instead of manually modifying `totalSupply` and `balances`, `_mint` should be called).
-
-`private` functions have no guarantees on their behavior, usage, or existence.
-
-Finally, sometimes language limitations will force us to e.g. make `internal` a function that should be `private` in order to implement features the way we want to. These cases will be well documented, and the normal stability guarantees won't apply.
-
-[[libraries]]
-=== Libraries
-
-Some of our Solidity libraries use ``struct``s to handle internal data that should not be accessed directly (e.g. `Counter`). There's an https://github.com/ethereum/solidity/issues/4637[open issue] in the Solidity repository requesting a language feature to prevent said access, but it looks like it won't be implemented any time soon. Because of this, we will use leading underscores and mark said `struct` s to make it clear to the user that its contents and layout are _not_ part of the API.
-
-[[events]]
-=== Events
-
-No events will be removed, and their arguments won't be changed in any way. New events may be added in later versions, and existing events may be emitted under new, reasonable circumstances (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/issues/707[from 2.1 on, `ERC20` also emits `Approval` on `transferFrom` calls]).
-
-[[drafts]]
-=== Drafts
-
-Some contracts implement EIPs that are still in Draft status, recognizable by a file name beginning with  `draft-`, such as `utils/cryptography/draft-EIP712.sol`. Due to their nature as drafts, the details of these contracts may change and we cannot guarantee their stability. Minor releases of OpenZeppelin Contracts may contain breaking changes for the contracts labelled as Drafts, which will be duly announced in the https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md[changelog]. The EIPs included are used by projects in production and this may make them less likely to change significantly.
-
-[[gas-costs]]
-=== Gas Costs
-
-While attempts will generally be made to lower the gas costs of working with OpenZeppelin Contracts, there are no guarantees regarding this. In particular, users should not assume gas costs will not increase when upgrading library versions.
-
-[[bugfixes]]
-=== Bug Fixes
-
-The API stability guarantees may need to be broken in order to fix a bug, and we will do so. This decision won't be made lightly however, and all options will be explored to make the change as non-disruptive as possible. When sufficient, contracts or functions which may result in unsafe behavior will be deprecated instead of removed (e.g. https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1543[#1543] and https://github.com/OpenZeppelin/openzeppelin-contracts/pull/1550[#1550]).
-
-[[solidity-compiler-version]]
-=== Solidity Compiler Version
-
-Starting on version 0.5.0, the Solidity team switched to a faster release cycle, with minor releases every few weeks (v0.5.0 was released on November 2018, and v0.5.5 on March 2019), and major, breaking-change releases every couple of months (with v0.6.0 released on December 2019 and v0.7.0 on July 2020). Including the compiler version in OpenZeppelin Contract's stability guarantees would therefore force the library to either stick to old compilers, or release frequent major updates simply to keep up with newer Solidity releases.
-
-Because of this, *the minimum required Solidity compiler version is not part of the stability guarantees*, and users may be required to upgrade their compiler when using newer versions of Contracts. Bug fixes will still be backported to past major releases so that all versions currently in use receive these updates.
-
-You can read more about the rationale behind this, the other options we considered and why we went down this path https://github.com/OpenZeppelin/openzeppelin-contracts/issues/1498#issuecomment-449191611[here].
-

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

@@ -1,32 +0,0 @@
-= Tokens
-
-Ah, the "token": blockchain's most powerful and most misunderstood tool.
-
-A token is a _representation of something in the blockchain_. This something can be money, time, services, shares in a company, a virtual pet, anything. By representing things as tokens, we can allow smart contracts to interact with them, exchange them, create or destroy them.
-
-[[but_first_coffee_a_primer_on_token_contracts]]
-== But First, [strikethrough]#Coffee# a Primer on Token Contracts
-
-Much of the confusion surrounding tokens comes from two concepts getting mixed up: _token contracts_ and the actual _tokens_.
-
-A _token contract_ is simply an Ethereum smart contract. "Sending tokens" actually means "calling a method on a smart contract that someone wrote and deployed". At the end of the day, a token contract is not much more than a mapping of addresses to balances, plus some methods to add and subtract from those balances.
-
-It is these balances that represent the _tokens_ themselves. Someone "has tokens" when their balance in the token contract is non-zero. That's it! These balances could be considered money, experience points in a game, deeds of ownership, or voting rights, and each of these tokens would be stored in different token contracts.
-
-[[different-kinds-of-tokens]]
-== Different Kinds of Tokens
-
-Note that there's a big difference between having two voting rights and two deeds of ownership: each vote is equal to all others, but houses usually are not! This is called https://en.wikipedia.org/wiki/Fungibility[fungibility]. _Fungible goods_ are equivalent and interchangeable, like Ether, fiat currencies, and voting rights. _Non-fungible_ goods are unique and distinct, like deeds of ownership, or collectibles.
-
-In a nutshell, when dealing with non-fungibles (like your house) you care about _which ones_ you have, while in fungible assets (like your bank account statement) what matters is _how much_ you have.
-
-== Standards
-
-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:
-
- * 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:erc777.adoc[ERC777]: a richer standard for fungible tokens, enabling new use cases and building on past learnings. Backwards compatible with ERC20.
- * 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.

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

@@ -1,73 +0,0 @@
-= Using with Upgrades
-
-If your contract is going to be deployed with upgradeability, such as using the xref:upgrades-plugins::index.adoc[OpenZeppelin Upgrades Plugins], you will need to use the Upgradeable variant of OpenZeppelin Contracts.
-
-This variant is available as a separate package called `@openzeppelin/contracts-upgradeable`, which is hosted in the repository https://github.com/OpenZeppelin/openzeppelin-contracts-upgradeable[OpenZeppelin/openzeppelin-contracts-upgradeable].
-
-It follows all of the rules for xref:upgrades-plugins::writing-upgradeable.adoc[Writing Upgradeable Contracts]: constructors are replaced by initializer functions, state variables are initialized in initializer functions, and we additionally check for storage incompatibilities across minor versions.
-
-TIP: OpenZeppelin provides a full suite of tools for deploying and securing upgradeable smart contracts. xref:openzeppelin::upgrades.adoc[Check out the full list of resources].
-
-== Overview
-
-=== Installation
-
-```console
-$ npm install @openzeppelin/contracts-upgradeable
-```
-
-=== Usage
-
-The package replicates the structure of the main OpenZeppelin Contracts package, but every file and contract has the suffix `Upgradeable`.
-
-```diff
--import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-+import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
- 
--contract MyCollectible is ERC721 {
-+contract MyCollectible is ERC721Upgradeable {
-```
-
-Constructors are replaced by internal initializer functions following the naming convention `+__{ContractName}_init+`. Since these are internal, you must always define your own public initializer function and call the parent initializer of the contract you extend.
-
-```diff
--    constructor() ERC721("MyCollectible", "MCO") public {
-+    function initialize() initializer public {
-+        __ERC721_init("MyCollectible", "MCO");
-     }
-```
-
-CAUTION: Use with multiple inheritance requires special attention. See the section below titled <<multiple-inheritance>>.
-
-Once this contract is set up and compiled, you can deploy it using the xref:upgrades-plugins::index.adoc[Upgrades Plugins]. The following snippet shows an example deployment script using Hardhat.
-
-```js
-// scripts/deploy-my-collectible.js
-const { ethers, upgrades } = require("hardhat");
-
-async function main() {
-  const MyCollectible = await ethers.getContractFactory("MyCollectible");
-
-  const mc = await upgrades.deployProxy(MyCollectible);
-
-  await mc.deployed();
-  console.log("MyCollectible deployed to:", mc.address);
-}
-
-main();
-```
-
-== Further Notes
-
-[[multiple-inheritance]]
-=== Multiple Inheritance
-
-Initializer functions are not linearized by the compiler like constructors. Because of this, each `+__{ContractName}_init+` function embeds the linearized calls to all parent initializers. As a consequence, calling two of these `init` functions can potentially initialize the same contract twice.
-
-The function `+__{ContractName}_init_unchained+` found in every contract is the initializer function minus the calls to parent initializers, and can be used to avoid the double initialization problem, but doing this manually is not recommended. We hope to be able to implement safety checks for this in future versions of the Upgrades Plugins.
-
-=== Storage Gaps
-
-You may notice that every contract includes a state variable named `+__gap+`. This is empty reserved space in storage that is put in place in Upgradeable contracts. It allows us to freely add new state variables in the future without compromising the storage compatibility with existing deployments.
-
-It isn't safe to simply add a state variable because it "shifts down" all of the state variables below in the inheritance chain. This makes the storage layouts incompatible, as explained in xref:upgrades-plugins::writing-upgradeable.adoc#modifying-your-contracts[Writing Upgradeable Contracts]. The size of the `+__gap+` array is calculated so that the amount of storage used by a contract always adds up to the same number (in this case 50 storage slots).

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

@@ -1,190 +0,0 @@
-= Utilities
-
-The OpenZeppelin Contracts provide a ton of useful utilities that you can use in your project. Here are some of the more popular ones.
-
-[[cryptography]]
-== Cryptography
-
-=== Checking Signatures On-Chain
-
-xref:api:utils.adoc#ECDSA[`ECDSA`] provides functions for recovering and managing Ethereum account ECDSA signatures. These are often generated via https://web3js.readthedocs.io/en/v1.7.3/web3-eth.html#sign[`web3.eth.sign`], and are a 65 byte array (of type `bytes` in Solidity) arranged the following way: `[[v (1)], [r (32)], [s (32)]]`.
-
-The data signer can be recovered with xref:api:utils.adoc#ECDSA-recover-bytes32-bytes-[`ECDSA.recover`], and its address compared to verify the signature. Most wallets will hash the data to sign and add the prefix '\x19Ethereum Signed Message:\n', so when attempting to recover the signer of an Ethereum signed message hash, you'll want to use xref:api:utils.adoc#ECDSA-toEthSignedMessageHash-bytes32-[`toEthSignedMessageHash`].
-
-[source,solidity]
-----
-using ECDSA for bytes32;
-
-function _verify(bytes32 data, bytes memory signature, address account) internal pure returns (bool) {
-    return data
-        .toEthSignedMessageHash()
-        .recover(signature) == account;
-}
-----
-
-WARNING: Getting signature verification right is not trivial: make sure you fully read and understand xref:api:utils.adoc#ECDSA[`ECDSA`]'s documentation.
-
-=== Verifying Merkle Proofs
-
-xref:api:utils.adoc#MerkleProof[`MerkleProof`] provides:
-
-* xref:api:utils.adoc#MerkleProof-verify-bytes32---bytes32-bytes32-[`verify`] - can prove that some value is part of a https://en.wikipedia.org/wiki/Merkle_tree[Merkle tree].
-
-* xref:api:utils.adoc#MerkleProof-multiProofVerify-bytes32-bytes32---bytes32---bool---[`multiProofVerify`] - can prove multiple values are part of a Merkle tree.
-
-[[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:
-
-* 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#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)`]
-* xref:api:utils.adoc#ERC165Checker-_supportsAllInterfaces-address-bytes4---[`myAddress._supportsAllInterfaces(bytes4[\])`]
-
-[source,solidity]
-----
-contract MyContract {
-    using ERC165Checker for address;
-
-    bytes4 private InterfaceId_ERC721 = 0x80ac58cd;
-
-    /**
-     * @dev transfer an ERC721 token from this contract to someone else
-     */
-    function transferERC721(
-        address token,
-        address to,
-        uint256 tokenId
-    )
-        public
-    {
-        require(token.supportsInterface(InterfaceId_ERC721), "IS_NOT_721_TOKEN");
-        IERC721(token).transferFrom(address(this), to, tokenId);
-    }
-}
-----
-
-[[math]]
-== Math
-
-The most popular math related library OpenZeppelin Contracts provides is xref:api:utils.adoc#SafeMath[`SafeMath`], which provides mathematical functions that protect your contract from overflows and underflows.
-
-Include the contract with `using SafeMath for uint256;` and then call the functions:
-
-* `myNumber.add(otherNumber)`
-* `myNumber.sub(otherNumber)`
-* `myNumber.div(otherNumber)`
-* `myNumber.mul(otherNumber)`
-* `myNumber.mod(otherNumber)`
-
-Easy!
-
-[[payment]]
-== Payment
-
-Want to split some payments between multiple people? Maybe you have an app that sends 30% of art purchases to the original creator and 70% of the profits to the current owner; you can build that with xref:api:finance.adoc#PaymentSplitter[`PaymentSplitter`]!
-
-In Solidity, there are some security concerns with blindly sending money to accounts, since it allows them to execute arbitrary code. You can read up on these security concerns in the https://consensys.github.io/smart-contract-best-practices/[Ethereum Smart Contract Best Practices] website. One of the ways to fix reentrancy and stalling problems is, instead of immediately sending Ether to accounts that need it, you can use xref:api:security.adoc#PullPayment[`PullPayment`], which offers an xref:api:security.adoc#PullPayment-_asyncTransfer-address-uint256-[`_asyncTransfer`] function for sending money to something and requesting that they xref:api:security.adoc#PullPayment-withdrawPayments-address-payable-[`withdrawPayments()`] it later.
-
-If you want to Escrow some funds, check out xref:api:utils.adoc#Escrow[`Escrow`] and xref:api:utils.adoc#ConditionalEscrow[`ConditionalEscrow`] for governing the release of some escrowed Ether.
-
-[[collections]]
-== Collections
-
-If you need support for more powerful collections than Solidity's native arrays and mappings, take a look at xref:api:utils.adoc#EnumerableSet[`EnumerableSet`] and xref:api:utils.adoc#EnumerableMap[`EnumerableMap`]. They are similar to mappings in that they store and remove elements in constant time and don't allow for repeated entries, but they also support _enumeration_, which means you can easily query all stored entries both on and off-chain.
-
-[[misc]]
-== Misc
-
-Want to check if an address is a contract? Use xref:api:utils.adoc#Address[`Address`] and xref:api:utils.adoc#Address-isContract-address-[`Address.isContract()`].
-
-Want to keep track of some numbers that increment by 1 every time you want another one? Check out xref:api:utils.adoc#Counters[`Counters`]. This is useful for lots of things, like creating incremental identifiers, as shown on the xref:erc721.adoc[ERC721 guide].
-
-=== Base64
-
-xref:api:utils.adoc#Base64[`Base64`] util allows you to transform `bytes32` data into its Base64 `string` representation. 
-
-This is specially useful to build 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.
-
-Consider this is an example to send JSON Metadata through a Base64 Data URI using an ERC721:
-
-[source, solidity]
-----
-// contracts/My721Token.sol
-// SPDX-License-Identifier: MIT
-
-import "@openzeppelin/contracts/token/ERC721/ERC721.sol";
-import "@openzeppelin/contracts/utils/Strings.sol";
-import "@openzeppelin/contracts/utils/Base64.sol";
-
-contract My721Token is ERC721 {
-    using Strings for uint256;
-
-    constructor() ERC721("My721Token", "MTK") {}
-    
-    ...
-
-    function tokenURI(uint256 tokenId)
-        public
-        pure
-        override
-        returns (string memory)
-    {
-        bytes memory dataURI = abi.encodePacked(
-            '{',
-                '"name": "My721Token #', tokenId.toString(), '"',
-                // Replace with extra ERC721 Metadata properties
-            '}'
-        );
-
-        return string(
-            abi.encodePacked(
-                "data:application/json;base64,", 
-                Base64.encode(dataURI)
-            )
-        );
-    }
-}
-----
-
-=== Multicall
-
-The `Multicall` abstract contract comes with a `multicall` function that bundles together multiple calls in a single external call. With it, external accounts may perform atomic operations comprising several function calls. This is not only useful for EOAs to make multiple calls in a single transaction, it's also a way to revert a previous call if a later one fails.
-
-Consider this dummy contract:
-
-[source,solidity]
-----
-// contracts/Box.sol
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.0;
-
-import "@openzeppelin/contracts/utils/Multicall.sol";
-
-contract Box is Multicall {
-    function foo() public {
-        ...
-    }
-
-    function bar() public {
-        ...
-    }
-}
-----
-
-This is how to call the `multicall` function using Truffle, 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();
-
-await instance.multicall([
-    instance.contract.methods.foo().encodeABI(),
-    instance.contract.methods.bar().encodeABI()
-]);
-----

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

@@ -1,15 +0,0 @@
-= Contracts Wizard
-:page-notoc:
-
-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!
-
-++++
-<script async src="https://wizard.openzeppelin.com/build/embed.js"></script>
-
-<oz-wizard style="display: block; min-height: 40rem;"></oz-wizard>
-++++
-
-

package/lib/openzeppelin-contracts-upgradeable.git/docs/templates/contract.hbs

@@ -1,85 +0,0 @@
-{{#each items}}
-:{{name}}: pass:normal[xref:#{{anchor}}[`++{{name}}++`]]
-{{/each}}
-
-[.contract]
-[[{{anchor}}]]
-=== `++{{name}}++` link:https://github.com/OpenZeppelin/openzeppelin-contracts/blob/v{{oz-version}}/{{__item_context.file.absolutePath}}[{github-icon},role=heading-link]
-
-[.hljs-theme-light.nopadding]
-```solidity
-import "@openzeppelin/{{__item_context.file.absolutePath}}";
-```
-
-{{{natspec.dev}}}
-
-{{#if modifiers}}
-[.contract-index]
-.Modifiers
---
-{{#each modifiers}}
-* {xref-{{anchor~}} }[`++{{name}}({{names params}})++`]
-{{/each}}
---
-{{/if}}
-
-{{#if has-functions}}
-[.contract-index]
-.Functions
---
-{{#each inherited-functions}}
-{{#unless @first}}
-[.contract-subindex-inherited]
-.{{contract.name}}
-{{/unless}}
-{{#each functions}}
-* {xref-{{anchor~}} }[`++{{name}}({{names params}})++`]
-{{/each}}
-
-{{/each}}
---
-{{/if}}
-
-{{#if has-events}}
-[.contract-index]
-.Events
---
-{{#each inheritance}}
-{{#unless @first}}
-[.contract-subindex-inherited]
-.{{name}}
-{{/unless}}
-{{#each events}}
-* {xref-{{anchor~}} }[`++{{name}}({{names params}})++`]
-{{/each}}
-
-{{/each}}
---
-{{/if}}
-
-{{#each modifiers}}
-[.contract-item]
-[[{{anchor}}]]
-==== `[.contract-item-name]#++{{name}}++#++({{typed-params params}})++` [.item-kind]#modifier#
-
-{{{natspec.dev}}}
-
-{{/each}}
-
-{{#each functions}}
-[.contract-item]
-[[{{anchor}}]]
-==== `[.contract-item-name]#++{{name}}++#++({{typed-params params}}){{#if returns}} → {{typed-params returns}}{{/if}}++` [.item-kind]#{{visibility}}#
-
-{{{natspec.dev}}}
-
-{{/each}}
-
-{{#each events}}
-[.contract-item]
-[[{{anchor}}]]
-==== `[.contract-item-name]#++{{name}}++#++({{typed-params params}})++` [.item-kind]#event#
-
-{{{natspec.dev}}}
-
-{{/each}}

package/lib/openzeppelin-contracts-upgradeable.git/docs/templates/helpers.js

@@ -1,46 +0,0 @@
-const { version } = require('../../package.json');
-
-module.exports['oz-version'] = () => version;
-
-module.exports['readme-path'] = (opts) => {
-  return 'contracts/' + opts.data.root.id.replace(/\.adoc$/, '') + '/README.adoc';
-};
-
-module.exports.names = (params) => params.map(p => p.name).join(', ');
-
-module.exports['typed-params'] = (params) => {
-  return params?.map(p => `${p.type}${p.indexed ? ' indexed' : ''}${p.name ? ' ' + p.name : ''}`).join(', ');
-};
-
-const slug = module.exports.slug = (str) => {
-  if (str === undefined) {
-    throw new Error('Missing argument');
-  }
-  return str.replace(/\W/g, '-');
-};
-
-const linksCache = new WeakMap();
-
-function getAllLinks (items) {
-  if (linksCache.has(items)) {
-    return linksCache.get(items);
-  }
-  const res = {};
-  linksCache.set(items, res);
-  for (const item of items) {
-    res[`xref-${item.anchor}`] = `xref:${item.__item_context.page}#${item.anchor}`;
-    res[slug(item.fullName)] = `pass:normal[xref:${item.__item_context.page}#${item.anchor}[\`${item.fullName}\`]]`;
-  }
-  return res;
-}
-
-module.exports['with-prelude'] = (opts) => {
-  const links = getAllLinks(opts.data.site.items);
-  const contents = opts.fn();
-  const neededLinks = contents
-    .match(/\{[-._a-z0-9]+\}/ig)
-    .map(m => m.replace(/^\{(.+)\}$/, '$1'))
-    .filter(k => k in links);
-  const prelude = neededLinks.map(k => `:${k}: ${links[k]}`).join('\n');
-  return prelude + '\n' + contents;
-};

package/lib/openzeppelin-contracts-upgradeable.git/docs/templates/page.hbs

@@ -1,4 +0,0 @@
-:github-icon: pass:[<svg class="icon"><use href="#github-icon"/></svg>]
-{{#with-prelude}}
-{{readme (readme-path)}}
-{{/with-prelude}}

package/lib/openzeppelin-contracts-upgradeable.git/docs/templates/properties.js

@@ -1,49 +0,0 @@
-const { isNodeType } = require('solidity-ast/utils');
-const { slug } = require('./helpers');
-
-module.exports.anchor = function anchor ({ item, contract }) {
-  let res = '';
-  if (contract) {
-    res += contract.name + '-';
-  }
-  res += item.name;
-  if ('parameters' in item) {
-    const signature = item.parameters.parameters.map(v => v.typeName.typeDescriptions.typeString).join(',');
-    res += slug('(' + signature + ')');
-  }
-  if (isNodeType('VariableDeclaration', item)) {
-    res += '-' + slug(item.typeName.typeDescriptions.typeString);
-  }
-  return res;
-};
-
-module.exports.inheritance = function ({ item, build }) {
-  if (!isNodeType('ContractDefinition', item)) {
-    throw new Error('used inherited-items on non-contract');
-  }
-
-  return item.linearizedBaseContracts
-    .map(id => build.deref('ContractDefinition', id))
-    .filter((c, i) => c.name !== 'Context' || i === 0);
-};
-
-module.exports['has-functions'] = function ({ item }) {
-  return item.inheritance.some(c => c.functions.length > 0);
-};
-
-module.exports['has-events'] = function ({ item }) {
-  return item.inheritance.some(c => c.events.length > 0);
-};
-
-module.exports['inherited-functions'] = function ({ item }) {
-  const { inheritance } = item;
-  const baseFunctions = new Set(
-    inheritance.flatMap(c => c.functions.flatMap(f => f.baseFunctions ?? [])),
-  );
-  return inheritance.map((contract, i) => ({
-    contract,
-    functions: contract.functions.filter(f =>
-      !baseFunctions.has(f.id) && (f.name !== 'constructor' || i === 0),
-    ),
-  }));
-};

package/lib/openzeppelin-contracts.git/docs/antora.yml

@@ -1,6 +0,0 @@
-name: contracts
-title: Contracts
-version: 4.x
-nav:
-  - modules/ROOT/nav.adoc
-  - modules/api/nav.adoc