Merge pull request #45 from OpenZeppelin/chore/link-fragments

chore/link fragments

Author: stevedylandev

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.
 

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

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

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.

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

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

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.

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

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"

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.