Merge pull request #108 from OpenZeppelin/feat/cairo-support-v3.0.0-audit-fixes-2

Cairo: support v3.0.0 audit fixes

Author: immrsd

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.
 
+<Callout type='warn'>
 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).
+</Callout>
+
+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.
+</APIItem>
+
+<APIItem
+    functionSignature="maximum_default_admin_transfer_delay() → u64"
+    id="IAccessControlDefaultAdminRules-maximum_default_admin_transfer_delay"
+    kind="external"
+>
+Maximum time in seconds for a `default_admin` transfer delay.
+
+<Callout type='warn'>
+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.
+</Callout>
 </APIItem>
 
 #### 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
 </Callout>
 </APIItem>
 
+<APIItem
+    functionSignature="maximum_default_admin_transfer_delay(self: @ContractState) → u64"
+    id="AccessControlDefaultAdminRulesComponent-maximum_default_admin_transfer_delay"
+    kind="external"
+>
+Maximum time in seconds for a `default_admin` transfer delay.
+
+<Callout type='warn'>
+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.
+</Callout>
+</APIItem>
+
 <APIItem
     functionSignature="has_role(self: @ContractState, role: felt252, account: ContractAddress) → bool"
     id="AccessControlDefaultAdminRulesComponent-has_role"

content/contracts-cairo/3.x/api/erc20.mdx

@@ -1139,6 +1139,8 @@ Allows contracts to hook logic into deposit and withdraw transactions. This is w
 
 ERC4626 preview methods must be inclusive of any entry or exit fees. Fees are calculated using [FeeConfigTrait](#ERC4626Component-FeeConfigTrait) methods and automatically adjust the final asset and share amounts. Fee transfers are handled in `ERC4626HooksTrait` methods.
 
+When a vault implements fees on deposits or withdrawals (either in shares or assets), fee transfers must be handled in these hooks by library clients. This creates a non-atomic operation flow consisting of multiple state-changing steps: transferring assets, minting or burning shares, and transferring (or minting) fees. Between these steps, the vault's state is temporarily inconsistent: the asset-to-share conversion rate does not accurately reflect the vault's final state until all steps have completed. Therefore, it is critical to avoid making any external calls (including to the vault contract itself) or querying conversion rates during hook execution.
+
 Special care must be taken when calling external contracts in these hooks. In that case, consider implementing reentrancy protections. For example, in the `withdraw` flow, the `withdraw_limit` is checked **before** the `before_withdraw` hook is invoked. If this hook performs a reentrant call that invokes `withdraw` again, the subsequent check on `withdraw_limit` will be done before the first withdrawal's core logic (e.g., burning shares and transferring assets) is executed. This could lead to bypassing withdrawal constraints or draining funds.
 
 See the [ERC4626AssetsFeesMock](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo#L253) and [ERC4626SharesFeesMock](https://github.com/OpenZeppelin/cairo-contracts/tree/main/packages/test_common/src/mocks/erc4626.cairo#L426) examples.

content/contracts-cairo/3.x/api/governance.mdx

@@ -185,6 +185,8 @@ Whether a proposal needs to be queued before execution. This indicates if the pr
 Delay between when a proposal is created and when the vote starts. The unit this duration is expressed in depends on the clock (see [ERC-6372](https://eips.ethereum.org/EIPS/eip-6372)) this contract uses.
 
 This can be increased to leave time for users to buy voting power, or delegate it, before the voting of a proposal starts.
+
+While this function returns a u64 value, timepoints must fit into u48 according to the EIP-6372 specification. Consequently this value must fit in a u48 (when added to the current clock).
 </APIItem>
 
 <APIItem
@@ -1674,6 +1676,7 @@ Cast a vote.
 Requirements:
 
 - The proposal must be active.
+- The current timepoint must be greater than the proposal's snapshot timepoint.
 
 Emits a [VoteCast](#GovernorComponent-VoteCast) event.
 </APIItem>
@@ -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.
 </APIItem>
@@ -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.

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