diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 872be190d5..56b606f0f1 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -2,14 +2,14 @@
 
 This document addresses how we should create PRs, give and receive reviews. The motivation is to have better code, reduce the time from creation to merge while sharing knowledge and insights that help everyone becoming better developers.
 
-Note that non of this is a hard rule, but suggestions / guidelines. Although everyone is encouraged to stick to this points as much as posible. Use your common sense if some of this do not apply well on a particular PR
+Note that non of this is a hard rule, but suggestions / guidelines. Although everyone is encouraged to stick to this points as much as possible. Use your common sense if some of this do not apply well on a particular PR
 
 ## How to create a good PR
 
 - Follow the template, unless for some reason it doesn't fit the content of the PR
 - Try hard on doing small PRs (> ~400 lines), in general is better to have 2 small PRs rather than a big one
 - Indicate clearly who should review it, ideally 2 team mates
-- Author of the PR is responsible for merging. Never do it until you have the aproval of the specified reviewers unless you have their explicit permision
+- Author of the PR is responsible for merging. Never do it until you have the approval of the specified reviewers unless you have their explicit permission
 - Introduce the purpose of the PR, for example: `Fixes the handle of ...`
 - Give brief context on why this is being done and link it to any relevant issue
 - Feel free to ask to specific team mates to review specific parts of the PR
@@ -40,4 +40,4 @@ Note that non of this is a hard rule, but suggestions / guidelines. Although eve
 This guide is based on the following content:
 
 - https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
-- https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/
\ No newline at end of file
+- https://github.blog/2015-01-21-how-to-write-the-perfect-pull-request/
diff --git a/README.md b/README.md
index 532db28a45..b658c10e87 100644
--- a/README.md
+++ b/README.md
@@ -177,7 +177,7 @@ The State component is the backbone of the node’s data management:
 
 - State Management: Handles all state-related data, including batches, blocks, and transactions.
 - Executor Integration: Communicates with the Executor to process transactions and update the state.
-- StateDB: used for persistance
+- StateDB: used for persistence
 
 ### Pool
 
diff --git a/sequencesender/config.go b/sequencesender/config.go
index a77b495f4c..ba3c9938d2 100644
--- a/sequencesender/config.go
+++ b/sequencesender/config.go
@@ -17,7 +17,7 @@ type Config struct {
 	// SenderAddress defines which private key the eth tx manager needs to use
 	// to sign the L1 txs
 	SenderAddress common.Address
-	// L2Coinbase defines which addess is going to receive the fees
+	// L2Coinbase defines which address is going to receive the fees
 	L2Coinbase common.Address `mapstructure:"L2Coinbase"`
 	// PrivateKey defines all the key store files that are going
 	// to be read in order to provide the private keys to sign the L1 txs