diff --git a/docs/adr/0003-governance-configuration-and-validation.md b/docs/adr/0003-governance-configuration-and-validation.md
index 53ca965..391841b 100644
--- a/docs/adr/0003-governance-configuration-and-validation.md
+++ b/docs/adr/0003-governance-configuration-and-validation.md
@@ -13,7 +13,7 @@
 
 Arc's block parameters — gas limit, base fee parameters, and reward beneficiary — are configured via the `ProtocolConfig` governance smart contract (`0x3600000000000000000000000000000000000001`). The proposer reads these values when building blocks, and other full nodes accept the resulting headers with minimal verification.
 
-Three governance-controlled values are dervied from `ProtocolConfig` values and end up in block headers:
+Three governance-controlled values are derived from `ProtocolConfig` values and end up in block headers:
 
 | Value | Header Field | Current Validation |
 |-------|--------------|--------------------|
@@ -21,7 +21,7 @@ Three governance-controlled values are dervied from `ProtocolConfig` values and
 | Base fee | `base_fee_per_gas` (child), `extra_data` (parent) | Parent extra_data → child base_fee check, but silently skipped if extra_data is malformed |
 | Reward beneficiary | `beneficiary` | None — proposer can set any address |
 
-This design has several gaps, mainly around validation, intentionally ommitted until this time. This ADR focuses on the `gasLimit` in particular.
+This design has several gaps, mainly around validation, intentionally omitted until this time. This ADR focuses on the `gasLimit` in particular.
 
 ### Gap 1: No consensus-level gas limit validation
 
diff --git a/docs/adr/0004-base-fee-validation.md b/docs/adr/0004-base-fee-validation.md
index 7438c50..086bd78 100644
--- a/docs/adr/0004-base-fee-validation.md
+++ b/docs/adr/0004-base-fee-validation.md
@@ -17,7 +17,7 @@ The value of 1) is that it is familiar and well-understood. The value of 2) is t
 
 The combination of these makes it challenging for integrators to precisely understand the next block base fee as the calculation is more involved. To address this, Arc includes the next block base fee in the header, computed at the end of the parent's block execution, since it is fully known at that point. 
 
-Currently, the implementation has several gaps in validation. This ADR, similar to ADR-003, seeks to document solutions to these gaps.
+Currently, the implementation has several gaps in validation. This ADR, similar to ADR-0003, seeks to document solutions to these gaps.
 
 ### Gap 1: No validation of the base fee computation
 
diff --git a/docs/running-an-arc-node.md b/docs/running-an-arc-node.md
index 93f04f9..21d87d3 100644
--- a/docs/running-an-arc-node.md
+++ b/docs/running-an-arc-node.md
@@ -697,7 +697,7 @@ Check out [reth system requirements](https://reth.rs/run/system-requirements/) f
 
 **Note**: during periods of sustained high load, such as during startup or extended sync if the node is far behind, the execution layer memory may surge on some hardware. This should not be an issue if running with the suggested System Requirements. However, if you do observe this, you can enable backpressure to throttle the pace of execution according to the speed of disk writes, which will constrain memory growth.
 
-To enable this, the `reth_` namespace should enabled on the **execution layer**:
+To enable this, the `reth_` namespace should be enabled on the **execution layer**:
 
 ```sh
 --http.api eth,net,web3,txpool,trace,debug,reth