Fix spelling and grammar

docs/pages/blog/3074-pitfalls.mdx

@@ -13,7 +13,7 @@ layout: minimal
 
 [EIP-3074](https://eips.ethereum.org/EIPS/eip-3074) has been confirmed for the next Ethereum hardfork (”Pectra”), which is amazing news for the Ethereum community.  For the first time, EOA users will be able to enjoy the benefits of account abstraction (AA) — gas sponsorship, transaction batching, session keys, passkeys, etc.  At ZeroDev, we cannot be more excited to bring these smart account features to EOA users.
 
-At its core, 3074 is a very simple proposal.  Two new opcodes, `AUTH` and `AUTHCALL`, together enable a smart contract (known as an “invoker”) to take over the address of a EOA.  Most of the complexity in enabling the aforementioned AA features is left out of the protocol itself, and left to the application layer (specifically invokers and relayers) to handle.
+At its core, 3074 is a very simple proposal.  Two new opcodes, `AUTH` and `AUTHCALL`, together enable a smart contract (known as an “invoker”) to take over the address of an EOA.  Most of the complexity in enabling the aforementioned AA features is left out of the protocol itself, and left to the application layer (specifically invokers and relayers) to handle.
 
 By leaving complexity out of the spec, however, EIP-3074 opens up many possible paths to account abstraction.  **The danger is that some of these paths may lead to a future of AA that is more centralized and permissioned than any of us intended or desired.**  This blog post explains:
 
@@ -50,7 +50,7 @@ Smart account transactions are particularly challenging for DoS protection, beca
 - It takes more computational resources to validate a transaction, since validation is implemented with smart contracts and therefore can consume significant computational resources.
 - Since the validation contract can read chain state, valid transactions may become invalid as the chain state changes.
 
-As a result, a mempool of nodes that verify smart account transactions are particularly vulnerable to DoS attacks.  The second problem is especially tricky, because if a relayer thinks that a smart account transaction is valid, packages it into a EOA, and submits it on-chain, only to find out that it’s invalid after all, the relayer will have wasted not just computational resources but also gas, which makes the attack particularly economically disruptive.
+As a result, a mempool of nodes that verify smart account transactions are particularly vulnerable to DoS attacks.  The second problem is especially tricky, because if a relayer thinks that a smart account transaction is valid, packages it into an EOA, and submits it on-chain, only to find out that it’s invalid after all, the relayer will have wasted not just computational resources but also gas, which makes the attack particularly economically disruptive.
 
 Since EIP-3074 doesn’t address this problem, the problem must be solved by invokers and relayers.  If it’s not solved, **the default behavior would be for all 3074 relayers to only accept transactions from trusted senders, resulting in fragmented and permissioned mempools, and a low degree of censorship resistance.**
 

docs/pages/sdk/faqs/use-with-gelato.mdx

@@ -1,6 +1,6 @@
 # Using ZeroDev with Gelato
 
-Gelato's has a unique approach to handling transaction fees without the need for an EntryPoint deposit or an on-chain paymaster. Instead, transaction fees are settled post-execution via [1Balance](https://docs.gelato.network/web3-services/relay/subscriptions-and-payments/1balance-and-relay) across all supported networks, ensuring accurate charging of gas consumed without necessitating per-chain user deposits.
+Gelato has a unique approach to handling transaction fees without the need for an EntryPoint deposit or an on-chain paymaster. Instead, transaction fees are settled post-execution via [1Balance](https://docs.gelato.network/web3-services/relay/subscriptions-and-payments/1balance-and-relay) across all supported networks, ensuring accurate charging of gas consumed without necessitating per-chain user deposits.
 
 For a deeper understanding of Gelato's capabilities, refer to [their comprehensive documentation](https://docs.gelato.network/web3-services/account-abstraction/advantages-and-highlights).
 

docs/pages/sdk/getting-started/quickstart-7702.mdx

@@ -1,10 +1,10 @@
 # Quickstart -- EIP-7702
 
-[EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) is an upcoming Ethereum upgrade that will allow for attaching a piece of EVM code to a EOA, effectively turning it into a "dual account" that can function simultaneously as a EOA and a smart account.  You can learn more about EIP-7702 from our blog series [here](/blog/7702-adoption) and [here](/blog/7702-for-dapps).
+[EIP-7702](https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7702.md) is an upcoming Ethereum upgrade that will allow for attaching a piece of EVM code to an EOA, effectively turning it into a "dual account" that can function simultaneously as an EOA and a smart account.  You can learn more about EIP-7702 from our blog series [here](/blog/7702-adoption) and [here](/blog/7702-for-dapps).
 
 In practical terms, this means that EOA users can now enjoy most of the benefits of AA, such as gas sponsorship, transaction batching, session keys, chain abstraction, and more.
 
-In this example, we will upgrade a EOA into a ZeroDev smart account ([Kernel](https://github.com/zerodevapp/kernel)) and send a gasless batched transaction from it.
+In this example, we will upgrade an EOA into a ZeroDev smart account ([Kernel](https://github.com/zerodevapp/kernel)) and send a gasless batched transaction from it.
 
 ## Complete example
 
@@ -36,7 +36,7 @@ Use the ZeroDev RPC on your project page from the dashboard.
 
 ## Upgrade EOA to smart account
 
-To upgrade a EOA to a smart account, you need to sign an "authorization."  You can create this authorization manually and pass it to the ZeroDev SDK, or you can let ZeroDev create this authorization automatically. 
+To upgrade an EOA to a smart account, you need to sign an "authorization."  You can create this authorization manually and pass it to the ZeroDev SDK, or you can let ZeroDev create this authorization automatically. 
 
 ### Automatically create the authorization
 
@@ -132,6 +132,6 @@ await kernelClient.waitForUserOperationReceipt({
 console.log("UserOp completed")
 ```
 
-Congratulations!  You just sent your first gasless, batched transaction using a EOA.  You can see it by looking up your account on [the Sepolia explorer](https://sepolia.etherscan.io/).  Note that you may need to look under "Internal Transactions" because UserOps do not appear as regular transactions.
+Congratulations!  You just sent your first gasless, batched transaction using an EOA.  You can see it by looking up your account on [the Sepolia explorer](https://sepolia.etherscan.io/).  Note that you may need to look under "Internal Transactions" because UserOps do not appear as regular transactions.
 
 Easy, right?  Now try some of the more advanced [examples](https://7702.zerodev.app/) for building with 7702, or explore the rest of the ZeroDev docs!

docs/pages/sdk/permissions/intro.mdx

@@ -72,7 +72,7 @@ Actions are arbitrary functions that the smart account will `delegatecall` to.
 
 Note that actions are NOT to be confused with the calls you actually want to execute.  For example, if you want to interact with Uniswap, that's just the call you want to execute.  "Action" here specifically refers to the execution function by which Uniswap is called.
 
-If that's confusing, just forget about actions.  Mostly commonly you will only be setting up signers and policies, and the `action` will default to Kernel's default `execute()` function, which is enough for most needs.
+If that's confusing, just forget about actions.  Most commonly you will only be setting up signers and policies, and the `action` will default to Kernel's default `execute()` function, which is enough for most needs.
 
 ## Next Steps
 

docs/pages/smart-wallet/permissions/intro.mdx

@@ -72,7 +72,7 @@ Actions are arbitrary functions that the smart account will `delegatecall` to.
 
 Note that actions are NOT to be confused with the calls you actually want to execute.  For example, if you want to interact with Uniswap, that's just the call you want to execute.  "Action" here specifically refers to the execution function by which Uniswap is called.
 
-If that's confusing, just forget about actions.  Mostly commonly you will only be setting up signers and policies, and the `action` will default to Kernel's default `execute()` function, which is enough for most needs.
+If that's confusing, just forget about actions.  Most commonly you will only be setting up signers and policies, and the `action` will default to Kernel's default `execute()` function, which is enough for most needs.
 
 ## Next Steps