diff --git a/crates/spammer/README.md b/crates/spammer/README.md
index bfc2dbf..eaaf802 100644
--- a/crates/spammer/README.md
+++ b/crates/spammer/README.md
@@ -391,7 +391,7 @@ a finalized block.
 The latency tracker records the time between:
 
 1. **Submission**: when the spammer sends the transaction to the RPC endpoint of a node
-2. **Finalization**: the block in which the the transaction was included is known to be finalized, via a RPC subscription
+2. **Finalization**: the block in which the transaction was included is known to be finalized, via a RPC subscription
 observes.
 
 This measures end-to-end transaction latency as experienced by a client.
diff --git a/docs/adr/0004-base-fee-validation.md b/docs/adr/0004-base-fee-validation.md
index 03d55c1..b3f9f05 100644
--- a/docs/adr/0004-base-fee-validation.md
+++ b/docs/adr/0004-base-fee-validation.md
@@ -15,7 +15,7 @@ On Arc, the base fee calculation combines: 1) an EIP-1559-style algorithm, 2)  s
 
 The value of 1) is that it is familiar and well-understood. The value of 2) is to enable rapid adjusting of fee parameters and strictly enforcing block gas limits through governance. The value of 3) is to dampen fee increases against sudden shocks in usage with Arc's fast blocktimes.
 
-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 the the header, computed at the end of the parent's block execution, since it is fully known at that point. 
+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.