build: bump to v0.2.0 alpha.3 (#512)

Getting ready for new alpha release later today --------- Co-authored-by: Daniel Bigos <[email protected]>
OpenZeppelin · Jan 30, 2025 · 43c73ce · 43c73ce
1 parent d142e88
commit 43c73ce
Show file tree

Hide file tree

Showing 24 changed files with 86 additions and 71 deletions.
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -10,11 +10,30 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ### Added
 
+-
+
+### Changed
+
+-
+
+### Changed (Breaking)
+
+-
+
+### Fixed
+
+-
+
+
+## [v0.2.0-alpha.3] - 2025-01-30
+
+### Added
+
+- Optimised implementation of bigintegers `Uint<_>` for finite fields. #495
 - `Erc4626` "Tokenized Vault Standard". #465
 - Implement `mul_div` for `U256`. #465
 - Implement `AddAssignChecked` for `StorageUint`. #474
 - `Erc20FlashMint` extension. #407
-- Optimised implementation of bigintegers `Uint<_>` for finite fields. #495
 
 ### Changed
 
@@ -31,9 +50,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 - Add full support for reentrancy (changed `VestingWallet` signature for some functions). #407
 - `Nonce::use_nonce` panics on exceeding `U256::MAX`. #467
 
-### Fixed
-
--
 
 ## [v0.2.0-alpha.2] - 2024-12-18
 
@@ -58,9 +74,6 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 - Update internal functions of `Erc721` and `Erc721Consecutive` to accept a reference to `Bytes`. #437
 
-### Fixed
-
--
 
 ## [v0.2.0-alpha.1] - 2024-11-15
 

diff --git a/Cargo.lock b/Cargo.lock
diff --git a/Cargo.toml b/Cargo.toml
@@ -63,7 +63,7 @@ authors = ["OpenZeppelin"]
 edition = "2021"
 license = "MIT"
 repository = "https://github.com/OpenZeppelin/rust-contracts-stylus"
-version = "0.2.0-alpha.2"
+version = "0.2.0-alpha.3"
 
 [workspace.lints.rust]
 missing_docs = "warn"
@@ -77,7 +77,9 @@ all = "warn"
 
 [workspace.dependencies]
 # Stylus SDK related
-stylus-sdk = { version = "0.7.0", default-features = false, features = ["mini-alloc"] }
+stylus-sdk = { version = "0.7.0", default-features = false, features = [
+  "mini-alloc",
+] }
 
 alloy = { version = "=0.7.3", features = [
   "contract",

diff --git a/docs/modules/ROOT/pages/access-control.adoc b/docs/modules/ROOT/pages/access-control.adoc
@@ -7,7 +7,7 @@ Access control—that is, "who is allowed to do this thing"—is incredibly impo
 
 The most common and basic form of access control is the concept of _ownership_: there's an account that is the `owner` 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 Stylus provides https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/ownable/struct.Ownable.html[`Ownable`] for implementing ownership in your contracts.
+OpenZeppelin Contracts for Stylus provides https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/ownable/struct.Ownable.html[`Ownable`] for implementing ownership in your contracts.
 
 [source,rust]
 ----
@@ -39,12 +39,12 @@ impl MyContract {
 }
 ----
 
-At deployment, the https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.owner[`owner`] of an `Ownable` contract is set to the provided `initial_owner` parameter.
+At deployment, the https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.owner[`owner`] of an `Ownable` contract is set to the provided `initial_owner` parameter.
 
 Ownable also lets you:
 
-* https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.transfer_ownership[`transfer_ownership`] from the owner account to a new one, and
-* https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.renounce_ownership[`renounce_ownership`] for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.
+* https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.transfer_ownership[`transfer_ownership`] from the owner account to a new one, and
+* https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/ownable/struct.Ownable.html#method.renounce_ownership[`renounce_ownership`] for the owner to relinquish this administrative privilege, a common pattern after an initial stage with centralized administration is over.
 
 WARNING: Removing the owner altogether will mean that administrative tasks that are protected by `only_owner` will no longer be callable!
 
@@ -65,7 +65,7 @@ Most software uses access control systems that are role-based: some users are re
 [[using-access-control]]
 === Using `AccessControl`
 
-OpenZeppelin Contracts provides https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] for implementing role-based access control. Its usage is straightforward: for each role that you want to define,
+OpenZeppelin Contracts provides https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] for implementing role-based access control. Its usage is straightforward: for each role that you want to define,
 you will create a new _role identifier_ that is used to grant, revoke, and check if an account has that role.
 
 Here's a simple example of using `AccessControl` in an xref:erc20.adoc[ERC-20 token] to define a 'minter' role, which allows accounts that have it create new tokens. Note that the example is unassuming of the way you construct your contract.
@@ -97,7 +97,7 @@ impl Example {
 }
 ----
 
-NOTE: Make sure you fully understand how https://docs.rs/openzeppelin-stylus/0.1.1/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] works before using it on your system, or copy-pasting the examples from this guide.
+NOTE: Make sure you fully understand how https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/access/control/struct.AccessControl.html[`AccessControl`] 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`. Indeed, where `AccessControl` shines is in scenarios where granular permissions are required, which can be implemented by defining _multiple_ roles.
 

diff --git a/docs/modules/ROOT/pages/crypto.adoc b/docs/modules/ROOT/pages/crypto.adoc
@@ -8,11 +8,11 @@ Developers can build a Merkle Tree off-chain, which allows for verifying that an
 
 TIP: OpenZeppelin Contracts provides a https://github.com/OpenZeppelin/merkle-tree[JavaScript library] for building trees off-chain and generating proofs.
 
-https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/merkle/struct.Verifier.html[`MerkleProof`] provides:
+https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/merkle/struct.Verifier.html[`MerkleProof`] provides:
 
-* https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify[`verify`] - can prove that some value is part of a https://en.wikipedia.org/wiki/Merkle_tree[Merkle tree].
+* https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify[`verify`] - can prove that some value is part of a https://en.wikipedia.org/wiki/Merkle_tree[Merkle tree].
 
-* https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof[`verify_multi_proof`] - can prove multiple values are part of a Merkle tree.
+* https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof[`verify_multi_proof`] - can prove multiple values are part of a Merkle tree.
 
 [source,rust]
 ----
@@ -22,6 +22,6 @@ pub fn verify(&self, proof: Vec<B256>, root: B256, leaf: B256) -> bool {
 }
 ----
 
-Note that these functions use `keccak256` as the hashing algorithm, but our library also provides generic counterparts: https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_with_builder[`verify_with_builder`] and https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof_with_builder[`verify_multi_proof_with_builder`].
+Note that these functions use `keccak256` as the hashing algorithm, but our library also provides generic counterparts: https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_with_builder[`verify_with_builder`] and https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/merkle/struct.Verifier.html#method.verify_multi_proof_with_builder[`verify_multi_proof_with_builder`].
 
-We also provide an adapter https://docs.rs/openzeppelin-crypto/0.1.1/openzeppelin_crypto/hash/index.html[`hash`] module to use your own hashers in conjunction with them that resembles Rust's standard library's API.
+We also provide an adapter https://docs.rs/openzeppelin-crypto/0.2.0-alpha.3/openzeppelin_crypto/hash/index.html[`hash`] module to use your own hashers in conjunction with them that resembles Rust's standard library's API.
diff --git a/docs/modules/ROOT/pages/erc1155-burnable.adoc b/docs/modules/ROOT/pages/erc1155-burnable.adoc
@@ -6,7 +6,7 @@ own tokens and those that they have been approved to use.
 [[usage]]
 == Usage
 
-In order to make https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/token/erc1155/extensions/burnable/index.html[`ERC-1155 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
+In order to make https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/token/erc1155/extensions/burnable/index.html[`ERC-1155 Burnable`] methods “external” so that other contracts can call them, you need to implement them by yourself for your final contract as follows:
 
 [source,rust]
 ----

diff --git a/docs/modules/ROOT/pages/erc1155-metadata-uri.adoc b/docs/modules/ROOT/pages/erc1155-metadata-uri.adoc
@@ -7,7 +7,7 @@ This is particularly useful for non-fungible tokens (NFTs) where each token is u
 [[usage]]
 == Usage
 
-In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/token/erc1155/extensions/metadata_uri/index.html[Metadata URI] flavour,
+In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/token/erc1155/extensions/metadata_uri/index.html[Metadata URI] flavour,
 you need to add the following code to your contract:
 
 [source,rust]

diff --git a/docs/modules/ROOT/pages/erc1155-pausable.adoc b/docs/modules/ROOT/pages/erc1155-pausable.adoc
@@ -7,7 +7,7 @@ Useful for scenarios such as preventing trades until the end of an evaluation pe
 [[usage]]
 == Usage
 
-In order to make your xref:erc1155.adoc[ERC-1155] token `pausable`, you need to use the https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC1155 token functions as follows:
+In order to make your xref:erc1155.adoc[ERC-1155] token `pausable`, you need to use the https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/utils/pausable/index.html[`Pausable`] contract and apply its mechanisms to ERC1155 token functions as follows:
 
 [source,rust]
 ----

diff --git a/docs/modules/ROOT/pages/erc1155-supply.adoc b/docs/modules/ROOT/pages/erc1155-supply.adoc
@@ -6,7 +6,7 @@ Useful for scenarios where Fungible and Non-fungible tokens have to be clearly i
 [[usage]]
 == Usage
 
-In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/token/erc1155/extensions/supply/index.html[Supply] flavour,
+In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/token/erc1155/extensions/supply/index.html[Supply] flavour,
 you need to reexport all the supply-related functions.
 Make sure to apply the `#[selector(name = "totalSupply")]` attribute to the `total_supply_all` function!
 You need to create the specified contract as follows:

diff --git a/docs/modules/ROOT/pages/erc1155-uri-storage.adoc b/docs/modules/ROOT/pages/erc1155-uri-storage.adoc
@@ -7,8 +7,8 @@ This is particularly useful for non-fungible tokens (NFTs) where each token is u
 [[usage]]
 == Usage
 
-In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/token/erc1155/extensions/uri_storage/index.html[URI Storage] flavour,
-your token should also use https://docs.rs/openzeppelin-stylus/0.2.0-alpha.2/openzeppelin_stylus/token/erc1155/extensions/metadata_uri/index.html[`ERC-1155 Metadata URI`] extension to provide additional URI metadata for each token.
+In order to make an xref:erc1155.adoc[ERC-1155] token with https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/token/erc1155/extensions/uri_storage/index.html[URI Storage] flavour,
+your token should also use https://docs.rs/openzeppelin-stylus/0.2.0-alpha.3/openzeppelin_stylus/token/erc1155/extensions/metadata_uri/index.html[`ERC-1155 Metadata URI`] extension to provide additional URI metadata for each token.
 You need to create a specified contract as follows:
 
 [source,rust]