OpenZeppelin · ericnordelo · Dec 12, 2025 · Dec 3, 2025
diff --git a/content/contracts-cairo/2.x/access.mdx b/content/contracts-cairo/2.x/access.mdx
@@ -474,12 +474,12 @@ Cairo field elements (`felt252`) store a maximum of 252 bits.
 With this discrepancy, this library maintains an agnostic stance on how contracts should create identifiers.
 Some ideas to consider:
 
-* Use [sn_keccak](https://docs.starknet.io/architecture-and-concepts/cryptography/#starknet_keccak) instead.
+* Use [sn_keccak](https://docs.starknet.io/learn/protocol/cryptography#starknet-keccak) instead.
 * Use Cairo friendly hashing algorithms like Poseidon, which are implemented in the
 [Cairo corelib](https://github.com/starkware-libs/cairo/blob/main/corelib/src/poseidon.cairo).
 
 <Callout>
-The `selector!` macro can be used to compute [sn_keccak](https://docs.starknet.io/architecture-and-concepts/cryptography/#starknet_keccak) in Cairo.
+The `selector!` macro can be used to compute [sn_keccak](https://docs.starknet.io/learn/protocol/cryptography#starknet-keccak) in Cairo.
 </Callout>
 
 ### Interface

diff --git a/content/contracts-cairo/2.x/accounts.mdx b/content/contracts-cairo/2.x/accounts.mdx
@@ -8,7 +8,7 @@ concept on Starknet.
 Instead, the network features native account abstraction and signature validation happens at the contract level.
 
 For a general overview of account abstraction, see
-[Starknet’s documentation](https://docs.starknet.io/architecture-and-concepts/accounts/introduction/).
+[Starknet’s documentation](https://docs.starknet.io/learn/protocol/accounts).
 A more detailed discussion on the topic can be found in
 [Starknet Shaman’s forum](https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781).
 
@@ -81,7 +81,7 @@ The Starknet protocol uses a few entrypoints for abstracting the accounts. We al
 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,
-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).
+but the entrypoint implementation can be customized to feature any validation mechanism [with some limitations](https://docs.starknet.io/learn/protocol/accounts#limitations).
 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.
@@ -94,7 +94,7 @@ Although these entrypoints are available to the protocol for its regular transac
 ## Starknet Account
 
 Starknet native account abstraction pattern allows for the creation of custom accounts with different validation schemes, but
-usually most account implementations validate transactions using the [Stark curve](https://docs.starknet.io/architecture-and-concepts/cryptography/#stark-curve) which is the most efficient way
+usually most account implementations validate transactions using the [Stark curve](https://docs.starknet.io/learn/protocol/cryptography#the-stark-curve) which is the most efficient way
 of validating signatures since it is a STARK-friendly curve.
 
 OpenZeppelin Contracts for Cairo provides [AccountComponent](/contracts-cairo/2.x/api/account#AccountComponent) for implementing this validation scheme.

diff --git a/content/contracts-cairo/2.x/api/account.mdx b/content/contracts-cairo/2.x/api/account.mdx
@@ -126,7 +126,7 @@ Get the status of a given nonce. `true` if the nonce is available to use.
 use openzeppelin_account::AccountComponent;
 ```
 
-Account component implementing [`ISRC6`](#ISRC6) for signatures over the [Starknet curve](https://docs.starknet.io/architecture-and-concepts/cryptography/#stark-curve).
+Account component implementing [`ISRC6`](#ISRC6) for signatures over the [Starknet curve](https://docs.starknet.io/learn/protocol/cryptography#the-stark-curve).
 
 Implementing [SRC5Component](./introspection#SRC5Component) is a requirement for this component to be implemented.
 
@@ -223,7 +223,7 @@ See [ISRC6::is\_valid\_signature](#ISRC6-is_valid_signature).
     id="AccountComponent-__validate_declare__"
     kind="external"
 >
-Validates a [`Declare` transaction](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/#declare-transaction).
+Validates a [`Declare` transaction](https://docs.starknet.io/learn/cheatsheets/transactions-reference#declare-v3).
 
 Returns the short string `'VALID'` if valid, otherwise it reverts.
 </APIItem>
@@ -233,7 +233,7 @@ Returns the short string `'VALID'` if valid, otherwise it reverts.
     id="AccountComponent-__validate_deploy__"
     kind="external"
 >
-Validates a [`DeployAccount` transaction](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/#deploy_account_transaction). See [Counterfactual Deployments](../guides/deployment).
+Validates a [`DeployAccount` transaction](https://docs.starknet.io/learn/cheatsheets/transactions-reference#deploy-account-v3). See [Counterfactual Deployments](../guides/deployment).
 
 Returns the short string `'VALID'` if valid, otherwise it reverts.
 </APIItem>
@@ -487,7 +487,7 @@ See [ISRC6::is\_valid\_signature](#ISRC6-is_valid_signature).
     id="EthAccountComponent-__validate_declare__"
     kind="external"
 >
-Validates a [`Declare` transaction](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/#declare-transaction).
+Validates a [`Declare` transaction](https://docs.starknet.io/learn/cheatsheets/transactions-reference#declare-v3).
 
 Returns the short string `'VALID'` if valid, otherwise it reverts.
 </APIItem>
@@ -497,7 +497,7 @@ Returns the short string `'VALID'` if valid, otherwise it reverts.
     id="EthAccountComponent-__validate_deploy__"
     kind="external"
 >
-Validates a [`DeployAccount` transaction](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/#deploy_account_transaction). See [Counterfactual Deployments](../guides/deployment).
+Validates a [`DeployAccount` transaction](https://docs.starknet.io/learn/cheatsheets/transactions-reference#deploy-account-v3). See [Counterfactual Deployments](../guides/deployment).
 
 Returns the short string `'VALID'` if valid, otherwise it reverts.
 </APIItem>

diff --git a/content/contracts-cairo/2.x/api/upgrades.mdx b/content/contracts-cairo/2.x/api/upgrades.mdx
@@ -29,7 +29,7 @@ Functions
   id="IUpgradeable-upgrade"
   kind="external"
 >
-Upgrades the contract code by updating its [class hash](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/).
+Upgrades the contract code by updating its [class hash](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/).
 
 This function is usually protected by an [Access Control](../access) mechanism.
 </APIItem>
@@ -55,7 +55,7 @@ Functions
   id="IUpgradeAndCall-upgrade_and_call"
   kind="external"
 >
-Upgrades the contract code by updating its [class hash](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/) and calls `selector` with the upgraded context.
+Upgrades the contract code by updating its [class hash](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/) and calls `selector` with the upgraded context.
 
 This function is usually protected by an [Access Control](../access) mechanism.
 </APIItem>
@@ -90,7 +90,7 @@ Events
   id="UpgradeableComponent-upgrade"
   kind="internal"
 >
-Upgrades the contract by updating the contract [class hash](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/).
+Upgrades the contract by updating the contract [class hash](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/).
 
 Requirements:
 
@@ -124,5 +124,5 @@ Emits an [Upgraded](#UpgradeableComponent-Upgraded) event.
   id="UpgradeableComponent-Upgraded"
   kind="event"
 >
-Emitted when the [class hash](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/) is upgraded.
+Emitted when the [class hash](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/) is upgraded.
 </APIItem>
diff --git a/content/contracts-cairo/2.x/api/utilities.mdx b/content/contracts-cairo/2.x/api/utilities.mdx
@@ -113,7 +113,7 @@ See [`openzeppelin_utils::cryptography::snip12`](#snip12).
 use openzeppelin_utils::deployments;
 ```
 
-Module containing utility functions for calculating contract addresses through [deploy\_syscall](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#deploy) and the [Universal Deployer Contract](../udc) (UDC).
+Module containing utility functions for calculating contract addresses through [deploy\_syscall](https://docs.starknet.io/build/corelib/core-starknet-syscalls-deploy_syscall#core-starknet-syscalls-deploy-syscall) and the [Universal Deployer Contract](../udc) (UDC).
 
 Members
 
@@ -144,7 +144,7 @@ Struct containing arguments necessary in [utils::calculate\_contract\_address\_f
   id="deployments-calculate_contract_address_from_deploy_syscall"
   kind="function"
 >
-Returns the contract address when passing the given arguments to [deploy\_syscall](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#deploy).
+Returns the contract address when passing the given arguments to [deploy\_syscall](https://docs.starknet.io/build/corelib/core-starknet-syscalls-deploy_syscall#core-starknet-syscalls-deploy-syscall).
 </APIItem>
 
 <APIItem
@@ -164,7 +164,7 @@ Returns the calculated contract address for UDC deployments.
 
 Origin-independent deployments (deployed from zero) should pass `Option::None` as `deployer_info`.
 
-Origin-dependent deployments hash `salt` with `caller_address` (member of [DeployerInfo](#deployments-DeployerInfo)) and pass the hashed salt to the inner [deploy\_syscall](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#deploy) as the `contract_address_salt` argument.
+Origin-dependent deployments hash `salt` with `caller_address` (member of [DeployerInfo](#deployments-DeployerInfo)) and pass the hashed salt to the inner [deploy\_syscall](https://docs.starknet.io/build/corelib/core-starknet-syscalls-deploy_syscall#core-starknet-syscalls-deploy-syscall) as the `contract_address_salt` argument.
 </APIItem>
 
 ### `math` [toc] [#math]

diff --git a/content/contracts-cairo/2.x/presets.mdx b/content/contracts-cairo/2.x/presets.mdx
@@ -11,7 +11,7 @@ For contract customization and combination of modules you can use [Wizard for Ca
 
 ## Available presets
 
-List of available presets and their corresponding [Sierra class hashes](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/). Like Contracts for Cairo,
+List of available presets and their corresponding [Sierra class hashes](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/). Like Contracts for Cairo,
 use of preset contracts are subject to the terms of the
 [MIT License](https://github.com/OpenZeppelin/cairo-contracts?tab=MIT-1-ov-file#readme).
 

diff --git a/content/contracts-cairo/2.x/udc.mdx b/content/contracts-cairo/2.x/udc.mdx
@@ -2,7 +2,7 @@
 title: Universal Deployer Contract
 ---
 
-The Universal Deployer Contract (UDC) is a singleton smart contract that wraps the [deploy syscall](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#deploy) to expose it to any contract that doesn’t implement it, such as account contracts. You can think of it as a standardized generic factory for Starknet contracts.
+The Universal Deployer Contract (UDC) is a singleton smart contract that wraps the [deploy syscall](https://docs.starknet.io/build/corelib/core-starknet-syscalls-deploy_syscall#core-starknet-syscalls-deploy-syscall) to expose it to any contract that doesn’t implement it, such as account contracts. You can think of it as a standardized generic factory for Starknet contracts.
 
 Since Starknet has no deployment transaction type, it offers a standardized way to deploy smart contracts by following the [Standard Deployer Interface](https://community.starknet.io/t/snip-deployer-contract-interface/2772) and emitting a [ContractDeployed](/contracts-cairo/2.x/api/udc#IUniversalDeployer-ContractDeployed) event.
 
@@ -28,7 +28,7 @@ pub trait IUniversalDeployer {
 
 ## Deploying a contract with the UDC
 
-First, [declare](https://docs.starknet.io/architecture-and-concepts/network-architecture/transactions/#declare-transaction) the target contract (if it’s not already declared).
+First, [declare](https://docs.starknet.io/learn/cheatsheets/transactions-reference#declare-v3) the target contract (if it’s not already declared).
 Next, call the UDC’s `deploy_contract` method.
 Here’s an implementation example in Cairo:
 
@@ -99,7 +99,7 @@ let deployed_addr = udc.deploy_contract(class_hash, salt, false, calldata.span()
 ## Version changes
 
 <Callout>
-See the [previous Universal Deployer API](https://docs.starknet.io/architecture-and-concepts/accounts/#using-the-universal-deployer-contract) for the initial spec.
+See the [previous Universal Deployer API](https://docs.starknet.io/learn/protocol/accounts#deploying-a-new-account) for the initial spec.
 </Callout>
 
 The latest iteration of the UDC includes some notable changes to the API which include:

diff --git a/content/contracts-cairo/2.x/upgrades.mdx b/content/contracts-cairo/2.x/upgrades.mdx
@@ -14,14 +14,14 @@ Make sure you follow [our security recommendations](#security) before upgrading.
 
 To better comprehend how upgradeability works in Starknet, it’s important to understand the difference between a contract and its contract class.
 
-[Contract Classes](https://docs.starknet.io/architecture-and-concepts/smart-contracts/contract-classes/) represent the source code of a program. All
+[Contract Classes](https://docs.starknet.io/build/starknet-by-example/applications/upgradeable-contract#upgradeable-contract) represent the source code of a program. All
 contracts are associated to a class, and many contracts can be instances of the same one. Classes are usually represented by
-a [class hash](https://docs.starknet.io/architecture-and-concepts/smart-contracts/class-hash/), and before a contract of a class can be deployed,
+a [class hash](https://docs.starknet.io/build/starknet-by-example/applications/factory#class-hash-and-contract-instance/), and before a contract of a class can be deployed,
 the class hash needs to be declared.
 
 ### `replace_class_syscall`
 
-The `[replace_class](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#replace_class)` syscall allows a contract to
+The `[replace_class](https://docs.starknet.io/build/corelib/core-starknet-syscalls-replace_class_syscall#core-starknet-syscalls-replace-class-syscall)` syscall allows a contract to
 update its source code by replacing its class hash once deployed.
 
 ```rust
@@ -34,7 +34,7 @@ fn upgrade(new_class_hash: ClassHash) {
 ```
 
 <Callout>
-If a contract is deployed without this mechanism, its class hash can still be replaced through [library calls](https://docs.starknet.io/architecture-and-concepts/smart-contracts/system-calls-cairo1/#library_call).
+If a contract is deployed without this mechanism, its class hash can still be replaced through [library calls](https://docs.starknet.io/build/starknet-by-example/advanced/library-calls#library-calls).
 </Callout>
 
 ## `Upgradeable` component

diff --git a/content/contracts-cairo/alpha/access.mdx b/content/contracts-cairo/alpha/access.mdx
@@ -476,12 +476,12 @@ Cairo field elements (`felt252`) store a maximum of 252 bits.
 With this discrepancy, this library maintains an agnostic stance on how contracts should create identifiers.
 Some ideas to consider:
 
-* Use [sn_keccak](https://docs.starknet.io/architecture-and-concepts/cryptography/#starknet_keccak) instead.
+* Use [sn_keccak](https://docs.starknet.io/learn/protocol/cryptography#starknet-keccak) instead.
 * Use Cairo friendly hashing algorithms like Poseidon, which are implemented in the
 [Cairo corelib](https://github.com/starkware-libs/cairo/blob/main/corelib/src/poseidon.cairo).
 
 <Callout>
-The `selector!` macro can be used to compute [sn_keccak](https://docs.starknet.io/architecture-and-concepts/cryptography/#starknet_keccak) in Cairo.
+The `selector!` macro can be used to compute [sn_keccak](https://docs.starknet.io/learn/protocol/cryptography#starknet-keccak) in Cairo.
 </Callout>
 
 ### Interface

diff --git a/content/contracts-cairo/alpha/accounts.mdx b/content/contracts-cairo/alpha/accounts.mdx
@@ -8,7 +8,7 @@ concept on Starknet.
 Instead, the network features native account abstraction and signature validation happens at the contract level.
 
 For a general overview of account abstraction, see
-[Starknet’s documentation](https://docs.starknet.io/architecture-and-concepts/accounts/introduction/).
+[Starknet’s documentation](https://docs.starknet.io/learn/protocol/accounts).
 A more detailed discussion on the topic can be found in
 [Starknet Shaman’s forum](https://community.starknet.io/t/starknet-account-abstraction-model-part-1/781).
 
@@ -81,7 +81,7 @@ The Starknet protocol uses a few entrypoints for abstracting the accounts. We al
 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,
-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).
+but the entrypoint implementation can be customized to feature any validation mechanism [with some limitations](https://docs.starknet.io/learn/protocol/accounts#limitations).
 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.
@@ -94,7 +94,7 @@ Although these entrypoints are available to the protocol for its regular transac
 ## Starknet Account
 
 Starknet native account abstraction pattern allows for the creation of custom accounts with different validation schemes, but
-usually most account implementations validate transactions using the [Stark curve](https://docs.starknet.io/architecture-and-concepts/cryptography/#stark-curve) which is the most efficient way
+usually most account implementations validate transactions using the [Stark curve](https://docs.starknet.io/learn/protocol/cryptography#the-stark-curve) which is the most efficient way
 of validating signatures since it is a STARK-friendly curve.
 
 OpenZeppelin Contracts for Cairo provides [AccountComponent](/contracts-cairo/alpha/api/account#AccountComponent) for implementing this validation scheme.