OpenZeppelin · stevedylandev · Sep 26, 2025 · Sep 26, 2025 · Sep 26, 2025
diff --git 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
@@ -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).
 
 <Callout>
-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).
 </Callout>
 
 ### Accessing component storage

diff --git 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
 <Callout type='warn'>
 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.
 </Callout>
 
 ## Usage

diff --git 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.
 </Callout>
 
-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
@@ -9,7 +9,7 @@ By default, token balance does not account for voting power. This makes transfer
 </Callout>
 
 <Callout type='warn'>
-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.
 </Callout>
 
 ## Key Features

diff --git 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
 <Callout type='warn'>
 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.
 </Callout>
 
 ## Usage

diff --git 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.
 </Callout>
 
-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
@@ -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
@@ -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).
 
 <APIItem
   functionSignature="calculate_vested_amount(self: @ContractState, token: ContractAddress, total_allocation: u256, timestamp: u64, start: u64, duration: u64, cliff: u64) → u256"

diff --git a/content/contracts-cairo/governance/governor.mdx b/content/contracts-cairo/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.
 </Callout>
 
-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
@@ -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
@@ -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
@@ -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
@@ -18,7 +18,7 @@ Additionally there are multiple custom extensions, including:
 * destruction of own tokens (ERC1155Burnable).
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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).
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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).
 
 <Callout>
 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
@@ -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
@@ -15,7 +15,7 @@ Additionally there are multiple custom extensions, including:
 * destruction of own tokens ([`ERC1155Burnable`](#ERC1155Burnable)).
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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.
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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).
 
 <Callout>
-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.
 </Callout>
 
 ## Core

diff --git 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).
 
 <Callout>
 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
@@ -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):
 
 <include cwd lang='solidity'>./examples/access-control/AccessManagedERC20MintBase.sol</include>
 

diff --git 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