Merge pull request #27 from OpenZeppelin/feat/cairo-contracts-fixes

Fixes for contracts-cairo

Author: ericnordelo

.github/workflows/lint.yml

@@ -13,7 +13,7 @@ jobs:
 
     steps:
       - name: Checkout code
-        uses: actions/checkout@v4
+        uses: actions/checkout@v5
 
       - name: Setup pnpm
         uses: pnpm/action-setup@v4
@@ -27,4 +27,4 @@ jobs:
         run: pnpm run check
 
       - name: Build check
-        run: pnpm run build
+        run: pnpm run build

content/contracts-cairo/1.0.0/accounts.mdx

@@ -80,12 +80,12 @@ interoperability with the ecosystem.
 The Starknet protocol uses a few entrypoints for abstracting the accounts. We already mentioned the first two
 as part of the ISRC6 interface, and both are required for enabling accounts to be used for executing transactions. The rest are optional:
 
-1. `\\__validate__` verifies the validity of the transaction to be executed. This is usually used to validate signatures,
+1. `__validate__` verifies the validity of the transaction to be executed. This is usually used to validate signatures,
 but the entrypoint implementation can be customized to feature any validation mechanism [with some limitations](https://docs.starknet.io/architecture-and-concepts/accounts/account-functions/#limitations_of_validation).
-2. `\\__execute__` executes the transaction if the validation is successful.
-3. `\\__validate_declare__` optional entrypoint similar to `\\__validate__` but for transactions
+2. `__execute__` executes the transaction if the validation is successful.
+3. `__validate_declare__` optional entrypoint similar to `__validate__` but for transactions
 meant to declare other contracts.
-4. `\\__validate_deploy__` optional entrypoint similar to `\\__validate__` but meant for [counterfactual deployments](/guides/deployment).
+4. `__validate_deploy__` optional entrypoint similar to `__validate__` but meant for [counterfactual deployments](/guides/deployment).
 
 <Callout>
 Although these entrypoints are available to the protocol for its regular transaction flow, they can also be called like any other method.
@@ -275,7 +275,7 @@ wraps and exposes the `deploy_syscall` to provide arbitrary deployments through
 But if you don’t have an account to invoke it, you will probably want to use the latter.
 
 To do counterfactual deployments, you need to implement another protocol-level entrypoint named
-`\\__validate_deploy__`. Check the [counterfactual deployments](/guides/deployment) guide to learn how.
+`__validate_deploy__`. Check the [counterfactual deployments](/guides/deployment) guide to learn how.
 
 ## Sending transactions
 
@@ -285,7 +285,7 @@ Let’s now explore how to send transactions through these accounts.
 
 First, let’s take the example account we created before and deploy it:
 
-```[,cairo]
+```rust
 #[starknet::contract(account)]
 mod MyAccount {
     use openzeppelin_account::AccountComponent;
@@ -333,7 +333,7 @@ The flag enables custom account variants.
 The following examples use `sncast` [v0.23.0](https://github.com/foundry-rs/starknet-foundry/releases/tag/v0.23.0).
 </Callout>
 
-```[,bash]
+```bash
 $ sncast \
   --url http://127.0.0.1:5050 \
   account create \
@@ -344,7 +344,7 @@ $ sncast \
 This command will output the precomputed contract address and the recommended `max-fee`.
 To counterfactually deploy the account, send funds to the address and then deploy the custom account.
 
-```[,bash]
+```bash
 $ sncast \
   --url http://127.0.0.1:5050 \
   account deploy \
@@ -353,7 +353,7 @@ $ sncast \
 
 Once the account is deployed, set the `--account` flag with the custom account name to send transactions from that account.
 
-```[,bash]
+```bash
 $ sncast \
   --account my-custom-account \
   --url http://127.0.0.1:5050 \
@@ -367,7 +367,7 @@ $ sncast \
 
 First, let’s take the example account we created before and deploy it:
 
-```[,cairo]
+```rust
 #[starknet::contract(account)]
 mod MyEthAccount {
     use openzeppelin_account::EthAccountComponent;
@@ -417,7 +417,7 @@ Next, precompute the EthAccount contract address using the declared class hash.
 The following examples use unreleased features from StarknetJS (`starknetjs@next`) at commit [d002baea0abc1de3ac6e87a671f3dec3757437b3](https://github.com/starknet-io/starknet.js/commit/d002baea0abc1de3ac6e87a671f3dec3757437b3).
 </Callout>
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { CallData, EthSigner, hash } from 'starknet';
 import { ABI as ETH_ABI } from '../abis/eth_account.js';
@@ -443,7 +443,7 @@ console.log('Pre-calculated EthAccount address: ', ethContractAddress);
 
 Send funds to the pre-calculated EthAccount address and deploy the contract.
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { Account, CallData, EthSigner, RpcProvider, stark } from 'starknet';
 import { ABI as ETH_ABI } from '../abis/eth_account.js';
@@ -479,7 +479,7 @@ console.log('EthAccount deployed at: ', contract_address);
 Once deployed, connect the EthAccount instance to the target contract which enables calls to come from the EthAccount.
 Here’s what an ERC20 transfer from an EthAccount looks like.
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { Account, RpcProvider, Contract, EthSigner } from 'starknet';
 dotenv.config();

content/contracts-cairo/1.0.0/erc1155.mdx

@@ -79,7 +79,7 @@ mod MyERC1155 {
 The following interface represents the full ABI of the Contracts for Cairo [ERC1155Component](/api/erc1155#ERC1155Component).
 The interface includes the [IERC1155](/api/erc1155#IERC1155) standard interface and the optional [IERC1155MetadataURI](/api/erc1155#IERC1155MetadataURI) interface together with [ISRC5](/api/introspection#ISRC5).
 
-To support older token deployments, as mentioned in [Dual interfaces](interfaces#dual_interfaces), the component also includes implementations of the interface written in camelCase.
+To support older token deployments, as mentioned in [Dual interfaces](guides/interfaces-and-dispatchers#dual-interfaces), the component also includes implementations of the interface written in camelCase.
 
 ```cairo
 #[starknet::interface]
@@ -156,7 +156,7 @@ In the spirit of the standard, we’ve also included batch operations in the non
 <Callout type='warn'>
 While [safe_transfer_from](/api/erc1155#IERC1155-safe_transfer_from) and [safe_batch_transfer_from](/api/erc1155#IERC1155-safe_batch_transfer_from) prevent loss by checking the receiver can handle the
 </Callout>
-tokens, this yields execution to the receiver which can result in a [reentrant call](security#reentrancy_guard).
+tokens, this yields execution to the receiver which can result in a [reentrant call](security#reentrancy-guard).
 
 ## Receiving tokens
 
@@ -190,7 +190,7 @@ When [safe_transfer_from](/api/erc1155#IERC1155-safe_transfer_from) and [safe_ba
 Otherwise, the transaction will fail.
 
 <Callout>
-For information on how to calculate interface IDs, see [Computing the interface ID](introspection#computing_the_interface_id).
+For information on how to calculate interface IDs, see [Computing the interface ID](introspection#computing-the-interface-id).
 </Callout>
 
 ### Creating a token receiver contract

content/contracts-cairo/1.0.0/erc20.mdx

@@ -71,7 +71,7 @@ For a more complete guide on ERC20 token mechanisms, see [Creating ERC20 Supply]
 The following interface represents the full ABI of the Contracts for Cairo [ERC20Component](/api/erc20#ERC20Component).
 The interface includes the [IERC20](/api/erc20#IERC20) standard interface as well as the optional [IERC20Metadata](/api/erc20#IERC20Metadata).
 
-To support older token deployments, as mentioned in [Dual interfaces](/interfaces#dual_interfaces), the component also includes an implementation of the interface written in camelCase.
+To support older token deployments, as mentioned in [Dual interfaces](/guides/interfaces-and-dispatchers#dual-interfaces), the component also includes an implementation of the interface written in camelCase.
 
 ```cairo
 #[starknet::interface]
@@ -106,7 +106,7 @@ Although Starknet is not EVM compatible, this component aims to be as close as p
 Some notable differences, however, can still be found, such as:
 
 * The `ByteArray` type is used to represent strings in Cairo.
-* The component offers a [dual interface](/interfaces#dual_interfaces) which supports both snake_case and camelCase methods, as opposed to just camelCase in Solidity.
+* The component offers a [dual interface](/guides/interfaces-and-dispatchers#dual-interfaces) which supports both snake_case and camelCase methods, as opposed to just camelCase in Solidity.
 * `transfer`, `transfer_from` and `approve` will never return anything different from `true` because they will revert on any error.
 * Function selectors are calculated differently between [Cairo](https://github.com/starkware-libs/cairo/blob/7dd34f6c57b7baf5cd5a30c15e00af39cb26f7e1/crates/cairo-lang-starknet/src/contract.rs#L39-L48) and [Solidity](https://solidity-by-example.org/function-selector/).
 

content/contracts-cairo/1.0.0/erc721.mdx

@@ -64,7 +64,7 @@ mod MyNFT {
 The following interface represents the full ABI of the Contracts for Cairo [ERC721Component](/api/erc721#ERC721Component).
 The interface includes the [IERC721](/api/erc721#IERC721) standard interface and the optional [IERC721Metadata](/api/erc721#IERC721Metadata) interface.
 
-To support older token deployments, as mentioned in [Dual interfaces](interfaces#dual_interfaces), the component also includes implementations of the interface written in camelCase.
+To support older token deployments, as mentioned in [Dual interfaces](guides/interfaces-and-dispatchers#dual-interfaces), the component also includes implementations of the interface written in camelCase.
 
 ```cairo
 #[starknet::interface]
@@ -158,7 +158,7 @@ When safe methods such as [safe_transfer_from](api/erc721#IERC721-safe_transfer_
 Otherwise, the transaction will fail.
 
 <Callout>
-For information on how to calculate interface IDs, see [Computing the interface ID](introspection#computing_the_interface_id).
+For information on how to calculate interface IDs, see [Computing the interface ID](introspection#computing-the-interface-id).
 </Callout>
 
 ### Creating a token receiver contract

content/contracts-cairo/1.0.0/guides/deployment.mdx

@@ -18,7 +18,7 @@ Note that the `class_hash` must be previously declared for the deployment to suc
 2. Send funds to the `contract_address`. Usually you will estimate the fee of the transaction first. Existing
 tools usually do this for you.
 3. Send a `DeployAccount` type transaction to the network.
-4. The protocol will then validate the transaction with the `\\__validate_deploy__` entrypoint of the contract to be deployed.
+4. The protocol will then validate the transaction with the `__validate_deploy__` entrypoint of the contract to be deployed.
 5. If the validation succeeds, the protocol will charge the fee and then register the contract as deployed.
 
 <Callout>
@@ -27,7 +27,7 @@ Although this method is very popular to deploy accounts, this works for any kind
 
 ## Deployment validation
 
-To be counterfactually deployed, the deploying contract must implement the `\\__validate_deploy__` entrypoint,
+To be counterfactually deployed, the deploying contract must implement the `__validate_deploy__` entrypoint,
 called by the protocol when a `DeployAccount` transaction is sent to the network.
 
 ```cairo

content/contracts-cairo/1.0.0/upgrades.mdx

@@ -4,7 +4,7 @@ title: Upgrades
 
 In different blockchains, multiple patterns have been developed for making a contract upgradeable including the widely adopted proxy patterns.
 
-Starknet has native upgradeability through a syscall that updates the contract source code, removing [the need for proxies](#proxies_in_starknet).
+Starknet has native upgradeability through a syscall that updates the contract source code, removing [the need for proxies](#proxies-in-starknet).
 
 <Callout type='warn'>
 Make sure you follow [our security recommendations](#security) before upgrading.
@@ -39,7 +39,7 @@ OpenZeppelin Contracts for Cairo provides [Upgradeable](https://github.com/OpenZ
 ### Usage
 
 Upgrades are often very sensitive operations, and some form of access control is usually required to
-avoid unauthorized upgrades. The [Ownable](access#ownership_and_ownable) module is used in this example.
+avoid unauthorized upgrades. The [Ownable](access#ownership-and-ownable) module is used in this example.
 
 <Callout>
 We will be using the following module to implement the [IUpgradeable](api/upgrades#IUpgradeable) interface described in the API Reference section.

content/contracts-cairo/1.0.0/utils/_class_hashes.mdx

@@ -80,12 +80,12 @@ interoperability with the ecosystem.
 The Starknet protocol uses a few entrypoints for abstracting the accounts. We already mentioned the first two
 as part of the ISRC6 interface, and both are required for enabling accounts to be used for executing transactions. The rest are optional:
 
-1. `\\__validate__` verifies the validity of the transaction to be executed. This is usually used to validate signatures,
+1. `__validate__` verifies the validity of the transaction to be executed. This is usually used to validate signatures,
 but the entrypoint implementation can be customized to feature any validation mechanism [with some limitations](https://docs.starknet.io/architecture-and-concepts/accounts/account-functions/#limitations_of_validation).
-2. `\\__execute__` executes the transaction if the validation is successful.
-3. `\\__validate_declare__` optional entrypoint similar to `\\__validate__` but for transactions
+2. `__execute__` executes the transaction if the validation is successful.
+3. `__validate_declare__` optional entrypoint similar to `__validate__` but for transactions
 meant to declare other contracts.
-4. `\\__validate_deploy__` optional entrypoint similar to `\\__validate__` but meant for [counterfactual deployments](/guides/deployment).
+4. `__validate_deploy__` optional entrypoint similar to `__validate__` but meant for [counterfactual deployments](/guides/deployment).
 
 <Callout>
 Although these entrypoints are available to the protocol for its regular transaction flow, they can also be called like any other method.
@@ -275,7 +275,7 @@ wraps and exposes the `deploy_syscall` to provide arbitrary deployments through
 But if you don’t have an account to invoke it, you will probably want to use the latter.
 
 To do counterfactual deployments, you need to implement another protocol-level entrypoint named
-`\\__validate_deploy__`. Check the [counterfactual deployments](/guides/deployment) guide to learn how.
+`__validate_deploy__`. Check the [counterfactual deployments](/guides/deployment) guide to learn how.
 
 ## Sending transactions
 
@@ -285,7 +285,7 @@ Let’s now explore how to send transactions through these accounts.
 
 First, let’s take the example account we created before and deploy it:
 
-```[,cairo]
+```rust
 #[starknet::contract(account)]
 mod MyAccount {
     use openzeppelin_account::AccountComponent;
@@ -333,7 +333,7 @@ The flag enables custom account variants.
 The following examples use `sncast` [v0.23.0](https://github.com/foundry-rs/starknet-foundry/releases/tag/v0.23.0).
 </Callout>
 
-```[,bash]
+```bash
 $ sncast \
   --url http://127.0.0.1:5050 \
   account create \
@@ -344,7 +344,7 @@ $ sncast \
 This command will output the precomputed contract address and the recommended `max-fee`.
 To counterfactually deploy the account, send funds to the address and then deploy the custom account.
 
-```[,bash]
+```bash
 $ sncast \
   --url http://127.0.0.1:5050 \
   account deploy \
@@ -353,7 +353,7 @@ $ sncast \
 
 Once the account is deployed, set the `--account` flag with the custom account name to send transactions from that account.
 
-```[,bash]
+```bash
 $ sncast \
   --account my-custom-account \
   --url http://127.0.0.1:5050 \
@@ -367,7 +367,7 @@ $ sncast \
 
 First, let’s take the example account we created before and deploy it:
 
-```[,cairo]
+```rust
 #[starknet::contract(account)]
 mod MyEthAccount {
     use openzeppelin_account::EthAccountComponent;
@@ -417,7 +417,7 @@ Next, precompute the EthAccount contract address using the declared class hash.
 The following examples use unreleased features from StarknetJS (`starknetjs@next`) at commit [d002baea0abc1de3ac6e87a671f3dec3757437b3](https://github.com/starknet-io/starknet.js/commit/d002baea0abc1de3ac6e87a671f3dec3757437b3).
 </Callout>
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { CallData, EthSigner, hash } from 'starknet';
 import { ABI as ETH_ABI } from '../abis/eth_account.js';
@@ -443,7 +443,7 @@ console.log('Pre-calculated EthAccount address: ', ethContractAddress);
 
 Send funds to the pre-calculated EthAccount address and deploy the contract.
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { Account, CallData, EthSigner, RpcProvider, stark } from 'starknet';
 import { ABI as ETH_ABI } from '../abis/eth_account.js';
@@ -479,7 +479,7 @@ console.log('EthAccount deployed at: ', contract_address);
 Once deployed, connect the EthAccount instance to the target contract which enables calls to come from the EthAccount.
 Here’s what an ERC20 transfer from an EthAccount looks like.
 
-```[,javascript]
+```javascript
 import * as dotenv from 'dotenv';
 import { Account, RpcProvider, Contract, EthSigner } from 'starknet';
 dotenv.config();