fix: snip12 guide

Author: ericnordelo

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
 

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/2.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
 

content/contracts-cairo/2.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/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
 

content/contracts-cairo/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.
 
 ```rust

content/contracts-cairo/guides/snip12.mdx

@@ -230,8 +230,8 @@ Finally, the full implementation of the `CustomERC20` contract looks like this:
 
 <Callout>
 We are using the [`ISRC6Dispatcher`](/api/account#ISRC6) to verify the signature,
-</Callout>
 and the [`NoncesComponent`](/api/utilities#NoncesComponent) to handle nonces to prevent replay attacks.
+</Callout>
 
 ```rust
 use core::hash::{HashStateExTrait, HashStateTrait};

content/upgrades-plugins/writing-upgradeable.mdx

@@ -386,7 +386,7 @@ Then the variable `base2` would be assigned the slot that `child` had in the pre
 
 Storage gaps are a convention for reserving storage slots in a base contract, allowing future versions of that contract to use up those slots without affecting the storage layout of child contracts.
 
-To create a storage gap, declare a fixed-size array in the base contract with an initial number of slots. This can be an array of `uint256` so that each element reserves a 32 byte slot. Use the name `\\__gap` or a name starting with `__gap_` for the array so that OpenZeppelin Upgrades will recognize the gap:
+To create a storage gap, declare a fixed-size array in the base contract with an initial number of slots. This can be an array of `uint256` so that each element reserves a 32 byte slot. Use the name `_gap` or a name starting with `__gap_` for the array so that OpenZeppelin Upgrades will recognize the gap:
 
 ```solidity
 contract Base

scripts/convert-adoc.js

@@ -135,7 +135,7 @@ async function convertAdocFiles(directory, apiRoute = "contracts/5.x/api") {
 				"<Callout type='warn'>\n$2\n</Callout>",
 			);
 
-			// Fix xref patterns with complex anchors like xref:#ISRC6-\\__execute__[...]
+			// Fix xref patterns with complex anchors like xref:#ISRC6-_execute__[...]
 			mdContent = mdContent.replace(
 				/xref:#([^[\]]+)\[([^\]]+)\]/g,
 				"[$2](#$1)",

scripts/process-mdx.js

@@ -101,7 +101,7 @@ async function processMdxFiles(directory) {
         "<Callout type='warn'>\n$2\n</Callout>",
       );
 
-      // Fix xref patterns with complex anchors like xref:#ISRC6-\\__execute__[...]
+      // Fix xref patterns with complex anchors like xref:#ISRC6-_execute__[...]
       content = content.replace(/xref:#([^[\]]+)\[([^\]]+)\]/g, "[$2](#$1)");
 
       // Fix simple xref patterns