From 3136414e1711c028809756fee0846aca8ce881ec Mon Sep 17 00:00:00 2001 From: immrsd Date: Fri, 19 Dec 2025 21:55:30 +0300 Subject: [PATCH 1/4] Clarify Governor voting start --- content/contracts-cairo/3.x/api/governance.mdx | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/content/contracts-cairo/3.x/api/governance.mdx b/content/contracts-cairo/3.x/api/governance.mdx index e5d5bbe1..d843a6c4 100644 --- a/content/contracts-cairo/3.x/api/governance.mdx +++ b/content/contracts-cairo/3.x/api/governance.mdx @@ -1674,6 +1674,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. @@ -1688,6 +1689,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 +1704,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 +1722,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 +1740,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. From ea646cd7c78ebb30845bdbb1b0659faef89c1b2a Mon Sep 17 00:00:00 2001 From: immrsd Date: Fri, 19 Dec 2025 22:09:53 +0300 Subject: [PATCH 2/4] Clarify EIP-6372 clock bounds --- content/contracts-cairo/3.x/api/governance.mdx | 4 ++++ content/contracts-cairo/3.x/api/utilities.mdx | 3 +++ 2 files changed, 7 insertions(+) diff --git a/content/contracts-cairo/3.x/api/governance.mdx b/content/contracts-cairo/3.x/api/governance.mdx index d843a6c4..7379a017 100644 --- a/content/contracts-cairo/3.x/api/governance.mdx +++ b/content/contracts-cairo/3.x/api/governance.mdx @@ -185,6 +185,10 @@ 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. + +NOTE: 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). Date: Fri, 19 Dec 2025 22:21:31 +0300 Subject: [PATCH 3/4] Add note regarding ERC4626 fees mechanics --- content/contracts-cairo/3.x/api/erc20.mdx | 2 ++ content/contracts-cairo/3.x/api/governance.mdx | 4 +--- content/contracts-cairo/3.x/api/utilities.mdx | 3 +-- 3 files changed, 4 insertions(+), 5 deletions(-) diff --git a/content/contracts-cairo/3.x/api/erc20.mdx b/content/contracts-cairo/3.x/api/erc20.mdx index c7d28f93..99418bfc 100644 --- a/content/contracts-cairo/3.x/api/erc20.mdx +++ b/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. diff --git a/content/contracts-cairo/3.x/api/governance.mdx b/content/contracts-cairo/3.x/api/governance.mdx index 7379a017..6cf6664e 100644 --- a/content/contracts-cairo/3.x/api/governance.mdx +++ b/content/contracts-cairo/3.x/api/governance.mdx @@ -186,9 +186,7 @@ Delay between when a proposal is created and when the vote starts. The unit this This can be increased to leave time for users to buy voting power, or delegate it, before the voting of a proposal starts. -NOTE: 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). +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). Date: Tue, 23 Dec 2025 19:50:39 +0300 Subject: [PATCH 4/4] Update docs to support AccessControlDefaultAdminRules fixes --- content/contracts-cairo/3.x/api/access.mdx | 34 ++++++++++++++++++++-- 1 file changed, 31 insertions(+), 3 deletions(-) diff --git a/content/contracts-cairo/3.x/api/access.mdx b/content/contracts-cairo/3.x/api/access.mdx index 002a41fb..5cfacba1 100644 --- a/content/contracts-cairo/3.x/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. + + +