build: v0.2.0 (#714)

Author: bidzyyys

CHANGELOG.md

@@ -5,24 +5,45 @@ All notable changes to this project will be documented in this file.
 The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
 and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
-## [Unreleased]
+## [v0.2.0] - 2025-06-20
+
+> **Heads-up:** this is the production release after four pre-releases
+> (`alpha.1-4`, `rc.0`). The items below aggregate the _user-facing_ changes
+> since **v0.1.2**. For the step-by-step evolution, see the individual
+> pre-release sections further down.
 
 ### Added
 
+- **ERC-1155 token** (`Erc1155`, `Burnable`, `MetadataUri`, `Supply`, `UriStorage`).
+- **ERC-4626** “Tokenized Vault Standard” and **ERC-20 Flash Mint** extension.
+- **ERC-2981** on-chain royalties.
+- **ERC-20 Utils**: `SafeErc20`.
+- **Finance**: `VestingWallet`.
+- **Ownership**: `Ownable2Step`.
+- **Token wrappers**: `Erc20Wrapper`, `Erc721Wrapper`.
+- **Cryptography**: Poseidon2 hash, Pedersen hash (Starknet params), Short-Weierstrass Curves.
+- **Math & utils**: optimised `Uint<_>` big-integer ops (`mul_div`, shift-left/right, checked/unchecked add/sub).
+- **Constructors** now supported across all contracts.
+- All events derive `Debug`; contracts implement `MethodError` and `IErc165`.
+
 ### Changed
 
-- Custom Solidity selector names in traits with `#[interface_id]` error out on conflicting function selectors. #702
-- Bump `cargo-stylus` to `v0.6.0`. #683
+- Keccak constants pre-computed at compile-time.
+- Optimisations across contracts and crypto libraries.
 
 ### Changed (Breaking)
 
-- Read-only functions in `IErc4626` now accept `&self`. #698
+- **Stylus SDK** ↑ to **v0.9.0** (`cargo-stylus` ↑ to v0.6.0)
+- Contracts refactored to new inheritance model.
+- Interface IDs now returned by `fn interface_id()`; `IErc165::supports_interface` takes `&self`; `Erc165` struct removed.
+- Public state fields made private.
+- Feature **`std` removed** from libraries.
 
 ### Fixed
 
-- `#[interface_id]` does not skip now `unsafe` keyword for unsafe traits. #705
-- `#[interface_id]` now correctly retains full trait generics. #705
-- `Erc20Wrapper::decimals` matches Solidity implementation. #699
+- Correct ERC-165 IDs for `IErc721Metadata`, `IErc721Enumerable`, etc.
+- `#[interface_id]` macro now propagates super-traits correctly.
+- Edge-cases in Merkle proofs, big-int overflows and re-entrancy bugs resolved.
 
 ## [v0.2.0-rc.0] - 2025-05-22
 

Cargo.lock

@@ -70,7 +70,7 @@ authors = ["OpenZeppelin"]
 edition = "2021"
 license = "MIT"
 repository = "https://github.com/OpenZeppelin/rust-contracts-stylus"
-version = "0.2.0-rc.0"
+version = "0.2.0"
 
 [workspace.lints.rust]
 missing_docs = "warn"
@@ -130,7 +130,7 @@ motsu = "=0.9.1"
 
 # members
 openzeppelin-stylus = { path = "contracts" }
-openzeppelin-stylus-proc = { path = "contracts-proc", version = ">=0.2.1, <=0.2.2" }
+openzeppelin-stylus-proc = { path = "contracts-proc", version = "=0.2.2" }
 openzeppelin-crypto = { path = "lib/crypto" }
 e2e = { path = "lib/e2e" }
 e2e-proc = { path = "lib/e2e-proc" }

Cargo.toml

@@ -21,7 +21,7 @@ line to your `Cargo.toml` (We recommend pinning to a specific version):
 
 ```toml
 [dependencies]
-openzeppelin-stylus = "=0.1.2"
+openzeppelin-stylus = "=0.2.0"
 ```
 
 If you want to use some of our newest features before they are fully stable or audited, you can try the latest alpha version of the library. We release a new alpha version every ~3 weeks.

README.md

@@ -1,5 +1,5 @@
 name: contracts-stylus
 title: Contracts for Stylus
-version: 0.1.1
+version: 0.2.0
 nav:
   - modules/ROOT/nav.adoc

docs/antora.yml

@@ -1,5 +1,11 @@
 * xref:index.adoc[Overview]
 
+* xref:access-control.adoc[Access Control]
+
+* xref:crypto.adoc[Cryptography]
+
+* xref:finance.adoc[Finance]
+
 * xref:tokens.adoc[Tokens]
 ** xref:erc20.adoc[ERC-20]
 *** xref:erc20.adoc#erc20-token-extensions[Extensions]
@@ -8,6 +14,4 @@
 ** xref:erc1155.adoc[ERC-1155]
 *** xref:erc1155.adoc#erc1155-token-extensions[Extensions]
 
-* xref:access-control.adoc[Access Control]
-* xref:crypto.adoc[Cryptography]
 * xref:utilities.adoc[Utilities]

docs/modules/ROOT/nav.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.2.0-rc.0/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/openzeppelin_stylus/access/ownable/struct.Ownable.html[`Ownable`] for implementing ownership in your contracts.
 
 [source,rust]
 ----
@@ -74,12 +74,12 @@ impl IOwnable for MyContract {
 }
 ----
 
-At deployment, the https://docs.rs/openzeppelin-stylus/0.2.0-rc.0/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/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.2.0-rc.0/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-rc.0/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/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/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!
 
@@ -100,7 +100,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.2.0-rc.0/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/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.
@@ -256,7 +256,7 @@ impl IAccessControl for Example {
 }
 ----
 
-NOTE: Make sure you fully understand how https://docs.rs/openzeppelin-stylus/0.2.0-rc.0/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/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.