diff --git a/content/contracts-cairo/2.x/wizard.mdx b/content/contracts-cairo/2.x/wizard.mdx
index 84f581f5..7b07a3a3 100644
--- a/content/contracts-cairo/2.x/wizard.mdx
+++ b/content/contracts-cairo/2.x/wizard.mdx
@@ -9,4 +9,6 @@ contract and learn about the components offered in OpenZeppelin Contracts for Ca
We strongly recommend checking the [Components](./components) section to understand how to extend from our library.
-
+import { UMBRELLA_VERSION } from "./utils/constants.js";
+
+
diff --git a/content/contracts-cairo/alpha/access.mdx b/content/contracts-cairo/3.x/access.mdx
similarity index 91%
rename from content/contracts-cairo/alpha/access.mdx
rename to content/contracts-cairo/3.x/access.mdx
index cf78465c..6defd17b 100644
--- a/content/contracts-cairo/alpha/access.mdx
+++ b/content/contracts-cairo/3.x/access.mdx
@@ -13,13 +13,13 @@ The most common and basic form of access control is the concept of ownership: th
of a contract and can do administrative tasks on it.
This approach is perfectly reasonable for contracts that have a single administrative user.
-OpenZeppelin Contracts for Cairo provides [OwnableComponent](/contracts-cairo/alpha/api/access#OwnableComponent) for implementing ownership in your contracts.
+OpenZeppelin Contracts for Cairo provides [OwnableComponent](/contracts-cairo/3.x/api/access#OwnableComponent) for implementing ownership in your contracts.
### Usage
Integrating this component into a contract first requires assigning an owner.
The implementing contract’s constructor should set the initial owner by passing the owner’s address to Ownable’s
-[`initializer`](/contracts-cairo/alpha/api/access#OwnableComponent-initializer) like this:
+[`initializer`](/contracts-cairo/3.x/api/access#OwnableComponent-initializer) like this:
```rust
#[starknet::contract]
@@ -106,7 +106,7 @@ will no longer be callable!
### Two step transfer
The component also offers a more robust way of transferring ownership via the
-[OwnableTwoStepImpl](/contracts-cairo/alpha/api/access#OwnableComponent-Embeddable-Impls-OwnableTwoStepImpl) implementation. A two step transfer mechanism helps
+[OwnableTwoStepImpl](/contracts-cairo/3.x/api/access#OwnableComponent-Embeddable-Impls-OwnableTwoStepImpl) implementation. A two step transfer mechanism helps
to prevent unintended and irreversible owner transfers. Simply replace the `OwnableMixinImpl`
with its respective two step variant:
@@ -146,7 +146,7 @@ flexibility in this regard.
In essence, we will be defining multiple roles, each allowed to perform different sets of actions.
An account may have, for example, 'moderator', 'minter' or 'admin' roles, which you will then check for
-instead of simply using [`assert_only_owner`](/contracts-cairo/alpha/api/access#OwnableComponent-assert_only_owner). This check can be enforced through [`assert_only_role`](/contracts-cairo/alpha/api/access#AccessControlComponent-assert_only_role).
+instead of simply using [`assert_only_owner`](/contracts-cairo/3.x/api/access#OwnableComponent-assert_only_owner). This check can be enforced through [`assert_only_role`](/contracts-cairo/3.x/api/access#AccessControlComponent-assert_only_role).
Separately, you will be able to define rules for how accounts can be granted a role, have it revoked, and more.
Most software uses access control systems that are role-based: some users are regular users, some may be supervisors
@@ -158,7 +158,7 @@ For each role that you want to define, you will create a new _role identifier_ t
check if an account has that role. See [Creating role identifiers](#creating-role-identifiers) for information
on creating identifiers.
-Here’s a simple example of implementing [AccessControl](/contracts-cairo/alpha/api/access#AccessControlComponent) on a portion of an ERC20 token contract which defines
+Here’s a simple example of implementing [AccessControl](/contracts-cairo/3.x/api/access#AccessControlComponent) on a portion of an ERC20 token contract which defines
and sets a 'minter' role:
```rust
@@ -242,12 +242,12 @@ mod MyContract {
```
-Make sure you fully understand how [AccessControl](/contracts-cairo/alpha/api/access#AccessControlComponent) works before
+Make sure you fully understand how [AccessControl](/contracts-cairo/3.x/api/access#AccessControlComponent) works before
using it on your system, or copy-pasting the examples from this guide.
While clear and explicit, this isn’t anything we wouldn’t have been able to achieve with
-[Ownable](/contracts-cairo/alpha/api/access#OwnableComponent). Where [AccessControl](/contracts-cairo/alpha/api/access#AccessControlComponent) shines the most is in scenarios where granular
+[Ownable](/contracts-cairo/3.x/api/access#OwnableComponent). Where [AccessControl](/contracts-cairo/3.x/api/access#AccessControlComponent) shines the most is in scenarios where granular
permissions are required, which can be implemented by defining _multiple_ roles.
Let’s augment our ERC20 token example by also defining a 'burner' role, which lets accounts destroy tokens:
@@ -350,16 +350,16 @@ security practice. Note that each account may still have more than one role, if
### Granting and revoking roles
-The ERC20 token example above uses [`_grant_role`](/contracts-cairo/alpha/api/access#AccessControlComponent-_grant_role),
+The ERC20 token example above uses [`_grant_role`](/contracts-cairo/3.x/api/access#AccessControlComponent-_grant_role),
an `internal` function that is useful when programmatically assigning
roles (such as during construction). But what if we later want to grant the 'minter' role to additional accounts?
By default, **accounts with a role cannot grant it or revoke it from other accounts**: all having a role does is making
-the [`assert_only_role`](/contracts-cairo/alpha/api/access#AccessControlComponent-assert_only_role) check pass. To grant and revoke roles dynamically, you will need help from the role’s _admin_.
+the [`assert_only_role`](/contracts-cairo/3.x/api/access#AccessControlComponent-assert_only_role) check pass. To grant and revoke roles dynamically, you will need help from the role’s _admin_.
Every role has an associated admin role, which grants permission to call the
-[`grant_role`](/contracts-cairo/alpha/api/access#AccessControlComponent-grant_role) and
-[`revoke_role`](/contracts-cairo/alpha/api/access#AccessControlComponent-revoke_role) functions.
+[`grant_role`](/contracts-cairo/3.x/api/access#AccessControlComponent-grant_role) and
+[`revoke_role`](/contracts-cairo/3.x/api/access#AccessControlComponent-revoke_role) functions.
A role can be granted or revoked by using these if the calling account has the corresponding admin role.
Multiple roles may have the same admin role to make management easier.
A role’s admin can even be the same role itself, which would cause accounts with that role to be able
@@ -369,9 +369,9 @@ This mechanism can be used to create complex permissioning structures resembling
provides an easy way to manage simpler applications. `AccessControl` includes a special role with the role identifier
of `0`, called `DEFAULT_ADMIN_ROLE`, which acts as the **default admin role for all roles**.
An account with this role will be able to manage any other role, unless
-[`set_role_admin`](/contracts-cairo/alpha/api/access#AccessControlComponent-set_role_admin) is used to select a new admin role.
+[`set_role_admin`](/contracts-cairo/3.x/api/access#AccessControlComponent-set_role_admin) is used to select a new admin role.
-Since it is the admin for all roles by default, and in fact it is also its own admin, this role carries significant risk. To mitigate this risk we provide [AccessControlDefaultAdminRules](/contracts-cairo/alpha/api/access#AccessControlDefaultAdminRulesComponent), a recommended extension of AccessControl that adds a number of enforced security measures for this role: the admin is restricted to a single account, with a 2-step transfer procedure with a delay in between steps.
+Since it is the admin for all roles by default, and in fact it is also its own admin, this role carries significant risk. To mitigate this risk we provide [AccessControlDefaultAdminRules](/contracts-cairo/3.x/api/access#AccessControlDefaultAdminRulesComponent), a recommended extension of AccessControl that adds a number of enforced security measures for this role: the admin is restricted to a single account, with a 2-step transfer procedure with a delay in between steps.
Let’s take a look at the ERC20 token example, this time taking advantage of the default admin role:
diff --git a/content/contracts-cairo/alpha/accounts.mdx b/content/contracts-cairo/3.x/accounts.mdx
similarity index 96%
rename from content/contracts-cairo/alpha/accounts.mdx
rename to content/contracts-cairo/3.x/accounts.mdx
index b699c4b9..32c4927f 100644
--- a/content/contracts-cairo/alpha/accounts.mdx
+++ b/content/contracts-cairo/3.x/accounts.mdx
@@ -13,7 +13,7 @@ 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).
-For detailed information on the usage and implementation check the [API Reference](/contracts-cairo/alpha/api/account) section.
+For detailed information on the usage and implementation check the [API Reference](/contracts-cairo/3.x/api/account) section.
## What is an account?
@@ -97,11 +97,11 @@ Starknet native account abstraction pattern allows for the creation of custom ac
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.
+OpenZeppelin Contracts for Cairo provides [AccountComponent](/contracts-cairo/3.x/api/account#AccountComponent) for implementing this validation scheme.
### Usage
-Constructing an account contract requires integrating both [AccountComponent](/contracts-cairo/alpha/api/account#AccountComponent) and [SRC5Component](/contracts-cairo/alpha/api/introspection#SRC5Component). The contract should also set up the constructor to initialize the public key that will be used as the account’s signer. Here’s an example of a basic contract:
+Constructing an account contract requires integrating both [AccountComponent](/contracts-cairo/3.x/api/account#AccountComponent) and [SRC5Component](/contracts-cairo/3.x/api/introspection#SRC5Component). The contract should also set up the constructor to initialize the public key that will be used as the account’s signer. Here’s an example of a basic contract:
```rust
#[starknet::contract(account)]
@@ -180,11 +180,11 @@ pub trait AccountABI {
## Ethereum Account
Besides the Stark-curve account, OpenZeppelin Contracts for Cairo also offers Ethereum-flavored accounts that use the [secp256k1](https://en.bitcoin.it/wiki/Secp256k1) curve for signature validation.
-For this the [EthAccountComponent](/contracts-cairo/alpha/api/account#EthAccountComponent) must be used.
+For this the [EthAccountComponent](/contracts-cairo/3.x/api/account#EthAccountComponent) must be used.
### Usage
-Constructing a secp256k1 account contract also requires integrating both [EthAccountComponent](/contracts-cairo/alpha/api/account#EthAccountComponent) and [SRC5Component](/contracts-cairo/alpha/api/introspection#SRC5Component).
+Constructing a secp256k1 account contract also requires integrating both [EthAccountComponent](/contracts-cairo/3.x/api/account#EthAccountComponent) and [SRC5Component](/contracts-cairo/3.x/api/introspection#SRC5Component).
The contract should also set up the constructor to initialize the public key that will be used as the account’s signer.
Here’s an example of a basic contract:
diff --git a/content/contracts-cairo/alpha/api/access.mdx b/content/contracts-cairo/3.x/api/access.mdx
similarity index 97%
rename from content/contracts-cairo/alpha/api/access.mdx
rename to content/contracts-cairo/3.x/api/access.mdx
index 002a41fb..5cfacba1 100644
--- a/content/contracts-cairo/alpha/api/access.mdx
+++ b/content/contracts-cairo/3.x/api/access.mdx
@@ -241,6 +241,7 @@ Functions
- [`change_default_admin_delay(new_delay)`](#IAccessControlDefaultAdminRules-change_default_admin_delay)
- [`rollback_default_admin_delay()`](#IAccessControlDefaultAdminRules-rollback_default_admin_delay)
- [`default_admin_delay_increase_wait()`](#IAccessControlDefaultAdminRules-default_admin_delay_increase_wait)
+- [`maximum_default_admin_transfer_delay()`](#IAccessControlDefaultAdminRules-maximum_default_admin_transfer_delay)
Events
@@ -401,11 +402,25 @@ May emit a [DefaultAdminDelayChangeCanceled](#IAccessControlDefaultAdminRules-De
id="IAccessControlDefaultAdminRules-default_admin_delay_increase_wait"
kind="external"
>
-Maximum time in seconds for an increase to [default\_admin\_delay](#IAccessControlDefaultAdminRules-default_admin_delay) (that is scheduled using [change\_default\_admin\_delay](#IAccessControlDefaultAdminRules-change_default_admin_delay)) to take effect. Defaults to 5 days.
-
-When the [default\_admin\_delay](#IAccessControlDefaultAdminRules-default_admin_delay) is scheduled to be increased, it goes into effect after the new delay has passed with the purpose of giving enough time for reverting any accidental change (i.e. using milliseconds instead of seconds) that may lock the contract. However, to avoid excessive schedules, the wait is capped by this function and it can be overridden for a custom [default\_admin\_delay](#IAccessControlDefaultAdminRules-default_admin_delay) increase scheduling.
+Maximum time in seconds for an increase to [default\_admin\_delay](#IAccessControlDefaultAdminRules-default_admin_delay) (that is scheduled using [change\_default\_admin\_delay](#IAccessControlDefaultAdminRules-change_default_admin_delay)) to take effect.
+
Make sure to add a reasonable amount of time while overriding this value, otherwise, there’s a risk of setting a high new delay that goes into effect almost immediately without the possibility of human intervention in the case of an input error (e.g. set milliseconds instead of seconds).
+
+
+Consider carefully the value set for `MAXIMUM_DEFAULT_ADMIN_TRANSFER_DELAY` too, since it will affect how fast you can recover from an accidental delay increase.
+
+
+
+Maximum time in seconds for a `default_admin` transfer delay.
+
+
+If `MAXIMUM_DEFAULT_ADMIN_TRANSFER_DELAY` is set too high, you might be unable to recover from an accidental delay increase for an extended period. Too low, and it unnecessarily restricts how much security delay you can impose for `default_admin` transfers. As a best practice, consider setting it in the 30-60 day range for a good balance between security and recoverability.
+
#### Events [!toc] [#IAccessControlDefaultAdminRules-Events]
@@ -1148,6 +1163,7 @@ Embeddable Implementations
- [`change_default_admin_delay(self, new_delay)`](#IAccessControlDefaultAdminRules-change_default_admin_delay)
- [`rollback_default_admin_delay(self)`](#IAccessControlDefaultAdminRules-rollback_default_admin_delay)
- [`default_admin_delay_increase_wait(self)`](#IAccessControlDefaultAdminRules-default_admin_delay_increase_wait)
+- [`maximum_default_admin_transfer_delay(self)`](#IAccessControlDefaultAdminRules-maximum_default_admin_transfer_delay)
#### AccessControlImpl [!toc] [#AccessControlDefaultAdminRulesComponent-Embeddable-Impls-AccessControlImpl]
@@ -1368,6 +1384,18 @@ Make sure to add a reasonable amount of time while overriding this value, otherw
+
+Maximum time in seconds for a `default_admin` transfer delay.
+
+
+If `MAXIMUM_DEFAULT_ADMIN_TRANSFER_DELAY` is set too high, you might be unable to recover from an accidental delay increase for an extended period. Too low, and it unnecessarily restricts how much security delay you can impose for `default_admin` transfers. As a best practice, consider setting it in the 30-60 day range for a good balance between security and recoverability.
+
+
+
@@ -1688,6 +1691,7 @@ Cast a vote with a `reason`.
Requirements:
- The proposal must be active.
+- The current timepoint must be greater than the proposal's snapshot timepoint.
Emits a [VoteCast](#GovernorComponent-VoteCast) event.
@@ -1702,6 +1706,7 @@ Cast a vote with a `reason` and additional serialized `params`.
Requirements:
- The proposal must be active.
+- The current timepoint must be greater than the proposal's snapshot timepoint.
Emits either:
@@ -1719,6 +1724,7 @@ Cast a vote using the `voter`'s signature.
Requirements:
- The proposal must be active.
+- The current timepoint must be greater than the proposal's snapshot timepoint.
- The nonce in the signed message must match the account's current nonce.
- `voter` must implement `SRC6::is_valid_signature`.
- `signature` must be valid for the message hash.
@@ -1736,6 +1742,7 @@ Cast a vote with a `reason` and additional serialized `params` using the `voter`
Requirements:
- The proposal must be active.
+- The current timepoint must be greater than the proposal's snapshot timepoint.
- The nonce in the signed message must match the account's current nonce.
- `voter` must implement `SRC6::is_valid_signature`.
- `signature` must be valid for the message hash.
diff --git a/content/contracts-cairo/alpha/api/introspection.mdx b/content/contracts-cairo/3.x/api/introspection.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/introspection.mdx
rename to content/contracts-cairo/3.x/api/introspection.mdx
diff --git a/content/contracts-cairo/alpha/api/merkle-tree.mdx b/content/contracts-cairo/3.x/api/merkle-tree.mdx
similarity index 99%
rename from content/contracts-cairo/alpha/api/merkle-tree.mdx
rename to content/contracts-cairo/3.x/api/merkle-tree.mdx
index 5772e073..85f623a1 100644
--- a/content/contracts-cairo/alpha/api/merkle-tree.mdx
+++ b/content/contracts-cairo/3.x/api/merkle-tree.mdx
@@ -15,7 +15,7 @@ This module provides:
To use it as a standalone package, you can add it in your `Scarb.toml` as follows:
-`openzeppelin_merkle_tree = "3.0.0-alpha.1"`
+`openzeppelin_merkle_tree = "3.0.0"`
## [](#modules)Modules
diff --git a/content/contracts-cairo/alpha/api/security.mdx b/content/contracts-cairo/3.x/api/security.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/security.mdx
rename to content/contracts-cairo/3.x/api/security.mdx
diff --git a/content/contracts-cairo/alpha/api/testing.mdx b/content/contracts-cairo/3.x/api/testing.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/testing.mdx
rename to content/contracts-cairo/3.x/api/testing.mdx
diff --git a/content/contracts-cairo/alpha/api/token_common.mdx b/content/contracts-cairo/3.x/api/token_common.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/token_common.mdx
rename to content/contracts-cairo/3.x/api/token_common.mdx
diff --git a/content/contracts-cairo/alpha/api/udc.mdx b/content/contracts-cairo/3.x/api/udc.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/udc.mdx
rename to content/contracts-cairo/3.x/api/udc.mdx
diff --git a/content/contracts-cairo/alpha/api/upgrades.mdx b/content/contracts-cairo/3.x/api/upgrades.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/api/upgrades.mdx
rename to content/contracts-cairo/3.x/api/upgrades.mdx
diff --git a/content/contracts-cairo/alpha/api/utilities.mdx b/content/contracts-cairo/3.x/api/utilities.mdx
similarity index 99%
rename from content/contracts-cairo/alpha/api/utilities.mdx
rename to content/contracts-cairo/3.x/api/utilities.mdx
index 6a6380a5..e63ad2ac 100644
--- a/content/contracts-cairo/alpha/api/utilities.mdx
+++ b/content/contracts-cairo/3.x/api/utilities.mdx
@@ -275,6 +275,8 @@ Returns the current timepoint determined by the contract's operational mode, int
Requirements:
- This function MUST always be non-decreasing.
+
+While this function returns a u64 value, timepoints must fit into u48 according to the EIP-6372 specification.
-Here’s an example of how to use the Immutable Component Config pattern with the [ERC2981Component](/contracts-cairo/alpha/api/token_common#erc2981component):
+Here’s an example of how to use the Immutable Component Config pattern with the [ERC2981Component](/contracts-cairo/3.x/api/token_common#erc2981component):
```rust
#[starknet::contract]
@@ -393,7 +393,7 @@ on how to use this function, refer to the [validate section of the SRC-107](http
Some components include dependencies of other components.
Contracts that integrate components with dependencies must also include the component dependency.
-For instance, [AccessControlComponent](/contracts-cairo/alpha/api/access#accesscontrolcomponent) depends on [SRC5Component](/contracts-cairo/alpha/api/introspection#src5component).
+For instance, [AccessControlComponent](/contracts-cairo/3.x/api/access#accesscontrolcomponent) depends on [SRC5Component](/contracts-cairo/3.x/api/introspection#src5component).
Creating a contract with `AccessControlComponent` should look like this:
```rust
@@ -567,7 +567,7 @@ mod ERC20Pausable {
The first thing to notice is that the contract imports the interfaces of the implementations that will be customized.
These will be used in the next code example.
-Next, the contract includes the [ERC20Component](/contracts-cairo/alpha/api/erc20#erc20component) implementations; however, `ERC20Impl` and `ERC20CamelOnlyImpl` are **not** embedded.
+Next, the contract includes the [ERC20Component](/contracts-cairo/3.x/api/erc20#erc20component) implementations; however, `ERC20Impl` and `ERC20CamelOnlyImpl` are **not** embedded.
Instead, we want to expose our custom implementation of an interface.
The following example shows the pausable logic integrated into the ERC20 implementations:
diff --git a/content/contracts-cairo/alpha/erc1155.mdx b/content/contracts-cairo/3.x/erc1155.mdx
similarity index 79%
rename from content/contracts-cairo/alpha/erc1155.mdx
rename to content/contracts-cairo/3.x/erc1155.mdx
index 45ed4c4a..5dafa923 100644
--- a/content/contracts-cairo/alpha/erc1155.mdx
+++ b/content/contracts-cairo/3.x/erc1155.mdx
@@ -2,17 +2,17 @@
title: ERC1155
---
-The ERC1155 multi-token standard is a specification for [fungibility-agnostic](https://docs.openzeppelin.com/contracts/5.x/tokens#different-kinds-of-tokens) token contracts.
+The ERC1155 multi-token standard is a specification for [fungibility-agnostic](https://docs.openzeppelin.com/contracts/3.x/tokens#different-kinds-of-tokens) token contracts.
The ERC1155 library implements an approximation of [EIP-1155](https://eips.ethereum.org/EIPS/eip-1155) in Cairo for StarkNet.
## Multi Token Standard
The distinctive feature of ERC1155 is that it uses a single smart contract to represent multiple tokens at once. This
-is why its [balance_of](/contracts-cairo/alpha/api/erc1155#IERC1155-balance_of) function differs from ERC20’s and ERC777’s: it has an additional ID argument for the
+is why its [balance_of](/contracts-cairo/3.x/api/erc1155#IERC1155-balance_of) function differs from ERC20’s and ERC777’s: it has an additional ID argument for the
identifier of the token that you want to query the balance of.
This is similar to how ERC721 does things, but in that standard a token ID has no concept of balance: each token is
-non-fungible and exists or doesn’t. The ERC721 [balance_of](/contracts-cairo/alpha/api/erc721#IERC721-balance_of) function refers to how many different tokens an account
+non-fungible and exists or doesn’t. The ERC721 [balance_of](/contracts-cairo/3.x/api/erc721#IERC721-balance_of) function refers to how many different tokens an account
has, not how many of each. On the other hand, in ERC1155 accounts have a distinct balance for each token ID, and
non-fungible tokens are implemented by simply minting a single one of them.
@@ -76,8 +76,8 @@ mod MyERC1155 {
## Interface
-The following interface represents the full ABI of the Contracts for Cairo [ERC1155Component](/contracts-cairo/alpha/api/erc1155#ERC1155Component).
-The interface includes the [IERC1155](/contracts-cairo/alpha/api/erc1155#IERC1155) standard interface and the optional [IERC1155MetadataURI](/contracts-cairo/alpha/api/erc1155#IERC1155MetadataURI) interface together with [ISRC5](/contracts-cairo/alpha/api/introspection#ISRC5).
+The following interface represents the full ABI of the Contracts for Cairo [ERC1155Component](/contracts-cairo/3.x/api/erc1155#ERC1155Component).
+The interface includes the [IERC1155](/contracts-cairo/3.x/api/erc1155#IERC1155) standard interface and the optional [IERC1155MetadataURI](/contracts-cairo/3.x/api/erc1155#IERC1155MetadataURI) interface together with [ISRC5](/contracts-cairo/3.x/api/introspection#ISRC5).
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.
@@ -148,13 +148,13 @@ Although Starknet is not EVM compatible, this implementation aims to be as close
## Batch operations
-Because all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, [balance_of_batch](/contracts-cairo/alpha/api/erc1155#IERC1155-balance_of_batch) and [safe_batch_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_batch_transfer_from), that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive. We also have [safe_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_transfer_from) for non-batch operations.
+Because all state is held in a single contract, it is possible to operate over multiple tokens in a single transaction very efficiently. The standard provides two functions, [balance_of_batch](/contracts-cairo/3.x/api/erc1155#IERC1155-balance_of_batch) and [safe_batch_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_batch_transfer_from), that make querying multiple balances and transferring multiple tokens simpler and less gas-intensive. We also have [safe_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_transfer_from) for non-batch operations.
In the spirit of the standard, we’ve also included batch operations in the non-standard functions, such as
-[batch_mint_with_acceptance_check](/contracts-cairo/alpha/api/erc1155#ERC1155Component-batch_mint_with_acceptance_check).
+[batch_mint_with_acceptance_check](/contracts-cairo/3.x/api/erc1155#ERC1155Component-batch_mint_with_acceptance_check).
-While [safe_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_transfer_from) and [safe_batch_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_batch_transfer_from) prevent loss by checking the receiver can handle the
+While [safe_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_transfer_from) and [safe_batch_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_batch_transfer_from) prevent loss by checking the receiver can handle the
tokens, this yields execution to the receiver which can result in a [reentrant call](./security#reentrancy-guard).
@@ -185,8 +185,8 @@ pub trait IERC1155Receiver {
}
```
-Implementing the `IERC1155Receiver` interface exposes the [on_erc1155_received](/contracts-cairo/alpha/api/erc1155#IERC1155Receiver-on_erc1155_received) and [on_erc1155_batch_received](/contracts-cairo/alpha/api/erc1155#IERC1155Receiver-on_erc1155_batch_received) methods.
-When [safe_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_transfer_from) and [safe_batch_transfer_from](/contracts-cairo/alpha/api/erc1155#IERC1155-safe_batch_transfer_from) are called, they invoke the recipient contract’s `on_erc1155_received` or `on_erc1155_batch_received` methods respectively which **must** return the [IERC1155Receiver interface ID](/contracts-cairo/alpha/api/erc1155#IERC1155Receiver).
+Implementing the `IERC1155Receiver` interface exposes the [on_erc1155_received](/contracts-cairo/3.x/api/erc1155#IERC1155Receiver-on_erc1155_received) and [on_erc1155_batch_received](/contracts-cairo/3.x/api/erc1155#IERC1155Receiver-on_erc1155_batch_received) methods.
+When [safe_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_transfer_from) and [safe_batch_transfer_from](/contracts-cairo/3.x/api/erc1155#IERC1155-safe_batch_transfer_from) are called, they invoke the recipient contract’s `on_erc1155_received` or `on_erc1155_batch_received` methods respectively which **must** return the [IERC1155Receiver interface ID](/contracts-cairo/3.x/api/erc1155#IERC1155Receiver).
Otherwise, the transaction will fail.
diff --git a/content/contracts-cairo/alpha/erc20.mdx b/content/contracts-cairo/3.x/erc20.mdx
similarity index 96%
rename from content/contracts-cairo/alpha/erc20.mdx
rename to content/contracts-cairo/3.x/erc20.mdx
index 4c0c5ba1..389c138d 100644
--- a/content/contracts-cairo/alpha/erc20.mdx
+++ b/content/contracts-cairo/3.x/erc20.mdx
@@ -2,7 +2,7 @@
title: ERC20
---
-The ERC20 token standard is a specification for [fungible tokens](https://docs.openzeppelin.com/contracts/4.x/tokens#different-kinds-of-tokens), a type of token where all the units are exactly equal to each other.
+The ERC20 token standard is a specification for [fungible tokens](https://docs.openzeppelin.com/contracts/3.x/tokens#different-kinds-of-tokens), a type of token where all the units are exactly equal to each other.
`token::erc20::ERC20Component` provides an approximation of [EIP-20](https://eips.ethereum.org/EIPS/eip-20) in Cairo for Starknet.
@@ -68,8 +68,8 @@ For a more complete guide on ERC20 token mechanisms, see [Creating ERC20 Supply]
## Interface
-The following interface represents the full ABI of the Contracts for Cairo [ERC20Component](/contracts-cairo/alpha/api/erc20#ERC20Component).
-The interface includes the [IERC20](/contracts-cairo/alpha/api/erc20#IERC20) standard interface as well as the optional [IERC20Metadata](/contracts-cairo/alpha/api/erc20#IERC20Metadata).
+The following interface represents the full ABI of the Contracts for Cairo [ERC20Component](/contracts-cairo/3.x/api/erc20#ERC20Component).
+The interface includes the [IERC20](/contracts-cairo/3.x/api/erc20#IERC20) standard interface as well as the optional [IERC20Metadata](/contracts-cairo/3.x/api/erc20#IERC20Metadata).
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.
diff --git a/content/contracts-cairo/alpha/erc4626.mdx b/content/contracts-cairo/3.x/erc4626.mdx
similarity index 97%
rename from content/contracts-cairo/alpha/erc4626.mdx
rename to content/contracts-cairo/3.x/erc4626.mdx
index bcacf612..b56ba562 100644
--- a/content/contracts-cairo/alpha/erc4626.mdx
+++ b/content/contracts-cairo/3.x/erc4626.mdx
@@ -174,13 +174,13 @@ $\delta = 6$, $a_0 = 1$, $a_1 = 10^5$
### Custom behavior: Adding fees to the vault
In ERC4626 vaults, fees can be captured during deposit/mint and/or withdraw/redeem operations. It is essential to remain
-compliant with the ERC4626 requirements regarding the preview functions. Fees are calculated through the [FeeConfigTrait](/contracts-cairo/alpha/api/erc20#ERC4626Component-FeeConfigTrait)
+compliant with the ERC4626 requirements regarding the preview functions. Fees are calculated through the [FeeConfigTrait](/contracts-cairo/3.x/api/erc20#ERC4626Component-FeeConfigTrait)
implementation. By default, the ERC4626 component charges no fees. If this is the desired behavior, you can use the default
[ERC4626DefaultNoFees](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/token/src/erc20/extensions/erc4626/erc4626.cairo#L899) implementation.
Starting from v3.0.0, fees can be charged in either assets or shares. Prior versions only supported fees taken in assets.
-See the updated [FeeConfigTrait](/contracts-cairo/alpha/api/erc20#ERC4626Component-FeeConfigTrait) and implementation examples in [ERC4626 mocks](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo).
+See the updated [FeeConfigTrait](/contracts-cairo/3.x/api/erc20#ERC4626Component-FeeConfigTrait) and implementation examples in [ERC4626 mocks](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo).
For example, if calling `deposit(100, receiver)`, the caller should deposit exactly 100 underlying tokens, including fees, and the receiver should receive a number of shares that matches the value returned by `preview_deposit(100)`.
@@ -379,8 +379,8 @@ pub mod ERC4626Fees {
## Interface
-The following interface represents the full ABI of the Contracts for Cairo [ERC4626Component](/contracts-cairo/alpha/api/erc20#ERC4626Component).
-The full interface includes the [IERC4626](/contracts-cairo/alpha/api/erc20#IERC4626), [IERC20](/contracts-cairo/alpha/api/erc20#IERC20), and [IERC20Metadata](/contracts-cairo/alpha/api/erc20#IERC20Metadata) interfaces.
+The following interface represents the full ABI of the Contracts for Cairo [ERC4626Component](/contracts-cairo/3.x/api/erc20#ERC4626Component).
+The full interface includes the [IERC4626](/contracts-cairo/3.x/api/erc20#IERC4626), [IERC20](/contracts-cairo/3.x/api/erc20#IERC20), and [IERC20Metadata](/contracts-cairo/3.x/api/erc20#IERC20Metadata) interfaces.
Note that implementing the IERC20Metadata interface is a requirement of IERC4626.
```rust
diff --git a/content/contracts-cairo/alpha/erc721.mdx b/content/contracts-cairo/3.x/erc721.mdx
similarity index 89%
rename from content/contracts-cairo/alpha/erc721.mdx
rename to content/contracts-cairo/3.x/erc721.mdx
index a2310b39..cf3936f4 100644
--- a/content/contracts-cairo/alpha/erc721.mdx
+++ b/content/contracts-cairo/3.x/erc721.mdx
@@ -2,7 +2,7 @@
title: ERC721
---
-The ERC721 token standard is a specification for [non-fungible tokens](https://docs.openzeppelin.com/contracts/5.x/tokens#different-kinds-of-tokens), or more colloquially: NFTs.
+The ERC721 token standard is a specification for [non-fungible tokens](https://docs.openzeppelin.com/contracts/3.x/tokens#different-kinds-of-tokens), or more colloquially: NFTs.
`token::erc721::ERC721Component` provides an approximation of [EIP-721](https://eips.ethereum.org/EIPS/eip-721) in Cairo for Starknet.
## Usage
@@ -61,8 +61,8 @@ mod MyNFT {
## Interface
-The following interface represents the full ABI of the Contracts for Cairo [ERC721Component](/contracts-cairo/alpha/api/erc721#ERC721Component).
-The interface includes the [IERC721](/contracts-cairo/alpha/api/erc721#IERC721) standard interface and the optional [IERC721Metadata](/contracts-cairo/alpha/api/erc721#IERC721Metadata) interface.
+The following interface represents the full ABI of the Contracts for Cairo [ERC721Component](/contracts-cairo/3.x/api/erc721#ERC721Component).
+The interface includes the [IERC721](/contracts-cairo/3.x/api/erc721#IERC721) standard interface and the optional [IERC721Metadata](/contracts-cairo/3.x/api/erc721#IERC721Metadata) interface.
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.
@@ -126,7 +126,7 @@ The design for `SRC5` is similar to OpenZeppelin’s [ERC165Storage](https://doc
## Token transfers
-This library includes [transfer_from](/contracts-cairo/alpha/api/erc721#IERC721-transfer_from) and [safe_transfer_from](/contracts-cairo/alpha/api/erc721#IERC721-safe_transfer_from) to transfer NFTs.
+This library includes [transfer_from](/contracts-cairo/3.x/api/erc721#IERC721-transfer_from) and [safe_transfer_from](/contracts-cairo/3.x/api/erc721#IERC721-safe_transfer_from) to transfer NFTs.
If using `transfer_from`, **the caller is responsible to confirm that the recipient is capable of receiving NFTs or else they may be permanently lost.**
The `safe_transfer_from` method mitigates this risk by querying the recipient contract’s interface support.
@@ -153,8 +153,8 @@ pub trait IERC721Receiver {
}
```
-Implementing the `IERC721Receiver` interface exposes the [on_erc721_received](/contracts-cairo/alpha/api/erc721#IERC721Receiver-on_erc721_received) method.
-When safe methods such as [safe_transfer_from](/contracts-cairo/alpha/api/erc721#IERC721-safe_transfer_from) and [safe_mint](/contracts-cairo/alpha/api/erc721#ERC721-safe_mint) are called, they invoke the recipient contract’s `on_erc721_received` method which **must** return the [IERC721Receiver interface ID](/contracts-cairo/alpha/api/erc721#IERC721Receiver).
+Implementing the `IERC721Receiver` interface exposes the [on_erc721_received](/contracts-cairo/3.x/api/erc721#IERC721Receiver-on_erc721_received) method.
+When safe methods such as [safe_transfer_from](/contracts-cairo/3.x/api/erc721#IERC721-safe_transfer_from) and [safe_mint](/contracts-cairo/3.x/api/erc721#ERC721-safe_mint) are called, they invoke the recipient contract’s `on_erc721_received` method which **must** return the [IERC721Receiver interface ID](/contracts-cairo/3.x/api/erc721#IERC721Receiver).
Otherwise, the transaction will fail.
@@ -209,5 +209,5 @@ mod MyTokenReceiver {
## Storing ERC721 URIs
Token URIs were previously stored as single field elements prior to Cairo v0.2.5.
-ERC721Component now stores only the base URI as a `ByteArray` and the full token URI is returned as the `ByteArray` concatenation of the base URI and the token ID through the [token_uri](/contracts-cairo/alpha/api/erc721#IERC721Metadata-token_uri) method.
+ERC721Component now stores only the base URI as a `ByteArray` and the full token URI is returned as the `ByteArray` concatenation of the base URI and the token ID through the [token_uri](/contracts-cairo/3.x/api/erc721#IERC721Metadata-token_uri) method.
This design mirrors OpenZeppelin’s default [Solidity implementation](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/932fddf69a699a9a80fd2396fd1a2ab91cdda123/contracts/token/ERC721/ERC721.sol#L85-L93) for ERC721.
diff --git a/content/contracts-cairo/alpha/finance.mdx b/content/contracts-cairo/3.x/finance.mdx
similarity index 76%
rename from content/contracts-cairo/alpha/finance.mdx
rename to content/contracts-cairo/3.x/finance.mdx
index 124efeb6..aa717f9e 100644
--- a/content/contracts-cairo/alpha/finance.mdx
+++ b/content/contracts-cairo/3.x/finance.mdx
@@ -6,8 +6,8 @@ This module includes primitives for financial systems.
## Vesting component
-The [VestingComponent](/contracts-cairo/alpha/api/finance#VestingComponent) manages the gradual release of ERC-20 tokens to a designated beneficiary based on a predefined vesting schedule.
-The implementing contract must implement the [OwnableComponent](/contracts-cairo/alpha/api/access#OwnableComponent), where the contract owner is regarded as the vesting beneficiary.
+The [VestingComponent](/contracts-cairo/3.x/api/finance#VestingComponent) manages the gradual release of ERC-20 tokens to a designated beneficiary based on a predefined vesting schedule.
+The implementing contract must implement the [OwnableComponent](/contracts-cairo/3.x/api/access#OwnableComponent), where the contract owner is regarded as the vesting beneficiary.
This structure allows ownership rights of both the contract and the vested tokens to be assigned and transferred.
@@ -22,26 +22,26 @@ for a beneficiary until a specified date.
### Vesting schedule
-The [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) trait defines the logic for calculating the vested amount based on a given timestamp. This
-logic is not part of the [VestingComponent](/contracts-cairo/alpha/api/finance#VestingComponent), so any contract implementing the [VestingComponent](/contracts-cairo/alpha/api/finance#VestingComponent) must provide its own
-implementation of the [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) trait.
+The [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) trait defines the logic for calculating the vested amount based on a given timestamp. This
+logic is not part of the [VestingComponent](/contracts-cairo/3.x/api/finance#VestingComponent), so any contract implementing the [VestingComponent](/contracts-cairo/3.x/api/finance#VestingComponent) must provide its own
+implementation of the [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) trait.
-There’s a ready-made implementation of the [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) trait available named [LinearVestingSchedule](/contracts-cairo/alpha/api/finance#LinearVestingSchedule).
+There’s a ready-made implementation of the [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) trait available named [LinearVestingSchedule](/contracts-cairo/3.x/api/finance#LinearVestingSchedule).
It incorporates a cliff period by returning 0 vested amount until the cliff ends. After the cliff, the vested amount
is calculated as directly proportional to the time elapsed since the beginning of the vesting schedule.
### Usage
-The contract must integrate [VestingComponent](/contracts-cairo/alpha/api/finance#VestingComponent) and [OwnableComponent](/contracts-cairo/alpha/api/access#OwnableComponent) as dependencies. The contract’s constructor
+The contract must integrate [VestingComponent](/contracts-cairo/3.x/api/finance#VestingComponent) and [OwnableComponent](/contracts-cairo/3.x/api/access#OwnableComponent) as dependencies. The contract’s constructor
should initialize both components. Core vesting parameters, such as `beneficiary`, `start`, `duration`
and `cliff_duration`, are passed as arguments to the constructor and set at the time of deployment.
-The implementing contract must provide an implementation of the [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) trait. This can be achieved either by importing
-a ready-made [LinearVestingSchedule](/contracts-cairo/alpha/api/finance#LinearVestingSchedule) implementation or by defining a custom one.
+The implementing contract must provide an implementation of the [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) trait. This can be achieved either by importing
+a ready-made [LinearVestingSchedule](/contracts-cairo/3.x/api/finance#LinearVestingSchedule) implementation or by defining a custom one.
-Here’s an example of a simple vesting wallet contract with a [LinearVestingSchedule](/contracts-cairo/alpha/api/finance#LinearVestingSchedule), where the vested amount
+Here’s an example of a simple vesting wallet contract with a [LinearVestingSchedule](/contracts-cairo/3.x/api/finance#LinearVestingSchedule), where the vested amount
is calculated as being directly proportional to the time elapsed since the start of the vesting period.
```rust
@@ -93,19 +93,19 @@ mod LinearVestingWallet {
}
```
-A vesting schedule will often follow a custom formula. In such cases, the [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) trait is useful.
+A vesting schedule will often follow a custom formula. In such cases, the [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) trait is useful.
To support a custom vesting schedule, the contract must provide an implementation of the
-[calculate_vested_amount](/contracts-cairo/alpha/api/finance#VestingComponent-calculate_vested_amount) function based on the desired formula.
+[calculate_vested_amount](/contracts-cairo/3.x/api/finance#VestingComponent-calculate_vested_amount) function based on the desired formula.
-When using a custom [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) implementation, the [LinearVestingSchedule](/contracts-cairo/alpha/api/finance#LinearVestingSchedule) must be excluded from the imports.
+When using a custom [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) implementation, the [LinearVestingSchedule](/contracts-cairo/3.x/api/finance#LinearVestingSchedule) must be excluded from the imports.
If there are additional parameters required for calculations, which are stored in the contract’s storage, you can access them using `self.get_contract()`.
-Here’s an example of a vesting wallet contract with a custom [VestingSchedule](/contracts-cairo/alpha/api/finance#VestingComponent-Vesting-Schedule) implementation, where tokens
+Here’s an example of a vesting wallet contract with a custom [VestingSchedule](/contracts-cairo/3.x/api/finance#VestingComponent-Vesting-Schedule) implementation, where tokens
are vested in a number of steps.
```rust
diff --git a/content/contracts-cairo/alpha/governance/governor.mdx b/content/contracts-cairo/3.x/governance/governor.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/governance/governor.mdx
rename to content/contracts-cairo/3.x/governance/governor.mdx
diff --git a/content/contracts-cairo/alpha/governance/multisig.mdx b/content/contracts-cairo/3.x/governance/multisig.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/governance/multisig.mdx
rename to content/contracts-cairo/3.x/governance/multisig.mdx
diff --git a/content/contracts-cairo/alpha/governance/timelock.mdx b/content/contracts-cairo/3.x/governance/timelock.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/governance/timelock.mdx
rename to content/contracts-cairo/3.x/governance/timelock.mdx
diff --git a/content/contracts-cairo/alpha/governance/votes.mdx b/content/contracts-cairo/3.x/governance/votes.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/governance/votes.mdx
rename to content/contracts-cairo/3.x/governance/votes.mdx
diff --git a/content/contracts-cairo/alpha/guides/deploy-udc.mdx b/content/contracts-cairo/3.x/guides/deploy-udc.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/guides/deploy-udc.mdx
rename to content/contracts-cairo/3.x/guides/deploy-udc.mdx
diff --git a/content/contracts-cairo/alpha/guides/deployment.mdx b/content/contracts-cairo/3.x/guides/deployment.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/guides/deployment.mdx
rename to content/contracts-cairo/3.x/guides/deployment.mdx
diff --git a/content/contracts-cairo/alpha/guides/erc20-permit.mdx b/content/contracts-cairo/3.x/guides/erc20-permit.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/guides/erc20-permit.mdx
rename to content/contracts-cairo/3.x/guides/erc20-permit.mdx
diff --git a/content/contracts-cairo/alpha/guides/erc20-supply.mdx b/content/contracts-cairo/3.x/guides/erc20-supply.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/guides/erc20-supply.mdx
rename to content/contracts-cairo/3.x/guides/erc20-supply.mdx
diff --git a/content/contracts-cairo/alpha/guides/interfaces-and-dispatchers.mdx b/content/contracts-cairo/3.x/guides/interfaces-and-dispatchers.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/guides/interfaces-and-dispatchers.mdx
rename to content/contracts-cairo/3.x/guides/interfaces-and-dispatchers.mdx
diff --git a/content/contracts-cairo/alpha/guides/snip12.mdx b/content/contracts-cairo/3.x/guides/snip12.mdx
similarity index 96%
rename from content/contracts-cairo/alpha/guides/snip12.mdx
rename to content/contracts-cairo/3.x/guides/snip12.mdx
index a86aae6b..d92926a9 100644
--- a/content/contracts-cairo/alpha/guides/snip12.mdx
+++ b/content/contracts-cairo/3.x/guides/snip12.mdx
@@ -9,7 +9,7 @@ is then to ensure that the received message was indeed signed by the expected si
OpenZeppelin Contracts for Cairo provides a set of utilities to make the implementation of this standard
as easy as possible, and in this guide we will walk you through the process of generating the hashes of typed messages
-using these utilities for on-chain signature verification. For that, let’s build an example with a custom [ERC20](/contracts-cairo/alpha/api/erc20#ERC20) contract
+using these utilities for on-chain signature verification. For that, let’s build an example with a custom [ERC20](/contracts-cairo/3.x/api/erc20#ERC20) contract
adding an extra `transfer_with_signature` method.
@@ -18,7 +18,7 @@ This is an educational example, and it is not intended to be used in production
## CustomERC20
-Let’s start with a basic ERC20 contract leveraging the [ERC20Component](/contracts-cairo/alpha/api/erc20#ERC20Component), and let’s add the new function.
+Let’s start with a basic ERC20 contract leveraging the [ERC20Component](/contracts-cairo/3.x/api/erc20#ERC20Component), and let’s add the new function.
Note that some declarations are omitted for brevity. The full example will be available at the end of the guide.
```rust
@@ -229,8 +229,8 @@ The expected parameter for the `get_message_hash` function is the address of acc
Finally, the full implementation of the `CustomERC20` contract looks like this:
-We are using the [`ISRC6Dispatcher`](/contracts-cairo/alpha/api/account#ISRC6) to verify the signature,
-and the [`NoncesComponent`](/contracts-cairo/alpha/api/utilities#NoncesComponent) to handle nonces to prevent replay attacks.
+We are using the [`ISRC6Dispatcher`](/contracts-cairo/3.x/api/account#ISRC6) to verify the signature,
+and the [`NoncesComponent`](/contracts-cairo/3.x/api/utilities#NoncesComponent) to handle nonces to prevent replay attacks.
```rust
diff --git a/content/contracts-cairo/alpha/index.mdx b/content/contracts-cairo/3.x/index.mdx
similarity index 91%
rename from content/contracts-cairo/alpha/index.mdx
rename to content/contracts-cairo/3.x/index.mdx
index 9c768d64..5e82cb51 100644
--- a/content/contracts-cairo/alpha/index.mdx
+++ b/content/contracts-cairo/3.x/index.mdx
@@ -8,8 +8,8 @@ title: Contracts for Cairo
**A library for secure smart contract development** written in Cairo for [Starknet][starknet]. This library consists of a set of
-[reusable components](/contracts-cairo/alpha/components) to build custom smart contracts, as well as ready-to-deploy [presets](/contracts-cairo/alpha/presets). You can also
-find other [utilities](/contracts-cairo/alpha/api/utilities) including [interfaces and dispatchers](/contracts-cairo/alpha/interfaces) and [test utilities](/contracts-cairo/alpha/api/testing)
+[reusable components](/contracts-cairo/3.x/components) to build custom smart contracts, as well as ready-to-deploy [presets](/contracts-cairo/3.x/presets). You can also
+find other [utilities](/contracts-cairo/3.x/api/utilities) including [interfaces and dispatchers](/contracts-cairo/3.x/interfaces) and [test utilities](/contracts-cairo/3.x/api/testing)
that facilitate testing with Starknet Foundry.
@@ -104,7 +104,7 @@ openzeppelin_utils = "{{openzeppelin_utils_version}}"
## Basic usage
-This is how it looks to build an ERC20 contract using the [ERC20 component](/contracts-cairo/alpha/erc20).
+This is how it looks to build an ERC20 contract using the [ERC20 component](/contracts-cairo/3.x/erc20).
Copy the code into `src/lib.cairo`.
```rust
diff --git a/content/contracts-cairo/alpha/interfaces.mdx b/content/contracts-cairo/3.x/interfaces.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/interfaces.mdx
rename to content/contracts-cairo/3.x/interfaces.mdx
diff --git a/content/contracts-cairo/alpha/introspection.mdx b/content/contracts-cairo/3.x/introspection.mdx
similarity index 97%
rename from content/contracts-cairo/alpha/introspection.mdx
rename to content/contracts-cairo/3.x/introspection.mdx
index 09fd89b4..03bc547f 100644
--- a/content/contracts-cairo/alpha/introspection.mdx
+++ b/content/contracts-cairo/3.x/introspection.mdx
@@ -16,7 +16,7 @@ which can be used by others to query if a given interface is supported.
### Usage
-To expose this functionality, the contract must implement the [SRC5Component](/contracts-cairo/alpha/api/introspection#SRC5Component), which defines the `supports_interface` function.
+To expose this functionality, the contract must implement the [SRC5Component](/contracts-cairo/3.x/api/introspection#SRC5Component), which defines the `supports_interface` function.
Here is an example contract:
```rust
diff --git a/content/contracts-cairo/alpha/macros.mdx b/content/contracts-cairo/3.x/macros.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/macros.mdx
rename to content/contracts-cairo/3.x/macros.mdx
diff --git a/content/contracts-cairo/alpha/macros/type_hash.mdx b/content/contracts-cairo/3.x/macros/type_hash.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/macros/type_hash.mdx
rename to content/contracts-cairo/3.x/macros/type_hash.mdx
diff --git a/content/contracts-cairo/alpha/macros/with_components.mdx b/content/contracts-cairo/3.x/macros/with_components.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/macros/with_components.mdx
rename to content/contracts-cairo/3.x/macros/with_components.mdx
diff --git a/content/contracts-cairo/alpha/presets.mdx b/content/contracts-cairo/3.x/presets.mdx
similarity index 85%
rename from content/contracts-cairo/alpha/presets.mdx
rename to content/contracts-cairo/3.x/presets.mdx
index 5511457f..c4b02116 100644
--- a/content/contracts-cairo/alpha/presets.mdx
+++ b/content/contracts-cairo/3.x/presets.mdx
@@ -25,13 +25,13 @@ Before version 2.x, class hashes were computed using the `scarb --dev` profile.
| Name | Sierra Class Hash |
| --- | --- |
-| [`AccountUpgradeable`](/contracts-cairo/alpha/api/account#AccountUpgradeable) | `{{AccountUpgradeableClassHash}}` |
-| [`ERC20Upgradeable`](/contracts-cairo/alpha/api/erc20#ERC20Upgradeable) | `{{ERC20UpgradeableClassHash}}` |
-| [`ERC721Upgradeable`](/contracts-cairo/alpha/api/erc721#ERC721Upgradeable) | `{{ERC721UpgradeableClassHash}}` |
-| [`ERC1155Upgradeable`](/contracts-cairo/alpha/api/erc1155#ERC1155Upgradeable) | `{{ERC1155UpgradeableClassHash}}` |
-| [`EthAccountUpgradeable`](/contracts-cairo/alpha/api/account#EthAccountUpgradeable) | `{{EthAccountUpgradeableClassHash}}` |
-| [`UniversalDeployer`](/contracts-cairo/alpha/api/udc#UniversalDeployer) | `{{UniversalDeployerClassHash}}` |
-| [`VestingWallet`](/contracts-cairo/alpha/api/finance#VestingWallet) | `{{VestingWalletClassHash}}` |
+| [`AccountUpgradeable`](/contracts-cairo/3.x/api/account#AccountUpgradeable) | `{{AccountUpgradeableClassHash}}` |
+| [`ERC20Upgradeable`](/contracts-cairo/3.x/api/erc20#ERC20Upgradeable) | `{{ERC20UpgradeableClassHash}}` |
+| [`ERC721Upgradeable`](/contracts-cairo/3.x/api/erc721#ERC721Upgradeable) | `{{ERC721UpgradeableClassHash}}` |
+| [`ERC1155Upgradeable`](/contracts-cairo/3.x/api/erc1155#ERC1155Upgradeable) | `{{ERC1155UpgradeableClassHash}}` |
+| [`EthAccountUpgradeable`](/contracts-cairo/3.x/api/account#EthAccountUpgradeable) | `{{EthAccountUpgradeableClassHash}}` |
+| [`UniversalDeployer`](/contracts-cairo/3.x/api/udc#UniversalDeployer) | `{{UniversalDeployerClassHash}}` |
+| [`VestingWallet`](/contracts-cairo/3.x/api/finance#VestingWallet) | `{{VestingWalletClassHash}}` |
[starkli](https://book.starkli.rs/introduction) class-hash command can be used to compute the class hash from a Sierra artifact.
diff --git a/content/contracts-cairo/alpha/security.mdx b/content/contracts-cairo/3.x/security.mdx
similarity index 86%
rename from content/contracts-cairo/alpha/security.mdx
rename to content/contracts-cairo/3.x/security.mdx
index 13c32d96..4b314eb7 100644
--- a/content/contracts-cairo/alpha/security.mdx
+++ b/content/contracts-cairo/3.x/security.mdx
@@ -10,7 +10,7 @@ Expect these modules to evolve.
## Initializable
-The [Initializable](/contracts-cairo/alpha/api/security#InitializableComponent) component provides a simple mechanism that mimics
+The [Initializable](/contracts-cairo/3.x/api/security#InitializableComponent) component provides a simple mechanism that mimics
the functionality of a constructor.
More specifically, it enables logic to be performed once and only once which is useful to set up a contract’s initial state when a constructor cannot be used, for example when there are circular dependencies at construction time.
@@ -68,16 +68,16 @@ pub trait InitializableABI {
## Pausable
-The [Pausable](/contracts-cairo/alpha/api/security#PausableComponent) component allows contracts to implement an emergency stop mechanism.
+The [Pausable](/contracts-cairo/3.x/api/security#PausableComponent) component allows contracts to implement an emergency stop mechanism.
This can be useful for scenarios such as preventing trades until the end of an evaluation period or having an emergency switch to freeze all transactions in the event of a large bug.
To become pausable, the contract should include `pause` and `unpause` functions (which should be protected).
-For methods that should be available only when paused or not, insert calls to `[assert_paused](/contracts-cairo/alpha/api/security#PausableComponent-assert_paused)` and `[assert_not_paused](/contracts-cairo/alpha/api/security#PausableComponent-assert_not_paused)`
+For methods that should be available only when paused or not, insert calls to `[assert_paused](/contracts-cairo/3.x/api/security#PausableComponent-assert_paused)` and `[assert_not_paused](/contracts-cairo/3.x/api/security#PausableComponent-assert_not_paused)`
respectively.
### Usage
-For example (using the [Ownable](/contracts-cairo/alpha/api/access#OwnableComponent) component for access control):
+For example (using the [Ownable](/contracts-cairo/3.x/api/access#OwnableComponent) component for access control):
```rust
#[starknet::contract]
@@ -164,8 +164,8 @@ A [reentrancy attack](https://gus-tavo-guim.medium.com/reentrancy-attack-on-smar
### Usage
-Since Cairo does not support modifiers like Solidity, the [ReentrancyGuard](/contracts-cairo/alpha/api/security#ReentrancyGuardComponent)
-component exposes two methods `[start](/contracts-cairo/alpha/api/security#ReentrancyGuardComponent-start)` and `[end](/contracts-cairo/alpha/api/security#ReentrancyGuardComponent-end)` to protect functions against reentrancy attacks.
+Since Cairo does not support modifiers like Solidity, the [ReentrancyGuard](/contracts-cairo/3.x/api/security#ReentrancyGuardComponent)
+component exposes two methods `[start](/contracts-cairo/3.x/api/security#ReentrancyGuardComponent-start)` and `[end](/contracts-cairo/3.x/api/security#ReentrancyGuardComponent-end)` to protect functions against reentrancy attacks.
The protected function must call `start` before the first function statement, and `end` before the return statement, as shown below:
```rust
diff --git a/content/contracts-cairo/alpha/udc.mdx b/content/contracts-cairo/3.x/udc.mdx
similarity index 88%
rename from content/contracts-cairo/alpha/udc.mdx
rename to content/contracts-cairo/3.x/udc.mdx
index dd25f5e8..35110ec7 100644
--- a/content/contracts-cairo/alpha/udc.mdx
+++ b/content/contracts-cairo/3.x/udc.mdx
@@ -4,7 +4,7 @@ title: Universal Deployer Contract
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/alpha/api/udc#IUniversalDeployer-ContractDeployed) event.
+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/3.x/api/udc#IUniversalDeployer-ContractDeployed) event.
For details on the motivation and the decision making process, see the [Universal Deployer Contract proposal](https://community.starknet.io/t/universal-deployer-contract-proposal/1864).
@@ -76,7 +76,7 @@ By making deployments dependent upon the origin address, users can reserve a who
Only the owner of the origin address can deploy to those addresses.
-Achieving this type of deployment necessitates that the origin sets `not_from_zero` to `true` in the [deploy_contract](/contracts-cairo/alpha/api/udc#UniversalDeployer-deploy_contract) call.
+Achieving this type of deployment necessitates that the origin sets `not_from_zero` to `true` in the [deploy_contract](/contracts-cairo/3.x/api/udc#UniversalDeployer-deploy_contract) call.
Under the hood, the function passes a modified salt to the `deploy_syscall`, which is the hash of the origin’s address with the given salt.
To deploy a unique contract address pass:
@@ -104,11 +104,11 @@ See the [previous Universal Deployer API](https://docs.starknet.io/learn/protoco
The latest iteration of the UDC includes some notable changes to the API which include:
-* `deployContract` method is replaced with the snake_case [deploy_contract](/contracts-cairo/alpha/api/udc#UniversalDeployer-deploy_contract).
-* `unique` parameter is replaced with `not_from_zero` in both the `deploy_contract` method and [ContractDeployed](/contracts-cairo/alpha/api/udc#IUniversalDeployer-ContractDeployed) event.
+* `deployContract` method is replaced with the snake_case [deploy_contract](/contracts-cairo/3.x/api/udc#UniversalDeployer-deploy_contract).
+* `unique` parameter is replaced with `not_from_zero` in both the `deploy_contract` method and [ContractDeployed](/contracts-cairo/3.x/api/udc#IUniversalDeployer-ContractDeployed) event.
## Precomputing contract addresses
This library offers utility functions written in Cairo to precompute contract addresses.
-They include the generic [calculate_contract_address_from_deploy_syscall](/contracts-cairo/alpha/api/utilities#deployments-calculate_contract_address_from_deploy_syscall) as well as the UDC-specific [calculate_contract_address_from_udc](/contracts-cairo/alpha/api/utilities#deployments-calculate_contract_address_from_udc).
-Check out the [deployments](/contracts-cairo/alpha/api/utilities#deployments) for more information.
+They include the generic [calculate_contract_address_from_deploy_syscall](/contracts-cairo/3.x/api/utilities#deployments-calculate_contract_address_from_deploy_syscall) as well as the UDC-specific [calculate_contract_address_from_udc](/contracts-cairo/3.x/api/utilities#deployments-calculate_contract_address_from_udc).
+Check out the [deployments](/contracts-cairo/3.x/api/utilities#deployments) for more information.
diff --git a/content/contracts-cairo/alpha/upgrades.mdx b/content/contracts-cairo/3.x/upgrades.mdx
similarity index 98%
rename from content/contracts-cairo/alpha/upgrades.mdx
rename to content/contracts-cairo/3.x/upgrades.mdx
index 811738cd..ab27ab32 100644
--- a/content/contracts-cairo/alpha/upgrades.mdx
+++ b/content/contracts-cairo/3.x/upgrades.mdx
@@ -47,7 +47,7 @@ Upgrades are often very sensitive operations, and some form of access control is
avoid unauthorized upgrades. The [Ownable](./access#ownership-and-ownable) module is used in this example.
-We will be using the following module to implement the [IUpgradeable](/contracts-cairo/alpha/api/upgrades#IUpgradeable) interface described in the API Reference section.
+We will be using the following module to implement the [IUpgradeable](/contracts-cairo/3.x/api/upgrades#IUpgradeable) interface described in the API Reference section.
```rust
diff --git a/content/contracts-cairo/3.x/utils/constants.js b/content/contracts-cairo/3.x/utils/constants.js
new file mode 100644
index 00000000..53c10df7
--- /dev/null
+++ b/content/contracts-cairo/3.x/utils/constants.js
@@ -0,0 +1,21 @@
+export const OPENZEPPELIN_INTERFACES_VERSION = "3.0.0";
+export const OPENZEPPELIN_UTILS_VERSION = "3.0.0";
+export const UMBRELLA_VERSION = "3.0.0";
+export const CLASS_HASH_SCARB_VERSION = "2.13.1";
+
+export const CLASS_HASHES = {
+ AccountUpgradeableClassHash:
+ "0x01d1777db36cdd06dd62cfde77b1b6ae06412af95d57a13dc40ac77b8a702381",
+ ERC20UpgradeableClassHash:
+ "0x0385b75aa04cfee201d2e2de42daf00a839367cfd740e9042766b447d891fea0",
+ ERC721UpgradeableClassHash:
+ "0x0356fbb89f6a6574ff97c4ecc5fe97808785ce0b093c8e864b87a184f48dbd9e",
+ ERC1155UpgradeableClassHash:
+ "0x05a6d419c7a599c9731e8e3a8a710b1f49b4857c65bd4d697a391772f96373c1",
+ EthAccountUpgradeableClassHash:
+ "0x000b5bcc16b8b0d86c24996e22206f6071bb8d7307837a02720f0ce2fa1b3d7c",
+ UniversalDeployerClassHash:
+ "0x01b2df6d8861670d4a8ca4670433b2418d78169c2947f46dc614e69f333745c8",
+ VestingWalletClassHash:
+ "0x00540c7f907539e1a283318fb3da16f1bf9d9e60ad10c20d0557a0185043b08f",
+};
diff --git a/content/contracts-cairo/alpha/utils/replacements.ts b/content/contracts-cairo/3.x/utils/replacements.ts
similarity index 88%
rename from content/contracts-cairo/alpha/utils/replacements.ts
rename to content/contracts-cairo/3.x/utils/replacements.ts
index 32791a2b..1e339982 100644
--- a/content/contracts-cairo/alpha/utils/replacements.ts
+++ b/content/contracts-cairo/3.x/utils/replacements.ts
@@ -1,7 +1,7 @@
import { CLASS_HASHES, CLASS_HASH_SCARB_VERSION, OPENZEPPELIN_INTERFACES_VERSION, OPENZEPPELIN_UTILS_VERSION, UMBRELLA_VERSION } from "./constants";
export const REPLACEMENTS = {
- include: ['**/content/contracts-cairo/alpha/**/*.mdx'],
+ include: ['**/content/contracts-cairo/3.x/**/*.mdx'],
replacements: {
umbrella_version: UMBRELLA_VERSION,
openzeppelin_interfaces_version: OPENZEPPELIN_INTERFACES_VERSION,
diff --git a/content/contracts-cairo/alpha/wizard.mdx b/content/contracts-cairo/3.x/wizard.mdx
similarity index 100%
rename from content/contracts-cairo/alpha/wizard.mdx
rename to content/contracts-cairo/3.x/wizard.mdx
diff --git a/content/contracts-cairo/alpha/utils/constants.js b/content/contracts-cairo/alpha/utils/constants.js
deleted file mode 100644
index d3ef174d..00000000
--- a/content/contracts-cairo/alpha/utils/constants.js
+++ /dev/null
@@ -1,21 +0,0 @@
-export const OPENZEPPELIN_INTERFACES_VERSION = "2.1.0-alpha.0";
-export const OPENZEPPELIN_UTILS_VERSION = "2.1.0-alpha.0";
-export const UMBRELLA_VERSION = "3.0.0-alpha.3";
-export const CLASS_HASH_SCARB_VERSION = "2.12.2";
-
-export const CLASS_HASHES = {
- AccountUpgradeableClassHash:
- "0x072b2479c3bf45bfc2391b0a04bb0fb4806b93a61a8fede391081535cad65038",
- ERC20UpgradeableClassHash:
- "0x0435835a8002b39bf6eb827678b32a75ed3e0bec580ef71a7c29a068d1a96d24",
- ERC721UpgradeableClassHash:
- "0x062212af6bc24e478b5f1c611d2f626270e3ef5825330173afa3e02a0848bcaa",
- ERC1155UpgradeableClassHash:
- "0x01a312230aa2774b3271204bfd41e8633d3b2ab48f10f4b56be1ef17806599c4",
- EthAccountUpgradeableClassHash:
- "0x071fa21092599f6ffdaed5da83961d895668c668a488465251d88606c26a34b7",
- UniversalDeployerClassHash:
- "0x038a75a9c5a0203e5fa94bb181850a4e6a349fc3fcda6a0ccbcaeb5c2f50c7c3",
- VestingWalletClassHash:
- "0x03e7d05eb2325c2e10d219f6b70468aef9e915352ac31521ec2950ebf0e3acb4",
-};
diff --git a/content/contracts-cairo/cairo-replacements.ts b/content/contracts-cairo/cairo-replacements.ts
index c6f03ba3..76952d1a 100644
--- a/content/contracts-cairo/cairo-replacements.ts
+++ b/content/contracts-cairo/cairo-replacements.ts
@@ -1,4 +1,4 @@
-import { REPLACEMENTS as alphaReplacements } from "./alpha/utils/replacements";
import { REPLACEMENTS as twoXReplacements } from "./2.x/utils/replacements";
+import { REPLACEMENTS as threeXReplacements } from "./3.x/utils/replacements";
-export const CAIRO_REPLACEMENTS = [alphaReplacements, twoXReplacements];
+export const CAIRO_REPLACEMENTS = [twoXReplacements, threeXReplacements];
diff --git a/content/contracts-cairo/latest-versions.js b/content/contracts-cairo/latest-versions.js
index ab44c70c..5b25e4f0 100644
--- a/content/contracts-cairo/latest-versions.js
+++ b/content/contracts-cairo/latest-versions.js
@@ -1,4 +1,4 @@
import { UMBRELLA_VERSION as latestAlphaVersion } from "./alpha/utils/constants.js";
-export const latestStable = "2.x";
+export const latestStable = "3.x";
export const latestAlpha = latestAlphaVersion;