diff --git a/content/community-contracts/utilities.mdx b/content/community-contracts/utilities.mdx index a509cea..6e53b8e 100644 --- a/content/community-contracts/utilities.mdx +++ b/content/community-contracts/utilities.mdx @@ -8,7 +8,7 @@ Multiple libraries and general purpose utilities included in the community versi ### Validating Typed Data Signatures -_For prior knowledge on how to validate signatures on-chain, check out the [OpenZeppelin Contracts documentation](/contracts/5.x/utilities#checking_signatures_on_chain)_ +_For prior knowledge on how to validate signatures on-chain, check out the [OpenZeppelin Contracts documentation](/contracts/5.x/utilities#checking-signatures-on-chain)_ As opposed to validating plain-text messages, it is possible to let your users sign structured data (i.e. typed values) in a way that is still readable on their wallets. This is possible by implementing [`EIP712`](/contracts/5.x/api/utils/cryptography#EIP712), a standard way to encode structured data into a typed data hash. diff --git a/content/contracts-cairo/1.0.0/components.mdx b/content/contracts-cairo/1.0.0/components.mdx index 947abb7..fd4384b 100644 --- a/content/contracts-cairo/1.0.0/components.mdx +++ b/content/contracts-cairo/1.0.0/components.mdx @@ -622,7 +622,7 @@ Creating a custom implementation of an interface must define **all** methods fro This is true even if the behavior of a method does not change from the component implementation (as `total_supply` exemplifies in this example). -The ERC20 documentation provides another custom implementation guide for [Customizing decimals](/contracts-cairo/1.0.0/erc20#customizing_decimals). +The ERC20 documentation provides another custom implementation guide for [Customizing decimals](/contracts-cairo/1.0.0/erc20#customizing-decimals). ### Accessing component storage diff --git a/content/contracts-cairo/1.0.0/erc20.mdx b/content/contracts-cairo/1.0.0/erc20.mdx index 9138c04..eb7e2cf 100644 --- a/content/contracts-cairo/1.0.0/erc20.mdx +++ b/content/contracts-cairo/1.0.0/erc20.mdx @@ -8,7 +8,7 @@ The ERC20 token standard is a specification for [fungible tokens](https://docs.o Prior to [Contracts v0.7.0](https://github.com/OpenZeppelin/cairo-contracts/releases/tag/v0.7.0), ERC20 contracts store and read `decimals` from storage; however, this implementation returns a static `18`. If upgrading an older ERC20 contract that has a decimals value other than `18`, the upgraded contract **must** use a custom `decimals` implementation. -See the [Customizing decimals](/contracts-cairo/1.0.0/erc20#customizing_decimals) guide. +See the [Customizing decimals](/contracts-cairo/1.0.0/erc20#customizing-decimals) guide. ## Usage diff --git a/content/contracts-cairo/1.0.0/governance/governor.mdx b/content/contracts-cairo/1.0.0/governance/governor.mdx index 9b579b1..741a46c 100644 --- a/content/contracts-cairo/1.0.0/governance/governor.mdx +++ b/content/contracts-cairo/1.0.0/governance/governor.mdx @@ -231,7 +231,7 @@ When using a timelock, it is the timelock that will execute proposals and thus t hold any funds, ownership, and access control roles. -TimelockController uses an [AccessControl](/contracts-cairo/1.0.0/access#role_based_accesscontrol) setup that we need to understand in order to set up roles. +TimelockController uses an [AccessControl](/contracts-cairo/1.0.0/access#role-based-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 must be granted, and it MUST be the only proposer (and canceller) in the system. diff --git a/content/contracts-cairo/1.0.0/governance/votes.mdx b/content/contracts-cairo/1.0.0/governance/votes.mdx index 27e89ee..16466bc 100644 --- a/content/contracts-cairo/1.0.0/governance/votes.mdx +++ b/content/contracts-cairo/1.0.0/governance/votes.mdx @@ -9,7 +9,7 @@ By default, token balance does not account for voting power. This makes transfer -The transferring of voting units must be handled by the implementing contract. In the case of `ERC20` and `ERC721` this is usually done via the hooks. You can check the [usage](/contracts-cairo/1.0.0/governance/governor#usage_2) section for examples of how to implement this. +The transferring of voting units must be handled by the implementing contract. In the case of `ERC20` and `ERC721` this is usually done via the hooks. You can check the [usage](/contracts-cairo/1.0.0/governance/governor#usage-and-setup) section for examples of how to implement this. ## Key Features diff --git a/content/contracts-cairo/2.0.0/erc20.mdx b/content/contracts-cairo/2.0.0/erc20.mdx index a1d24f1..7ad048d 100644 --- a/content/contracts-cairo/2.0.0/erc20.mdx +++ b/content/contracts-cairo/2.0.0/erc20.mdx @@ -8,7 +8,7 @@ The ERC20 token standard is a specification for [fungible tokens](https://docs.o Prior to [Contracts v0.7.0](https://github.com/OpenZeppelin/cairo-contracts/releases/tag/v0.7.0), ERC20 contracts store and read `decimals` from storage; however, this implementation returns a static `18`. If upgrading an older ERC20 contract that has a decimals value other than `18`, the upgraded contract **must** use a custom `decimals` implementation. -See the [Customizing decimals](/contracts-cairo/2.0.0/erc20#customizing_decimals) guide. +See the [Customizing decimals](/contracts-cairo/2.0.0/erc20#customizing-decimals) guide. ## Usage diff --git a/content/contracts-cairo/2.0.0/governance/governor.mdx b/content/contracts-cairo/2.0.0/governance/governor.mdx index 6aeb0d6..2c09296 100644 --- a/content/contracts-cairo/2.0.0/governance/governor.mdx +++ b/content/contracts-cairo/2.0.0/governance/governor.mdx @@ -231,7 +231,7 @@ When using a timelock, it is the timelock that will execute proposals and thus t hold any funds, ownership, and access control roles. -TimelockController uses an [AccessControl](/contracts-cairo/2.0.0/access#role_based_accesscontrol) setup that we need to understand in order to set up roles. +TimelockController uses an [AccessControl](/contracts-cairo/2.0.0/access#role-based-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 must be granted, and it MUST be the only proposer (and canceller) in the system. diff --git a/content/contracts-cairo/2.0.0/presets.mdx b/content/contracts-cairo/2.0.0/presets.mdx index de0b6fa..13fdf05 100644 --- a/content/contracts-cairo/2.0.0/presets.mdx +++ b/content/contracts-cairo/2.0.0/presets.mdx @@ -46,7 +46,7 @@ starkli deploy {ERC20Upgradeable-class-hash} \ ``` If a class hash has yet to be declared, copy/paste the preset contract code and declare it locally. -Start by [setting up a project](/contracts-cairo/2.0.0#set_up_your_project) and [installing the Contracts for Cairo library](/contracts-cairo/2.0.0#install_the_library). +Start by [setting up a project](/contracts-cairo/2.0.0#set-up-your-project) and [installing the Contracts for Cairo library](/contracts-cairo/2.0.0#install-the-library). Copy the target preset contract from the [presets directory](https://github.com/OpenZeppelin/cairo-contracts/blob/release-v2.0.0/packages/presets/src) and paste it in the new project’s `src/lib.cairo` like this: ```cairo diff --git a/content/contracts-cairo/api/finance.mdx b/content/contracts-cairo/api/finance.mdx index b409929..f0981e4 100644 --- a/content/contracts-cairo/api/finance.mdx +++ b/content/contracts-cairo/api/finance.mdx @@ -162,7 +162,7 @@ Internal implementations A trait that defines the logic for calculating the vested amount based on a given timestamp. -You can read more about the trait's purpose and how to use it [here](../finance#vesting_schedule). +You can read more about the trait's purpose and how to use it [here](../finance#vesting-schedule). -TimelockController uses an [AccessControl](../access#role_based_accesscontrol) setup that we need to understand in order to set up roles. +TimelockController uses an [AccessControl](../access#role-based-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 must be granted, and it MUST be the only proposer (and canceller) in the system. diff --git a/content/contracts-stylus/0.2.0/erc1155.mdx b/content/contracts-stylus/0.2.0/erc1155.mdx index b9c0cfd..873b78b 100644 --- a/content/contracts-stylus/0.2.0/erc1155.mdx +++ b/content/contracts-stylus/0.2.0/erc1155.mdx @@ -2,7 +2,7 @@ title: ERC-1155 --- -ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts-stylus/0.2.0/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts-stylus/0.2.0/tokens#but_first_coffee_a_primer_on_token_contracts). +ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts-stylus/0.2.0/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts-stylus/0.2.0/tokens#but-first-coffee-a-primer-on-token-contracts). ## Extensions diff --git a/content/contracts-stylus/erc1155.mdx b/content/contracts-stylus/erc1155.mdx index e37fdf7..ac91ab9 100644 --- a/content/contracts-stylus/erc1155.mdx +++ b/content/contracts-stylus/erc1155.mdx @@ -2,7 +2,7 @@ title: ERC-1155 --- -ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](./tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](./tokens#but_first_coffee_a_primer_on_token_contracts). +ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](./tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](./tokens#but-first-coffee-a-primer-on-token-contracts). ## Extensions diff --git a/content/contracts-stylus/erc4626.mdx b/content/contracts-stylus/erc4626.mdx index 8d744b6..9f88ba8 100644 --- a/content/contracts-stylus/erc4626.mdx +++ b/content/contracts-stylus/erc4626.mdx @@ -7,7 +7,7 @@ Implementation of the ERC-4626 "Tokenized Vault Standard" as defined in [ERC-462 This extension allows the minting and burning of "shares" (represented using the ERC-20 inheritance) in exchange for underlying "assets" through standardized `deposit`, `mint`, `redeem` and `burn` workflows. This contract extends the ERC-20 standard. Any additional extensions included along it would affect the "shares" token represented by this contract and not the "assets" token which is an independent contract. ## Security concern: Inflation attack -To read more about the security concerns associated with the ERC-4626, check the [Inflation attack](/contracts/5.x/erc4626#inflation-attack) description. +To read more about the security concerns associated with the ERC-4626, check the [Inflation attack](/contracts/5.x/erc4626#security-concern-inflation-attack) description. ## Usage diff --git a/content/contracts/3.x/api/token/ERC1155.mdx b/content/contracts/3.x/api/token/ERC1155.mdx index 414f6ab..2a73ea7 100644 --- a/content/contracts/3.x/api/token/ERC1155.mdx +++ b/content/contracts/3.x/api/token/ERC1155.mdx @@ -18,7 +18,7 @@ Additionally there are multiple custom extensions, including: * destruction of own tokens (ERC1155Burnable). -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC1155 (such as [`_mint`](#`_mint(address-account,-uint256-id,-uint256-amount,-bytes-data) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC1155 Presets](/contracts/3.x/erc1155#Presets) (such as ERC1155PresetMinterPauser) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC1155 (such as [`_mint`](#`_mint(address-account,-uint256-id,-uint256-amount,-bytes-data) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC1155 Presets](/contracts/3.x/erc1155#preset-erc1155-contract) (such as ERC1155PresetMinterPauser) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/3.x/api/token/ERC20.mdx b/content/contracts/3.x/api/token/ERC20.mdx index 4bc0236..17cd31c 100644 --- a/content/contracts/3.x/api/token/ERC20.mdx +++ b/content/contracts/3.x/api/token/ERC20.mdx @@ -36,7 +36,7 @@ The following related EIPs are in draft status and can be found in the drafts di * ERC20Permit -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as [`_mint`](#`_mint(address-account,-uint256-amount) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC20 Presets](/contracts/3.x/erc20#Presets) (such as ERC20PresetMinterPauser) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as [`_mint`](#`_mint(address-account,-uint256-amount) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC20 Presets](/contracts/3.x/erc20#preset-erc20-contract) (such as ERC20PresetMinterPauser) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/3.x/api/token/ERC721.mdx b/content/contracts/3.x/api/token/ERC721.mdx index 2817893..954b34d 100644 --- a/content/contracts/3.x/api/token/ERC721.mdx +++ b/content/contracts/3.x/api/token/ERC721.mdx @@ -22,7 +22,7 @@ Additionally there are multiple custom extensions, including: * destruction of own tokens (ERC721Burnable). -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as [`_mint`](#`_mint(address-to,-uint256-tokenid) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC721 Presets](/contracts/3.x/erc721#Presets) (such as ERC721PresetMinterPauserAutoId) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as [`_mint`](#`_mint(address-to,-uint256-tokenid) *internal*`)) and expose them as external functions in the way they prefer. On the other hand, [ERC721 Presets](/contracts/3.x/erc721#preset-erc721-contract) (such as ERC721PresetMinterPauserAutoId) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/3.x/erc1155.mdx b/content/contracts/3.x/erc1155.mdx index acfc815..c91cd90 100644 --- a/content/contracts/3.x/erc1155.mdx +++ b/content/contracts/3.x/erc1155.mdx @@ -2,7 +2,7 @@ title: ERC1155 --- -ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts/3.x/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts/3.x/tokens#but_first_coffee_a_primer_on_token_contracts). +ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts/3.x/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts/3.x/tokens#but-first-coffee-a-primer-on-token-contracts). ERC1155 draws ideas from all of [ERC20](/contracts/3.x/erc20), [ERC721](/contracts/3.x/erc721), and [ERC777](/contracts/3.x/erc777). If you’re unfamiliar with those standards, head to their guides before moving on. diff --git a/content/contracts/4.x/access-control.mdx b/content/contracts/4.x/access-control.mdx index ffc977c..7e19fd3 100644 --- a/content/contracts/4.x/access-control.mdx +++ b/content/contracts/4.x/access-control.mdx @@ -56,7 +56,7 @@ Most software uses access control systems that are role-based: some users are re OpenZeppelin Contracts provides [`AccessControl`](/contracts/4.x/api/access#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 [`ERC20` token](/contracts/4.x/tokens#ERC20) to define a 'minter' role, which allows accounts that have it create new tokens: +Here’s a simple example of using `AccessControl` in an [`ERC20` token](/contracts/4.x/erc20) to define a 'minter' role, which allows accounts that have it create new tokens: ```solidity // contracts/MyToken.sol diff --git a/content/contracts/4.x/api/token/ERC1155.mdx b/content/contracts/4.x/api/token/ERC1155.mdx index aa2b1aa..55b88af 100644 --- a/content/contracts/4.x/api/token/ERC1155.mdx +++ b/content/contracts/4.x/api/token/ERC1155.mdx @@ -15,7 +15,7 @@ Additionally there are multiple custom extensions, including: * destruction of own tokens ([`ERC1155Burnable`](#ERC1155Burnable)). -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC1155 (such as [`_mint`](#ERC1155-_mint-address-uint256-uint256-bytes-)) and expose them as external functions in the way they prefer. On the other hand, [ERC1155 Presets](/contracts/4.x/erc1155#Presets) (such as [`ERC1155PresetMinterPauser`](#ERC1155PresetMinterPauser)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC1155 (such as [`_mint`](#ERC1155-_mint-address-uint256-uint256-bytes-)) and expose them as external functions in the way they prefer. On the other hand, [ERC1155 Presets](/contracts/4.x/erc1155#preset-erc1155-contract) (such as [`ERC1155PresetMinterPauser`](#ERC1155PresetMinterPauser)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/4.x/api/token/ERC20.mdx b/content/contracts/4.x/api/token/ERC20.mdx index 26078e4..0fcfa9f 100644 --- a/content/contracts/4.x/api/token/ERC20.mdx +++ b/content/contracts/4.x/api/token/ERC20.mdx @@ -34,7 +34,7 @@ Finally, there are some utilities to interact with ERC20 contracts in various wa * [`TokenTimelock`](#TokenTimelock): hold tokens for a beneficiary until a specified time. -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as [`_mint`](#ERC20-_mint-address-uint256-)) and expose them as external functions in the way they prefer. On the other hand, [ERC20 Presets](/contracts/4.x/erc20#Presets) (such as [`ERC20PresetMinterPauser`](#ERC20PresetMinterPauser)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC20 (such as [`_mint`](#ERC20-_mint-address-uint256-)) and expose them as external functions in the way they prefer. On the other hand, [ERC20 Presets](/contracts/4.x/erc20#preset-erc20-contract) (such as [`ERC20PresetMinterPauser`](#ERC20PresetMinterPauser)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/4.x/api/token/ERC721.mdx b/content/contracts/4.x/api/token/ERC721.mdx index a627548..f520501 100644 --- a/content/contracts/4.x/api/token/ERC721.mdx +++ b/content/contracts/4.x/api/token/ERC721.mdx @@ -33,7 +33,7 @@ Additionally there are a few of other extensions: * [`ERC721Wrapper`](#ERC721Wrapper): Wrapper to create an ERC721 backed by another ERC721, with deposit and withdraw methods. Useful in conjunction with [`ERC721Votes`](#ERC721Votes). -This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as [`_mint`](#ERC721-_mint-address-uint256-)) and expose them as external functions in the way they prefer. On the other hand, [ERC721 Presets](/contracts/4.x/erc721#Presets) (such as [`ERC721PresetMinterPauserAutoId`](#ERC721PresetMinterPauserAutoId)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. +This core set of contracts is designed to be unopinionated, allowing developers to access the internal functions in ERC721 (such as [`_mint`](#ERC721-_mint-address-uint256-)) and expose them as external functions in the way they prefer. On the other hand, [ERC721 Presets](/contracts/4.x/erc721#preset-erc721-contract) (such as [`ERC721PresetMinterPauserAutoId`](#ERC721PresetMinterPauserAutoId)) are designed using opinionated patterns to provide developers with ready to use, deployable contracts. ## Core diff --git a/content/contracts/4.x/erc1155.mdx b/content/contracts/4.x/erc1155.mdx index d6f6040..77a3603 100644 --- a/content/contracts/4.x/erc1155.mdx +++ b/content/contracts/4.x/erc1155.mdx @@ -2,7 +2,7 @@ title: ERC1155 --- -ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts/4.x/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts/4.x/tokens#but_first_coffee_a_primer_on_token_contracts). +ERC1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](/contracts/4.x/tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](/contracts/4.x/tokens#but-first-coffee-a-primer-on-token-contracts). ERC1155 draws ideas from all of [ERC20](/contracts/4.x/erc20), [ERC721](/contracts/4.x/erc721), and [ERC777](/contracts/4.x/erc777). If you’re unfamiliar with those standards, head to their guides before moving on. diff --git a/content/contracts/5.x/access-control.mdx b/content/contracts/5.x/access-control.mdx index adcd4a7..db04f52 100644 --- a/content/contracts/5.x/access-control.mdx +++ b/content/contracts/5.x/access-control.mdx @@ -158,7 +158,7 @@ OpenZeppelin Contracts provides [`AccessManager`](/contracts/5.x/api/access#Acce In order to restrict access to some functions of your contract, you should inherit from the [`AccessManaged`](/contracts/5.x/api/access#AccessManaged) contract provided along with the manager. This provides the `restricted` modifier that can be used to protect any externally facing function. Note that you will have to specify the address of the AccessManager instance ([`initialAuthority`](/contracts/5.x/api/access#AccessManaged-constructor-address-)) in the constructor so the `restricted` modifier knows which manager to use for checking permissions. -Here’s a simple example of an [ERC-20 token](./tokens#ERC20) that defines a `mint` function that is restricted by an [`AccessManager`](/contracts/5.x/api/access#AccessManager): +Here’s a simple example of an [ERC-20 token](./erc20) that defines a `mint` function that is restricted by an [`AccessManager`](/contracts/5.x/api/access#AccessManager): ./examples/access-control/AccessManagedERC20MintBase.sol diff --git a/content/contracts/5.x/account-abstraction.mdx b/content/contracts/5.x/account-abstraction.mdx index 3d91d5f..a099f9a 100644 --- a/content/contracts/5.x/account-abstraction.mdx +++ b/content/contracts/5.x/account-abstraction.mdx @@ -85,7 +85,7 @@ To build your own account, see [accounts](./accounts). The smart contract accounts are created by a Factory contract defined by the Account developer. This factory receives arbitrary bytes as `initData` and returns an `address` where the logic of the account is deployed. -To build your own factory, see [account factories](./accounts#accounts_factory). +To build your own factory, see [account factories](./accounts#accounts-factory). ### Paymaster Contract diff --git a/content/contracts/5.x/eoa-delegation.mdx b/content/contracts/5.x/eoa-delegation.mdx index 6209e12..cc11451 100644 --- a/content/contracts/5.x/eoa-delegation.mdx +++ b/content/contracts/5.x/eoa-delegation.mdx @@ -95,7 +95,7 @@ The ability to set code to execute logic on an EOA allows users to leverage ERC- Once your EOA is delegated to an ERC-4337 compatible account, you can send user operations through the entry point contract. The user operation includes all the necessary fields for execution, including gas limits, fees, and the actual call data to execute. The entry point will validate the operation and execute it in the context of your delegated account. -Similar to how [sending a UserOp](./accounts#bundle_a_useroperation) is achieved for factory accounts, here’s how you can construct a UserOp for an EOA who’s delegated to an [`Account`](/contracts/5.x/api/account#Account) contract. +Similar to how [sending a UserOp](./accounts#batched-execution) is achieved for factory accounts, here’s how you can construct a UserOp for an EOA who’s delegated to an [`Account`](/contracts/5.x/api/account#Account) contract. ```typescript const userOp = { diff --git a/content/contracts/5.x/erc1155.mdx b/content/contracts/5.x/erc1155.mdx index 57d97c8..e5df92b 100644 --- a/content/contracts/5.x/erc1155.mdx +++ b/content/contracts/5.x/erc1155.mdx @@ -2,7 +2,7 @@ title: ERC-1155 --- -ERC-1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](./tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](./tokens#but_first_coffee_a_primer_on_token_contracts). +ERC-1155 is a novel token standard that aims to take the best from previous standards to create a [**fungibility-agnostic**](./tokens#different-kinds-of-tokens) and **gas-efficient** [token contract](./tokens#but-first-coffee-a-primer-on-token-contracts). ERC-1155 draws ideas from all of [ERC-20](./erc20), [ERC-721](./erc721), and [ERC-777](https://eips.ethereum.org/EIPS/eip-777). If you’re unfamiliar with those standards, head to their guides before moving on. diff --git a/content/contracts/5.x/governance.mdx b/content/contracts/5.x/governance.mdx index 78fe040..9fc180c 100644 --- a/content/contracts/5.x/governance.mdx +++ b/content/contracts/5.x/governance.mdx @@ -36,7 +36,7 @@ When using a timelock with your Governor contract, you can use either OpenZeppel [Tally](https://www.tally.xyz) 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 [IERC6372](/contracts/5.x/api/interfaces#IERC6372), visualize voting power and advocates, navigate proposals, and cast votes. For proposal creation in particular, projects can also use [Defender Transaction Proposals](/defender/module/actions#transaction-proposals-reference) as an alternative interface. +For all of these options, the Governor will be compatible with Tally: users will be able to create proposals, see voting periods and delays following [IERC6372](/contracts/5.x/api/interfaces#IERC6372), visualize voting power and advocates, navigate proposals, and cast votes. For proposal creation in particular, projects can also use [Defender Transaction Proposals](/defender/module/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. @@ -106,7 +106,7 @@ A proposal is a sequence of actions that the Governor contract will perform if i Let’s say we want to create a proposal to give a team a grant, in the form of ERC-20 tokens from the governance treasury. This proposal will consist of a single action where the target is the ERC-20 token, calldata is the encoded function call `transfer(, )`, and with 0 ETH attached. -Generally a proposal will be created with the help of an interface such as Tally or [Defender Proposals](/defender/module/actions#transaction-proposals-reference). Here we will show how to create the proposal using Ethers.js. +Generally a proposal will be created with the help of an interface such as Tally or [Defender Proposals](/defender/module/transaction-proposals). Here we will show how to create the proposal using Ethers.js. First we get all the parameters necessary for the proposal action. diff --git a/content/contracts/5.x/learn/connecting-to-public-test-networks.mdx b/content/contracts/5.x/learn/connecting-to-public-test-networks.mdx index 64e72cd..9d082bb 100644 --- a/content/contracts/5.x/learn/connecting-to-public-test-networks.mdx +++ b/content/contracts/5.x/learn/connecting-to-public-test-networks.mdx @@ -6,7 +6,7 @@ After you have [written your contracts](./developing-smart-contracts), and [trie We will use **public testing networks** (aka _testnets_) for this, which are networks that operate similar to the main Ethereum network, but where Ether has no value and is free to acquire - making them ideal for testing your contracts at no cost. -In this guide, we will use our beloved [`Box` contract](./developing-smart-contracts#box-contract), and deploy it to a testnet, while learning: +In this guide, we will use our beloved [`Box` contract](./developing-smart-contracts#first-contract), and deploy it to a testnet, while learning: * [What test networks are available](#available-testnets) * [How to set up your project for working on a testnet](#connecting-a-project-to-a-public-network) @@ -61,7 +61,7 @@ Make sure to keep your mnemonic secure. Do not commit secrets to version control Since we are using public nodes, we will need to sign all our transactions locally. We will configure the network with our mnemonic and an Alchemy endpoint. -This part assumes you have already set up a project. If you haven’t, head over to the guide on [Setting up a Solidity project](./developing-smart-contracts#setting-up-a-solidity-project). +This part assumes you have already set up a project. If you haven’t, head over to the guide on [Setting up a Solidity project](./developing-smart-contracts#setting-up-a-project). We need to update our configuration file with a new network connection to the testnet. Here we will use Sepolia, but you can use whichever you want: @@ -125,7 +125,7 @@ Armed with a funded account, let’s deploy our contracts to the testnet! ## Working on a testnet -With a project configured to work on a public testnet, we can now finally [deploy our `Box` contract](./deploying-and-interacting#deploying-a-smart-contract). The command here is exactly the same as if you were on your [local development network](./deploying-and-interacting#local-blockchain), though it will take a few seconds to run as new blocks are mined. +With a project configured to work on a public testnet, we can now finally [deploy our `Box` contract](./deploying-and-interacting#deploying-a-smart-contract). The command here is exactly the same as if you were on your [local development network](./deploying-and-interacting#setting-up-a-local-blockchain), though it will take a few seconds to run as new blocks are mined. ```console $ npx hardhat run --network sepolia scripts/deploy.js @@ -141,7 +141,7 @@ You can see your contract on a block explorer such as [Etherscan](https://ethers You can check out the contract we deployed in the example above, along with all transactions sent to it, [here](https://sepolia.etherscan.io/address/0x1b99CCaCea0e4046db618770dEF72180F8138641). -You can also interact with your instance as you regularly would, either using the [console](./deploying-and-interacting#interacting-from-the-console), or [programmatically](./deploying-and-interacting#interacting-programatically). +You can also interact with your instance as you regularly would, either using the [console](./deploying-and-interacting#interacting-from-the-console), or [programmatically](./deploying-and-interacting#interacting-programmatically). ```console $ npx hardhat console --network sepolia diff --git a/content/contracts/5.x/learn/deploying-and-interacting.mdx b/content/contracts/5.x/learn/deploying-and-interacting.mdx index 006752f..815f2b2 100644 --- a/content/contracts/5.x/learn/deploying-and-interacting.mdx +++ b/content/contracts/5.x/learn/deploying-and-interacting.mdx @@ -47,9 +47,9 @@ You can also run an actual Ethereum node in _[development mode](https://geth.eth In the [Developing Smart Contracts guide](./developing-smart-contracts) we set up our development environment. -If you don't already have this setup, please [create](./setting-up-a-node-project#creating-a-project) and [setup](./developing-smart-contracts#setting-up-a-solidity-project) the project and then [create](./developing-smart-contracts#first-contract) and [compile](./developing-smart-contracts#compiling-solidity-source-code) our Box smart contract. +If you don't already have this setup, please [create](./setting-up-a-node-project#creating-a-project) and [setup](./developing-smart-contracts#setting-up-a-project) the project and then [create](./developing-smart-contracts#first-contract) and [compile](./developing-smart-contracts#compiling-solidity) our Box smart contract. -With our project setup complete we're now ready to deploy a contract. We'll be deploying `Box`, from the [Developing Smart Contracts](./developing-smart-contracts#box-contract) guide. Make sure you have a copy of [Box](./developing-smart-contracts#box-contract) in `contracts/Box.sol`. +With our project setup complete we're now ready to deploy a contract. We'll be deploying `Box`, from the [Developing Smart Contracts](./developing-smart-contracts#first-contract) guide. Make sure you have a copy of [Box](./developing-smart-contracts#first-contract) in `contracts/Box.sol`. Hardhat uses either [declarative deployments](https://hardhat.org/hardhat-runner/docs/guides/deploying) or [scripts](https://hardhat.org/hardhat-runner/docs/advanced/scripts#writing-scripts-with-hardhat) to deploy contracts. diff --git a/content/contracts/5.x/learn/sending-gasless-transactions.mdx b/content/contracts/5.x/learn/sending-gasless-transactions.mdx index c2f3478..8cacd5b 100644 --- a/content/contracts/5.x/learn/sending-gasless-transactions.mdx +++ b/content/contracts/5.x/learn/sending-gasless-transactions.mdx @@ -64,7 +64,7 @@ We will create a simple contract that just counts transactions sent to it, but w ### Setting up the Environment -We will begin by creating a new npm project and installing all dependencies, including [Ganache](https://www.trufflesuite.com/ganache) (which we’ll use to [run a local network](./deploying-and-interacting#local-blockchain)): +We will begin by creating a new npm project and installing all dependencies, including [Ganache](https://www.trufflesuite.com/ganache) (which we’ll use to [run a local network](./deploying-and-interacting#setting-up-a-local-blockchain)): ```console $ mkdir gsn-dapp && cd gsn-dapp @@ -80,7 +80,7 @@ $ npx oz init ``` -Check out [Getting Started with the OpenZeppelin CLI](./deploying-and-interacting#getting-started-with-the-cli) if you’re unfamiliar with it. +Check out [Getting Started with the OpenZeppelin CLI](./deploying-and-interacting#interacting-from-the-console) if you’re unfamiliar with it. ### Creating our Contract diff --git a/content/contracts/5.x/learn/upgrading-smart-contracts.mdx b/content/contracts/5.x/learn/upgrading-smart-contracts.mdx index f0f2555..2edc268 100644 --- a/content/contracts/5.x/learn/upgrading-smart-contracts.mdx +++ b/content/contracts/5.x/learn/upgrading-smart-contracts.mdx @@ -83,7 +83,7 @@ In order to upgrade a contract like `Box` we need to first deploy it as an upgra With Hardhat, we use [scripts](https://hardhat.org/hardhat-runner/docs/advanced/scripts#writing-scripts-with-hardhat) to deploy upgradeable contracts. -We will create a script to deploy our upgradeable Box contract using [`deployProxy`](/upgrades-plugins/api-hardhat-upgrades#deploy-proxy). We will save this file as `scripts/deploy_upgradeable_box.js`. +We will create a script to deploy our upgradeable Box contract using [`deployProxy`](/upgrades-plugins/api-hardhat-upgrades#deployproxy). We will save this file as `scripts/deploy_upgradeable_box.js`. ```js const { ethers, upgrades } = require('hardhat'); @@ -150,7 +150,7 @@ After creating the Solidity file, we can now upgrade the instance we had deploye 1. Deploy the implementation contract (our `BoxV2` contract) 2. Call the `ProxyAdmin` to update the proxy contract to use the new implementation. -We will create a script to upgrade our `Box` contract to use `BoxV2` using [`upgradeProxy`](/upgrades-plugins/api-hardhat-upgrades#upgrade-proxy). We will save this file as `scripts/upgrade_box.js`. +We will create a script to upgrade our `Box` contract to use `BoxV2` using [`upgradeProxy`](/upgrades-plugins/api-hardhat-upgrades#upgradeproxy). We will save this file as `scripts/upgrade_box.js`. We need to specify the address of our proxy contract from when we deployed our `Box` contract. ```js diff --git a/content/contracts/5.x/learn/writing-automated-tests.mdx b/content/contracts/5.x/learn/writing-automated-tests.mdx index 3f87555..6ac7a36 100644 --- a/content/contracts/5.x/learn/writing-automated-tests.mdx +++ b/content/contracts/5.x/learn/writing-automated-tests.mdx @@ -34,7 +34,7 @@ $ npm install --save-dev @nomicfoundation/hardhat-toolbox We will keep our test files in a `test` directory. Tests are best structured by mirroring the [`contracts` directory](./developing-smart-contracts#first-contract): for each `.sol` file there, create a corresponding test file. -Time to write our first tests! These will test properties of the `Box` contract [from previous guides](./developing-smart-contracts#box-contract): a simple contract that lets you `retrieve` a value the owner previously `store` d. +Time to write our first tests! These will test properties of the `Box` contract [from previous guides](./developing-smart-contracts#first-contract): a simple contract that lets you `retrieve` a value the owner previously `store` d. Create a `test` directory in your project root. We will save the test as `test/Box.test.js`. Each test `.js` file commonly has the tests for a single contract, and is named after it. diff --git a/content/contracts/5.x/multisig.mdx b/content/contracts/5.x/multisig.mdx index cf5d4aa..8526ff1 100644 --- a/content/contracts/5.x/multisig.mdx +++ b/content/contracts/5.x/multisig.mdx @@ -8,7 +8,7 @@ Popular implementations like [Safe](https://safe.global/) (formerly Gnosis Safe) ## Beyond Standard Signature Verification -As discussed in the [accounts section](./accounts#signature_validation), the standard approach for smart contracts to verify signatures is [ERC-1271](https://eips.ethereum.org/EIPS/eip-1271), which defines an `isValidSignature(hash, signature)`. However, it is limited in two important ways: +As discussed in the [accounts section](./accounts#signature-validation), the standard approach for smart contracts to verify signatures is [ERC-1271](https://eips.ethereum.org/EIPS/eip-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 diff --git a/content/defender/module/deploy.mdx b/content/defender/module/deploy.mdx index 1978a78..6b313bd 100644 --- a/content/defender/module/deploy.mdx +++ b/content/defender/module/deploy.mdx @@ -63,7 +63,7 @@ We provide a quickstart tutorial to deploy and upgrade a smart contract using De -Using `CREATE2` may affect `msg.sender` behavior; see documentation for details [here](/defender/tutorial/deploy#deploy-caveat)! +Using `CREATE2` may affect `msg.sender` behavior; see documentation for details [here](/defender/tutorial/deploy#caveats)! ## Metadata diff --git a/content/defender/module/relayers.mdx b/content/defender/module/relayers.mdx index 6dc880d..6e0af16 100644 --- a/content/defender/module/relayers.mdx +++ b/content/defender/module/relayers.mdx @@ -30,7 +30,7 @@ Keep in mind that you’ll need to fund each Relayer individually with ETH (or t -Testnet Relayers created through the Deploy wizard will be automatically funded if possible. Read more [here](/defender/module/deploy#wizard-3). +Testnet Relayers created through the Deploy wizard will be automatically funded if possible. Read more [here](/defender/module/deploy#step-3-upgrading). ### API Keys diff --git a/content/defender/tutorial/deploy.mdx b/content/defender/tutorial/deploy.mdx index 91f91fa..243ee1f 100644 --- a/content/defender/tutorial/deploy.mdx +++ b/content/defender/tutorial/deploy.mdx @@ -2,7 +2,7 @@ title: Securely deploy and upgrade a smart contract --- -Defender allows you to easily deploy and upgrade smart contracts across chains while maintaining the best security practices. This tutorial shows how to use a [Relayer](/defender/settings#relayers) to deploy a contract called Box and upgrade it with the UUPS proxy pattern via a [Safe wallet](https://safe.global/) (multisig). +Defender allows you to easily deploy and upgrade smart contracts across chains while maintaining the best security practices. This tutorial shows how to use a [Relayer](/defender/module/relayers) to deploy a contract called Box and upgrade it with the UUPS proxy pattern via a [Safe wallet](https://safe.global/) (multisig). ## Pre-requisites @@ -37,7 +37,7 @@ Now, you will create a Defender test environment with the Sepolia testnet, where 4. Select the approval process associated with your funded relayer that will execute the deployments for the test environment. In case you don’t already have an approval process, Defender will allow you to create one within the wizard flow. Relayers automate the payment of gas fees and take care of private key secure storage, transaction signing, nonce management, gas pricing estimation, and resubmissions. However, you may also choose to deploy using an EOA ("Externally Owned Account") or Safe wallet. - Read more about relayers and how to manage them [here](/defender/settings#relayers). + Read more about relayers and how to manage them [here](/defender/module/relayers). + diff --git a/content/stellar-contracts/0.2.0/utils/upgradeable.mdx b/content/stellar-contracts/0.2.0/utils/upgradeable.mdx index 67ffebf..18fc159 100644 --- a/content/stellar-contracts/0.2.0/utils/upgradeable.mdx +++ b/content/stellar-contracts/0.2.0/utils/upgradeable.mdx @@ -23,8 +23,8 @@ provides a lightweight upgradeability framework with additional support for stru It consists of two main components: -1. ***[`Upgradeable`](/stellar-contracts/utils/upgradeable#upgrade_only)*** for cases where only the WASM binary needs to be updated. -2. ***[`UpgradeableMigratable`](/stellar-contracts/utils/upgradeable#upgrade_and_migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries +1. ***[`Upgradeable`](/stellar-contracts/utils/upgradeable#upgrade-only)*** for cases where only the WASM binary needs to be updated. +2. ***[`UpgradeableMigratable`](/stellar-contracts/utils/upgradeable#upgrade-and-migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries must be modified (migrated) during the upgrade process. The recommended way to use this module is through the `\#[derive(Upgradeable)]` and `#[derive(UpgradeableMigratable)]` diff --git a/content/stellar-contracts/0.3.0/utils/upgradeable.mdx b/content/stellar-contracts/0.3.0/utils/upgradeable.mdx index 3970823..b2be663 100644 --- a/content/stellar-contracts/0.3.0/utils/upgradeable.mdx +++ b/content/stellar-contracts/0.3.0/utils/upgradeable.mdx @@ -23,8 +23,8 @@ provides a lightweight upgradeability framework with additional support for stru It consists of two main components: -1. ***[`Upgradeable`](/stellar-contracts/0.3.0/utils/upgradeable#upgrade_only)*** for cases where only the WASM binary needs to be updated. -2. ***[`UpgradeableMigratable`](/stellar-contracts/0.3.0/utils/upgradeable#upgrade_and_migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries +1. ***[`Upgradeable`](/stellar-contracts/0.3.0/utils/upgradeable#upgrade-only)*** for cases where only the WASM binary needs to be updated. +2. ***[`UpgradeableMigratable`](/stellar-contracts/0.3.0/utils/upgradeable#upgrade-and-migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries must be modified (migrated) during the upgrade process. The recommended way to use this module is through the `\#[derive(Upgradeable)]` and `#[derive(UpgradeableMigratable)]` diff --git a/content/stellar-contracts/utils/upgradeable.mdx b/content/stellar-contracts/utils/upgradeable.mdx index 9a97454..5a8407a 100644 --- a/content/stellar-contracts/utils/upgradeable.mdx +++ b/content/stellar-contracts/utils/upgradeable.mdx @@ -23,8 +23,8 @@ provides a lightweight upgradeability framework with additional support for stru It consists of two main components: -1. ***[`Upgradeable`](#upgrade_only)*** for cases where only the WASM binary needs to be updated. -2. ***[`UpgradeableMigratable`](#upgrade_and_migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries +1. ***[`Upgradeable`](#upgrade-only)*** for cases where only the WASM binary needs to be updated. +2. ***[`UpgradeableMigratable`](#upgrade-and-migrate)*** for more advanced scenarios where, in addition to the WASM binary, specific storage entries must be modified (migrated) during the upgrade process. The recommended way to use this module is through the `#[derive(Upgradeable)]` and `#[derive(UpgradeableMigratable)]` diff --git a/content/substrate-runtimes/2.0.2/pallets/collator-selection.mdx b/content/substrate-runtimes/2.0.2/pallets/collator-selection.mdx index 2ac8284..11f351b 100644 --- a/content/substrate-runtimes/2.0.2/pallets/collator-selection.mdx +++ b/content/substrate-runtimes/2.0.2/pallets/collator-selection.mdx @@ -13,7 +13,7 @@ This pallet is needed to manage the set of [collators](/substrate-runtimes/2.0.2 ## Config * Pallet-specific configs - * `UpdateOrigin` — defines the list of origins that are able to modify the settings of collators (e.g. set and remove list of [invulnerables](/substrate-runtimes/2.0.2/glossary#invulnerable), desired [candidates](/substrate-runtimes/2.0.2/glossary#candidates), [candidacy bond](/substrate-runtimes/2.0.2/glossary#candidacy_bond)). This type should implement the trait `EnsureOrigin`. + * `UpdateOrigin` — defines the list of origins that are able to modify the settings of collators (e.g. set and remove list of [invulnerables](/substrate-runtimes/2.0.2/glossary#invulnerable), desired [candidates](/substrate-runtimes/2.0.2/glossary#candidate), [candidacy bond](/substrate-runtimes/2.0.2/glossary#candidacy-bond)). This type should implement the trait `EnsureOrigin`. * `PotId` — id of account that will hold a [Pot](/substrate-runtimes/2.0.2/glossary#pot). * `MaxCandidates` — maximum number of candidates * `MinEligibleCollators` — minimum number of collators to collect for the session diff --git a/content/substrate-runtimes/2.0.2/pallets/parachain-system.mdx b/content/substrate-runtimes/2.0.2/pallets/parachain-system.mdx index b769d64..45860f3 100644 --- a/content/substrate-runtimes/2.0.2/pallets/parachain-system.mdx +++ b/content/substrate-runtimes/2.0.2/pallets/parachain-system.mdx @@ -19,7 +19,7 @@ This pallet is a core element of each parachain. It will: ## Config * Pallet-specific configs: - * `OnSystemEvent` — a handler that will be called when new [validation data](/substrate-runtimes/2.0.2/glossary#validation_data) will be set (once each block). New validation data will also be passed to it. Look to `trait OnSystemEvent` for more details. + * `OnSystemEvent` — a handler that will be called when new [validation data](/substrate-runtimes/2.0.2/glossary#validation-data) will be set (once each block). New validation data will also be passed to it. Look to `trait OnSystemEvent` for more details. * `SelfParaId` — getter for a parachain id of this chain * `OutboundXcmpMessageSource` — source of outgoing XCMP messages. It is queried in `finalize_block` and later included into collation information * `DmpQueue` — a handler for the incoming **downward** messages from relay chain @@ -27,7 +27,7 @@ This pallet is a core element of each parachain. It will: * `XcmpMessageHandler` — a handler for the incoming _horizontal_ messages from other parachains * `ReservedXcmpWeight` — default weight limit for the for the XCMP message processing. May be overriden by storage `ReservedXcmpWeightOverride` . If incoming messages in block will exceed the weight limit, they won’t be processed. * `CheckAssociatedRelayNumber` — type that implements `trait CheckAssociatedRelayNumber` . Currently there are three implementations: no check (`AnyRelayNumber`), strict increase (`RelayNumberStrictlyIncreases`), monotonic increase (`RelayNumberMonotonicallyIncreases`). It is needed to maintain some order between blocks in relay chain and parachain. - * `ConsensusHook` — this is a feature-enabled config ( for the management of the [unincluded segment](/substrate-runtimes/2.0.2/glossary#unincluded_segment). Requires the implementation of `trait ConsensusHook`. There are several implementations of it, in `parachain-system` crate (`FixedCapacityUnincludedSegment`) and in `aura-ext` crate (`FixedVelocityConsensusHook`). It is needed to maintain the logic of segment length handling. + * `ConsensusHook` — this is a feature-enabled config ( for the management of the [unincluded segment](/substrate-runtimes/2.0.2/glossary#unincluded-segment). Requires the implementation of `trait ConsensusHook`. There are several implementations of it, in `parachain-system` crate (`FixedCapacityUnincludedSegment`) and in `aura-ext` crate (`FixedVelocityConsensusHook`). It is needed to maintain the logic of segment length handling. * Common parameters for all pallets: * `RuntimeEvent` * `WeightInfo` @@ -104,7 +104,7 @@ Validate and perform the authorized upgrade. ### Pallet's workflow * Block Initialization - * Remove already processed [validation code](/substrate-runtimes/2.0.2/glossary#validation_code) + * Remove already processed [validation code](/substrate-runtimes/2.0.2/glossary#validation-code) * Update `UnincludedSegment` with latest parent hash * Cleans up `ValidationData` and other functions. * Calculate weights for everything that was done in `on_finalize` hook diff --git a/content/substrate-runtimes/2.0.2/pallets/proxy.mdx b/content/substrate-runtimes/2.0.2/pallets/proxy.mdx index 7951849..93c6419 100644 --- a/content/substrate-runtimes/2.0.2/pallets/proxy.mdx +++ b/content/substrate-runtimes/2.0.2/pallets/proxy.mdx @@ -117,7 +117,7 @@ If the proxy requires an announcement before the call, this dispatchable will fa ***Params:*** * `real: AccountIdLookupOf` — the account on which behalf this call will be made -* `force_proxy_type: Option` — specific [proxy type](/substrate-runtimes/2.0.2/glossary#proxy_type) to get proxy for. If not specified, first one found in the storage will be used. +* `force_proxy_type: Option` — specific [proxy type](/substrate-runtimes/2.0.2/glossary#proxy-type) to get proxy for. If not specified, first one found in the storage will be used. * `call: Box<::RuntimeCall>` — a call to execute ***Errors:*** @@ -264,7 +264,7 @@ pub fn create_pure( ) ``` -This call creates a [pure account](/substrate-runtimes/2.0.2/glossary#pur_account) with a proxy issued to it from the call’s origin. +This call creates a [pure account](/substrate-runtimes/2.0.2/glossary#pure-account) with a proxy issued to it from the call’s origin. The origin must be signed for this call. diff --git a/content/substrate-runtimes/2.0.2/pallets/transaction_payment.mdx b/content/substrate-runtimes/2.0.2/pallets/transaction_payment.mdx index 6d7c724..66d23e7 100644 --- a/content/substrate-runtimes/2.0.2/pallets/transaction_payment.mdx +++ b/content/substrate-runtimes/2.0.2/pallets/transaction_payment.mdx @@ -18,7 +18,7 @@ This pallet also exposes - how to update fees for the next block based on past fees (`Config::FeeMultiplierUpdate`) - how fees are paid (`Config::OnChargeTransaction`) -The base fee and adjusted [weight](/substrate-runtimes/2.0.2/glossary#weight_fee) and [length](/substrate-runtimes/2.0.2/glossary#length_fee) fees constitute the _inclusion fee_, which is the minimum fee for a transaction to be included in a block. The formula of final fee: +The base fee and adjusted [weight](/substrate-runtimes/2.0.2/glossary#weight-fee) and [length](/substrate-runtimes/2.0.2/glossary#length-fee) fees constitute the _inclusion fee_, which is the minimum fee for a transaction to be included in a block. The formula of final fee: ```rust, ignore inclusion_fee = base_fee + length_fee + [fee_multiplier_update * weight_fee]; final_fee = inclusion_fee + tip; diff --git a/content/substrate-runtimes/pallets/collator-selection.mdx b/content/substrate-runtimes/pallets/collator-selection.mdx index 55f5e8b..cb6b42c 100644 --- a/content/substrate-runtimes/pallets/collator-selection.mdx +++ b/content/substrate-runtimes/pallets/collator-selection.mdx @@ -15,7 +15,7 @@ This pallet is needed to manage the set of [collators](/substrate-runtimes/gloss ## Config * Pallet-specific configs - * `UpdateOrigin` — defines the list of origins that are able to modify the settings of collators (e.g. set and remove list of [invulnerables](/substrate-runtimes/glossary#invulnerable), desired [candidates](/substrate-runtimes/glossary#candidates), [candidacy bond](/substrate-runtimes/glossary#candidacy_bond)). This type should implement the trait `EnsureOrigin`. + * `UpdateOrigin` — defines the list of origins that are able to modify the settings of collators (e.g. set and remove list of [invulnerables](/substrate-runtimes/glossary#invulnerable), desired [candidates](/substrate-runtimes/glossary#candidate), [candidacy bond](/substrate-runtimes/glossary#candidacy-bond)). This type should implement the trait `EnsureOrigin`. * `PotId` — id of account that will hold a [Pot](/substrate-runtimes/glossary#pot). * `MaxCandidates` — maximum number of candidates * `MinEligibleCollators` — minimum number of collators to collect for the session diff --git a/content/substrate-runtimes/pallets/parachain-system.mdx b/content/substrate-runtimes/pallets/parachain-system.mdx index 62b44d1..3ebd010 100644 --- a/content/substrate-runtimes/pallets/parachain-system.mdx +++ b/content/substrate-runtimes/pallets/parachain-system.mdx @@ -21,7 +21,7 @@ This pallet is a core element of each parachain. It will: ## Config * Pallet-specific configs: - * `OnSystemEvent` — a handler that will be called when new [validation data](../glossary#validation_data) will be set (once each block). New validation data will also be passed to it. Look to `trait OnSystemEvent` for more details. + * `OnSystemEvent` — a handler that will be called when new [validation data](../glossary#validation-data) will be set (once each block). New validation data will also be passed to it. Look to `trait OnSystemEvent` for more details. * `SelfParaId` — getter for a parachain id of this chain * `OutboundXcmpMessageSource` — source of outgoing XCMP messages. It is queried in `finalize_block` and later included into collation information * `DmpQueue` — a handler for the incoming **downward** messages from relay chain @@ -29,7 +29,7 @@ This pallet is a core element of each parachain. It will: * `XcmpMessageHandler` — a handler for the incoming _horizontal_ messages from other parachains * `ReservedXcmpWeight` — default weight limit for the XCMP message processing. May be overridden by storage `ReservedXcmpWeightOverride`. If incoming messages in block will exceed the weight limit, they won’t be processed. * `CheckAssociatedRelayNumber` — type that implements `trait CheckAssociatedRelayNumber` . Currently there are three implementations: no check (`AnyRelayNumber`), strict increase (`RelayNumberStrictlyIncreases`), monotonic increase (`RelayNumberMonotonicallyIncreases`). It is needed to maintain some order between blocks in relay chain and parachain. - * `ConsensusHook` — this is a feature-enabled config for the management of the [unincluded segment](../glossary#unincluded_segment). Requires the implementation of `trait ConsensusHook`. There are several implementations of it, in `parachain-system` crate (`FixedCapacityUnincludedSegment`) and in `aura-ext` crate (`FixedVelocityConsensusHook`). It is needed to maintain the logic of segment length handling. + * `ConsensusHook` — this is a feature-enabled config for the management of the [unincluded segment](../glossary#unincluded-segment). Requires the implementation of `trait ConsensusHook`. There are several implementations of it, in `parachain-system` crate (`FixedCapacityUnincludedSegment`) and in `aura-ext` crate (`FixedVelocityConsensusHook`). It is needed to maintain the logic of segment length handling. * Common parameters for all pallets: * `RuntimeEvent` * `WeightInfo` @@ -106,7 +106,7 @@ Validate and perform the authorized upgrade. ### Pallet's workflow * Block Initialization - * Remove already processed [validation code](../glossary#validation_code) + * Remove already processed [validation code](../glossary#validation-code) * Update `UnincludedSegment` with latest parent hash * Cleans up `ValidationData` and other functions. * Calculate weights for everything that was done in `on_finalize` hook diff --git a/content/substrate-runtimes/pallets/proxy.mdx b/content/substrate-runtimes/pallets/proxy.mdx index 56d615f..d0b8c74 100644 --- a/content/substrate-runtimes/pallets/proxy.mdx +++ b/content/substrate-runtimes/pallets/proxy.mdx @@ -119,7 +119,7 @@ If the proxy requires an announcement before the call, this dispatchable will fa ***Params:*** * `real: AccountIdLookupOf` — the account on which behalf this call will be made -* `force_proxy_type: Option` — specific [proxy type](/substrate-runtimes/glossary#proxy_type) to get proxy for. If not specified, first one found in the storage will be used. +* `force_proxy_type: Option` — specific [proxy type](/substrate-runtimes/glossary#proxy-type) to get proxy for. If not specified, first one found in the storage will be used. * `call: Box<::RuntimeCall>` — a call to execute ***Errors:*** @@ -266,7 +266,7 @@ pub fn create_pure( ) ``` -This call creates a [pure account](/substrate-runtimes/glossary#pure_account) with a proxy issued to it from the call's origin. +This call creates a [pure account](/substrate-runtimes/glossary#pure-account) with a proxy issued to it from the call's origin. The origin must be signed for this call. diff --git a/content/substrate-runtimes/pallets/transaction_payment.mdx b/content/substrate-runtimes/pallets/transaction_payment.mdx index 0729e4b..74ce247 100644 --- a/content/substrate-runtimes/pallets/transaction_payment.mdx +++ b/content/substrate-runtimes/pallets/transaction_payment.mdx @@ -20,7 +20,7 @@ This pallet also exposes - how to update fees for the next block based on past fees (`Config::FeeMultiplierUpdate`) - how fees are paid (`Config::OnChargeTransaction`) -The base fee and adjusted [weight](/substrate-runtimes/glossary#weight_fee) and [length](/substrate-runtimes/glossary#length_fee) fees constitute the _inclusion fee_, which is the minimum fee for a transaction to be included in a block. The formula of final fee: +The base fee and adjusted [weight](/substrate-runtimes/glossary#weight-fee) and [length](/substrate-runtimes/glossary#length-fee) fees constitute the _inclusion fee_, which is the minimum fee for a transaction to be included in a block. The formula of final fee: ```rust inclusion_fee = base_fee + length_fee + [fee_multiplier_update * weight_fee]; final_fee = inclusion_fee + tip; diff --git a/content/uniswap-hooks/api/fee.mdx b/content/uniswap-hooks/api/fee.mdx index 12afd65..df0131c 100644 --- a/content/uniswap-hooks/api/fee.mdx +++ b/content/uniswap-hooks/api/fee.mdx @@ -22,7 +22,7 @@ import "uniswap-hooks/src/fee/BaseDynamicAfterFee.sol"; Base implementation for dynamic target hook fees applied after swaps. Enables to enforce a dynamic target determined by [`BaseDynamicAfterFee._getTargetUnspecified`](#BaseDynamicAfterFee-_getTargetUnspecified-address-struct-PoolKey-struct-SwapParams-bytes-) for the unspecified currency of the swap -during [`BaseAsyncSwap._beforeSwap`](/uniswap-hooks/base#BaseAsyncSwap-_beforeSwap-address-struct-PoolKey-struct-SwapParams-bytes-), where if the swap outcome results better than the target, any positive difference is taken +during [`BaseAsyncSwap._beforeSwap`](/uniswap-hooks/api/base#BaseAsyncSwap-_beforeSwap-address-struct-PoolKey-struct-SwapParams-bytes-), where if the swap outcome results better than the target, any positive difference is taken as a hook fee, being posteriorily handled or distributed by the hook via [`BaseDynamicAfterFee._afterSwapHandler`](#BaseDynamicAfterFee-_afterSwapHandler-struct-PoolKey-struct-SwapParams-BalanceDelta-uint256-uint256-). @@ -283,7 +283,7 @@ Customizable handler called after `_afterSwap` to handle or distribute the fees.
-Set the hook permissions, specifically [`BaseHook.beforeSwap`](/uniswap-hooks/base#BaseHook-beforeSwap-address-struct-PoolKey-struct-SwapParams-bytes-), [`BaseHook.afterSwap`](/uniswap-hooks/base#BaseHook-afterSwap-address-struct-PoolKey-struct-SwapParams-BalanceDelta-bytes-) and `afterSwapReturnDelta`. +Set the hook permissions, specifically [`BaseHook.beforeSwap`](/uniswap-hooks/api/base#BaseHook-beforeSwap-address-struct-PoolKey-struct-SwapParams-bytes-), [`BaseHook.afterSwap`](/uniswap-hooks/api/base#BaseHook-afterSwap-address-struct-PoolKey-struct-SwapParams-BalanceDelta-bytes-) and `afterSwapReturnDelta`.
diff --git a/content/uniswap-hooks/api/general.mdx b/content/uniswap-hooks/api/general.mdx index 3db672b..703fadb 100644 --- a/content/uniswap-hooks/api/general.mdx +++ b/content/uniswap-hooks/api/general.mdx @@ -158,7 +158,7 @@ Handles the before swap hook. For the first swap in a block, it saves the current pool state as a checkpoint. For subsequent swaps in the same block, it calculates a target output based on the beginning-of-block state, -and sets the inherited `_targetOutput` and `_applyTargetOutput` variables to enforce price limits in [`BaseHook._afterSwap`](/uniswap-hooks/base#BaseHook-_afterSwap-address-struct-PoolKey-struct-SwapParams-BalanceDelta-bytes-). +and sets the inherited `_targetOutput` and `_applyTargetOutput` variables to enforce price limits in [`BaseHook._afterSwap`](/uniswap-hooks/api/base#BaseHook-_afterSwap-address-struct-PoolKey-struct-SwapParams-BalanceDelta-bytes-). @@ -471,7 +471,7 @@ Hooks into the `afterSwap` hook to get the ticks crossed by the swap and fill th Places a limit order by adding liquidity out of range at a specific tick. The order will be filled when the pool price crosses the specified `tick`. Takes a `PoolKey` `key`, target `tick`, direction `zeroForOne` indicating whether to buy currency0 or currency1, and amount of `liquidity` to place. The interaction with the `poolManager` is done -via the `unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/base#BaseCustomAccounting-unlockCallback-bytes-) function. +via the `unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/api/base#BaseCustomAccounting-unlockCallback-bytes-) function. @@ -492,7 +492,7 @@ Cancels a limit order by removing liquidity from the pool. Takes a `PoolKey` `ke direction `zeroForOne` indicating whether it was buying currency0 or currency1, and recipient address `to` for the removed liquidity. Note that partial cancellation is not supported - the entire liquidity added by the msg.sender will be removed. Note also that cancelling an order will cancel the order placed by the msg.sender, not orders placed by other users in the same tick range. -The interaction with the `poolManager` is done via the `unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/base#BaseCustomAccounting-unlockCallback-bytes-) function. +The interaction with the `poolManager` is done via the `unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/api/base#BaseCustomAccounting-unlockCallback-bytes-) function. @@ -512,7 +512,7 @@ The interaction with the `poolManager` is done via the `unlock` function, which Withdraws liquidity from a filled order, sending it to address `to`. Takes an `OrderId` `orderId` of the filled order to withdraw from. Returns the withdrawn amounts as `(amount0, amount1)`. Can only be called after the order is filled - use `cancelOrder` to remove liquidity from unfilled orders. The interaction with the `poolManager` is done via the -`unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/base#BaseCustomAccounting-unlockCallback-bytes-) function. +`unlock` function, which will trigger the [`BaseCustomAccounting.unlockCallback`](/uniswap-hooks/api/base#BaseCustomAccounting-unlockCallback-bytes-) function. @@ -934,8 +934,8 @@ import "uniswap-hooks/src/general/LiquidityPenaltyHook.sol"; Just-in-Time (JIT) liquidity provisioning resistant hook. -This hook disincentivizes JIT attacks by penalizing LP fee collection during [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-), -and disabling it during [`BaseHook._afterAddLiquidity`](/uniswap-hooks/base#BaseHook-_afterAddLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) if liquidity was recently added to the position. +This hook disincentivizes JIT attacks by penalizing LP fee collection during [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/api/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-), +and disabling it during [`BaseHook._afterAddLiquidity`](/uniswap-hooks/api/base#BaseHook-_afterAddLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) if liquidity was recently added to the position. The penalty is donated to the pool's liquidity providers in range at the time of removal. See [`LiquidityPenaltyHook._calculateLiquidityPenalty`](#LiquidityPenaltyHook-_calculateLiquidityPenalty-BalanceDelta-uint48-) for penalty calculation. @@ -1054,7 +1054,7 @@ Sets the `PoolManager` address and the `getBlockNumberOffset`. Tracks `lastAddedLiquidityBlock` and withholds `feeDelta` if liquidity was recently added within the `blockNumberOffset` period. -See [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) for claiming the withheld fees back. +See [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/api/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) for claiming the withheld fees back. @@ -1221,7 +1221,7 @@ Returns the `withheldFees` for a liquidity position. `withheldFees` are UniswapV4's `feesAccrued` retained by this hook during liquidity addition if liquidity has been recently added within the `blockNumberOffset` block time window, with the purpose of disabling fee -collection during JIT liquidity provisioning attacks. See [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) for claiming the fees back. +collection during JIT liquidity provisioning attacks. See [`BaseHook._afterRemoveLiquidity`](/uniswap-hooks/api/base#BaseHook-_afterRemoveLiquidity-address-struct-PoolKey-struct-ModifyLiquidityParams-BalanceDelta-BalanceDelta-bytes-) for claiming the fees back. diff --git a/content/upgrades-plugins/api-hardhat-upgrades.mdx b/content/upgrades-plugins/api-hardhat-upgrades.mdx index 8600642..326439a 100644 --- a/content/upgrades-plugins/api-hardhat-upgrades.mdx +++ b/content/upgrades-plugins/api-hardhat-upgrades.mdx @@ -15,9 +15,9 @@ The following options are common to some functions. * `"state-variable-assignment"`: Allows assigning state variables in a contract even though they will be stored in the implementation. * `"state-variable-immutable"`: Allows use of immutable variables, which are not unsafe * `"constructor"`: Allows defining a constructor. See `constructorArgs`. - * `"delegatecall"`, `"selfdestruct"`: Allow the use of these operations. Incorrect use of this option can put funds at risk of permanent loss. See [Can I safely use `delegatecall` and `selfdestruct`?](/upgrades-plugins/faq#delegatecall-selfdestruct) + * `"delegatecall"`, `"selfdestruct"`: Allow the use of these operations. Incorrect use of this option can put funds at risk of permanent loss. See [Can I safely use `delegatecall` and `selfdestruct`?](/upgrades-plugins/faq#can-i-safely-use-delegatecall-and-selfdestruct) * `"missing-public-upgradeto"`: Allow UUPS implementations that do not contain a public `upgradeTo` or `upgradeToAndCall` function. Enabling this option is likely to cause a revert due to the built-in UUPS safety mechanism. - * `"internal-function-storage"`: Allow internal functions in storage variables. Internal functions are code pointers which will no longer be valid after an upgrade, so they must be reassigned during upgrades. See [How can I use internal functions in storage variables?](/upgrades-plugins/faq#internal-function-storage) + * `"internal-function-storage"`: Allow internal functions in storage variables. Internal functions are code pointers which will no longer be valid after an upgrade, so they must be reassigned during upgrades. See [How can I use internal functions in storage variables?](/upgrades-plugins/faq#how-can-i-use-internal-functions-in-storage-variables) * `"missing-initializer"`: Allows implementations where an initializer function is not detected. * `"missing-initializer-call"`: Allows implementations where a parent initializer is not called from the child initializer. * `"duplicate-initializer-call"`: Allows implementations where a parent initializer is called more than once from the child initializer. @@ -39,14 +39,14 @@ The following options are common to some functions. * `useDefenderDeploy`: (`boolean`) Deploy contracts using OpenZeppelin Defender instead of ethers.js. See [Using with OpenZeppelin Defender](/upgrades-plugins/defender-deploy). * `verifySourceCode`: (`boolean`) When using OpenZeppelin Defender deployments, whether to verify source code on block explorers. Defaults to `true`. * `relayerId`: (`string`) When using OpenZeppelin Defender deployments, the ID of the relayer to use for the deployment. Defaults to the relayer configured for your deployment environment on Defender. -* `salt`: (`string`) When using OpenZeppelin Defender deployments, if this is not set, deployments will be performed using the CREATE opcode. If this is set, deployments will be performed using the CREATE2 opcode with the provided salt. Note that deployments using a Safe are done using CREATE2 and require a salt. ***Warning:*** CREATE2 affects `msg.sender` behavior. See [Caveats](/defender/tutorial/deploy#deploy-caveat) for more information. +* `salt`: (`string`) When using OpenZeppelin Defender deployments, if this is not set, deployments will be performed using the CREATE opcode. If this is set, deployments will be performed using the CREATE2 opcode with the provided salt. Note that deployments using a Safe are done using CREATE2 and require a salt. ***Warning:*** CREATE2 affects `msg.sender` behavior. See [Caveats](/defender/tutorial/deploy#caveats) for more information. * `metadata`: (` commitHash?: string; tag?: string; [k: string]: any; `) When using OpenZeppelin Defender deployments, you can use this to identify, tag, or classify deployments. See [Metadata](/defender/module/deploy#metadata). * `proxyFactory`: (`ethers.ContractFactory`) Customizes the ethers contract factory to use for deploying the proxy, allowing a custom proxy contract to be deployed. See [factories.ts](https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/master/packages/plugin-hardhat/src/utils/factories.ts) for the default contract factory for each kind of proxy. * **Since:** `@openzeppelin/hardhat-upgrades@3.7.0` * `deployFunction`: (`(hre, opts, factory, ...args) => Promise`) Customizes the function used to deploy the proxy. Can be used along with the `proxyFactory` option to override constructor parameters for custom proxy deployments. See [deploy.ts](https://github.com/OpenZeppelin/openzeppelin-upgrades/blob/master/packages/plugin-hardhat/src/utils/deploy.ts) for the default deploy function. * **Since:** `@openzeppelin/hardhat-upgrades@3.7.0` -Note that the options `unsafeAllow` can also be specified in a more granular way directly in the source code if using Solidity >=0.8.2. See [How can I disable some of the checks?](/upgrades-plugins/faq#how-can-i-disable-checks) +Note that the options `unsafeAllow` can also be specified in a more granular way directly in the source code if using Solidity >=0.8.2. See [How can I disable some of the checks?](/upgrades-plugins/faq#how-can-i-disable-some-of-the-checks) The following options have been deprecated. diff --git a/content/upgrades-plugins/api-truffle-upgrades.mdx b/content/upgrades-plugins/api-truffle-upgrades.mdx index 49b190d..121e90d 100644 --- a/content/upgrades-plugins/api-truffle-upgrades.mdx +++ b/content/upgrades-plugins/api-truffle-upgrades.mdx @@ -20,7 +20,7 @@ The following options are common to some functions. * `"state-variable-assignment"`: Allows assigning state variables in a contract even though they will be stored in the implementation. * `"state-variable-immutable"`: Allows use of immutable variables, which are not unsafe * `"constructor"`: Allows defining a constructor. See `constructorArgs`. - * `"delegatecall"`, `"selfdestruct"`: Allow the use of these operations. Incorrect use of this option can put funds at risk of permanent loss. See [Can I safely use `delegatecall` and `selfdestruct`?](/upgrades-plugins/faq#delegatecall-selfdestruct) + * `"delegatecall"`, `"selfdestruct"`: Allow the use of these operations. Incorrect use of this option can put funds at risk of permanent loss. See [Can I safely use `delegatecall` and `selfdestruct`?](/upgrades-plugins/faq#can-i-safely-use-delegatecall-and-selfdestruct) * `"missing-public-upgradeto"`: Allow UUPS implementations that do not contain a public `upgradeTo` or `upgradeToAndCall` function. Enabling this option is likely to cause a revert due to the built-in UUPS safety mechanism. * `unsafeAllowRenames`: (`boolean`) Configure storage layout check to allow variable renaming. * `unsafeSkipStorageCheck`: (`boolean`) upgrades the proxy or beacon without first checking for storage layout compatibility errors. This is a dangerous option meant to be used as a last resort. @@ -31,7 +31,7 @@ The following options are common to some functions. * If set to `"onchange"`, the implementation contract is redeployed only if the bytecode has changed from previous deployments. * `txOverrides`: (`TruffleTxOptions`) A Truffle [options](https://trufflesuite.com/docs/truffle/how-to/contracts/run-migrations/#deployerdeploycontract-args-options) object to override transaction parameters, such as `gas` and `gasPrice`. Applies to all transactions sent by a function with this option, even if the function sends multiple transactions. -Note that the options `unsafeAllow` can also be specified in a more granular way directly in the source code if using Solidity >=0.8.2. See [How can I disable some of the checks?](/upgrades-plugins/faq#how-can-i-disable-checks) +Note that the options `unsafeAllow` can also be specified in a more granular way directly in the source code if using Solidity >=0.8.2. See [How can I disable some of the checks?](/upgrades-plugins/faq#how-can-i-disable-some-of-the-checks) The following options have been deprecated. diff --git a/content/upgrades-plugins/foundry/foundry-upgrades.mdx b/content/upgrades-plugins/foundry/foundry-upgrades.mdx index a8c9e40..dae565b 100644 --- a/content/upgrades-plugins/foundry/foundry-upgrades.mdx +++ b/content/upgrades-plugins/foundry/foundry-upgrades.mdx @@ -98,7 +98,7 @@ extra_output = ["storageLayout"] 1. If you are upgrading your contract from a previous version, add the `@custom:oz-upgrades-from ` annotation to the new version of your contract according to [Define Reference Contracts](/upgrades-plugins/api-core#define-reference-contracts) or specify the `referenceContract` option when calling the library’s functions. 2. Run `forge clean` before running your Foundry script or tests, or include the `--force` option when running `forge script` or `forge test`. -If you do not want to run upgrade safety validations, you can skip the above steps and use the [`unsafeSkipAllChecks` option](/upgrades-plugins/foundry/api#Options) when calling the `Upgrades` library’s functions, or use the `UnsafeUpgrades` library instead. Note that these are dangerous options meant to be used as a last resort. +If you do not want to run upgrade safety validations, you can skip the above steps and use the [`unsafeSkipAllChecks` option](/upgrades-plugins/foundry/api/Options) when calling the `Upgrades` library’s functions, or use the `UnsafeUpgrades` library instead. Note that these are dangerous options meant to be used as a last resort. ### Optional: Custom output directory diff --git a/scripts/link-validation.ts b/scripts/link-validation.ts index 3048df0..756bdfa 100644 --- a/scripts/link-validation.ts +++ b/scripts/link-validation.ts @@ -87,7 +87,22 @@ async function getHeadings({ data, }: InferPageType): Promise { const pageData = await data.load(); - return pageData.toc.map((item) => item.url.slice(1)); + const tocHeadings = pageData.toc.map((item) => item.url.slice(1)); + + // Also extract actual anchor IDs from the content for API reference pages + const content = await data.getText("raw"); + const anchorRegex = /<\/a>/g; + const anchorIds: string[] = []; + let match: any; + + while ((match = anchorRegex.exec(content)) !== null) { + anchorIds.push(match[1]); + } + + // Combine TOC headings and actual anchor IDs, removing duplicates + const allHeadings = [...new Set([...tocHeadings, ...anchorIds])]; + + return allHeadings; } function getFiles(scope?: string | null) {