docs: editorial-review

docs/pages/global-address/index.mdx

@@ -1,19 +1,19 @@
-# Smart Routing Address
+# Smart routing address
 
-**Smart Routing Address** enables users to easily deposit funds to a L2/L3 from any CEXs, fiat onramps, and chains, by simply sending funds to a unique deposit address on any chain.
+**Smart Routing Address** enables users to easily deposit funds to an L2/L3 from any CEXs, fiat on-ramps, and chains, by simply sending funds to a unique deposit address on any chain.
 
-Technically, **Smart Routing Address** is an address that encodes a _cross-chain intent_. **When anyone sends funds to a smart routing address on _any chain_, they are funding the intent and thereby triggering the intent on a _specific destination chain_.** In other words, smart routing address is _source-chain agnostic_, but _target-chain specific_.
+Technically, **Smart Routing Address** is an address that encodes a _cross-chain intent_. **When anyone sends funds to a smart routing address on _any chain_, they are funding the intent and thereby triggering the intent on a _specific destination chain_.** In other words, a smart routing address is _source-chain-agnostic_, but _target-chain-specific_.
 
-## Common Use Cases
+## Common use cases
 
 - Sending funds from CEXs directly to an L2/L3.
-- Using a fiat onramp with a L2/L3, even if the onramp doesn't directly support the L2/L3.
+- Using a fiat on-ramp with an L2/L3, even if the on-ramp doesn't directly support the L2/L3.
 - Depositing into a token vault with funds from another chain.
 - Cross-chain transfers.
 
-## Try Smart Routing Address
+## Try smart routing address
 
-You can try using smart routing address at [the official portal](https://smart-routing-address.zerodev.app/).
+You can use the smart routing address at [the official portal](https://smart-routing-address.zerodev.app/).
 
 Should your users send the wrong tokens to their smart routing address, they can also use the portal to retrieve their funds.
 
@@ -41,15 +41,15 @@ bun add @zerodev/smart-routing-address
 
 ## Usage
 
-Smart routing address has a beautifully simple API: just `createSmartRoutingAddress` and then send funds to it. That's really it.
+The Smart Routing Address has a beautifully simple API: create a Smart Routing Address and then send funds to it. That’s really it.
 
-### Code Example
+### Code example
 
 We recommend that you take a look at [our code example](https://github.com/zerodevapp/smart-routing-address-example) (even better if you try running it) as you follow along the docs.
 
 ### Creating a smart routing address
 
-In the following example, we are going to create a smart routing address that, when receiving funds on any chain, will transfer the funds to a specific address on Base. This is helpful when, for instance, you want to create a deposit address for your user, so that they can send funds to the address on any chain (possibly from a CEX), and then they will receive funds in their wallet on the chain that your app runs on.
+In the following example, we will create a smart routing address that, when receiving funds on any chain, transfers them to a specific address on Base. This is helpful when, for instance, you want to create a deposit address for your user so they can send funds to the address on any chain (possibly from a CEX), and then receive them in their wallet on the chain your app runs on.
 
 First import some types and functions:
 
@@ -113,25 +113,25 @@ const { smartRoutingAddress } = await createSmartRoutingAddress({
 
 The options are:
 
-- `owner` is an address that is authorized to recover funds from the smart routing address, in case the smart routing address fails to execute the target action for whatever reason. Typically you would set this to your user's EOA wallet, but you could also set it to your own address if you want to recover funds for users.
+- `owner`: is an address authorized to recover funds from the smart routing address if the smart routing address fails to execute the target action for any reason. Typically, you would set this to your user’s EOA wallet, but you could also set it to your own address if you want to recover funds for users.
 
-- `destChain` is the chain on which the `actions` are supposed to happen. This is presumably the chain that your app runs on.
+- `destChain`: is the chain on which the `actions` are supposed to happen. This is presumably the chain that your app runs on.
 
-- `srcTokens` is a list of tokens that the smart routing address should be able to receive. Only tokens listed in `srcTokens` will trigger actions on the destination. The other tokens sent to the address will have to be manually recovered by the `owner`.
+- `srcTokens`: is a list of tokens that the smart routing address can receive. Only tokens listed in `srcTokens` will trigger actions on the destination. The other tokens sent to the address will need to be recovered manually by the `owner`.
 
-- `actions` is a map that records which action will be triggered by which token. In the example above, we specified an action that will be triggered when the smart routing address receives `USDC`.
+- `actions`: is a map that records which action will be triggered by which token. In the example above, we specified an action that will be triggered when the smart routing address receives `USDC`.
 
-- `slippage` is the _maximum_ slippage that the user can expect. `slippage` is an integer, where 1 is equal to 0.01% (so 100 would mean 1% slippage). You can skip this param if you are unsure what to set, and the SDK will estimate a reasonable slippage based on your other settings.
+- `slippage`: is the _maximum_ slippage that the user can expect. `slippage` is an integer, where 1 is equal to 0.01% (so 100 would mean 1% slippage). You can skip this parameter if you are unsure what to set, and the SDK will estimate a reasonable slippage based on your other settings.
 
 Once you have created a smart routing address, you can send tokens to it on any of the chains specified in `srcTokens`, and the `actions` will happen on the `destChain`. It's really that simple.
 
-## Fee Sponsorship
+## Fee sponsorship
 
 By default, Smart Routing Address deducts usage fees from the user's transferred tokens. However, as a developer, you can sponsor these fees so your users receive the full amount they deposit.
 
-**Example**: When a user deposits 10 USDC to their smart routing address, they will receive exactly 10 USDC on the destination chain, while your dapp pays the usage fees separately.
+**Example**: When a user deposits 10 `USDC` to their smart routing address, they will receive exactly 10 `USDC` on the destination chain, while your dapp pays the usage fees separately.
 
-### Sponsored Fee Configuration
+### Sponsored fee configuration
 
 To set up fee sponsorship, you must perform two steps:
 
@@ -182,7 +182,7 @@ Only tokens that are **both** configured with the project ID in the code **and**
 ### Notes
 
 - Smart Routing Address integrates with bridges under the hood, so the usage pricing is on top of the underlying bridge fees.
-- Pricing can be negotiated. Feel free to reach out.
+- Pricing is negotiable. Feel free to [reach out](https://zerodev.app/contact).
 
 ## Supported chains
 

docs/pages/index.mdx

@@ -1,29 +1,29 @@
-# ZeroDev Introduction
+# ZeroDev introduction
 
-**ZeroDev is the most powerful smart account solution**, with support for both ERC-4337 and [EIP-7702](/sdk/getting-started/quickstart-7702).
+**ZeroDev is the most powerful smart account solution**, supporting both [ERC-4337](https://eips.ethereum.org/EIPS/eip-4337) and [EIP-7702](/sdk/getting-started/quickstart-7702).
 
 ZeroDev improves Web3 UX by enabling:
 
 - Key abstraction
-    - Login with [passkeys](/sdk/advanced/passkeys) or [social accounts](/sdk/signers/intro).
+    - Log in with [passkeys](/sdk/advanced/passkeys) or [social accounts](/sdk/signers/intro).
     - [Recover user accounts](/sdk/advanced/recovery) if they lose their login.
 
 - Gas abstraction
     - [Sponsor gas](/sdk/core-api/sponsor-gas) for users.
-    - Let users [pay gas with ERC20 tokens](/sdk/core-api/pay-gas-with-erc20s).
+    - Let users [pay for gas with `ERC-20` tokens](/sdk/core-api/pay-gas-with-erc20s).
 
 - Transaction abstraction
-    - [Batch multiple transactions](/sdk/core-api/batch-transactions) into one.  No more tedious approvals.
-    - [Automate transactions](/sdk/permissions/intro) with session keys.  Great for AI agents.
+    - [Batch multiple transactions](/sdk/core-api/batch-transactions) into one—no more tedious approvals.
+    - [Automate transactions](/sdk/permissions/intro) with session keys. Great for AI agents.
 
 - Chain abstraction
     - [Spend tokens on any chain](/sdk/advanced/chain-abstraction), without bridging.
-    - [On/offramp with any exchanges](/smart-routing-address), even on L2s.
+    - [On/off-ramp with any exchanges](/smart-routing-address), even on L2s.
 
-ZeroDev can be used as a standalone embedded smart account, or used alongside WaaS solutions such as Privy and Dynamic.
+ZeroDev can be used as a standalone embedded smart account or used alongside WaaS solutions such as Privy and Dynamic.
 
-ZeroDev is the most trusted solution in AA, powering more than 6 million smart accounts on 50+ networks for 200+ teams.
+ZeroDev is the most trusted solution for AA (account abstraction), powering more than 6 million smart accounts across 50+ networks for 200+ teams.
 
-## Getting Started
+## Getting started
 
 To start coding with ZeroDev, check out [the quickstart](/sdk/getting-started/quickstart) or [the tutorial](/sdk/getting-started/tutorial).

docs/pages/meta-infra/api.mdx

@@ -1,3 +1,3 @@
 # Admin API
 
-ZeroDev infra can be configured through APIs.  [Check out all our APIs here.](https://zerodev-api.readme.io/reference/getaddresbyeoav2)
+ZeroDev infrastructure is configurable through APIs. [Check out all our APIs here.](https://zerodev-api.readme.io/reference/getaddresbyeoav2)

docs/pages/meta-infra/custom-gas-policies.mdx

@@ -1,20 +1,20 @@
-# Custom Gas Policies
+# Custom gas policies
 
 Custom gas policies enable you to tailor your sponsorship criteria using a webhook. This feature allows you to set up a custom policy that calls a URL you provide to determine whether to sponsor a transaction.
 
-## Getting Started
+## Getting started
 
 To utilize custom gas policies, you'll need to configure a webhook endpoint on your server. This endpoint will receive data from ZeroDev and must return a JSON response indicating whether to proceed with the transaction sponsorship.
 
-### Setting up Your Webhook Endpoint
+### Setting up your webhook endpoint
 
 **Endpoint Requirements:**
 
 - Must accept `POST` requests.
 - The `POST` request will include the `userOp`, `projectId`, and `chainId` in the body (see example below).
 - The request must return a `200` status with a JSON body indicating whether to proceed (see example below).
 
-## Configuring Your Custom Policy
+## Configuring your custom policy
 
 Sign in to your ZeroDev dashboard and navigate to the Gas Policies page. At the bottom of the page, you will find the Custom Policy form as shown below.
 
@@ -25,11 +25,11 @@ Sign in to your ZeroDev dashboard and navigate to the Gas Policies page. At the
 Enter the following options:
 
 - **Webhook URL**: The full URL that the ZeroDev policy engine will make a POST request to.
-- **Timeout Settings**: The amount of time the policy engine will wait for a response from your webhook URL. It's important to keep response times low to decrease latency for your end-users.
-- **Policy Pass on Error**: Select this option to always pass the policy when an error occurs or the webhook times out.
+- **Timeout Settings**: The amount of time the policy engine will wait for a response from your webhook URL. It’s important to keep response times low to reduce latency for your end users.
+- **Policy Pass on Error**: Select this option always to pass the policy when an error occurs or the webhook times out.
 - **Enabling the Policy**: Toggle this option when you are ready to enable the policy for your project.
 
-## Webhook Payload
+## Webhook payload
 
 The `POST` request sent to your webhook URL will include the following:
 
@@ -58,11 +58,11 @@ Here is an example request body:
 }
 ```
 
-## Expected Webhook Response
+## Expected webhook response
 
 Your webhook should respond with a `200` status code and a JSON body indicating whether to proceed with the transaction. Additionally, you can specify how the webhook's decision interacts with ZeroDev's internal policy checks using an optional `logicalOperator` field.
 
-### Response Fields:
+### Response fields:
 
 - **`proceed`** (boolean, required): Indicates whether to sponsor the `userOp` (`true`) or not (`false`).
 - **`logicalOperator`** (string, optional): Defines how to combine the webhook's `proceed` value with ZeroDev's policy checks.
@@ -72,9 +72,9 @@ Your webhook should respond with a `200` status code and a JSON body indicating
     - `'or'`: Proceed if either ZeroDev's policy checks or `proceed` is `true`.
   - Default: `'and'` (if the field is omitted).
 
-### Example Webhook Responses:
+### Example webhook responses:
 
-#### Proceed using logical AND (default):
+#### Proceed using logical `AND` (default):
 
 ```json
 {
@@ -84,7 +84,7 @@ Your webhook should respond with a `200` status code and a JSON body indicating
 
 In this case, the transaction will proceed only if both ZeroDev's internal policy checks and the webhook return `true`.
 
-#### Proceed using logical OR:
+#### Proceed using logical `OR`:
 
 ```json
 {
@@ -93,27 +93,31 @@ In this case, the transaction will proceed only if both ZeroDev's internal polic
 }
 ```
 
-With the `logicalOperator` set to `'or'`, the transaction will proceed if either ZeroDev's policy checks or the webhook approve it.
+With the `logicalOperator` set to `'or'`, the transaction will proceed if either ZeroDev’s policy checks or the webhook approves it.
 
-## Behavior of Transaction Approval
+## Behavior of transaction approval
 
-When a transaction is submitted, ZeroDev performs internal policy checks to determine if the transaction meets the predefined criteria (e.g., gas policies, rate limits). The result of these checks is combined with the webhook's `proceed` value based on the `logicalOperator`.
+When a transaction is submitted, ZeroDev performs internal policy checks to determine whether it meets predefined criteria (e.g., gas policies, rate limits). The result of these checks is combined with the webhook's `proceed` value based on the `logicalOperator`.
 
 - **Logical AND (`'and'`):**
 
   The transaction proceeds only if both ZeroDev's policy checks and the webhook approve (`true`).
 
 - **Logical OR (`'or'`):**
 
-  The transaction proceeds if either ZeroDev's policy checks or the webhook approve (`true`).
+  The transaction proceeds if either ZeroDev's policy checks or the webhook approves (`true`).
 
-**Note:** If the `logicalOperator` field is omitted or contains an invalid value, it defaults to `'and'`.
+:::note
 
-## Example Webhook Server
+If the `logicalOperator` field is omitted or contains an invalid value, it defaults to `'and'`.
+
+:::
+
+## Example webhook server
 
 To help you get started with implementing your custom gas policies, we've provided an example webhook server. This server demonstrates how you might receive and handle incoming webhook requests from ZeroDev.
 
-The repository includes a basic server setup using Express.js, which listens for POST requests on a specified route. It logs the incoming data to the console and responds with a JSON object indicating whether to sponsor the transaction.
+The repository includes a basic server setup with Express.js that listens for POST requests on a specified route. It logs incoming data to the console and returns a JSON object indicating whether to sponsor the transaction.
 
 You can find the example server [here](https://github.com/zerodevapp/example-webhook-server/tree/main).
 

docs/pages/meta-infra/gas-policies.mdx

@@ -1,10 +1,10 @@
-# Gas Policies
+# Gas policies
 
-You can configure **gas policies** for ZeroDev paymaster to have fine-grained control over what you sponsor, and how much.
+You can configure **gas policies** for the ZeroDev paymaster to have fine-grained control over what you sponsor and how much you sponsor.
 
-Paymaster policies can be configured through either [the dashboard](https://dashboard.zerodev.app/paymasters) or [the API](/meta-infra/api).
+Paymaster policies configurations are possible through either [the dashboard](https://dashboard.zerodev.app/paymasters) or [the API](/meta-infra/api).
 
-## Policy Types
+## Policy types
 
 There are four types of gas policies on ZeroDev:
 
@@ -13,20 +13,20 @@ There are four types of gas policies on ZeroDev:
 - Wallet policies: policies that apply to specific wallet addresses.
 - [Custom policies](/meta-infra/custom-gas-policies): if none of the policies above meet your needs, you can program totally custom policies via a webhook.
 
-## Rate Limit Types
+## Rate limit types
 
 When you create a new policy, you set up one or more *rate limits*.
 
 There are four types of rate limits:
 
-- Amount: limit by the amount of gas
-- Request: limit by the number of requests
-- Gas Price: limit by the current gas price
-- Amount per txn: limit by the amount of gas per transaction
+- **Amount**: limited by the amount of gas
+- **Request**: limit by the number of requests
+- **Gas Price**: limited by the current gas price
+- **Amount per txn**: limit by the amount of gas per transaction
 
 ## Policy examples
 
-The policies and rate limits are hopefully intuitive, but here are some common examples in case they are helpful.  We will be using Polygon (MATIC) in these examples.
+The policies and rate limits are hopefully intuitive, but here are some common examples in case they are helpful. We will be using Polygon (MATIC) in these examples.
 
 ### Sponsor up to 1 MATIC every hour for the entire project
 
@@ -44,7 +44,7 @@ Here we create a contract policy:
   <img src="/img/gas_policy_example_2.png" width="80%" />
 </p>
 
-### Sponsor transactions for a specific function when gas price is below 50 GWEI
+### Sponsor transactions for a specific function when the gas price is below 50 GWEI
 
 Here we create a contract policy:
 

docs/pages/meta-infra/intro.mdx

@@ -1,27 +1,27 @@
-# Meta AA Infrastructure
+# Meta AA infrastructure
 
-ZeroDev works with major AA infra providers to provide a "meta intrastructure."  Our meta infra proxies traffic to the underlying bundlers and paymasters, ensuring that our users have the highest possible uptime, since traffic can be routed to a different bundler when one goes down.
+ZeroDev works with major AA infra providers to provide a “meta infrastructure.” Our meta infra proxies traffic to the underlying bundlers and paymasters, ensuring that our users have the highest possible uptime, since traffic can be routed to a different bundler when one goes down.
 
-ZeroDev integrates with the following infra provider:
+ZeroDev integrates with the following infra providers:
 
-- [UltraRelay](/sdk/core-api/sponsor-gas#ultrarelay), ZeroDev's own bundler optimized for sponsored transactions
+- [UltraRelay](/sdk/core-api/sponsor-gas#ultrarelay) (ZeroDev’s own bundler is optimized for sponsored transactions)
 - Alchemy
 - Gelato
 - Pimlico
 
-To get started using bundlers & paymasters through ZeroDev:
+To get started using bundlers and paymasters through ZeroDev:
 
 ## Getting a ZeroDev RPC
 
-You will need an RPC to start using bundlers & paymasters through ZeroDev.
+You will need an RPC to start using bundlers and paymasters through ZeroDev.
 
 - Sign up at the ZeroDev dashboard
 - Create a project
-- Copy the RPC from the project page (each network has an RPC).
+- Copy the RPC from the project page (each network has an RPC)
 
-The same RPC can be used as both bundler and paymaster RPCs.
+The same RPC can serve as both a bundler and a paymaster RPC.
 
-[Learn more about bundler & paymaster RPCs here](/meta-infra/rpcs).
+[Learn more about bundler and paymaster RPCs here](/meta-infra/rpcs).
 
 ## Setting up sponsoring policies