polkamarkets-js 3.4.1 → 3.4.2

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

@@ -1,239 +0,0 @@
-= How to set up on-chain governance
-
-In this guide we will learn how OpenZeppelin’s Governor contract works, how to set it up, and how to use it to create proposals, vote for them, and execute them, using tools provided by Ethers.js and Tally.
-
-NOTE: Find detailed contract documentation at xref:api:governance.adoc[Governance API].
-
-== Introduction
-
-Decentralized protocols are in constant evolution from the moment they are publicly released. Often, the initial team retains control of this evolution in the first stages, but eventually delegates it to a community of stakeholders. The process by which this community makes decisions is called on-chain governance, and it has become a central component of decentralized protocols, fueling varied decisions such as parameter tweaking, smart contract upgrades, integrations with other protocols, treasury management, grants, etc.
-
-This governance protocol is generally implemented in a special-purpose contract called “Governor”. The GovernorAlpha and GovernorBravo contracts designed by Compound have been very successful and popular so far, with the downside that projects with different requirements have had to fork the code to customize it for their needs, which can pose a high risk of introducing security issues. For OpenZeppelin Contracts, we set out to build a modular system of Governor contracts so that forking is not needed, and different requirements can be accommodated by writing small modules using Solidity inheritance. You will find the most common requirements out of the box in OpenZeppelin Contracts, but writing additional ones is simple, and we will be adding new features as requested by the community in future releases. Additionally, the design of OpenZeppelin Governor requires minimal use of storage and results in more gas efficient operation.
-
-== Compatibility
-
-OpenZeppelin’s Governor system was designed with a concern for compatibility with existing systems that were based on Compound’s GovernorAlpha and GovernorBravo. Because of this, you will find that many modules are presented in two variants, one of which is built for compatibility with those systems.
-
-=== ERC20Votes & ERC20VotesComp
-
-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
-
-An OpenZeppelin Governor contract is not interface-compatible with Compound's GovernorAlpha or Bravo. Even though events are fully compatible, proposal lifecycle functions (creation, execution, etc.) have different signatures that are meant to optimize storage use. Other functions from GovernorAlpha and Bravo are likewise not available. It’s possible to opt in some Bravo-like behavior by inheriting from the GovernorStorage module. This module provides proposal enumerability and alternate versions of the `queue`, `execute` and `cancel` function that only take the proposal id. This module reduces the calldata needed by some operations in exchange for an increased storage footprint. This might be a good trade-off for some L2 chains. It also provides primitives for indexer-free frontends.
-
-Note that even with the use of this module, one important difference with Compound's GovernorBravo is the way that `proposalId`s are calculated. Governor uses the hash of the proposal parameters with the purpose of keeping its data off-chain by event indexing, while the original Bravo implementation uses sequential `proposalId`s.
-
-=== GovernorTimelockControl & GovernorTimelockCompound
-
-When using a timelock with your Governor contract, you can use either OpenZeppelin’s TimelockController or Compound’s Timelock. Based on the choice of timelock, you should choose the corresponding Governor module: GovernorTimelockControl or GovernorTimelockCompound respectively. This allows you to migrate an existing GovernorAlpha instance to an OpenZeppelin-based Governor without changing the timelock in use.
-
-=== Tally
-
-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, 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.
-
-== Setup
-
-=== Token
-
-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[]
-```
-
-If your project already has a live token that does not include ERC20Votes and is not upgradeable, you can wrap it in a governance token by using ERC20Wrapper. This will allow token holders to participate in governance by wrapping their tokens 1-to-1.
-
-```solidity
-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`]. 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/ERC721.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.
-
-=== Governor
-
-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 (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%).
-
-For 3) we will use GovernorCountingSimple, a module that offers 3 options to voters: For, Against, and Abstain, and where only For and Abstain votes are counted towards quorum.
-
-Besides these modules, Governor itself has some parameters we must set.
-
-votingDelay: How long after a proposal is created should voting power be fixed. A large voting delay gives users time to unstake tokens if necessary.
-
-votingPeriod: How long does a proposal remain open to votes.
-
-These parameters are specified in the unit defined in the token's clock. Assuming the token uses block numbers, and assuming block time of around 12 seconds, we will have set votingDelay = 1 day = 7200 blocks, and votingPeriod = 1 week = 50400 blocks.
-
-We can optionally set a proposal threshold as well. This restricts proposal creation to accounts that have enough voting power.
-
-```solidity
-include::api:example$governance/MyGovernor.sol[]
-```
-
-=== Timelock
-
-It is good practice to add a timelock to governance decisions. This allows users to exit the system if they disagree with a decision before it is executed. We will use OpenZeppelin’s TimelockController in combination with the GovernorTimelockControl module.
-
-IMPORTANT: When using a timelock, it is the timelock that will execute proposals and thus the timelock that should hold any funds, ownership, and access control roles. Before version 4.5 there was no way to recover funds in the Governor contract when using a timelock! Before version 4.3, when using the Compound Timelock, ETH in the timelock was not easily accessible.
-
-TimelockController uses an AccessControl setup that we need to understand in order to set up roles.
-
-- The Proposer role is in charge of queueing operations: this is the role the Governor instance should be granted, and it should likely be the only proposer in the system.
-- The Executor role is in charge of executing already available operations: we can assign this role to the special zero address to allow anyone to execute (if operations can be particularly time sensitive, the Governor should be made Executor instead).
-- Lastly, there is the Admin role, which can grant and revoke the two previous roles: this is a very sensitive role that will be granted automatically to the timelock itself, and optionally to a second account, which can be used for ease of setup but should promptly renounce the role.
-
-== Proposal Lifecycle
-
-Let’s walk through how to create and execute a proposal on our newly deployed Governor.
-
-A proposal is a sequence of actions that the Governor contract will perform if it passes. Each action consists of a target address, calldata encoding a function call, and an amount of ETH to include. Additionally, a proposal includes a human-readable description.
-
-=== Create a Proposal
-
-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 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.
-
-```javascript
-const tokenAddress = ...;
-const token = await ethers.getContractAt(‘ERC20’, tokenAddress);
-
-const teamAddress = ...;
-const grantAmount = ...;
-const transferCalldata = token.interface.encodeFunctionData(‘transfer’, [teamAddress, grantAmount]);
-```
-
-Now we are ready to call the propose function of the Governor. Note that we don’t pass in one array of actions, but instead three arrays corresponding to the list of targets, the list of values, and the list of calldatas. In this case it’s a single action, so it’s simple:
-
-```javascript
-await governor.propose(
-  [tokenAddress],
-  [0],
-  [transferCalldata],
-  “Proposal #1: Give grant to team”,
-);
-```
-
-This will create a new proposal, with a proposal id that is obtained by hashing together the proposal data, and which will also be found in an event in the logs of the transaction.
-
-=== Cast a Vote
-
-Once a proposal is active, delegates can cast their vote. Note that it is delegates who carry voting power: if a token holder wants to participate, they can set a trusted representative as their delegate, or they can become a delegate themselves by self-delegating their voting power.
-
-Votes are cast by interacting with the Governor contract through the `castVote` family of functions. Voters would generally invoke this from a governance UI such as Tally.
-
-image::tally-vote.png[Voting in Tally]
-
-=== Execute the Proposal
-
-Once the voting period is over, if quorum was reached (enough voting power participated) and the majority voted in favor, the proposal is considered successful and can proceed to be executed. Once a proposal passes, it can be queued and executed from the same place you voted.
-
-image::tally-exec.png[Administration Panel in Tally]
-
-We will see now how to do this manually using Ethers.js.
-
-If a timelock was set up, the first step to execution is queueing. You will notice that both the queue and execute functions require passing in the entire proposal parameters, as opposed to just the proposal id. This is necessary because this data is not stored on chain, as a measure to save gas. Note that these parameters can always be found in the events emitted by the contract. The only parameter that is not sent in its entirety is the description, since this is only needed in its hashed form to compute the proposal id.
-
-To queue, we call the queue function:
-
-```javascript
-const descriptionHash = ethers.utils.id(“Proposal #1: Give grant to team”);
-
-await governor.queue(
-  [tokenAddress],
-  [0],
-  [transferCalldata],
-  descriptionHash,
-);
-```
-
-This will cause the Governor to interact with the timelock contract and queue the actions for execution after the required delay.
-
-After enough time has passed (according to the timelock parameters), the proposal can be executed. If there was no timelock to begin with, this step can be ran immediately after the proposal succeeds.
-
-```javascript
-await governor.execute(
-  [tokenAddress],
-  [0],
-  [transferCalldata],
-  descriptionHash,
-);
-```
-
-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
-
-=== Motivation
-
-It is sometimes difficult to deal with durations expressed in number of blocks because of inconsistent or unpredictable time between blocks. This is particularly true of some L2 networks where blocks are produced based on blockchain usage. Using number of blocks can also lead to the governance rules being affected by network upgrades that modify the expected time between blocks.
-
-The difficulty of replacing block numbers with timestamps is that the Governor and the token must both use the same format when querying past votes. If a token is designed around block numbers, it is not possible for a Governor to reliably do timestamp based lookups.
-
-Therefore, designing a timestamp based voting system starts with the token.
-
-=== Token
-
-Since v4.9, all voting contracts (including xref:api:token/ERC20.adoc#ERC20Votes[`ERC20Votes`] and xref:api:token/ERC721.adoc#ERC721Votes[`ERC721Votes`]) rely on xref:api:interfaces.adoc#IERC6372[IERC6372] for clock management. In order to change from operating with block numbers to operating with timestamps, all that is required is to override the `clock()` and `CLOCK_MODE()` functions.
-
-```solidity
-include::api:example$governance/MyTokenTimestampBased.sol[]
-```
-
-=== Governor
-
-The Governor will automatically detect the clock mode used by the token and adapt to it. There is no need to override anything in the Governor contract. However, the clock mode does affect how some values are interpreted. It is therefore necessary to set the `votingDelay()` and `votingPeriod()` accordingly.
-
-```solidity
-// SPDX-License-Identifier: MIT
-pragma solidity ^0.8.20;
-
-import {Governor} from "@openzeppelin/contracts/governance/Governor.sol";
-import {GovernorCountingSimple} from "@openzeppelin/contracts/governance/compatibility/GovernorCountingSimple.sol";
-import {GovernorVotes} from "@openzeppelin/contracts/governance/extensions/GovernorVotes.sol";
-import {GovernorVotesQuorumFraction} from "@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol";
-import {GovernorTimelockControl} from "@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol";
-import {TimelockController} from "@openzeppelin/contracts/governance/TimelockController.sol";
-import {IVotes} from "@openzeppelin/contracts/governance/utils/IVotes.sol";
-
-contract MyGovernor is Governor, GovernorCountingSimple, GovernorVotes, GovernorVotesQuorumFraction, GovernorTimelockControl {
-    constructor(IVotes _token, TimelockController _timelock)
-        Governor("MyGovernor")
-        GovernorVotes(_token)
-        GovernorVotesQuorumFraction(4)
-        GovernorTimelockControl(_timelock)
-    {}
-
-    function votingDelay() public pure virtual override returns (uint256) {
-        return 1 days;
-    }
-
-    function votingPeriod() public pure virtual override returns (uint256) {
-        return 1 weeks;
-    }
-
-    function proposalThreshold() public pure virtual override returns (uint256) {
-        return 0;
-    }
-
-    // ...
-}
-```
-
-=== 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, 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.

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

@@ -1,70 +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.
-
-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 xref:backwards-compatibility.adoc[Backwards Compatibility].
-
-== Overview
-
-[[install]]
-=== Installation
-
-==== Hardhat (npm)
-
-```console
-$ npm install @openzeppelin/contracts
-```
-
-==== Foundry (git)
-
-WARNING: When installing via git, it is a common error to use the `master` branch. This is a development branch that should be avoided in favor of tagged releases. The release process involves security measures that the `master` branch does not guarantee.
-
-WARNING: Foundry installs the latest version initially, but subsequent `forge update` commands will use the `master` branch.
-
-```console
-$ forge install OpenZeppelin/openzeppelin-contracts
-```
-
-Add `@openzeppelin/contracts/=lib/openzeppelin-contracts/contracts/` in `remappings.txt.` 
-
-[[usage]]
-=== Usage
-
-Once installed, you can use the contracts in the library by importing them:
-
-[source,solidity]
-----
-include::api:example$MyNFT.sol[]
-----
-
-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.
-
-The https://contracts.openzeppelin.com/security[Security Center] contains more details about the secure development process.
-
-[[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].
-
-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/lib/openzeppelin-contracts/docs/modules/ROOT/pages/multisig.adoc

@@ -1,306 +0,0 @@
-= Multisig Account
-
-A multi-signature (multisig) account is a smart account that requires multiple authorized signers to approve operations before execution. Unlike traditional accounts controlled by a single private key, multisigs distribute control among multiple parties, eliminating single points of failure. For example, a 2-of-3 multisig requires signatures from at least 2 out of 3 possible signers.
-
-Popular implementations like https://safe.global/[Safe] (formerly Gnosis Safe) have become the standard for securing valuable assets. Multisigs provide enhanced security through collective authorization, customizable controls for ownership and thresholds, and the ability to rotate signers without changing the account address.
-
-== Beyond Standard Signature Verification
-
-As discussed in the xref:accounts.adoc#signature_validation[accounts section], the standard approach for smart contracts to verify signatures is https://eips.ethereum.org/EIPS/eip-1271[ERC-1271], which defines an `isValidSignature(hash, signature)`. However, it is limited in two important ways:
-
-1. It assumes the signer has an EVM address
-2. It treats the signer as a single identity
-
-This becomes problematic when implementing multisig accounts where:
-
-* You may want to use signers that don't have EVM addresses (like keys from hardware devices)
-* Each signer needs to be individually verified rather than treated as a collective identity
-* You need a threshold system to determine when enough valid signatures are present
-
-The https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/utils/cryptography/SignatureChecker.sol[SignatureChecker] library is useful for verifying EOA and ERC-1271 signatures, but it's not designed for more complex arrangements like threshold-based multisigs.
-
-== ERC-7913 Signers
-
-https://eips.ethereum.org/EIPS/eip-7913[ERC-7913] extends the concept of signer representation to include keys that don't have EVM addresses, addressing this limitation. OpenZeppelin implements this standard through three contracts:
-
-=== SignerERC7913
-
-The xref:api:utils.adoc#SignerERC7913[`SignerERC7913`] contract allows a single ERC-7913 formatted signer to control an account. The signer is represented as a `bytes` object that concatenates a verifier address and a key: `verifier || key`.
-
-[source,solidity]
-----
-// contracts/MyAccountERC7913.sol
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.24;
-
-import {Account} from "@openzeppelin/community-contracts/account/Account.sol";
-import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
-import {ERC721Holder} from "@openzeppelin/contracts/token/ERC721/utils/ERC721Holder.sol";
-import {ERC1155Holder} from "@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol";
-import {ERC7739} from "@openzeppelin/community-contracts/utils/cryptography/signers/ERC7739.sol";
-import {ERC7821} from "@openzeppelin/community-contracts/account/extensions/ERC7821.sol";
-import {Initializable} from "@openzeppelin/contracts/proxy/utils/Initializable.sol";
-import {SignerERC7913} from "@openzeppelin/community-contracts/utils/cryptography/signers/SignerERC7913.sol";
-
-contract MyAccountERC7913 is Account, SignerERC7913, ERC7739, ERC7821, ERC721Holder, ERC1155Holder, Initializable {
-    constructor() EIP712("MyAccount7913", "1") {}
-
-    function initialize(bytes memory signer) public initializer {
-        _setSigner(signer);
-    }
-
-    function setSigner(bytes memory signer) public onlyEntryPointOrSelf {
-        _setSigner(signer);
-    }
-
-    /// @dev Allows the entry point as an authorized executor.
-    function _erc7821AuthorizedExecutor(
-        address caller,
-        bytes32 mode,
-        bytes calldata executionData
-    ) internal view virtual override returns (bool) {
-        return caller == address(entryPoint()) || super._erc7821AuthorizedExecutor(caller, mode, executionData);
-    }
-}
-----
-
-WARNING: Leaving an account uninitialized may leave it unusable since no public key was associated with it.
-
-=== MultiSignerERC7913
-
-The xref:api:utils/cryptography.adoc#MultiSignerERC7913[`MultiSignerERC7913`] contract extends this concept to support multiple signers with a threshold-based signature verification system.
-
-[source,solidity]
-----
-// contracts/MyAccountMultiSigner.sol
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.27;
-
-import {Account} from "@openzeppelin/community-contracts/account/Account.sol";
-import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
-import {ERC721Holder} from "@openzeppelin/contracts/token/ERC721/utils/ERC721Holder.sol";
-import {ERC1155Holder} from "@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol";
-import {ERC7739} from "@openzeppelin/community-contracts/utils/cryptography/signers/ERC7739.sol";
-import {ERC7821} from "@openzeppelin/community-contracts/account/extensions/ERC7821.sol";
-import {Initializable} from "@openzeppelin/contracts/proxy/utils/Initializable.sol";
-import {MultiSignerERC7913} from "@openzeppelin/community-contracts/utils/cryptography/signers/MultiSignerERC7913.sol";
-
-contract MyAccountMultiSigner is
-    Account,
-    MultiSignerERC7913,
-    ERC7739,
-    ERC7821,
-    ERC721Holder,
-    ERC1155Holder,
-    Initializable
-{
-    constructor() EIP712("MyAccountMultiSigner", "1") {}
-
-    function initialize(bytes[] memory signers, uint256 threshold) public initializer {
-        _addSigners(signers);
-        _setThreshold(threshold);
-    }
-
-    function addSigners(bytes[] memory signers) public onlyEntryPointOrSelf {
-        _addSigners(signers);
-    }
-
-    function removeSigners(bytes[] memory signers) public onlyEntryPointOrSelf {
-        _removeSigners(signers);
-    }
-
-    function setThreshold(uint256 threshold) public onlyEntryPointOrSelf {
-        _setThreshold(threshold);
-    }
-
-    /// @dev Allows the entry point as an authorized executor.
-    function _erc7821AuthorizedExecutor(
-        address caller,
-        bytes32 mode,
-        bytes calldata executionData
-    ) internal view virtual override returns (bool) {
-        return caller == address(entryPoint()) || super._erc7821AuthorizedExecutor(caller, mode, executionData);
-    }
-}
-----
-
-This implementation is ideal for standard multisig setups where each signer has equal authority, and a fixed number of approvals is required.
-
-The `MultiSignerERC7913` contract provides several key features for managing multi-signature accounts. It maintains a set of authorized signers and implements a threshold-based system that requires a minimum number of signatures to approve operations. The contract includes an internal interface for managing signers, allowing for the addition and removal of authorized parties.
-
-NOTE: `MultiSignerERC7913` safeguards to ensure that the threshold remains achievable based on the current number of active signers, preventing situations where operations could become impossible to execute.
-
-The contract also provides public functions for querying signer information: xref:api:utils/cryptography.adoc#MultiSignerERC7913-isSigner-bytes-[`isSigner(bytes memory signer)`] to check if a given signer is authorized, xref:api:utils/cryptography.adoc#MultiSignerERC7913-getSigners-uint64-uint64-[`getSigners(uint64 start, uint64 end)`] to retrieve a paginated list of authorized signers, and xref:api:utils/cryptography.adoc#MultiSignerERC7913-getSignerCount[`getSignerCount()`] to get the total number of signers. These functions are useful when validating signatures, implementing customized access control logic, or building user interfaces that need to display signer information.
-
-=== MultiSignerERC7913Weighted
-
-For more sophisticated governance structures, the xref:api:utils/cryptography.adoc#MultiSignerERC7913Weighted[`MultiSignerERC7913Weighted`] contract extends `MultiSignerERC7913` by assigning different weights to each signer.
-
-[source,solidity]
-----
-// contracts/MyAccountMultiSignerWeighted.sol
-// SPDX-License-Identifier: MIT
-
-pragma solidity ^0.8.27;
-
-import {Account} from "@openzeppelin/community-contracts/account/Account.sol";
-import {EIP712} from "@openzeppelin/contracts/utils/cryptography/EIP712.sol";
-import {ERC721Holder} from "@openzeppelin/contracts/token/ERC721/utils/ERC721Holder.sol";
-import {ERC1155Holder} from "@openzeppelin/contracts/token/ERC1155/utils/ERC1155Holder.sol";
-import {ERC7739} from "@openzeppelin/community-contracts/utils/cryptography/signers/ERC7739.sol";
-import {ERC7821} from "@openzeppelin/community-contracts/account/extensions/ERC7821.sol";
-import {Initializable} from "@openzeppelin/contracts/proxy/utils/Initializable.sol";
-import {MultiSignerERC7913Weighted} from "@openzeppelin/community-contracts/utils/cryptography/signers/MultiSignerERC7913Weighted.sol";
-
-contract MyAccountMultiSignerWeighted is
-    Account,
-    MultiSignerERC7913Weighted,
-    ERC7739,
-    ERC7821,
-    ERC721Holder,
-    ERC1155Holder,
-    Initializable
-{
-    constructor() EIP712("MyAccountMultiSignerWeighted", "1") {}
-
-    function initialize(bytes[] memory signers, uint256[] memory weights, uint256 threshold) public initializer {
-        _addSigners(signers);
-        _setSignerWeights(signers, weights);
-        _setThreshold(threshold);
-    }
-
-    function addSigners(bytes[] memory signers) public onlyEntryPointOrSelf {
-        _addSigners(signers);
-    }
-
-    function removeSigners(bytes[] memory signers) public onlyEntryPointOrSelf {
-        _removeSigners(signers);
-    }
-
-    function setThreshold(uint256 threshold) public onlyEntryPointOrSelf {
-        _setThreshold(threshold);
-    }
-
-    function setSignerWeights(bytes[] memory signers, uint256[] memory weights) public onlyEntryPointOrSelf {
-        _setSignerWeights(signers, weights);
-    }
-
-    /// @dev Allows the entry point as an authorized executor.
-    function _erc7821AuthorizedExecutor(
-        address caller,
-        bytes32 mode,
-        bytes calldata executionData
-    ) internal view virtual override returns (bool) {
-        return caller == address(entryPoint()) || super._erc7821AuthorizedExecutor(caller, mode, executionData);
-    }
-}
-----
-
-This implementation is perfect for scenarios where different signers should have varying levels of authority, such as:
-
-* Board members with different voting powers
-* Organizational structures with hierarchical decision-making
-* Hybrid governance systems combining core team and community members
-* Execution setups like "social recovery" where you trust particular guardians more than others
-
-The `MultiSignerERC7913Weighted` contract extends `MultiSignerERC7913` with a weighting system. Each signer can have a custom weight, and operations require the total weight of signing participants to meet or exceed the threshold. Signers without explicit weights default to a weight of 1.
-
-NOTE: When setting up a weighted multisig, ensure the threshold value matches the scale used for signer weights. For example, if signers have weights like 1, 2, or 3, then a threshold of 4 would require at least two signers (e.g., one with weight 1 and one with weight 3).
-
-== Setting Up a Multisig Account
-
-To create a multisig account, you need to:
-
-1. Define your signers
-2. Determine your threshold
-3. Initialize your account with these parameters
-
-The example below demonstrates setting up a 2-of-3 multisig account with different types of signers:
-
-[source,solidity]
-----
-// Example setup code
-function setupMultisigAccount() external {
-    // Create signers using different types of keys
-    bytes memory ecdsaSigner = alice; // EOA address (20 bytes)
-    
-    // P256 signer with format: verifier || pubKey
-    bytes memory p256Signer = abi.encodePacked(
-        p256Verifier,
-        bobP256PublicKeyX,
-        bobP256PublicKeyY
-    );
-    
-    // RSA signer with format: verifier || pubKey
-    bytes memory rsaSigner = abi.encodePacked(
-        rsaVerifier,
-        abi.encode(charlieRSAPublicKeyE, charlieRSAPublicKeyN)
-    );
-    
-    // Create array of signers
-    bytes[] memory signers = new bytes[](3);
-    signers[0] = ecdsaSigner;
-    signers[1] = p256Signer;
-    signers[2] = rsaSigner;
-    
-    // Set threshold to 2 (2-of-3 multisig)
-    uint256 threshold = 2;
-    
-    // Initialize the account
-    myMultisigAccount.initialize(signers, threshold);
-}
-----
-
-For a weighted multisig, you would also specify weights:
-
-[source,solidity]
-----
-// Example setup for weighted multisig
-function setupWeightedMultisigAccount() external {
-    // Create array of signers (same as above)
-    bytes[] memory signers = new bytes[](3);
-    signers[0] = ecdsaSigner;
-    signers[1] = p256Signer;
-    signers[2] = rsaSigner;
-    
-    // Assign weights to signers (Alice:1, Bob:2, Charlie:3)
-    uint256[] memory weights = new uint256[](3);
-    weights[0] = 1;
-    weights[1] = 2;
-    weights[2] = 3;
-    
-    // Set threshold to 4 (requires at least Bob+Charlie or all three)
-    uint256 threshold = 4;
-    
-    // Initialize the weighted account
-    myWeightedMultisigAccount.initialize(signers, weights, threshold);
-}
-----
-
-IMPORTANT: The xref:api:utils/cryptography.adoc#MultiSignerERC7913-_validateReachableThreshold--[`_validateReachableThreshold`] function ensures that the sum of weights for all active signers meets or exceeds the threshold. Any customization built on top of the multisigner contracts must ensure the threshold is always reachable.
-
-For multisig accounts, the signature is a complex structure that contains both the signers and their individual signatures. The format follows ERC-7913's specification and must be properly encoded.
-
-=== Signature Format
-
-The multisig signature is encoded as:
-
-[source,solidity]
-----
-abi.encode(
-    bytes[] signers,   // Array of signers sorted by `keccak256`
-    bytes[] signatures // Array of signatures corresponding to each signer
-)
-----
-
-Where:
-
-* `signers` is an array of the signers participating in this particular signature
-* `signatures` is an array of the individual signatures corresponding to each signer
-
-[NOTE]
-====
-To avoid duplicate signers, the contract uses `keccak256` to generate a unique id for each signer. When providing a multisignature, the `signers` array should be sorted in ascending order by `keccak256`, and the `signatures` array must match the order of their corresponding signers.
-====

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

@@ -1,31 +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 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[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.