Browse Source

Fix typos and inaccuracies in documentation (#5815)

Co-authored-by: Hadrien Croubois <hadrien.croubois@gmail.com>
Torprius 2 months ago
parent
commit
7dcf761dd0

+ 1 - 1
docs/modules/ROOT/pages/access-control.adoc

@@ -123,7 +123,7 @@ There is an additional feature built on top of `AccessControl`: giving the execu
 
 At this point, with both a proposer and an executor assigned, the timelock can perform operations.
 
-An optional next step is for the deployer to renounce its administrative privileges and leave the timelock self-administered. If the deployer decides to do so, all further maintenance, including assigning new proposers/schedulers or changing the timelock duration will have to follow the timelock workflow. This links the governance of the timelock to the governance of contracts attached to the timelock, and enforce a delay on timelock maintenance operations.
+An optional next step is for the deployer to renounce its administrative privileges and leave the timelock self-administered. If the deployer decides to do so, all further maintenance, including assigning new proposers/schedulers or changing the timelock duration will have to follow the timelock workflow. This links the governance of the timelock to the governance of contracts attached to the timelock, and enforces a delay on timelock maintenance operations.
 
 WARNING: If the deployer renounces administrative rights in favour of timelock itself, assigning new proposers or executors will require a timelocked operation. This means that if the accounts in charge of any of these two roles become unavailable, then the entire contract (and any contract it controls) becomes locked indefinitely.
 

+ 4 - 4
docs/modules/ROOT/pages/account-abstraction.adoc

@@ -28,7 +28,7 @@ struct PackedUserOperation {
 
 This process of bundling user operations involves several costs that the bundler must cover, including base transaction fees, calldata serialization, entrypoint execution, and paymaster context costs. To compensate for these expenses, bundlers use the `preVerificationGas` and `gasFees` fields to charge users appropriately.
 
-NOTE: Estimating `preVerificationGas` is not standardized as it varies based on network conditions such as gas prices and the size of the operation bundle.
+NOTE: Estimating `preVerificationGas` is not standardized as it varies based on factors like calldata size, signature complexity, and bundler-specific serialization costs.
 
 TIP: Use xref:api:account.adoc#ERC4337Utils[`ERC4337Utils`] to manipulate the `UserOperation` struct and other ERC-4337 related values.
 
@@ -36,7 +36,7 @@ TIP: Use xref:api:account.adoc#ERC4337Utils[`ERC4337Utils`] to manipulate the `U
 
 Each `UserOperation` is executed through a contract known as the https://etherscan.io/address/0x4337084D9E255Ff0702461CF8895CE9E3b5Ff108#code[`EntryPoint`]. This contract is a singleton deployed across multiple networks at the same address although other custom implementations may be used.
 
-The Entrypoint contracts is considered a trusted entity by the account.
+The Entrypoint contract is considered a trusted entity by the account.
 
 === Bundlers
 
@@ -83,7 +83,7 @@ To build your own factory, see xref:accounts.adoc#accounts_factory[account facto
 
 === Paymaster Contract
 
-A Paymaster is an optional entity that can sponsor gas fees for Accounts, or allow them to pay for those fees in ERC-20 instead of native currency. This abstracts gas away of the user experience in the same way that computational costs of cloud servers are abstracted away from end-users.
+A Paymaster is an optional entity that can sponsor gas fees for Accounts, or allow them to pay for those fees in ERC-20 instead of native currency. This abstracts gas away from the user experience in the same way that computational costs of cloud servers are abstracted away from end-users.
 
 To build your own paymaster, see https://docs.openzeppelin.com/community-contracts/0.0.1/paymasters[paymasters].
 
@@ -95,6 +95,6 @@ To process a bundle of `UserOperations`, bundlers call xref:api:account.adoc#Acc
 
 These rules outline the requirements for operations to be processed by the canonical mempool.
 
-Accounts can access its own storage during the validation phase, they might easily violate ERC-7562 storage access rules in undirect ways. For example, most accounts access their public keys from storage when validating a signature, limiting the ability of having accounts that validate operations for other accounts (e.g. via ERC-1271)
+Accounts can access their own storage during the validation phase, they might easily violate ERC-7562 storage access rules in indirect ways. For example, most accounts access their public keys from storage when validating a signature, limiting the ability of having accounts that validate operations for other accounts (e.g. via ERC-1271)
 
 TIP: Although any Account that breaks such rules may still be processed by a private bundler, developers should keep in mind the centralization tradeoffs of relying on private infrastructure instead of _permissionless_ execution.