diff --git a/docs/arbos/gas.md b/docs/arbos/gas.md
index 7e79f92eeb..ec7ecee179 100644
--- a/docs/arbos/gas.md
+++ b/docs/arbos/gas.md
@@ -8,6 +8,8 @@ The L1 component is the product of the tx's estimated contribution to its batch'
 
 [The L2 component](arbos.md#l2pricingstate) consists of the traditional fees geth would pay to miners in a vanilla L1 chain, such as the computation and storage charges applying the state transition function entails. ArbOS charges additional fees for executing its L2-specific [precompiles](precompiles.md), whose fees are dynamically priced according to the specific resources used while executing the call.
 
+Calling an Arbitrum node's `eth_estimateGas` RPC returns a value sufficient to cover both the L1 and L2 components of the fee for the current gas price. (See [2-D fees](https://medium.com/offchainlabs/understanding-arbitrum-2-dimensional-fees-fd1d582596c9) for more.)
+
 [drop_l1_link]: https://github.com/OffchainLabs/nitro/blob/2ba6d1aa45abcc46c28f3d4f560691ce5a396af8/arbos/l1pricing/l1pricing.go#L232
 
 ## Tips in L2
diff --git a/docs/faqs/how-fees.md b/docs/faqs/how-fees.md
index 2fdac856d2..056a0f87c1 100644
--- a/docs/faqs/how-fees.md
+++ b/docs/faqs/how-fees.md
@@ -10,4 +10,4 @@ The L2 component covers the cost of operating the L2 chain; it uses Geth for gas
 
 L2 Gas price adjusts responsively to chain congestion, ala EIP 1559.
 
-Calling an Arbitrum node's `eth_estimateGas` returns a value sufficient to cover both the L1 and L2 components of the fee for the current gas price (see [here](https://medium.com/offchainlabs/understanding-arbitrum-2-dimensional-fees-fd1d582596c9) for more.)
+Calling an Arbitrum node's `eth_estimateGas` RPC returns a value sufficient to cover both the L1 and L2 components of the fee for the current gas price; this is the value that, e.g., will appear in users' wallets. (See [2-D fees](https://medium.com/offchainlabs/understanding-arbitrum-2-dimensional-fees-fd1d582596c9) for more.)
diff --git a/docs/why-nitro.md b/docs/why-nitro.md
index 45973a6cc1..130c7ae462 100644
--- a/docs/why-nitro.md
+++ b/docs/why-nitro.md
@@ -36,6 +36,8 @@ Note that supporting calldata compression also requires a more sophisticated mec
 
 The classic AVM achieved a strong degree of EVM compatibility with its ability to handle any EVM opcodes. However, being a distinct VM, the AVM’s internal behavior in some ways diverged with that of the EVM. Most noticeable for smart contract developers was the denomination of “ArbGas”, who’s units didn’t correspond to Ethereum L1 gas; e.g,. a simple transfer takes 21,000 gas on L1 but over 100,000 ArbGas on in the AVM. This meant that contracts that included gas calculation logic that were initially built for L1 had to be modified accordingly to be deployed on L2, and likewise with any client side tooling with similar hardcoded expectations about a chain’s gas. With Nitro, [gas](./arbos/gas.md) on L1 and L2 essentially correspond 1:1.
 
+(Note that transactions have to cover the total cost of both L2 execution and L1 calldata; the value returned by Arbitrum nodes' `eth_estimateGas` RPC — and in turn, the value users will see in their wallets — is calculated to be sufficient to cover this total cost. See [2-D fees](https://medium.com/offchainlabs/understanding-arbitrum-2-dimensional-fees-fd1d582596c9) for more.)
+
 Additionally, node functionality peripheral to execution itself, but still important / expected by much tooling and infrastructure — e.g. support for transaction tracing — is essentially inherited out-of-the-box in Nitro, giving Nitro stronger compatibility with Ethereum not just within its virtual machine, but also with how clients interact with it.
 
 In short, there’s no better way to achieve Ethereum compatibility than to reuse the Ethereum software itself.