fix: minor typo and throttling description updates

protocol/minimum-base-fee.md

@@ -76,7 +76,7 @@ Priority fee auctions occur when blocks are near the gas limit or when the base
 
 It can also be argued that **scaled** rollups will run well below their gas target in typical conditions, which makes the "gas target" more of a "congestion threshold." Ethereum's base fees are _congestion_ fees, and scaled rollups should rarely be congested: their maximum capacity should be much higher than typical usage. A minimum base fee would be charged in the vast majority of cases, and higher fees would only be charged when the rollup needs to discourage transactions near its capacity. In this scenario, we would need to think of congestion often starting from base fees that are the lowest the chain will allow. Today, that's 1 wei, which takes far too long to adjust to the market prices that are needed to prevent first-price auctions using priority fees.
 
-When the base fee is at or near its minimum value, it can only increase as fast as the `BASE_FEE_MAX_CHANGE_DENOMINATOR` of EIP 1559 allows. Ethereum has this value set to `8`. The maximum the base fee can increase in one block is `(ELASTICITY_MULTIPLIER - 1) / BASE_FEE_MAX_CHANGE_DENOMINATOR`, which is `(2 - 1) / 8 = 1/8` or 12.5%. That produces a doubling time of 5.9 blocks at 12 seconds each, or 71 seconds. On OP Mainnet, the denominator is `250`, which produces a maximum increase per block of 0.4% and a doubling time of 17.7 blocks at 2 seconds each, or 35be seconds. On Base, the denominator is `50`, which produces a maximum increase per block of 2% and a doubling time of 35 blocks at 2 seconds each, or 70 seconds. Base's elasticity was recently changed from `2` to `3`, which gives a maximum increase per block of 4% and a doubling time of 17.7 blocks at 2 seconds each, or 35 seconds.
+When the base fee is at or near its minimum value, it can only increase as fast as the `BASE_FEE_MAX_CHANGE_DENOMINATOR` of EIP 1559 allows. Ethereum has this value set to `8`. The maximum the base fee can increase in one block is `(ELASTICITY_MULTIPLIER - 1) / BASE_FEE_MAX_CHANGE_DENOMINATOR`, which is `(2 - 1) / 8 = 1/8` or 12.5%. That produces a doubling time of 5.9 blocks at 12 seconds each, or 71 seconds. On OP Mainnet, the denominator is `250`, which produces a maximum increase per block of 0.4% and a doubling time of 17.7 blocks at 2 seconds each, or 35 seconds. On Base, the denominator is `50`, which produces a maximum increase per block of 2% and a doubling time of 35 blocks at 2 seconds each, or 70 seconds. Base's elasticity was recently changed from `2` to `3`, which gives a maximum increase per block of 4% and a doubling time of 17.7 blocks at 2 seconds each, or 35 seconds.
 
 The current prevailing base fee on Base today is slightly below 0.001 gwei. It takes 411 blocks (13.7 minutes) for the base fee to increase from 1 wei to 0.001 gwei if every block is completely full at the gas limit. (In practice, we see 70% full blocks in these scenarios, so the fees take even longer to increase.) If we could configure a minimum base fee of 0.0001 gwei, we could speed up the fee adjustment (and the corresponding end of the priority fee auction) to 59 blocks, or a little under two minutes. We could even eliminate the priority fee auctions that occur while the chain is adjusting from the minimum to the typical market fee price by setting the minimum to that price to begin with. [Arbitrum One sets a minimum of 0.01 gwei](https://docs.arbitrum.io/how-arbitrum-works/gas-fees#child-chain-gas-pricing). At recent ETH prices around $2500, any of these three minimum base fees (which correspond to `2**20` through `2**24`) would be much less than one cent for a USDC transfer (about 40,500 gas). As ETH prices change, rollup operators will want to adjust the minimum base fee accordingly.
 
@@ -100,7 +100,7 @@ We expect this change to have little impact on applications. Applications estima
 
 * **Hard-code a minimum base fee** (like [EIP 7762](https://eips.ethereum.org/EIPS/eip-7762)). This is the simplest solution, but it doesn't give the chain operator any flexibility to adjust the minimum base fee. Establishing a Superchain-wide consensus on a minimum base fee seems difficult, especially if the value will have to wait for the next fork to be changed.
 * **Link the minimum base fee to an outside price signal** (like [EIP 7918](https://eips.ethereum.org/EIPS/eip-7918)). This approach avoids choosing a magic number for the minimum base fee and has more elegant economics: the fee doesn't drop when we have a good signal that reducing the base fee wouldn't increase gas usage. The downside is that it's harder to reason about the right values to use in the formula, which makes it hard to build a consensus around. A configurable minimum base fee gives us an option that L1 doesn't have: it allows rollup operators to change the minimum base fee as needed to ensure the fee market is working properly.
-* **Do nothing**. We expect to make batcher sequencer throttling unnecessary by repricing calldata correctly, but setting a minimum base fee still gives us two big wins: we can protect the fee market from long periods of first-price auctions in a generalized way, and we can make sure OP Stack is prepared for scaled rollups that persistently operate below their gas target.
+* **Do nothing**. We expect to make batcher sequencer throttling occur less often by repricing calldata correctly, but setting a minimum base fee still gives us two big wins: we can protect the fee market from long periods of first-price auctions in a generalized way, and we can make sure OP Stack is prepared for scaled rollups that persistently operate below their gas target.
 
 # Risks & Uncertainties