base · soheimam · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026 · Jul 23, 2026
diff --git a/docs/apps/index.mdx b/docs/apps/index.mdx
@@ -333,7 +333,7 @@ Base is a fast, low-cost Ethereum L2 built to bring the next billion users oncha
     `useReadContract` caches its result and does not automatically refetch after a write. Use `queryClient.invalidateQueries` with the read's query key to trigger a single refetch when a transaction confirms.
     </Note>
 
-    Surface three states to the user: waiting for wallet signature, waiting for on-chain confirmation, and success.
+    Surface three states to the user: waiting for wallet signature, waiting for onchain confirmation, and success.
 
     <Warning>
     Without `useSwitchChain`, calling `writeContract` while the wallet is on the wrong network causes wagmi to attempt a background chain switch. If the user misses or dismisses the wallet popup, the button stays at "Confirm in Wallet..." indefinitely with no error and no recovery path.

diff --git a/docs/apps/quickstart/build-app.mdx b/docs/apps/quickstart/build-app.mdx
@@ -333,7 +333,7 @@ Base is a fast, low-cost Ethereum L2 built to bring the next billion users oncha
     `useReadContract` caches its result and does not automatically refetch after a write. Use `queryClient.invalidateQueries` with the read's query key to trigger a single refetch when a transaction confirms.
     </Note>
 
-    Surface three states to the user: waiting for wallet signature, waiting for on-chain confirmation, and success.
+    Surface three states to the user: waiting for wallet signature, waiting for onchain confirmation, and success.
 
     <Warning>
     Without `useSwitchChain`, calling `writeContract` while the wallet is on the wrong network causes wagmi to attempt a background chain switch. If the user misses or dismisses the wallet popup, the button stays at "Confirm in Wallet..." indefinitely with no error and no recovery path.

diff --git a/docs/base-account/guides/accept-payments.mdx b/docs/base-account/guides/accept-payments.mdx
@@ -176,7 +176,7 @@ export async function verifyAndFulfillPayment(
     throw new Error('Transaction already processed');
   }
 
-  // 2. Verify the payment status on-chain
+  // 2. Verify the payment status onchain
   const { status, sender, amount, recipient } = await getPaymentStatus({ 
     id: txId,
     testnet

diff --git a/docs/base-account/improve-ux/spend-permissions.mdx b/docs/base-account/improve-ux/spend-permissions.mdx
@@ -23,7 +23,7 @@ If you're using Sub Accounts, learn how Base Account can automatically fund Sub
 
 ### Request a Spend Permission
 
-You create an EIP-712 payload that describes the permission and ask the user to sign it. Store the resulting signature along with the permission data so you can register the permission on-chain later. The SDK helper below handles construction and signing for you.
+You create an EIP-712 payload that describes the permission and ask the user to sign it. Store the resulting signature along with the permission data so you can register the permission onchain later. The SDK helper below handles construction and signing for you.
 
 | Field Name  | Type      | Description                                                                              |
 | ----------- | --------- | ---------------------------------------------------------------------------------------- |

diff --git a/docs/base-account/reference/base-pay/getOrCreateSubscriptionOwnerWallet.mdx b/docs/base-account/reference/base-pay/getOrCreateSubscriptionOwnerWallet.mdx
@@ -342,7 +342,7 @@ const basicWallet = await base.subscription.getOrCreateSubscriptionOwnerWallet({
 <Note>
 **Wallet Address is Public**
 
-The smart wallet address is public and will be visible on-chain. This is expected and safe - users need to know which address they're granting permissions to.
+The smart wallet address is public and will be visible onchain. This is expected and safe - users need to know which address they're granting permissions to.
 </Note>
 
 ## Related Functions

diff --git a/docs/base-account/reference/core/capabilities/auxiliaryFunds.mdx b/docs/base-account/reference/core/capabilities/auxiliaryFunds.mdx
@@ -1,12 +1,12 @@
 ---
 title: "auxiliaryFunds"
-description: "Indicates wallet access to funds beyond on-chain balance verification"
+description: "Indicates wallet access to funds beyond onchain balance verification"
 ---
 
 Defined in [EIP-5792](https://eips.ethereum.org/EIPS/eip-5792)
 
 <Info>
-The auxiliaryFunds capability allows wallets to indicate they have access to funds beyond what can be directly verified on-chain by the wallet's address. This enables more flexible transaction execution and improved user experiences.
+The auxiliaryFunds capability allows wallets to indicate they have access to funds beyond what can be directly verified onchain by the wallet's address. This enables more flexible transaction execution and improved user experiences.
 </Info>
 
 <Warning>
@@ -28,7 +28,7 @@ The auxiliary funds capability configuration for the specified chain.
 
 <Expandable title="AuxiliaryFunds capability properties">
 <ResponseField name="supported" type="boolean">
-Indicates whether the wallet has access to auxiliary funding sources beyond on-chain balance.
+Indicates whether the wallet has access to auxiliary funding sources beyond onchain balance.
 </ResponseField>
 </Expandable>
 </ResponseField>
@@ -50,7 +50,7 @@ if (auxiliaryFunds?.supported) {
   // Don't block transactions based on visible balance alone
   console.log("Wallet has access to auxiliary funds");
 } else {
-  // Check on-chain balance before allowing transactions
+  // Check onchain balance before allowing transactions
   const balance = await provider.request({
     method: 'eth_getBalance',
     params: [userAddress, 'latest']
@@ -140,7 +140,7 @@ async function checkCanExecuteTransaction(amount: bigint) {
     return true;
   }
 
-  // Check on-chain balance as fallback
+  // Check onchain balance as fallback
   const balance = await provider.request({
     method: 'eth_getBalance', 
     params: [userAddress, 'latest']

diff --git a/docs/base-account/reference/core/capabilities/overview.mdx b/docs/base-account/reference/core/capabilities/overview.mdx
@@ -27,7 +27,7 @@ const baseCapabilities = capabilities["0x2105"]; // Base mainnet chain ID
 | Capability | Method | Description |
 |-----------|---------|-------------|
 | [signInWithEthereum](/base-account/reference/core/capabilities/signInWithEthereum) | `wallet_connect` | SIWE authentication |
-| [auxiliaryFunds](/base-account/reference/core/capabilities/auxiliaryFunds) | `wallet_sendCalls` | Access to funds beyond the visible on-chain balance (currently disabled) |
+| [auxiliaryFunds](/base-account/reference/core/capabilities/auxiliaryFunds) | `wallet_sendCalls` | Access to funds beyond the visible onchain balance (currently disabled) |
 | [atomic](/base-account/reference/core/capabilities/atomic) | `wallet_sendCalls` | Atomic batch transactions |
 | [paymasterService](/base-account/reference/core/capabilities/paymasterService) | `wallet_sendCalls` | Gasless transactions |
 | [flowControl](/base-account/reference/core/capabilities/flowControl) | `wallet_sendCalls` | Flow control |

diff --git a/docs/base-account/reference/core/provider-rpc-methods/wallet_getCapabilities.mdx b/docs/base-account/reference/core/provider-rpc-methods/wallet_getCapabilities.mdx
@@ -27,7 +27,7 @@ Capabilities object for a specific chain (e.g., "0x2105" for Base Mainnet).
 
 <Expandable title="Available capabilities">
 <ResponseField name="auxiliaryFunds" type="object">
-Indicates wallet access to funds beyond on-chain balance verification. This capability is currently disabled.
+Indicates wallet access to funds beyond onchain balance verification. This capability is currently disabled.
 
 <Expandable title="auxiliaryFunds properties">
 <ResponseField name="supported" type="boolean">

diff --git a/docs/base-account/reference/spend-permission-utilities/getPermissionStatus.mdx b/docs/base-account/reference/spend-permission-utilities/getPermissionStatus.mdx
@@ -64,7 +64,7 @@ A promise that resolves to an object containing permission status details.
   When the next allowance period begins. This is calculated as one second after the current period ends.
 </ResponseField>
 <ResponseField name="isRevoked" type="boolean">
-  True if the permission has been revoked on-chain.
+  True if the permission has been revoked onchain.
 </ResponseField>
 <ResponseField name="isExpired" type="boolean">
   True if the current timestamp is past the permission's end time.

diff --git a/docs/base-chain/api-reference/ethereum-json-rpc-api/eth_call.mdx b/docs/base-chain/api-reference/ethereum-json-rpc-api/eth_call.mdx
@@ -4,7 +4,7 @@ sidebarTitle: 'eth_call'
 description: 'Executes a message call without creating a transaction. Use pending to simulate against pre-confirmed state.'
 ---
 
-Executes a message call immediately without broadcasting a transaction to the network. No gas is consumed on-chain. Used to read contract state or simulate calls.
+Executes a message call immediately without broadcasting a transaction to the network. No gas is consumed onchain. Used to read contract state or simulate calls.
 
 <Tip>
 **Flashblocks:** Query `https://mainnet.base.org` with `"pending"` to simulate against the current pre-confirmed block state, updated every ~200ms.

diff --git a/docs/base-chain/api-reference/ethereum-json-rpc-api/eth_getLogs.mdx b/docs/base-chain/api-reference/ethereum-json-rpc-api/eth_getLogs.mdx
@@ -4,7 +4,7 @@ sidebarTitle: 'eth_getLogs'
 description: 'Returns logs matching a filter. Use pending to query logs from pre-confirmed transactions.'
 ---
 
-Returns an array of all logs matching a given filter object. Particularly useful for indexing on-chain events.
+Returns an array of all logs matching a given filter object. Particularly useful for indexing onchain events.
 
 <Warning>
 Queries spanning large block ranges or high-activity contracts can time out or be rejected. Keep `fromBlock`-to-`toBlock` ranges under 2,000 blocks for reliable results. Node providers may enforce their own limits.

diff --git a/docs/base-chain/api-reference/flashblocks-api/flashblocks-api-overview.mdx b/docs/base-chain/api-reference/flashblocks-api/flashblocks-api-overview.mdx
@@ -77,7 +77,7 @@ Contains full block header properties. **Only present in the `index: 0` message*
 <ParamField path="gas_limit" type="string">Maximum gas allowed in this block (hex).</ParamField>
 <ParamField path="timestamp" type="string">Unix timestamp of block creation (hex).</ParamField>
 <ParamField path="base_fee_per_gas" type="string">EIP-1559 base fee per gas (hex).</ParamField>
-<ParamField path="prev_randao" type="string">Previous RANDAO value used for on-chain randomness.</ParamField>
+<ParamField path="prev_randao" type="string">Previous RANDAO value used for onchain randomness.</ParamField>
 <ParamField path="extra_data" type="string">Arbitrary data field set by the sequencer.</ParamField>
 <ParamField path="parent_beacon_block_root" type="string">Root of the parent beacon block (EIP-4788).</ParamField>
 </Card>

diff --git a/docs/base-chain/node-operators/node-providers.mdx b/docs/base-chain/node-operators/node-providers.mdx
@@ -16,7 +16,7 @@ import {HeaderNoToc} from "/snippets/headerNoToc.mdx";
 
 ## 1RPC
 
-[1RPC](https://1rpc.io/) is the first and only on-chain attested privacy preserving RPC that eradicates metadata exposure and leakage when interacting with blockchains. 1RPC offers free and [paid plans](https://www.1rpc.io/#pricing) with additional features and increased request limits.
+[1RPC](https://1rpc.io/) is the first and only onchain attested privacy preserving RPC that eradicates metadata exposure and leakage when interacting with blockchains. 1RPC offers free and [paid plans](https://www.1rpc.io/#pricing) with additional features and increased request limits.
 
 <HeaderNoToc title="Supported Networks"/>
 

diff --git a/docs/base-chain/specs/protocol/batcher.mdx b/docs/base-chain/specs/protocol/batcher.mdx
@@ -51,7 +51,7 @@ Each channel covers a contiguous, non-overlapping range of L2 block numbers. The
 
 The derivation spec constrains how far the L2 timestamp may advance ahead of the L1 timestamp of its origin block. An L2 block's timestamp must not exceed the L1 origin timestamp plus `max_sequencer_drift`. Prior to the Fjord hardfork, `max_sequencer_drift` is a per-chain configuration parameter. From Fjord onward it is fixed at 1800 seconds. When this limit is exceeded, the derivation pipeline will only accept a batch if its transaction list is empty (a deposit-only block). The batcher must therefore not include user transactions in blocks whose timestamp would exceed the drift limit, and must coordinate with the sequencer accordingly.
 
-To prevent the sequencer from outpacing the batcher's L1 submission capacity, the batcher measures its data availability backlog — the total encoded size of L2 blocks that have been sequenced but whose data has not yet been confirmed on L1. When the backlog exceeds a configured threshold, the batcher signals the sequencer to reduce its block production rate. The throttle can be graduated: a modest backlog may request a modest slowdown, while a large backlog may pause block production entirely until the batcher catches up. This feedback mechanism is transparent to the derivation pipeline and is not reflected in any on-chain data.
+To prevent the sequencer from outpacing the batcher's L1 submission capacity, the batcher measures its data availability backlog — the total encoded size of L2 blocks that have been sequenced but whose data has not yet been confirmed on L1. When the backlog exceeds a configured threshold, the batcher signals the sequencer to reduce its block production rate. The throttle can be graduated: a modest backlog may request a modest slowdown, while a large backlog may pause block production entirely until the batcher catches up. This feedback mechanism is transparent to the derivation pipeline and is not reflected in any onchain data.
 
 ## Compression
 
@@ -73,4 +73,4 @@ If a submitted frame's L1 transaction fails to be included, the batcher must res
 
 The Fjord hardfork changes the channel encoding format. Channels opened after Fjord activation must use Brotli compression and prefix the first frame's payload with version byte `0x01`. The protocol limit `max_rlp_bytes_per_channel` increases substantially at Fjord activation, relaxing the channel size constraint. Channels opened before Fjord activation must use the pre-Fjord format for all their frames, regardless of when those frames are posted.
 
-The Holocene hardfork imposes strict ordering requirements at both the frame and batch layers. At the frame layer, frames for a given channel must be delivered to the derivation pipeline contiguously and in order; a non-first frame that is not the immediate successor of the previously seen frame for that channel is dropped immediately, and an incomplete channel is dropped if a new first frame for it arrives before its final frame has been seen. At the batch layer, batches within a channel must be strictly ordered by L2 timestamp with no repeated timestamps; any batch with a timestamp not strictly greater than the previous batch in the same channel causes the channel to be invalidated and all remaining batches in it to be dropped. These rules impose no new on-chain obligations, but they mean the batcher has zero tolerance for frame delivery gaps or reordering after Holocene activation.
+The Holocene hardfork imposes strict ordering requirements at both the frame and batch layers. At the frame layer, frames for a given channel must be delivered to the derivation pipeline contiguously and in order; a non-first frame that is not the immediate successor of the previously seen frame for that channel is dropped immediately, and an incomplete channel is dropped if a new first frame for it arrives before its final frame has been seen. At the batch layer, batches within a channel must be strictly ordered by L2 timestamp with no repeated timestamps; any batch with a timestamp not strictly greater than the previous batch in the same channel causes the channel to be invalidated and all remaining batches in it to be dropped. These rules impose no new onchain obligations, but they mean the batcher has zero tolerance for frame delivery gaps or reordering after Holocene activation.
diff --git a/docs/base-chain/specs/reference/glossary.mdx b/docs/base-chain/specs/reference/glossary.mdx
@@ -784,7 +784,7 @@ proof][fault-proof].
 
 [fault-proof]: glossary#fault-proof
 
-An on-chain _interactive_ proof, performed by [validators][validator], that demonstrates that a [sequencer] provided
+An onchain _interactive_ proof, performed by [validators][validator], that demonstrates that a [sequencer] provided
 erroneous [output roots][l2-output].
 
 ### Time Slot
-Original file line number
+Diff line change
@@ Expand Up / @@ -16,7 +16,7 @@ import {HeaderNoToc} from "/snippets/headerNoToc.mdx"; @@
     ## 1RPC
-    [1RPC](https://1rpc.io/) is the first and only on-chain attested privacy preserving RPC that eradicates metadata exposure and leakage when interacting with blockchains. 1RPC offers free and [paid plans](https://www.1rpc.io/#pricing) with additional features and increased request limits.
+    [1RPC](https://1rpc.io/) is the first and only onchain attested privacy preserving RPC that eradicates metadata exposure and leakage when interacting with blockchains. 1RPC offers free and [paid plans](https://www.1rpc.io/#pricing) with additional features and increased request limits.
     <HeaderNoToc title="Supported Networks"/>
@@ Expand Down @@